Re: [Intel-gfx] [PATCH i-g-t 1/3] igt_kms: Don't assume we have cursor planes if we have primary ones

On 21 November 2016 at 23:32, Lyude wrote: > On certain models of nvidia and AMD GPUs, we can have a primary plane > without any DRM plane for the cursor plane. Check for this so we don't > segfault on non-intel hardware. > > Signed-off-by: Lyude > --- > lib/igt_kms.c | 27 +++---

Re: [Intel-gfx] [PATCH i-g-t 2/3] igt_kms: Change the max number of pipes to 6

On 21 November 2016 at 23:32, Lyude wrote: > Unfortunately the assumption that we only have 6 display pipes available > is specific to Intel, and seems to be breaking igt_display_init() on > both radeon and nouveau since this causes us not to leave enough space > in the igt_display_t struct to hol

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Tidy load failure reporting (rev3)

== Series Details == Series: drm/i915: Tidy load failure reporting (rev3) URL : https://patchwork.freedesktop.org/series/16435/ State : success == Summary == Series 16435v3 drm/i915: Tidy load failure reporting https://patchwork.freedesktop.org/api/1.0/series/16435/revisions/3/mbox/ Test drv_

Re: [Intel-gfx] ✗ Fi.CI.BAT: warning for drm/i915/guc: Drop comment on fwif autogeneration

On 06/12/2016 05:41, Arkadiusz Hiler wrote: On Mon, Dec 05, 2016 at 06:59:01PM +, Patchwork wrote: == Series Details == Series: drm/i915/guc: Drop comment on fwif autogeneration URL : https://patchwork.freedesktop.org/series/16373/ State : warning == Summary == Series 16373v1 drm/i915/

Re: [Intel-gfx] ✗ Fi.CI.BAT: warning for series starting with [1/2] drm/i915: Advertise ppgtt support type in platform definition

On 06/12/2016 17:57, Michel Thierry wrote: On 05/12/16 18:15, Patchwork wrote: == Series Details == Series: series starting with [1/2] drm/i915: Advertise ppgtt support type in platform definition URL : https://patchwork.freedesktop.org/series/16403/ State : warning == Summary == Series 16

[Intel-gfx] [PATCH v3] drm/i915: Tidy load failure reporting

From: Tvrtko Ursulin Several changes here: * Remove unused i915_report_error. * Unexport __i915_printk and rename it to i915_load_error, converting the latter from a macro to a static function. * Use drm_dev_printk instead of open-coding the same. v2: Fix reversed error condition. v3: Rem

Re: [Intel-gfx] [RFC 5/5] drm: Do not log driver prefix in debug messages

Hi, On 06/12/2016 19:49, Gustavo Padovan wrote: Hi Tvrtko, 2016-12-06 Tvrtko Ursulin : From: Tvrtko Ursulin Driver prefix is a bit redundant in debug messages. If we choose not to log it we change debug messages which used to look like this: [i915:edp_panel_off [i915]] Wait for panel pow

[Intel-gfx] [PATCH i-g-t] lib: Use igt_assert_eq in CHECK_RETURN

So that debug logs contain the unexpected value. Signed-off-by: Tomeu Vizoso --- lib/igt_kms.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/lib/igt_kms.c b/lib/igt_kms.c index 989704e14803..1e30ddcc5373 100644 --- a/lib/igt_kms.c +++ b/lib/igt_kms.c @@ -1681,7 +1681,7 @@ s

[Intel-gfx] [PATCH] tools/backlight_helper: #include "config.h"

From: Mike Gilbert --- tools/backlight_helper.c | 4 1 file changed, 4 insertions(+) diff --git a/tools/backlight_helper.c b/tools/backlight_helper.c index a00f0d6bd8a2..aadb8fac92ba 100644 --- a/tools/backlight_helper.c +++ b/tools/backlight_helper.c @@ -1,3 +1,7 @@ +#ifdef HAVE_CONFIG_H

[Intel-gfx] [PATCH i-g-t v10 21/21] tests/sw_sync: Add subtest test_sync_busy_unixsocket

