[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Remove two sloppy inline functions from .h (rev2)

== Series Details == Series: drm/i915: Remove two sloppy inline functions from .h (rev2) URL : https://patchwork.freedesktop.org/series/14931/ State : success == Summary == Series 14931v2 drm/i915: Remove two sloppy inline functions from .h

Re: [Intel-gfx] [PATCH v2 01/11] drm/i915: Create distinct lockclasses for execution vs user timelines

On ma, 2016-11-07 at 13:59 +, Chris Wilson wrote: > @@ -56,6 +61,24 @@ int i915_gem_timeline_init(struct drm_i915_private *i915, >   return 0; >  } >   > +int i915_gem_timeline_init(struct drm_i915_private *i915, > +    struct i915_gem_timeline *timeline, > +

[Intel-gfx] Updated drm-intel-testing

Hi all, New -testing cycle with cool stuff: - gpu idling rework for s/r (Imre) - vlv mappable scanout fix - speed up probing in resume (Lyude) - dp audio workarounds for gen9 (Dhinakaran) - more conversion to using dev_priv internally (Ville) - more gen9+ wm fixes and cleanups (Maarten) -

[Intel-gfx] [PATCH v2] drm/i915: Remove two sloppy inline functions from .h

Get rid of sloppy inline functions now that we don't have more users: i915_gem_request_get_seqno i915_gem_request_get_engine v2: - request->engine is always non-NULL (Chris) Signed-off-by: Joonas Lahtinen Cc: Chris Wilson Reviewed-by:

Re: [Intel-gfx] [PATCH v9 11/11] drm/i915: Add a kerneldoc summary for i915_perf.c

On Mon, 2016-11-07 at 11:49 -0800, Robert Bragg wrote: > In particular this tries to capture for posterity some of the early > challenges we had with using the core perf infrastructure in case we > ever want to revisit adapting perf for device metrics. > > Cc: Chris Wilson

Re: [Intel-gfx] [PATCH v9 09/11] drm/i915: add dev.i915.oa_max_sample_rate sysctl

On Mon, 2016-11-07 at 11:49 -0800, Robert Bragg wrote: > The maximum OA sampling frequency is now configurable via a > dev.i915.oa_max_sample_rate sysctl parameter. > > Following the precedent set by perf's similar > kernel.perf_event_max_sample_rate the default maximum rate is 10Hz > >

Re: [Intel-gfx] [PATCH v9 05/11] drm/i915: Add 'render basic' Haswell OA unit config

On Mon, 2016-11-07 at 11:49 -0800, Robert Bragg wrote: > Adds a static OA unit, MUX + B Counter configuration for basic render > metrics on Haswell. This is auto generated from an XML > description of metric sets, currently maintained in gputop, ref: > > https://github.com/rib/gputop > >

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

Hi all, FIXME: Add owner of second tree to To: Add author(s)/SOB of conflicting commits. Today's linux-next merge of the tip tree got a conflict in: drivers/gpu/drm/i915/i915_gem_shrinker.c between commits: 1233e2db199d ("drm/i915: Move object backing storage manipulation to its

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/dp: Update connector status for DP MST hotplugs (rev3)

== Series Details == Series: drm/i915/dp: Update connector status for DP MST hotplugs (rev3) URL : https://patchwork.freedesktop.org/series/14821/ State : success == Summary == Series 14821v3 drm/i915/dp: Update connector status for DP MST hotplugs

[Intel-gfx] [PATCH v2] drm/i915/dp: Update connector status for DP MST hotplugs

Hotplugging a monitor in DP MST configuration triggers short pulses. Although the short pulse handling path ends up in the MST hotplug function, we do not perform a detect before sending the hotplug uvent. This leads to the connector status not being updated when the userspace calls

[Intel-gfx] [RFC i-g-t 3/4] igt_aux: Add some list helpers from wayland

Since we're going to be using lists for keeping track of EDIDs we've allocated on the chamelium, add some generic list helpers from the wayland project. Signed-off-by: Lyude --- lib/igt_aux.c | 27 +++ lib/igt_aux.h | 38

[Intel-gfx] [RFC i-g-t 4/4] Add support for hotplug testing with the Chamelium

For the purpose of testing things such as hotplugging and bad monitors, the ChromeOS team ended up designing a neat little device known as the Chamelium. More information on this can be found here: https://www.chromium.org/chromium-os/testing/chamelium This adds support for a couple of

[Intel-gfx] [RFC i-g-t 0/4] intel-gpu-tools: Add support for the Chamelium

For a very long time, we've had basically no automated testing coverage of hotplugging functionality mainly because the only way to test this sort of thing was to manually plug and unplug the connectors yourself. As well, this also means we could never automate testing of various DisplayPort

[Intel-gfx] [RFC i-g-t 2/4] igt_aux: Add igt_set_autoresume_delay()

The default autoresume delay is about 5 seconds. It's possible on a system that's not very fast this might not be a long enough time, since an asynchronous hotplug event we scheduled on the chamelium that was intended to happen during suspend could happen before we actually manage to suspend. So,

[Intel-gfx] [RFC i-g-t 1/4] igt_aux: Add igt_skip_without_suspend_support()

Since all of the chamelium calls are blocking, we need to be able to make suspend/resume tests with it multi-threaded. As such, it's not the best idea to rely on igt_system_suspend_autoresume() for skipping tests on systems without suspend/resume support since we could accidentally leave the

Re: [Intel-gfx] [PATCH] drm/i915/dp: Update connector status for DP MST hotplugs

On Mon, 2016-11-07 at 18:14 +0200, Ville Syrjälä wrote: > On Thu, Nov 03, 2016 at 08:38:32PM -0700, Dhinakaran Pandiyan wrote: > > Hotplugging a monitor in DP MST configuration triggers short pulses. > > Although the short pulse handling path ends up in the MST hotplug function, > > we do not

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/dp: Make space for null terminator in the DP device ID char array (rev2)

== Series Details == Series: drm/dp: Make space for null terminator in the DP device ID char array (rev2) URL : https://patchwork.freedesktop.org/series/14865/ State : success == Summary == Series 14865v2 drm/dp: Make space for null terminator in the DP device ID char array

[Intel-gfx] [PATCH v2] drm/dp: Make space for null terminator in the DP device ID char array

The DP device identification string read from the DPCD registers is 6 characters long at max. and we store it in a char array of the same length without space for the NULL terminator. Fix this by increasing the array size to 7 and initialize it to an empty string. v2: Use %*pE format specifier

Re: [Intel-gfx] [REGRESSION] Linux 4.9-rc4: gfx glitches on Intel Sandybridge (was: Re: Linux 4.9-rc4)

Am Montag, 7. November 2016, 19:09:36 CET schrieb Jani Nikula: > On Mon, 07 Nov 2016, Martin Steigerwald wrote: > > It is also the same kind of corruptions as shown in > > > > [Bug 177701] warning in intel_dp_aux_transfer > >

[Intel-gfx] [PATCH igt v2 0/6] corresponding changes for i915-perf interface

The i915-perf series affects the command parser and itself includes new uapi which these i-g-t changes try to cover. This version splits up the gem_exec_parse.c changes I also made some adjustments to the i915 perf tests to scale raw timestamps in terms of a 1250Hz timestamp frequency

[Intel-gfx] [PATCH igt v2 1/6] igt/perf: add i915 perf stream tests for Haswell

Signed-off-by: Robert Bragg --- tests/Makefile.sources |1 + tests/perf.c | 2220 2 files changed, 2221 insertions(+) create mode 100644 tests/perf.c diff --git a/tests/Makefile.sources

[Intel-gfx] [PATCH igt v2 6/6] igt/gem_exec_parse: update for version 8 changes

This adapts the tests to account for the parser no longer reporting privilege violations back to userspace as EINVAL errors (they are left to the HW command parser to squash the commands to NOOPS). The interface change isn't expected to affect userspace and in fact it looks like the previous

[Intel-gfx] [PATCH igt v2 4/6] igt/gem_exec_parse: move hsw_load_register_reg down

No functional change, just moving hsw_load_regster_reg test code down below the execbuf utilities in preparation for updating to use them. Signed-off-by: Robert Bragg --- tests/gem_exec_parse.c | 174 - 1 file changed, 87

[Intel-gfx] [PATCH igt v2 2/6] igt/gem_exec_parse: remove oacontrol checks

The command parser no longer whitelists or does anything special for the OACONTROL register which is now considered owned by i915-perf. As a follow up the plan is to at least check that attempting to write to OACONTROL from userspace must not fail with an EINVAL error, otherwise Mesa's graceful

[Intel-gfx] [PATCH igt v2 3/6] igt/gem_exec_parse: some minor cleanups

This normalizes the execbuf utilities in this file to all use memset to clear obj, reloc and execbuf structures and set them up in the same order. As I was debugging some unpredictable test failures I was getting unsure that all these structures were being fully initialized. The same

[Intel-gfx] [PATCH igt v2 5/6] igt/gem_exec_parse: update hsw_load_register_reg

This generalises hsw_load_register_reg to loop through an array of allowed and disallowed registers and to use the exec_batch[_patched] utilities. Signed-off-by: Robert Bragg --- tests/gem_exec_parse.c | 132 - 1 file

Re: [Intel-gfx] [PATCH 1/5] drm/i915: Fix scaling check for 90/270 degree plane rotation

On Mon, Nov 07, 2016 at 10:20:53PM +0200, ville.syrj...@linux.intel.com wrote: > From: Ville Syrjälä > > Starting from commit b63a16f6cd89 ("drm/i915: Compute display surface > offset in the plane check hook for SKL+") we've already rotated the src > coordinates by

Re: [Intel-gfx] [PATCH 5/5] drm/i915: Use intel_fb_gtt_offset() also for gen2/3 primary plane

On Mon, Nov 07, 2016 at 10:20:57PM +0200, ville.syrj...@linux.intel.com wrote: > From: Ville Syrjälä > > The code to determine the primary plane offset for gen2/3 looks > different than the code for gen4+, but in fact it's doing the same > thing. Let's make it

Re: [Intel-gfx] [PATCH 3/5] drm/i915: Grab the rotation from the passed plane state for VLV sprites

On Mon, Nov 07, 2016 at 10:20:55PM +0200, ville.syrj...@linux.intel.com wrote: > From: Ville Syrjälä > > Use the passed in plane_state instead of plane->state in > vlv_update_plane(). Currently the two are one and the same, but if we > start queuing up multiple

Re: [Intel-gfx] [PATCH 4/5] drm/i915: Fix error handling for cursor/sprite plane create failure

On Mon, Nov 07, 2016 at 10:20:56PM +0200, ville.syrj...@linux.intel.com wrote: > From: Ville Syrjälä > > intel_cursor_plane_create() and intel_sprite_plane_create() return > an error pointer, so let's not mistakenly look for a NULL pointer. > > Cc: Chris Wilson

Re: [Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Mark CPU cache as dirty when used for rendering (rev2)

On Mon, Nov 07, 2016 at 05:15:49PM -, Patchwork wrote: > == Series Details == > > Series: drm/i915: Mark CPU cache as dirty when used for rendering (rev2) > URL : https://patchwork.freedesktop.org/series/14930/ > State : success An indication that we are missing some coverage. Pushed.

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Assortment of plane fixes

== Series Details == Series: drm/i915: Assortment of plane fixes URL : https://patchwork.freedesktop.org/series/14936/ State : success == Summary == Series 14936v1 drm/i915: Assortment of plane fixes https://patchwork.freedesktop.org/api/1.0/series/14936/revisions/1/mbox/ fi-bdw-5557u

[Intel-gfx] [PATCH 5/5] drm/i915: Use intel_fb_gtt_offset() also for gen2/3 primary plane

From: Ville Syrjälä The code to determine the primary plane offset for gen2/3 looks different than the code for gen4+, but in fact it's doing the same thing. Let's make it uniform. Allows us to eliminate the 'obj' from the list of local variables as well.

[Intel-gfx] [PATCH 3/5] drm/i915: Grab the rotation from the passed plane state for VLV sprites

From: Ville Syrjälä Use the passed in plane_state instead of plane->state in vlv_update_plane(). Currently the two are one and the same, but if we start queuing up multiple plane updates they might not be. Looks like this was rebase fail on my part. Cc: Daniel

[Intel-gfx] [PATCH 1/5] drm/i915: Fix scaling check for 90/270 degree plane rotation

From: Ville Syrjälä Starting from commit b63a16f6cd89 ("drm/i915: Compute display surface offset in the plane check hook for SKL+") we've already rotated the src coordinates by 270 degrees by the time we check if a scaler is needed or not, so we must not account

[Intel-gfx] [PATCH 4/5] drm/i915: Fix error handling for cursor/sprite plane create failure

From: Ville Syrjälä intel_cursor_plane_create() and intel_sprite_plane_create() return an error pointer, so let's not mistakenly look for a NULL pointer. Cc: Chris Wilson Reported-by: Chris Wilson References:

[Intel-gfx] [PATCH 2/5] drm/i915: Ignore bogus plane coordinates on SKL when the plane is not visible

From: Ville Syrjälä When the plane is invisible we may have all sorts of bogus stuff in the coordinates, which we must ignore or else we might fail the plane update. This started to happen on SKL when I moved the plane offset computation to happen in the check

[Intel-gfx] [PATCH 0/5] drm/i915: Assortment of plane fixes

From: Ville Syrjälä I found another breakage from my SKL plane check stuff when testing out Xv on SKL, and we still have that 90/270 rotation fix which I already sent out earlier. I also spotted a harmless bug in the VLV/CHV sprite code so I figured I'd include the

[Intel-gfx] ✗ Fi.CI.BAT: failure for Enable i915 perf stream for Haswell OA unit

== Series Details == Series: Enable i915 perf stream for Haswell OA unit URL : https://patchwork.freedesktop.org/series/14935/ State : failure == Summary == Series 14935v1 Enable i915 perf stream for Haswell OA unit https://patchwork.freedesktop.org/api/1.0/series/14935/revisions/1/mbox/

[Intel-gfx] [PATCH v9 11/11] drm/i915: Add a kerneldoc summary for i915_perf.c

In particular this tries to capture for posterity some of the early challenges we had with using the core perf infrastructure in case we ever want to revisit adapting perf for device metrics. Cc: Chris Wilson Signed-off-by: Robert Bragg

[Intel-gfx] [PATCH v9 08/11] drm/i915: Add dev.i915.perf_stream_paranoid sysctl option

Consistent with the kernel.perf_event_paranoid sysctl option that can allow non-root users to access system wide cpu metrics, this can optionally allow non-root users to access system wide OA counter metrics from Gen graphics hardware. Signed-off-by: Robert Bragg

[Intel-gfx] [PATCH v9 10/11] drm/i915: Add more Haswell OA metric sets

This adds 'compute', 'compute extended', 'memory reads', 'memory writes' and 'sampler balance' metric sets for Haswell. The code is auto generated from an XML description of metric sets, currently maintained in gputop, ref: https://github.com/rib/gputop > gputop-data/oa-*.xml >

[Intel-gfx] [PATCH v9 07/11] drm/i915: advertise available metrics via sysfs

Each metric set is given a sysfs entry like: /sys/class/drm/card0/metrics//id This allows userspace to enumerate the specific sets that are available for the current system. The 'id' file contains an unsigned integer that can be used to open the associated metric set via

[Intel-gfx] [PATCH v9 09/11] drm/i915: add dev.i915.oa_max_sample_rate sysctl

The maximum OA sampling frequency is now configurable via a dev.i915.oa_max_sample_rate sysctl parameter. Following the precedent set by perf's similar kernel.perf_event_max_sample_rate the default maximum rate is 10Hz Signed-off-by: Robert Bragg ---

[Intel-gfx] [PATCH v9 03/11] drm/i915: return EACCES for check_cmd() failures

check_cmd() is checking whether a command adheres to certain restrictions that ensure it's safe to execute within a privileged batch buffer. Returning false implies a privilege problem, not that the command is invalid. The distinction makes the difference between allowing the buffer to be

[Intel-gfx] [PATCH v9 06/11] drm/i915: Enable i915 perf stream for Haswell OA unit

Gen graphics hardware can be set up to periodically write snapshots of performance counters into a circular buffer via its Observation Architecture and this patch exposes that capability to userspace via the i915 perf interface. v2: Make sure to initialize ->specific_ctx_id when opening,

[Intel-gfx] [PATCH v9 05/11] drm/i915: Add 'render basic' Haswell OA unit config

Adds a static OA unit, MUX + B Counter configuration for basic render metrics on Haswell. This is auto generated from an XML description of metric sets, currently maintained in gputop, ref: https://github.com/rib/gputop > gputop-data/oa-*.xml > scripts/i915-perf-kernelgen.py $ make -C

[Intel-gfx] [PATCH v9 00/11] Enable i915 perf stream for Haswell OA unit

Rebased and updated with more feedback from Sourab and Matt. In particular the patch that added the oa_min_timer_exponent sysctl parameter has now been replaced with one adding an oa_max_sample_rate parameter in Hz. This way userspace policy won't need to be tailored to different systems when

[Intel-gfx] [PATCH v9 02/11] drm/i915: rename OACONTROL GEN7_OACONTROL

OACONTROL changes quite a bit for gen8, with some bits split out into a per-context OACTXCONTROL register. Rename now before adding more gen7 OA registers Signed-off-by: Robert Bragg Reviewed-by: Matthew Auld Reviewed-by: Sourab Gupta

[Intel-gfx] [PATCH v9 04/11] drm/i915: don't whitelist oacontrol in cmd parser

Being able to program OACONTROL from a non-privileged batch buffer is not sufficient to be able to configure the OA unit. This was originally allowed to help enable Mesa to expose OA counters via the INTEL_performance_query extension, but the current implementation based on programming OACONTROL

[Intel-gfx] [PATCH v9 01/11] drm/i915: Add i915 perf infrastructure

Adds base i915 perf infrastructure for Gen performance metrics. This adds a DRM_IOCTL_I915_PERF_OPEN ioctl that takes an array of uint64 properties to configure a stream of metrics and returns a new fd usable with standard VFS system calls including read() to read typed and sized records; ioctl()

Re: [Intel-gfx] [PATCH v3 4/4] drm/i915: Implement Link Rate fallback on Link training failure

Jani, could you please take a look at this patch? I have addressed your comments on the previous revision. The common_rates array can be moved into Intel dp structure in a follow up patch since that would require changes in a lot of places other than the link rate fallback implementation.

Re: [Intel-gfx] [PATCH] drm/dp: Make space for null terminator in the DP device ID char array

On Fri, 04 Nov 2016, Dhinakaran Pandiyan wrote: > The DP device identification string read from the DPCD registers is 6 > characters long at max. and we store it in a char array of the same length > without space for the NULL terminator. Fix this by increasing the

Re: [Intel-gfx] [PATCH] drm/dp: Make space for null terminator in the DP device ID char array

Mika, Can you take a look at this? -DK On Fri, 2016-11-04 at 14:06 -0700, Dhinakaran Pandiyan wrote: > The DP device identification string read from the DPCD registers is 6 > characters long at max. and we store it in a char array of the same length > without space for the NULL terminator. Fix

Re: [Intel-gfx] [PATCH v2] drm: move allocation out of drm_get_format_name()

Thomas has already acked the earlier version, but in case you need it for this one, too. vmwgfx portion: Acked-by: Sinclair Yeh On Mon, Nov 07, 2016 at 12:48:09AM +, Eric Engestrom wrote: > Fixes: 90844f00049e9f42573fd31d7c32e8fd31d3fd07 > > drm: make

Re: [Intel-gfx] [PATCH v2] drm: move allocation out of drm_get_format_name()

On Mon, 07 Nov 2016, Eric Engestrom wrote: > On Monday, 2016-11-07 10:10:13 +0200, Jani Nikula wrote: >> On Mon, 07 Nov 2016, Eric Engestrom wrote: >> > Fixes: 90844f00049e9f42573fd31d7c32e8fd31d3fd07 >> > >> > drm: make drm_get_format_name

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Mark CPU cache as dirty when used for rendering (rev2)

== Series Details == Series: drm/i915: Mark CPU cache as dirty when used for rendering (rev2) URL : https://patchwork.freedesktop.org/series/14930/ State : success == Summary == Series 14930v2 drm/i915: Mark CPU cache as dirty when used for rendering

Re: [Intel-gfx] [PATCH v2] drm: move allocation out of drm_get_format_name()

On Monday, 2016-11-07 10:10:13 +0200, Jani Nikula wrote: > On Mon, 07 Nov 2016, Eric Engestrom wrote: > > Fixes: 90844f00049e9f42573fd31d7c32e8fd31d3fd07 > > > > drm: make drm_get_format_name thread-safe > > > > Signed-off-by: Eric Engestrom > >

Re: [Intel-gfx] [REGRESSION] Linux 4.9-rc4: gfx glitches on Intel Sandybridge (was: Re: Linux 4.9-rc4)

On Mon, 07 Nov 2016, Martin Steigerwald wrote: > It is also the same kind of corruptions as shown in > > [Bug 177701] warning in intel_dp_aux_transfer > https://bugzilla.kernel.org/show_bug.cgi?id=177701 > > Just compare > >

[Intel-gfx] [PATCH v2] drm/i915: Mark CPU cache as dirty when used for rendering

On LLC, or even snooped, machines rendering via the GPU ends up in the CPU cache. This cacheline dirt also needs to be flushed to main memory when moving to an incoherent domain, such as the display's scanout engine. Mostly, this happens because either the object is marked as dirty from its first

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Remove two sloppy inline functions from .h

== Series Details == Series: drm/i915: Remove two sloppy inline functions from .h URL : https://patchwork.freedesktop.org/series/14931/ State : success == Summary == Series 14931v1 drm/i915: Remove two sloppy inline functions from .h

Re: [Intel-gfx] [PATCH] drm/i915: Mark CPU cache as dirty when used for rendering

On Mon, Nov 07, 2016 at 03:46:28PM +, Chris Wilson wrote: > On LLC, or even snooped, machines rendering via the GPU ends up in the CPU > cache. This cacheline dirt also needs to be flushed to main memory when > moving to an incoherent domain, such as the display's scanout engine. > Mostly,

Re: [Intel-gfx] [PATCH] drm/i915: Remove two sloppy inline functions from .h

On Mon, Nov 07, 2016 at 06:13:20PM +0200, Joonas Lahtinen wrote: > Get rid of sloppy inline functions now that we don't have more users: > > i915_gem_request_get_seqno > i915_gem_request_get_engine > > Cc: Chris Wilson > Signed-off-by: Joonas Lahtinen

Re: [Intel-gfx] [PATCH 1/3] drm/i915: Remove chipset flush after cache flush

On ma, 2016-11-07 at 12:10 +, Chris Wilson wrote: > On Mon, Nov 07, 2016 at 02:01:46PM +0200, Joonas Lahtinen wrote: > > > > On su, 2016-11-06 at 12:59 +, Chris Wilson wrote: > > > > > > We always flush the chipset prior to executing with the GPU, so we can > > > skip the flush during

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Mark CPU cache as dirty when used for rendering

== Series Details == Series: drm/i915: Mark CPU cache as dirty when used for rendering URL : https://patchwork.freedesktop.org/series/14930/ State : success == Summary == Series 14930v1 drm/i915: Mark CPU cache as dirty when used for rendering

Re: [Intel-gfx] [PATCH] drm/i915/dp: Update connector status for DP MST hotplugs

On Thu, Nov 03, 2016 at 08:38:32PM -0700, Dhinakaran Pandiyan wrote: > Hotplugging a monitor in DP MST configuration triggers short pulses. > Although the short pulse handling path ends up in the MST hotplug function, > we do not perform a detect before sending the hotplug uvent. This leads to >

[Intel-gfx] [PATCH] drm/i915: Mark CPU cache as dirty when used for rendering

On LLC, or even snooped, machines rendering via the GPU ends up in the CPU cache. This cacheline dirt also needs to be flushed to main memory when moving to an incoherent domain, such as the display's scanout engine. Mostly, this happens because either the object is marked as dirty from its first

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [v2,01/11] drm/i915: Create distinct lockclasses for execution vs user timelines

== Series Details == Series: series starting with [v2,01/11] drm/i915: Create distinct lockclasses for execution vs user timelines URL : https://patchwork.freedesktop.org/series/14926/ State : success == Summary == Series 14926v1 Series without cover letter

Re: [Intel-gfx] [PATCH i-g-t v5] tests/kms_plane_multiple: CRC based atomic correctness test

Thanks for the review.  On Mon, 2016-11-07 at 14:04 +0100, Maarten Lankhorst wrote: > Op 02-11-16 om 10:32 schreef Mika Kahola: > > > > This is a testcase with multiple planes. The idea here is the > > following > > > >  - draw a uniform frame with blue color > >  - grab crc for reference > >  

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/1] drm/i915: Don't take execlist spinlock when setting wedged

== Series Details == Series: series starting with [1/1] drm/i915: Don't take execlist spinlock when setting wedged URL : https://patchwork.freedesktop.org/series/14925/ State : success == Summary == Series 14925v1 Series without cover letter

Re: [Intel-gfx] [PATCH v2] drm: move allocation out of drm_get_format_name()

On Sun, Nov 6, 2016 at 7:48 PM, Eric Engestrom wrote: > Fixes: 90844f00049e9f42573fd31d7c32e8fd31d3fd07 > > drm: make drm_get_format_name thread-safe > > Signed-off-by: Eric Engestrom > [danvet: Clarify that the returned pointer must be freed

Re: [Intel-gfx] [PATCH 05/15] drm/i915: Handle the overflow condition for command stream buf

On Mon, 2016-11-07 at 03:10 -0800, Matthew Auld wrote: > On 4 November 2016 at 09:30, wrote: > > From: Sourab Gupta > > > > Add a compile time option for detecting the overflow condition of command > > stream buffer, and not overwriting the old

Re: [Intel-gfx] [REGRESSION] Linux 4.9-rc4: gfx glitches on Intel Sandybridge (was: Re: Linux 4.9-rc4)

Am Montag, 7. November 2016, 13:04:16 CET schrieb Jani Nikula: > On Sun, 06 Nov 2016, Martin Steigerwald wrote: > > Hi. > > > > Am Samstag, 5. November 2016, 16:46:33 CET schrieb Linus Torvalds: > >> So it's once again a Saturday afternoon rather than Sunday, this time > >>

[Intel-gfx] [PATCH v2 10/11] drm/i915: Enable userspace to opt-out of implicit fencing

Userspace is faced with a dilemma. The kernel requires implicit fencing to manage resource usage (we always must wait for the GPU to finish before releasing its PTE) and for third parties. However, userspace may wish to avoid this serialisation if it is either using explicit fencing between

[Intel-gfx] [PATCH v2 05/11] drm/i915/scheduler: Signal the arrival of a new request

The start of the scheduler, add a hook into request submission for the scheduler to see the arrival of new requests and prepare its runqueues. Signed-off-by: Chris Wilson Reviewed-by: Tvrtko Ursulin --- drivers/gpu/drm/i915/i915_drv.c

[Intel-gfx] [PATCH v2 03/11] drm/i915: Defer transfer onto execution timeline to actual hw submission

Defer the transfer from the client's timeline onto the execution timeline from the point of readiness to the point of actual submission. For example, in execlists, a request is finally submitted to hardware when the hardware is ready, and only put onto the hardware queue when the request is ready.

[Intel-gfx] [PATCH v2 04/11] drm/i915: Remove engine->execlist_lock

The execlist_lock is now completely subsumed by the engine->timeline->lock, and so we can remove the redundant layer of locking. Signed-off-by: Chris Wilson Reviewed-by: Tvrtko Ursulin --- drivers/gpu/drm/i915/i915_debugfs.c | 4 ++--

[Intel-gfx] [PATCH v2 08/11] HACK drm/i915/scheduler: emulate a scheduler for guc

This emulates execlists on top of the GuC in order to defer submission of requests to the hardware. This deferral allows time for high priority requests to gazump their way to the head of the queue, however it nerfs the GuC by converting it back into a simple execlist (where the CPU has to wake up

[Intel-gfx] [PATCH v2 07/11] drm/i915/scheduler: Boost priorities for flips

Boost the priority of any rendering required to show the next pageflip as we want to avoid missing the vblank by being delayed by invisible workload. We prioritise avoiding jank and jitter in the GUI over starving background tasks. v2: Descend dma_fence_array when boosting priorities.

[Intel-gfx] [PATCH v2 09/11] drm/i915/scheduler: Support user-defined priorities

Use a priority stored in the context as the initial value when submitting a request. This allows us to change the default priority on a per-context basis, allowing different contexts to be favoured with GPU time at the expense of lower importance work. The user can adjust the context's priority

[Intel-gfx] [PATCH v2 02/11] drm/i915: Split request submit/execute phase into two

In order to support deferred scheduling, we need to differentiate between when the request is ready to run (i.e. the submit fence is signaled) and when the request is actually run (a new execute fence). This is typically split between the request itself wanting to wait upon others (for which we

[Intel-gfx] [PATCH v2 06/11] drm/i915/scheduler: Record all dependencies upon request construction

The scheduler needs to know the dependencies of each request for the lifetime of the request, as it may choose to reschedule the requests at any time and must ensure the dependency tree is not broken. This is in additional to using the fence to only allow execution after all dependencies have been

[Intel-gfx] [PATCH v2 01/11] drm/i915: Create distinct lockclasses for execution vs user timelines

In order to simplify the lockdep annotation, as they become more complex in the future with deferred execution and multiple paths through the same functions, create a separate lockclass for the user timeline and the hardware execution timeline. We should only ever be locking the user timeline and

[Intel-gfx] Trivial scheduler, take 2

Not much to report here. Biggest change is converting the recursive DFS for PI into an iterative algorithm. The biggest challenge remains trying to get a consistent set of names so we avoid confusing ourselves going forwards into preemption. Biggest TODO task is check for perf regressions from the

Re: [Intel-gfx] [PATCH 05/12] drm/i915/scheduler: Record all dependencies upon request construction

On 07/11/2016 13:39, Chris Wilson wrote: On Mon, Nov 07, 2016 at 01:30:43PM +, Tvrtko Ursulin wrote: On 07/11/2016 09:30, Chris Wilson wrote: On Mon, Nov 07, 2016 at 09:12:57AM +, Tvrtko Ursulin wrote: On 04/11/2016 15:11, Chris Wilson wrote: On Fri, Nov 04, 2016 at 02:44:44PM

Re: [Intel-gfx] [PATCH 05/12] drm/i915/scheduler: Record all dependencies upon request construction

On Mon, Nov 07, 2016 at 01:30:43PM +, Tvrtko Ursulin wrote: > > On 07/11/2016 09:30, Chris Wilson wrote: > >On Mon, Nov 07, 2016 at 09:12:57AM +, Tvrtko Ursulin wrote: > >> > >>On 04/11/2016 15:11, Chris Wilson wrote: > >>>On Fri, Nov 04, 2016 at 02:44:44PM +, Tvrtko Ursulin wrote: >

Re: [Intel-gfx] [PATCH 05/12] drm/i915/scheduler: Record all dependencies upon request construction

On 07/11/2016 09:30, Chris Wilson wrote: On Mon, Nov 07, 2016 at 09:12:57AM +, Tvrtko Ursulin wrote: On 04/11/2016 15:11, Chris Wilson wrote: On Fri, Nov 04, 2016 at 02:44:44PM +, Tvrtko Ursulin wrote: On 03/11/2016 11:55, Chris Wilson wrote: On Thu, Nov 03, 2016 at 11:03:47AM

Re: [Intel-gfx] [PATCH i-g-t v5] tests/kms_plane_multiple: CRC based atomic correctness test

Op 02-11-16 om 10:32 schreef Mika Kahola: > This is a testcase with multiple planes. The idea here is the following > > - draw a uniform frame with blue color > - grab crc for reference > - put planes randomly on top with the same blue color > - punch holes with black color into the primary

Re: [Intel-gfx] [PATCH 1/1] drm/i915: Don't take execlist spinlock when setting wedged

Chris Wilson writes: > On Mon, Nov 07, 2016 at 02:35:38PM +0200, Mika Kuoppala wrote: >> We do take execlist spinlock on thread context when >> we declare gpu to be wedged. Avoid the need to change >> the spinlock type just for the sake of wedging by >> removing the

Re: [Intel-gfx] ✗ Fi.CI.BAT: warning for series starting with [v5,1/4] drm/i915: Avoid early GPU idling due to already pending idle work

On ma, 2016-11-07 at 10:15 +, Patchwork wrote: > == Series Details == > > Series: series starting with [v5,1/4] drm/i915: Avoid early GPU idling due to > already pending idle work > URL   : https://patchwork.freedesktop.org/series/14917/ > State : warning > > == Summary == > > Series

Re: [Intel-gfx] [PATCH 1/1] drm/i915: Don't take execlist spinlock when setting wedged

On Mon, Nov 07, 2016 at 02:35:38PM +0200, Mika Kuoppala wrote: > We do take execlist spinlock on thread context when > we declare gpu to be wedged. Avoid the need to change > the spinlock type just for the sake of wedging by > removing the spinlock. Keep irqs disabled during reset > phase and only

[Intel-gfx] [PATCH 1/1] drm/i915: Don't take execlist spinlock when setting wedged

We do take execlist spinlock on thread context when we declare gpu to be wedged. Avoid the need to change the spinlock type just for the sake of wedging by removing the spinlock. Keep irqs disabled during reset phase and only enable on success path. Also add explicit disable to setting wedged so

Re: [Intel-gfx] [PATCH 0/2] drm/i915/opregion: proper handling of DIDL and CADL

Hi Jani, this is sad and also bad news. Means that actually we don't have any driver which makes the brightness keys on the Fujitsu LIFEBOOK E7x6 series work. On the other hand I saw that recent patches to intel_opregion.c introduced quirks based on the DMI strings for some machines. I consider

Re: [Intel-gfx] [PATCH v4] drm/i915: Limit Valleyview and earlier to only using mappable scanout

On Mon, Nov 07, 2016 at 01:36:03PM +0200, Ville Syrjälä wrote: > On Mon, Nov 07, 2016 at 11:01:28AM +, Chris Wilson wrote: > > + /* Valleyview is definitely limited to scanning out the first > > +* 512MiB respectively. Lets presume this behaviour was >

Re: [Intel-gfx] [PATCH 1/3] drm/i915: Remove chipset flush after cache flush

On Mon, Nov 07, 2016 at 02:01:46PM +0200, Joonas Lahtinen wrote: > On su, 2016-11-06 at 12:59 +, Chris Wilson wrote: > > We always flush the chipset prior to executing with the GPU, so we can > > skip the flush during ordinary domain management. > > > > Signed-off-by: Chris Wilson

Re: [Intel-gfx] [PATCH 1/3] drm/i915: Remove chipset flush after cache flush

On su, 2016-11-06 at 12:59 +, Chris Wilson wrote: > We always flush the chipset prior to executing with the GPU, so we can > skip the flush during ordinary domain management. > > Signed-off-by: Chris Wilson Maybe even add? Fixes: dcd79934b0dd ("drm/i915:

Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Round tile chunks up for constructing partial VMAs

On Mon, Nov 07, 2016 at 11:15:40AM -, Patchwork wrote: > == Series Details == > > Series: drm/i915: Round tile chunks up for constructing partial VMAs > URL : https://patchwork.freedesktop.org/series/14922/ > State : failure > > == Summary == > > Series 14922v1 drm/i915: Round tile chunks

Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Remove the vma from the object list upon close

On Fri, Nov 04, 2016 at 05:45:36PM -, Patchwork wrote: > == Series Details == > > Series: drm/i915: Remove the vma from the object list upon close > URL : https://patchwork.freedesktop.org/series/14850/ > State : failure > > == Summary == > > Series 14850v1 drm/i915: Remove the vma from

Re: [Intel-gfx] [PATCH v4] drm/i915: Limit Valleyview and earlier to only using mappable scanout

On Mon, Nov 07, 2016 at 11:01:28AM +, Chris Wilson wrote: > Valleyview appears tobe limited to only scanning out from the first 512MiB > of the Global GTT. Lets presume that this behaviour was inherited from the > display block copied from g4x (not Ironlake) and all earlier generations > are

Re: [Intel-gfx] [PATCH] shmem: fix pageflags after swapping DMA32 object

On Sun, Nov 06, 2016 at 08:08:29PM -0800, Hugh Dickins wrote: > If shmem_alloc_page() does not set PageLocked and PageSwapBacked, then > shmem_replace_page() needs to do so for itself. Without this, it puts > newpage on the wrong lru, re-unlocks the unlocked newpage, and system > descends into

  1   2   >