On 11/27/2017 12:50 PM, Sagar Arun Kamble wrote:
On 11/26/2017 5:50 PM, Chris Wilson wrote:
An interesting discussion regarding "hybrid interrupt polling" for NVMe
came to the conclusion that the ideal busyspin before sleeping
I think hybrid approach suggests sleep (1/2 duration) and then
On 11/26/2017 5:50 PM, Chris Wilson wrote:
An interesting discussion regarding "hybrid interrupt polling" for NVMe
came to the conclusion that the ideal busyspin before sleeping
I think hybrid approach suggests sleep (1/2 duration) and then busyspin (1/2
duration)
(for small I/O size), so th
On 11/24/2017 4:51 PM, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
Will be adding a new per-engine flags shortly so it makes sense
to consolidate.
Signed-off-by: Tvrtko Ursulin
Suggested-by: Chris Wilson
Reviewed-by: Sagar Arun Kamble
I had thought of cmd parser more like a workaround s
> -Original Message-
> From: Latvala, Petri
> Sent: Friday, November 24, 2017 2:58 PM
> To: Srinivas, Vidya
> Cc: intel-gfx@lists.freedesktop.org
> Subject: Re: [Intel-gfx] [PATCH i-g-t] i-g-t: kms_plane_scaling: Enhanced
> scaling tests
>
> On Wed, Nov 22, 2017 at 01:45:04PM +0530, Vid
Do I need to be basing my patches on a different tree than Linus'? In
general, how do people find what tree they should be basing their
patch off of?
On Sun, Nov 26, 2017 at 7:52 PM, Patchwork
wrote:
> == Series Details ==
>
> Series: drm/i915: Avoid enum conversion warning (rev2)
> URL : http
== Series Details ==
Series: drm/i915: Avoid enum conversion warning (rev2)
URL : https://patchwork.freedesktop.org/series/34269/
State : failure
== Summary ==
Applying: drm/i915: Avoid enum conversion warning
Using index info to reconstruct a base tree...
M drivers/gpu/drm/i915/intel_dd
Fixes the following enum conversion warning:
drivers/gpu/drm/i915/intel_ddi.c:1481:30: error: implicit conversion
from enumeration type 'enum port' to different enumeration type 'enum
intel_dpll_id' [-Werror,-Wenum-conversion]
enum intel_dpll_id pll_id = port;
~~
== Series Details ==
Series: drm/i915: Record default HW state in the GPU error state
URL : https://patchwork.freedesktop.org/series/34420/
State : warning
== Summary ==
Test perf:
Subgroup blocking:
fail -> PASS (shard-hsw) fdo#102252
Test drv_module_reload
== Series Details ==
Series: drm/i915: Flush everything on switching to the kernel_context
URL : https://patchwork.freedesktop.org/series/34419/
State : success
== Summary ==
Test drv_selftest:
Subgroup mock_sanitycheck:
dmesg-warn -> PASS (shard-snb) fdo#103717
T
== Series Details ==
Series: drm/i915: Record default HW state in the GPU error state
URL : https://patchwork.freedesktop.org/series/34420/
State : success
== Summary ==
Series 34420v1 drm/i915: Record default HW state in the GPU error state
https://patchwork.freedesktop.org/api/1.0/series/344
== Series Details ==
Series: drm/i915: Mark up Ironlake ips with rpm wakerefs
URL : https://patchwork.freedesktop.org/series/34416/
State : success
== Summary ==
Test gem_eio:
Subgroup in-flight-suspend:
pass -> FAIL (shard-hsw) fdo#103375
Test kms_frontbuff
== Series Details ==
Series: drm/i915: Flush everything on switching to the kernel_context
URL : https://patchwork.freedesktop.org/series/34419/
State : success
== Summary ==
Series 34419v1 drm/i915: Flush everything on switching to the kernel_context
https://patchwork.freedesktop.org/api/1.0/
It may be of interest to both compare the active HW context against the
default (or NULL) context, to see what has been changed and if either are
corrupt.
Signed-off-by: Chris Wilson
Cc: Mika Kuoppala
---
drivers/gpu/drm/i915/i915_drv.h | 1 +
drivers/gpu/drm/i915/i915_gpu_error.c | 23 +
== Series Details ==
Series: series starting with [1/4] lib: avoid < in gtkdoc comments (rev2)
URL : https://patchwork.freedesktop.org/series/34413/
State : warning
== Summary ==
Test kms_frontbuffer_tracking:
Subgroup fbc-1p-offscren-pri-shrfb-draw-blt:
pass -> F
Even though all rendering should have been flushed at the end of the
previous requests, add an extra flush after switching to the
kernel_context. As the switch to the kernel_context is used when idling
the gpu (e.g. suspend), having an extra layer of paranoia to ensure
everything is flushed to memo
== Series Details ==
Series: drm/i915: Mark up Ironlake ips with rpm wakerefs
URL : https://patchwork.freedesktop.org/series/34416/
State : success
== Summary ==
Series 34416v1 drm/i915: Mark up Ironlake ips with rpm wakerefs
https://patchwork.freedesktop.org/api/1.0/series/34416/revisions/1/m
Currently Ironlake operates under the assumption that rpm awake (and its
error checking is disabled). As such, we have missed a few places where we
access registers without taking the rpm wakeref and thus trigger
warnings. intel_ips being one culprit.
As this involved adding a potentially sleeping
== Series Details ==
Series: series starting with [1/4] lib: avoid < in gtkdoc comments (rev2)
URL : https://patchwork.freedesktop.org/series/34413/
State : success
== Summary ==
IGT patchset tested on top of latest successful build
4c57ff468fa4870184b3da56432602f967af intel/pmu: Catch-up
== Series Details ==
Series: series starting with [1/4] lib: avoid < in gtkdoc comments
URL : https://patchwork.freedesktop.org/series/34413/
State : success
== Summary ==
IGT patchset tested on top of latest successful build
4c57ff468fa4870184b3da56432602f967af intel/pmu: Catch-up with i9
Bunch of neat improvements:
- xml generates correctly depend upon the test binaries
- no need to re-run autogen.sh when new chapters/functions get added,
all handed by meson
Still one issue:
- the gtkdoc target doesn't depend upon the custom_target yet, hacked
around using build_by_default:
For reasons entirely not clear to me meson gtkdoc runs in strict
xml parsing mode, whereas automake gtkdoc doesn't. And gtkdoc itself
is to dense to correctly escape this stuff.
Paper around this.
Signed-off-by: Daniel Vetter
---
lib/igt_aux.c | 4 ++--
lib/igt_core.c| 4 ++--
l
I haven't figured out how to make this work with meson's gtkdoc
support.
But then all the docs are for the internal library and the tests, and
for that the version information isn't really all that useful. You
just want whatever matches your sourcecode really.
So let's go the easy way and just re
Bunch of neat improvements:
- xml generates correctly depend upon the test binaries
- no need to re-run autogen.sh when new chapters/functions get added,
all handed by meson
Still one issue:
- the gtkdoc target doesn't depend upon the custom_target yet, hacked
around using build_by_default:
Helps with making it compile everywhere. This fixes:
commit db31e3c1ca0953b6e6832c25060acd01012a66dd
Author: Tvrtko Ursulin
Date: Wed Nov 8 12:06:52 2017 +
lib/core: Avoid unused result in backtrace printing
(Yes, I don't have libunwind on this machine here. Accidentally)
Cc: Tvrtko
== Series Details ==
Series: series starting with [v3,1/2] drm/i915: Expose the busyspin durations
for i915_wait_request
URL : https://patchwork.freedesktop.org/series/34404/
State : success
== Summary ==
Warning: bzip CI_DRM_3389/shard-glkb3/results31.json.bz2 wasn't in correct JSON
format
== Series Details ==
Series: drm: drm_vblank_cleanup: WARN when refcount > 0 (rev3)
URL : https://patchwork.freedesktop.org/series/32648/
State : failure
== Summary ==
Applying: drm: drm_vblank_cleanup: WARN when refcount > 0
Patch failed at 0001 drm: drm_vblank_cleanup: WARN when refcount > 0
On 11/24/2017 12:34 AM, Ville Syrjala wrote:
From: Ville Syrjälä
Use drm_mode_get_hv_timing() to fill out the plane clip rectangle.
Note that this replaces crtc_state->adjusted_mode usage with
crtc_state->mode. The latter is the correct choice since that's the
mode the user provided and it m
Quoting Lukas Wunner (2017-11-26 12:20:32)
> On Sat, Nov 25, 2017 at 07:41:55PM +, Chris Wilson wrote:
> > As both the hotplug event and fbdev configuration run asynchronously, it
> > is possible for them to run concurrently. If configuration fails, we were
> > freeing the fbdev causing a use-a
Warn when refcount is > 0 in drm_vblank_cleanup.
Signed-off-by: PrasannaKumar Muralidharan
---
Changes in v4:
* Print refcount value.
Changes in v3:
* Dropped i915 patch that is used for testing this.
No changes in v2.
drivers/gpu/drm/drm_vblank.c | 8 +++-
1 file changed, 7 insertions(+
== Series Details ==
Series: series starting with [v3,1/2] drm/i915: Expose the busyspin durations
for i915_wait_request
URL : https://patchwork.freedesktop.org/series/34404/
State : success
== Summary ==
Series 34404v1 series starting with [v3,1/2] drm/i915: Expose the busyspin
durations fo
On Sun, Nov 26, 2017 at 11:58:43AM +, Chris Wilson wrote:
> Quoting Lukas Wunner (2017-11-26 11:49:19)
> > Hm, the race at hand would be solved by the intel_fbdev_sync() below,
> > or am I missing something? Still wondering why it's necessary to
> > leave the fbdev around...
>
> The race is s
An interesting discussion regarding "hybrid interrupt polling" for NVMe
came to the conclusion that the ideal busyspin before sleeping was half
of the expected request latency (and better if it was already halfway
through that request). This suggested that we too should look again at
our tradeoff b
Looking at the distribution of i915_wait_request for a set of GL
benchmarks, we see:
broadwell# python bcc/tools/funclatency.py -u i915_wait_request
usecs : count distribution
0 -> 1 : 29184||
2 -> 3 :
On Sat, Nov 25, 2017 at 07:41:55PM +, Chris Wilson wrote:
> As both the hotplug event and fbdev configuration run asynchronously, it
> is possible for them to run concurrently. If configuration fails, we were
> freeing the fbdev causing a use-after-free in the hotplug event.
>
> <7>[ 3069.9352
Quoting Lukas Wunner (2017-11-26 11:49:19)
> On Sat, Nov 25, 2017 at 07:41:55PM +, Chris Wilson wrote:
> > @@ -697,10 +697,8 @@ static void intel_fbdev_initial_config(void *data,
> > async_cookie_t cookie)
> >
> > /* Due to peculiar init order wrt to hpd handling this is separate. */
>
On Sat, Nov 25, 2017 at 07:41:55PM +, Chris Wilson wrote:
> @@ -697,10 +697,8 @@ static void intel_fbdev_initial_config(void *data,
> async_cookie_t cookie)
>
> /* Due to peculiar init order wrt to hpd handling this is separate. */
> if (drm_fb_helper_initial_config(&ifbdev->help
Quoting Lukas Wunner (2017-11-25 21:03:35)
> On Sat, Nov 25, 2017 at 07:41:55PM +, Chris Wilson wrote:
> > As both the hotplug event and fbdev configuration run asynchronously, it
> > is possible for them to run concurrently. If configuration fails, we were
> > freeing the fbdev causing a use-a
37 matches
Mail list logo