Add subtest test_sync_busy_fork which increments the timeline in a forked child process, where the timeline fd has been sent through a UNIX socket. Signed-off-by: Robert Foss Reviewed-by: Tomeu Vizoso --- tests/sw_sync.c | 103 1 file cha

[Intel-gfx] [PATCH i-g-t v10 19/21] tests/sw_sync: Add subtest test_sync_merge_invalid

Add subtest test_sync_merge_invalid that tests merging invalid fences. Signed-off-by: Robert Foss Reviewed-by: Tomeu Vizoso --- tests/sw_sync.c | 41 + 1 file changed, 41 insertions(+) diff --git a/tests/sw_sync.c b/tests/sw_sync.c index 5bccb053..3c876e

[Intel-gfx] [PATCH i-g-t v10 06/21] tests/sw_sync: Add subtest test_sync_busy

This subtest verifies that waiting on fences works properly. Signed-off-by: Robert Foss Reviewed-by: Eric Engestrom Reviewed-by: Tomeu Vizoso --- tests/sw_sync.c | 51 +++ 1 file changed, 51 insertions(+) diff --git a/tests/sw_sync.c b/tests/sw_

[Intel-gfx] [PATCH i-g-t v10 18/21] tests/sw_sync: Add igt_require check for sw_sync feature

Make sure that this test is skipped if the sw_sync feature is missing from the host system. Signed-off-by: Robert Foss Reviewed-by: Tomeu Vizoso --- lib/sw_sync.c | 1 + tests/sw_sync.c | 3 +++ 2 files changed, 4 insertions(+) diff --git a/lib/sw_sync.c b/lib/sw_sync.c index d4ecc898..61455

[Intel-gfx] [PATCH i-g-t v10 17/21] lib/sw_sync: Add igt_require_sw_sync to enable skipping on no sw_sync support

Add igt_require_sw_sync to provide tests to skip if sw_sync support isn't available on the host machine. Signed-off-by: Robert Foss Reviewed-by: Tomeu Vizoso --- lib/sw_sync.c | 22 ++ lib/sw_sync.h | 1 + 2 files changed, 23 insertions(+) diff --git a/lib/sw_sync.c b/lib/

[Intel-gfx] [PATCH i-g-t v10 15/21] tests/sw_sync: Add subtest test_timeline_closed

This subtest verifies that the fences of a timeline are not signalled when a timelne is closed. Signed-off-by: Robert Foss Reviewed-by: Tomeu Vizoso --- tests/sw_sync.c | 17 + 1 file changed, 17 insertions(+) diff --git a/tests/sw_sync.c b/tests/sw_sync.c index 572efc3b..1de45

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

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 Reviewed-by: Tomeu Vizoso --- tests/sw_sync.c | 67 + 1 file changed, 67 insertio

[Intel-gfx] [PATCH i-g-t v10 20/21] tests/sw_sync: Add subtest test_sync_busy_fork

Add subtest test_sync_busy_fork which increments the timeline in a forked child process. Signed-off-by: Robert Foss Reviewed-by: Tomeu Vizoso --- tests/sw_sync.c | 39 +++ 1 file changed, 39 insertions(+) diff --git a/tests/sw_sync.c b/tests/sw_sync.c index

[Intel-gfx] [PATCH i-g-t v10 16/21] tests/sw_sync: Add subtest test_timeline_closed_signaled

Add subtest test_timeline_closed_signaled that verifies that a signaled fence stays signaled after its timeline has been closed. Signed-off-by: Robert Foss Reviewed-by: Tomeu Vizoso --- tests/sw_sync.c | 18 ++ 1 file changed, 18 insertions(+) diff --git a/tests/sw_sync.c b/tes

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

This subtest verifies merging a fence with itself does not fail. Signed-off-by: Robert Foss Reviewed-by: Eric Engestrom Reviewed-by: Tomeu Vizoso --- tests/sw_sync.c | 27 +++ 1 file changed, 27 insertions(+) diff --git a/tests/sw_sync.c b/tests/sw_sync.c index 7780c9e

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

