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
> ---
>
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
== 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
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
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
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
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:
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
+++
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 @@
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
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
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 +++
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
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
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
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
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
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
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
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,
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
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
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
---
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 +
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(+)
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
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
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
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
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
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
== 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
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
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
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
== 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
== 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/
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
== 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]
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
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
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
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 +++---
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
---
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
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
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
== 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
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
>-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:
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:
== 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
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
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
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
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
== 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
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
== 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
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
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
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
>
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
== 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()
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
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
== 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
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
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
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
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
>
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
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
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
> >
> >
74 matches
Mail list logo