From: Rafael Antognolli 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 stil

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

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 Reviewed-by: Tomeu Vizoso --- tests/sw_sync.c | 16 1 file changed, 16 insertions(+) diff --git a/tests/sw_sync.c b/tests/sw_sync

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

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 Reviewed-by: Tomeu Vizoso --- tests/sw_sync.c | 66 + 1 file changed, 66 ins

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

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 Reviewed-by: Tomeu Vizoso --- tests/sw_sync.c | 139 1 file ch

[Intel-gfx] [PATCH i-g-t v10 02/21] test/sw_sync: Add sw_sync test

Add initial tests for sw_sync. Signed-off-by: Robert Foss Signed-off-by: Gustavo Padovan Reviewed-by: Eric Engestrom Reviewed-by: Tomeu Vizoso --- tests/Makefile.sources | 1 + tests/sw_sync.c| 51 ++ 2 files changed, 52 insertions(+)

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

This subtests tests that creating fences on negative timelines fail. Signed-off-by: Robert Foss Reviewed-by: Eric Engestrom Reviewed-by: Tomeu Vizoso --- tests/sw_sync.c | 8 1 file changed, 8 insertions(+) diff --git a/tests/sw_sync.c b/tests/sw_sync.c index 3db62cd0..1ec88741 10064

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

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 Reviewed-by: Tomeu Vizoso --- tests/sw_sync.c | 73 +

[Intel-gfx] [PATCH i-g-t v10 00/21] Implement sw_sync test

This series implements the sw_sync test and the lib/sw_sync helper functions for said test. The sw_sync subtests range from very basic tests of the sw_sync functionality, to stress testing and randomized tests. Changes since v1: Added "Reviewed-by: Eric Engestrom " tag lib/sw_sync: - Fixe

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

This subtest verifies that merging two fences works in the simples possible case. Signed-off-by: Robert Foss Reviewed-by: Eric Engestrom Reviewed-by: Tomeu Vizoso --- tests/sw_sync.c | 23 +++ 1 file changed, 23 insertions(+) diff --git a/tests/sw_sync.c b/tests/sw_sync.c

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

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. Signed-off-by: Robert Foss Reviewed-by: Eric Engestr

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

This subtest verifies the access ordering of multiple consumer threads. Signed-off-by: Robert Foss Reviewed-by: Eric Engestrom Reviewed-by: Tomeu Vizoso --- tests/sw_sync.c | 98 + 1 file changed, 98 insertions(+) diff --git a/tests/sw_s

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

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: Gustavo Padovan Reviewed-by: Eric Engestrom Reviewed-by: Tomeu Vizoso --

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Do not reset detect_done flag in intel_dp_detect

== Series Details == Series: drm/i915: Do not reset detect_done flag in intel_dp_detect URL : https://patchwork.freedesktop.org/series/16456/ State : success == Summary == Series 16456v1 drm/i915: Do not reset detect_done flag in intel_dp_detect https://patchwork.freedesktop.org/api/1.0/series

[Intel-gfx] [PATCH] drm/i915: Do not reset detect_done flag in intel_dp_detect

The detect_done flag was introduced in the commit 7d23e3c37bb3fc6952dc84007ee60cb533fd2d5c in order to avoid multiple detects on hotplug where intel_dp_long_pulse() was called from HPD handler as well as in intel_dp_detect. So this detect_done flag was required to make sure intel_dp_detect() did no

Re: [Intel-gfx] [PATCH v2] drm/i915: Tidy load failure reporting

On Tue, Dec 06, 2016 at 07:00:26PM +, Tvrtko Ursulin wrote: > From: Tvrtko Ursulin > > Several changes here: > > * Remove unused i915_report_error. The plan was to start using it for the more prominent errors. (Any and every DRM_ERROR should be considered to be a userfacing error message a

Re: [Intel-gfx] [PATCH] drm/i915: Use DRM_DEV_ERROR in i915_driver_load

On Tue, Dec 06, 2016 at 07:04:13PM +, Tvrtko Ursulin wrote: > From: Tvrtko Ursulin > > Now that it is available we don't have to open code a similar > error message ourselves. > > Signed-off-by: Tvrtko Ursulin Reviewed-by: Chris Wilson -Chris -- Chris Wilson, Intel Open Source Technology

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Use DRM_DEV_ERROR in i915_driver_load

== Series Details == Series: drm/i915: Use DRM_DEV_ERROR in i915_driver_load URL : https://patchwork.freedesktop.org/series/16441/ State : failure == Summary == Series 16441v1 drm/i915: Use DRM_DEV_ERROR in i915_driver_load https://patchwork.freedesktop.org/api/1.0/series/16441/revisions/1/mbo

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Tidy load failure reporting (rev2)

== Series Details == Series: drm/i915: Tidy load failure reporting (rev2) URL : https://patchwork.freedesktop.org/series/16435/ State : success == Summary == Series 16435v2 drm/i915: Tidy load failure reporting https://patchwork.freedesktop.org/api/1.0/series/16435/revisions/2/mbox/ fi-bdw-5

Re: [Intel-gfx] [RFC 5/5] drm: Do not log driver prefix in debug messages

Hi Tvrtko, 2016-12-06 Tvrtko Ursulin : > From: Tvrtko Ursulin > > Driver prefix is a bit redundant in debug messages. If we choose > not to log it we change debug messages which used to look like this: > > [i915:edp_panel_off [i915]] Wait for panel power off time > > to this: > > [edp_pane

[Intel-gfx] ✗ Fi.CI.BAT: failure for DRM logging tidy

== Series Details == Series: DRM logging tidy URL : https://patchwork.freedesktop.org/series/16439/ State : failure == Summary == CC [M] drivers/gpu/drm/i915/intel_renderstate_gen6.o CC [M] drivers/gpu/drm/i915/i915_guc_submission.o CC [M] drivers/gpu/drm/i915/intel_renderstate_gen7.o

[Intel-gfx] [PATCH] drm/i915: Use DRM_DEV_ERROR in i915_driver_load

From: Tvrtko Ursulin Now that it is available we don't have to open code a similar error message ourselves. Signed-off-by: Tvrtko Ursulin --- drivers/gpu/drm/i915/i915_drv.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/

[Intel-gfx] [PATCH v2] drm/i915: Tidy load failure reporting

From: Tvrtko Ursulin Several changes here: * Remove unused i915_report_error. * Unexport __i915_printk and rename it to i915_load_error, converting the latter from a macro to a static function. * Use drm_dev_printk instead of open-coding the same. v2: Fix reversed error condition. Signed

[Intel-gfx] [RFC 5/5] drm: Do not log driver prefix in debug messages

From: Tvrtko Ursulin Driver prefix is a bit redundant in debug messages. If we choose not to log it we change debug messages which used to look like this: [i915:edp_panel_off [i915]] Wait for panel power off time to this: [edp_panel_off [i915]] Wait for panel power off time Signed-off-by: T

[Intel-gfx] [RFC 3/5] drm: Respect driver set DRM_NAME in drm_dev_printk

From: Tvrtko Ursulin Same as the previous patch did for drm_printk, allow for the logging macros to pass in the driver set DRM_NAME. Signed-off-by: Tvrtko Ursulin --- drivers/gpu/drm/drm_drv.c | 14 +++--- drivers/gpu/drm/i915/i915_drv.c | 3 ++- include/drm/drmP.h

[Intel-gfx] [RFC 4/5] drm: Use drm_printk for all logging macros

From: Tvrtko Ursulin Eliminate _DRM_PRINTK macro and use drm_printk for all log levels. This required drm_printk to vary the verbosity level of the logged metadata depending on the log level. Signed-off-by: Tvrtko Ursulin --- drivers/gpu/drm/drm_drv.c | 31 ++- inc

[Intel-gfx] [RFC 1/5] drm/i915: Give our log messages our name

From: Tvrtko Ursulin Define DRM_NAME to i915 so that the log messages we output change from: [drm] RC6 on to: [i915] RC6 on Since I wasn't around in the beginning of DRM I wonder whether that was the intended purpose of DRM_NAME or if it was something else. Today it looks a bit messy with

[Intel-gfx] [RFC 2/5] drm: Respect driver set DRM_NAME in drm_printk

From: Tvrtko Ursulin Instead of logging with the DRM core name, pass in the name explicitly in order to allow individual drivers to have all their log messages prefixed with their own name. For instance i915, instead of: [drm:edp_panel_off [i915]] Wait for panel power off time would now log d

[Intel-gfx] [RFC 0/5] DRM logging tidy

From: Tvrtko Ursulin I wasn't here at the beginnings of DRM so I might have gotten this wrong, however the existance of DRM_NAME suggested to me that the intention was to allow individual drivers to override it and get appropriate prefixes in their log messages. I can't see that any driver is us

[Intel-gfx] ✗ Fi.CI.BAT: warning for drm/i915: Tidy load failure reporting

== Series Details == Series: drm/i915: Tidy load failure reporting URL : https://patchwork.freedesktop.org/series/16435/ State : warning == Summary == Series 16435v1 drm/i915: Tidy load failure reporting https://patchwork.freedesktop.org/api/1.0/series/16435/revisions/1/mbox/ Test drv_module_

Re: [Intel-gfx] ✗ Fi.CI.BAT: warning for series starting with [1/2] drm/i915: Advertise ppgtt support type in platform definition

On 05/12/16 18:15, Patchwork wrote: == Series Details == Series: series starting with [1/2] drm/i915: Advertise ppgtt support type in platform definition URL : https://patchwork.freedesktop.org/series/16403/ State : warning == Summary == Series 16403v1 Series without cover letter https://pa

Re: [Intel-gfx] [PATCH] drm/i915/guc: Drop comment on fwif autogeneration

>-Original Message- >From: Hiler, Arkadiusz >Sent: Monday, December 5, 2016 9:37 PM >To: Srivatsa, Anusha >Cc: intel-gfx@lists.freedesktop.org; Mcgee, Jeff ; >Kamble, Sagar A >Subject: Re: [PATCH] drm/i915/guc: Drop comment on fwif autogeneration > >On Tue, Dec 06, 2016 at 12:59:03AM +0

[Intel-gfx] [PATCH] drm/i915: Tidy load failure reporting

From: Tvrtko Ursulin Several changes here: * Remove unused i915_report_error. * Unexport __i915_printk and rename it to i915_load_error, converting the latter from a macro to a static function. * Use drm_dev_printk instead of open-coding the same. Signed-off-by: Tvrtko Ursulin --- drive

[Intel-gfx] ✗ Fi.CI.BAT: failure for Link Training failure handling by sending Hotplug Uevent (rev2)

== Series Details == Series: Link Training failure handling by sending Hotplug Uevent (rev2) URL : https://patchwork.freedesktop.org/series/16399/ State : failure == Summary == Series 16399v2 Link Training failure handling by sending Hotplug Uevent https://patchwork.freedesktop.org/api/1.0/ser

[Intel-gfx] [PATCH v4 1/4] drm: Add a new connector atomic property for link status

At the time userspace does setcrtc, we've already promised the mode would work. The promise is based on the theoretical capabilities of the link, but it's possible we can't reach this in practice. The DP spec describes how the link should be reduced, but we can't reduce the link below the requireme

Re: [Intel-gfx] [PATCH 1/4] drm: Add a new connector atomic property for link status

On Tue, Dec 06, 2016 at 08:23:05AM +0100, Daniel Vetter wrote: > On Mon, Dec 05, 2016 at 04:27:35PM -0800, Manasi Navare wrote: > > At the time userspace does setcrtc, we've already promised the mode > > would work. The promise is based on the theoretical capabilities of > > the link, but it's poss

Re: [Intel-gfx] [Mesa-dev] [PATCH 00/27] Renderbuffer Decompression (and GBM modifiers)

2016-12-01 20:09 GMT-02:00 Ben Widawsky : > From: Ben Widawsky > > This patch series ultimately adds support within the i965 driver for > Renderbuffer Decompression with GBM. In short, this feature reduces memory > bandwidth by allowing the GPU to work with losslessly compressed data and > having

[Intel-gfx] [PATCH i-g-t v1] tests/kms_ccs: Add test for render compression

Add a few subtests that check that lossless compressed render targets are properly displayed. Also test a few error conditions. Cc: Ville Syrjälä Cc: Ben Widawsky Signed-off-by: Tomeu Vizoso --- Hi, this has been tested with Ville's branch at: https://github.com/vsyrjala/linux/tree/fb_format

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Use memcpy_from_wc for GPU error capture (rev3)

== Series Details == Series: drm/i915: Use memcpy_from_wc for GPU error capture (rev3) URL : https://patchwork.freedesktop.org/series/16323/ State : success == Summary == Series 16323v3 drm/i915: Use memcpy_from_wc for GPU error capture https://patchwork.freedesktop.org/api/1.0/series/16323/re

Re: [Intel-gfx] [PATCH v3] drm/i915: Use memcpy_from_wc for GPU error capture

On 06/12/2016 12:40, Chris Wilson wrote: On all platforms we now always read the contents of buffers via the GTT, i.e. using WC cpu access. Reads are slow, but they can be accelerated with an internal read buffer using sse4.1 (movntqda). This is our i915_memcpy_from_wc() routine which also check

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Use memcpy_from_wc for GPU error capture (rev2)

== Series Details == Series: drm/i915: Use memcpy_from_wc for GPU error capture (rev2) URL : https://patchwork.freedesktop.org/series/16323/ State : failure == Summary == Series 16323v2 drm/i915: Use memcpy_from_wc for GPU error capture https://patchwork.freedesktop.org/api/1.0/series/16323/re

Re: [Intel-gfx] [PATCH] drm: Don't block the kworker waiting for mode_config.lock in output_poll()

On Tue, Dec 06, 2016 at 11:55:14AM +, Eric Engestrom wrote: > On Tuesday, 2016-12-06 11:37:15 +, Chris Wilson wrote: > > If we cannot acquire the mode_config.lock immediately, just back off and > > s/mode_config.lock/mode_config.mutex lock/ ? Fixed > > > queue a new attempt after the pol

[Intel-gfx] [PATCH v3] drm/i915: Use memcpy_from_wc for GPU error capture

On all platforms we now always read the contents of buffers via the GTT, i.e. using WC cpu access. Reads are slow, but they can be accelerated with an internal read buffer using sse4.1 (movntqda). This is our i915_memcpy_from_wc() routine which also checks for sse4.1 support and so we can fallback

Re: [Intel-gfx] [PATCH v2] drm/i915: Use memcpy_from_wc for GPU error capture

On Tue, Dec 06, 2016 at 12:22:03PM +, Chris Wilson wrote: > On all platforms we now always read the contents of buffers via the GTT, > i.e. using WC cpu access. Reads are slow, but they can be accelerated > with an internal read buffer using sse4.1 (movntqda). This is our > i915_memcpy_from_wc(

[Intel-gfx] [PATCH v2] drm/i915: Use memcpy_from_wc for GPU error capture

On all platforms we now always read the contents of buffers via the GTT, i.e. using WC cpu access. Reads are slow, but they can be accelerated with an internal read buffer using sse4.1 (movntqda). This is our i915_memcpy_from_wc() routine which also checks for sse4.1 support and so we can fallback

[Intel-gfx] ✓ Fi.CI.BAT: success for drm: Don't block the kworker waiting for mode_config.lock in output_poll()

== Series Details == Series: drm: Don't block the kworker waiting for mode_config.lock in output_poll() URL : https://patchwork.freedesktop.org/series/16413/ State : success == Summary == Series 16413v1 drm: Don't block the kworker waiting for mode_config.lock in output_poll() https://patchw

Re: [Intel-gfx] [PATCH] drm: Don't block the kworker waiting for mode_config.lock in output_poll()

On Tuesday, 2016-12-06 11:37:15 +, Chris Wilson wrote: > If we cannot acquire the mode_config.lock immediately, just back off and s/mode_config.lock/mode_config.mutex lock/ ? > queue a new attempt after the poll interval. This is mostly to stop the > hung task spam when the system is deadlock

[Intel-gfx] [PATCH] drm: Don't block the kworker waiting for mode_config.lock in output_poll()

If we cannot acquire the mode_config.lock immediately, just back off and queue a new attempt after the poll interval. This is mostly to stop the hung task spam when the system is deadlocked, but it will also lessen the load (in such extreme cases). Signed-off-by: Chris Wilson --- drivers/gpu/drm

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Shrink pipe config checker (rev2)

== Series Details == Series: drm/i915: Shrink pipe config checker (rev2) URL : https://patchwork.freedesktop.org/series/16359/ State : success == Summary == Series 16359v2 drm/i915: Shrink pipe config checker https://patchwork.freedesktop.org/api/1.0/series/16359/revisions/2/mbox/ Test drv_mo

[Intel-gfx] [PATCH v2] drm/i915: Shrink pipe config checker

From: Tvrtko Ursulin Replace INTEL_ERR_OR_DBG_KMS macro with an intel_err_or_dbg_kms function to shrink the code and rodata strings. textdata bss dec hex filename 1271480 418312016 1315327 1411ff i915.ko.0 1265160 418312016 1309007 13f94f i915.ko.2 Total of ~6 K

[Intel-gfx] [PATCH] dim: Try git-merge --ff-only before git-rebase -i when updating branches.

When a branch can be fast-forwarded, try it first before rebasing. This will prevent a whole lot of editor windows opening with 'noop' when running dim ub. Signed-off-by: Maarten Lankhorst --- dim | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/dim b/dim index fa63ae8c8a79

Re: [Intel-gfx] [PATCH 2/2] drm/i915: Keep has_* in alphabetical order

On Mon, Dec 05, 2016 at 05:57:04PM -0800, Michel Thierry wrote: > As it already says in the comment block... Reviewed-by: Michał Winiarski -Michał > Signed-off-by: Michel Thierry > --- > drivers/gpu/drm/i915/i915_drv.h | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) _

Re: [Intel-gfx] [PATCH 1/2] drm/i915: Advertise ppgtt support type in platform definition

On Mon, Dec 05, 2016 at 05:57:03PM -0800, Michel Thierry wrote: > Instead of being hidden in sanitize_enable_ppgtt. > It also seems to be the place to do so nowadays. Reviewed-by: Michał Winiarski -Michał > Signed-off-by: Michel Thierry > --- > drivers/gpu/drm/i915/i915_drv.h | 3 +++ >

Re: [Intel-gfx] [PATCH 15/15] drm/i915: Pass crtc state to vlv_compute_wm_level()

Hey, Op 02-12-16 om 14:07 schreef Ville Syrjälä: > On Thu, Dec 01, 2016 at 03:47:55PM +0100, Maarten Lankhorst wrote: >> Op 28-11-16 om 18:37 schreef ville.syrj...@linux.intel.com: >>> From: Ville Syrjälä >>> >>> Rather than accessing crtc->config in vlv_compute_wm_level() let's >>> pass in the c

Re: [Intel-gfx] [PATCH v2 11/15] drm/i915: Protect DSPARB registers with a spinlock

Op 05-12-16 om 15:13 schreef ville.syrj...@linux.intel.com: > From: Ville Syrjälä > > Each DSPARB register can house bits for two separate pipes, hence > we must protect the registers during reprogramming so that parallel > FIFO reconfigurations happening simultaneosly on multiple pipes won't > co

Re: [Intel-gfx] [alsa-devel] [PATCH v4 0/3] support DP MST audio

On Tue, 06 Dec 2016 08:51:43 +0100, Daniel Vetter wrote: > > On Tue, Dec 6, 2016 at 8:20 AM, Takashi Iwai wrote: > > On Tue, 06 Dec 2016 03:58:21 +0100, > > Yang, Libin wrote: > >> > >> The patchset is based on drm-tip branch in > >> git://anongit.freedesktop.org/drm-tip > > > > I'll review and m