[Intel-gfx] [PATCH 6/6] drm/i915: Enable support for nonblocking modeset

Signed-off-by: Maarten Lankhorst --- drivers/gpu/drm/i915/intel_display.c | 9 - 1 file changed, 9 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c index 7a66a4252ee0..9fe8873d82cb 100644 ---

[Intel-gfx] [PATCH 4/6] drm/i915: Update atomic modeset state synchronously

All of this state should be updated as soon as possible. It shouldn't be done later because then future updates may not depend on it. Signed-off-by: Maarten Lankhorst --- drivers/gpu/drm/i915/intel_display.c | 15 --- 1 file changed, 8

[Intel-gfx] [PATCH 1/6] drm/i915: Convert intel_hdmi to use atomic state

This is the last connector still looking at crtc->config. Fix this. Signed-off-by: Maarten Lankhorst --- drivers/gpu/drm/i915/intel_hdmi.c | 48 +-- 1 file changed, 21 insertions(+), 27 deletions(-) diff --git

[Intel-gfx] [PATCH 2/6] drm/i915: Pass atomic state to intel_audio_codec_enable

drm_select_eld requires mode_config.mutex and connection_mutex because it looks at the connector list and at the legacy encoders. This is not required, because when we call audio_codec_enable we know which connector it was called for, so pass the state. This also removes having to look at

[Intel-gfx] [PATCH 5/6] drm/i915: Pass atomic state to verify_connector_state

This gets rid of a warning that the connectors are used without locking when doing a nonblocking modeset. Signed-off-by: Maarten Lankhorst --- drivers/gpu/drm/i915/intel_display.c | 24 +++- 1 file changed, 15 insertions(+), 9 deletions(-)

[Intel-gfx] [PATCH 0/6] drm/i915: Enable support for nonblocking modesets.

This fixes a few places where we emit warnings on nonblocking modesets, then flips the switch and enables it. Tested on my BDW and SKL, but SKL still fails on the detection whether nonblocking modesets are supported with some WM related issue. Fixing this and support for atomic connector

[Intel-gfx] [PATCH 3/6] drm/edid: Remove drm_select_eld

The only user was i915, which is now gone. Signed-off-by: Maarten Lankhorst --- drivers/gpu/drm/drm_edid.c | 26 -- include/drm/drm_edid.h | 1 - 2 files changed, 27 deletions(-) diff --git a/drivers/gpu/drm/drm_edid.c

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Enable support for nonblocking modesets.

== Series Details == Series: drm/i915: Enable support for nonblocking modesets. URL : https://patchwork.freedesktop.org/series/12098/ State : success == Summary == Series 12098v1 drm/i915: Enable support for nonblocking modesets.

Re: [Intel-gfx] [PATCH] Revert "drm/i915: Check live status before reading edid"

On Fri, 19 Aug 2016, David Weinehall wrote: > On Thu, Aug 18, 2016 at 10:29:43AM +0300, David Weinehall wrote: >> On Wed, Aug 17, 2016 at 04:43:36PM +0300, Jani Nikula wrote: >> > On Wed, 17 Aug 2016, Chris Wilson wrote: >> > > On Wed,

Re: [Intel-gfx] FIFO underruns

On Tue, 06 Sep 2016, t s wrote: > I know that this is not the latest general kernel, but I wonder if this is > a known problem and what can be done about it. Try drm-intel-nightly branch of [1], and if the problem persists, file a bug at [2]. BR, Jani. [1]

Re: [Intel-gfx] Regression in v4.8-rc4: i915 flickering since commit 1c80c25fb6

On Sun, 04 Sep 2016, Dominik Brodowski wrote: > Hi! > > Since commit 1c80c25fb6 (determined by git bisect, and confirmed by > reverting this patch on top of 9ca581b50d), the sceen on my DELL XPS 13 > is flickering every once in a while (sometimes multiple times per >

Re: [Intel-gfx] [PATCH] tools/intel_guc_logger: Utility for capturing GuC firmware logs in a file

On 9/6/2016 9:22 PM, Tvrtko Ursulin wrote: On 06/09/16 16:33, Goel, Akash wrote: On 9/6/2016 6:47 PM, Tvrtko Ursulin wrote: Hi, On 06/09/16 11:43, akash.g...@intel.com wrote: From: Akash Goel This patch provides a test utility which helps capture GuC firmware logs

Re: [Intel-gfx] [PATCH] tools/intel_guc_logger: Utility for capturing GuC firmware logs in a file

On 07/09/16 09:44, Chris Wilson wrote: On Wed, Sep 07, 2016 at 01:40:27PM +0530, Goel, Akash wrote: On 9/6/2016 9:22 PM, Tvrtko Ursulin wrote: [snip] +while (!stop_logging) +{ +if (test_duration && (igt_seconds_elapsed() > test_duration)) { If you agree to allow no poll

Re: [Intel-gfx] [PATCH v2 11/14] drm/i915: Fallback to lower link rate and lane count during link training

On Tue, 2016-09-06 at 17:13 -0700, Manasi Navare wrote: > 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

Re: [Intel-gfx] [PATCH i-g-t] demo/Makefile.source: Compile intel_sprite_on when HAVE_LIBDRM_INTEL.

Thanks for catching this Marius. Reviewed-by Robert Foss Rob. On 2016-09-07 05:59 AM, Marius Vlad wrote: Introduced with commit cd86866dec. Signed-off-by: Marius Vlad CC: Robert Foss ---

[Intel-gfx] [PATCH i-g-t] assembler, lib, overlay, tools, tests/: Fix warnings about unused variables.

Signed-off-by: Marius Vlad --- assembler/gen8_disasm.c | 5 - lib/intel_device_info.c | 6 -- overlay/igfx.c| 7 --- tests/testdisplay.c | 1 - tools/intel_bios_reader.c | 22 -- 5 files changed, 41 deletions(-)

Re: [Intel-gfx] [PATCH] tools/intel_guc_logger: Utility for capturing GuC firmware logs in a file

On Wed, Sep 07, 2016 at 01:40:27PM +0530, Goel, Akash wrote: > > > On 9/6/2016 9:22 PM, Tvrtko Ursulin wrote: > > > >On 06/09/16 16:33, Goel, Akash wrote: > >>On 9/6/2016 6:47 PM, Tvrtko Ursulin wrote: > >>>Hi, > >>> > >>>On 06/09/16 11:43, akash.g...@intel.com wrote: > From: Akash Goel

Re: [Intel-gfx] [PATCH] tools/intel_guc_logger: Utility for capturing GuC firmware logs in a file

On 9/7/2016 3:07 PM, Tvrtko Ursulin wrote: On 07/09/16 09:44, Chris Wilson wrote: On Wed, Sep 07, 2016 at 01:40:27PM +0530, Goel, Akash wrote: On 9/6/2016 9:22 PM, Tvrtko Ursulin wrote: [snip] +while (!stop_logging) +{ +if (test_duration && (igt_seconds_elapsed() >

[Intel-gfx] [PATCH i-g-t] demo/Makefile.source: Compile intel_sprite_on when HAVE_LIBDRM_INTEL.

Introduced with commit cd86866dec. Signed-off-by: Marius Vlad CC: Robert Foss --- demos/Makefile.sources | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/demos/Makefile.sources b/demos/Makefile.sources index

[Intel-gfx] [PATCH] drm: squash lines for simple wrapper functions

Remove unneeded variables and assignments. Signed-off-by: Masahiro Yamada --- drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c | 6 +- drivers/gpu/drm/amd/amdgpu/sdma_v2_4.c| 6 +- drivers/gpu/drm/amd/amdgpu/sdma_v3_0.c| 6

Re: [Intel-gfx] [PATCH] tools/intel_guc_logger: Utility for capturing GuC firmware logs in a file

On Wed, Sep 07, 2016 at 10:37:07AM +0100, Tvrtko Ursulin wrote: > > On 07/09/16 09:44, Chris Wilson wrote: > >And fixing the blocking read() is about 10 lines in the kernel... > > Haven't checked but if that is the case, since we are already fixing > relayfs issues, it would be good to do that

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

Reviewed-by: Mika Kahola On Fri, 2016-09-02 at 22:05 +0300, Pandiyan, Dhinakaran wrote: > On Fri, 2016-09-02 at 14:20 +0300, Mika Kahola wrote: > > > > On Thu, 2016-09-01 at 15:08 -0700, Manasi Navare wrote: > > > > > > Fix the number of tries in channel euqalization

[Intel-gfx] [PATCH v4 09/25] drm/i915/slpc: If using SLPC, do not set frequency

From: Tom O'Rourke When frequency requests are made by SLPC, host driver should not attempt to make frequency requests due to potential conflicts. Host-based turbo operations are already avoided when SLPC is used. This change covers other frequency requests such as from

[Intel-gfx] [PATCH v4 07/25] drm/i915/slpc: Use intel_slpc_* functions if supported

From: Tom O'Rourke On platforms with SLPC support: call intel_slpc_*() functions from corresponding intel_*_gt_powersave() functions; and do not use rps functions. v1: Return void instead of ignored error code (Paulo) enable/disable RC6 in SLPC flows (Sagar)

[Intel-gfx] [PATCH v4 02/25] drm/i915/slpc: Expose guc functions for use with SLPC

From: Tom O'Rourke Expose host2guc_action for use by SLPC in intel_slpc.c. Expose functions to allocate and release objects used by GuC to be used for SLPC shared memory object. v1: Updated function names as they need to be made extern. (ChrisW) Reviewed-by: David

[Intel-gfx] [PATCH v4 04/25] drm/i915/slpc: Add SKL SLPC Support

From: Tom O'Rourke This patch adds has_slpc to skylake info. The SLPC interface has changed and could continue to change. Only GuC versions known to be compatible are supported here. On Skylake, GuC firmware v6 is supported. Other platforms and versions can be added

[Intel-gfx] [PATCH v4 05/25] drm/i915/slpc: Add enable_slpc module parameter

From: Tom O'Rourke i915.enable_slpc is used to override the default for slpc usage. The expected values are -1=auto, 0=disabled [default], 1=enabled. slpc_enable_sanitize() converts i915.enable_slpc to either 0 or 1. Interpretation of default value is based on

[Intel-gfx] [PATCH v4 12/25] drm/i915/slpc: Send reset event

From: Tom O'Rourke Add host2guc SLPC reset event and send reset event during enable. v1: Extract host2guc_slpc to handle slpc status code coding style changes (Paulo) Removed WARN_ON for checking msb of gtt address of shared gem obj. (ChrisW)

[Intel-gfx] [PATCH v4 13/25] drm/i915/slpc: Send shutdown event

From: Tom O'Rourke Send SLPC shutdown event during disable, suspend, and reset operations. Sending shutdown event while already shutdown is OK. v1: Return void instead of ignored error code (Paulo) Removed WARN_ON for checking msb of gtt address of shared gem

[Intel-gfx] [PATCH v4 10/25] drm/i915/slpc: Allocate/Release/Initialize SLPC shared data

From: Tom O'Rourke SLPC shared data is used to pass information to/from SLPC in GuC firmware. For Skylake, platform sku type and slice count are identified from device id and fuse values. Support for other platforms needs to be added. v1: Update for SLPC interface

[Intel-gfx] [PATCH v4 06/25] drm/i915/slpc: Sanitize SLPC version

From: Tom O'Rourke The SLPC interface has changed and could continue to change. Only GuC versions known to be compatible are supported here. On Skylake, GuC firmware v9 is supported. Other platforms and versions can be added here later. v1: Updated with modified

[Intel-gfx] [PATCH v4 11/25] drm/i915/slpc: Update sysfs/debugfs interfaces for frequency parameters

From: Tom O'Rourke When SLPC is controlling requested frequency, the rps.cur_freq value is not used to make the frequency request. Requested frequency from register RPNSWREQ has the value most recently requested by SLPC firmware. Adding new sysfs interface

[Intel-gfx] [PATCH v4 14/25] drm/i915/slpc: Add slpc_status enum values

From: Tom O'Rourke v1: fix whitespace (Sagar) v2-v3: Rebase. v4: Updated with GuC firmware v9. Signed-off-by: Tom O'Rourke Signed-off-by: Sagar Arun Kamble --- drivers/gpu/drm/i915/intel_slpc.h | 26

[Intel-gfx] [PATCH v4 18/25] drm/i915/slpc: Add i915_slpc_info to debugfs

From: Tom O'Rourke i915_slpc_info shows the contents of SLPC shared data parsed into text format. v1: Reformat slpc info (Radek) squashed query task state info in slpc info, kunmap before seq_print (Paulo) return void instead of ignored return value (Paulo)

[Intel-gfx] [PATCH v4 23/25] drm/i915/slpc: Keep RP SW Mode enabled while disabling rps

With SLPC, only RP SW Mode control should be left enabled by i915. Else, SLPC requests through through RPNSWREQ will not be granted. Signed-off-by: Sagar Arun Kamble --- drivers/gpu/drm/i915/intel_pm.c | 8 +++- 1 file changed, 7 insertions(+), 1 deletion(-) diff

[Intel-gfx] [PATCH v4 15/25] drm/i915/slpc: Add parameter unset/set/get functions

From: Tom O'Rourke Add slpc_param_id enum values. Add events for setting/unsetting parameters. v1: Use host2guc_slpc update slcp_param_id enum values for SLPC 2015.2.4 return void instead of ignored error code (Paulo) v2: Checkpatch update. v3: Rebase. v4:

[Intel-gfx] [PATCH v4 00/25] Add support for GuC-based SLPC

SLPC (Single Loop Power Controller) is a replacement for some host-based power management features. The SLPC implementation runs in firmware on GuC. This series has been tested with SKL GuC firmware version 9.18 which is yet to be released. Performance and power testing with these patches and

[Intel-gfx] [PATCH v4 01/25] drm/i915: Remove RPM suspend dependency on rps.enabled and related changes

For Gen9, RPM suspend is dependent on rps.enabled. This is needed for other platforms as RC6 and RPS enabling is indicated by rps.enabled. RPM Suspend depends only on RC6, so we need to remove the check of rps.enabled. For Gen9 RC6 and RPS enabling is separated hence do rps.enabled check only for

[Intel-gfx] [PATCH v4 17/25] drm/i915/slpc: Add enable/disable debugfs for slpc

From: Tom O'Rourke Adds debugfs hooks for each slpc task. The enable/disable debugfs files are i915_slpc_gtperf, i915_slpc_balancer, and i915_slpc_dcc. Each of these can take the values: "default", "enabled", or "disabled" v1: update for SLPC v2015.2.4 dfps and

[Intel-gfx] [PATCH v4 19/25] drm/i915/slpc: Add Broxton SLPC support

From: Tom O'Rourke Adds has_slpc to broxton info and adds broxton firmware version check to sanitize_slpc_option. v1: Adjusted slpc version check for major version 8. Added message if version mismatch happens for easier debug. (Sagar) v2-v3: Rebase. v4: Commit

[Intel-gfx] [PATCH v4 16/25] drm/i915/slpc: Add slpc support for max/min freq

From: Tom O'Rourke Update sysfs and debugfs functions to set SLPC parameters when setting max/min frequency. v1: Update for SLPC 2015.2.4 (params for both slice and unslice) Replace HAS_SLPC with intel_slpc_active() (Paulo) Signed-off-by: Tom O'Rourke

[Intel-gfx] [PATCH v4 08/25] drm/i915/slpc: Enable SLPC in guc if supported

From: Tom O'Rourke If slpc enabled, then add enable SLPC flag to guc control parameter during guc load. v1: Use intel_slpc_enabled() (Paulo) Reviewed-by: David Weinehall Signed-off-by: Tom O'Rourke

[Intel-gfx] [PATCH v4 03/25] drm/i915/slpc: Add has_slpc capability flag

From: Tom O'Rourke Add has_slpc capablity flag to indicate GuC firmware supports single loop power control (SLPC). SLPC is a replacement for some host-based power management features. v1: fix whitespace (Sagar) Reviewed-by: David Weinehall

[Intel-gfx] [PATCH v4 20/25] drm/i915/slpc: Only Enable GTPERF, Disable DCC, Balancer, IBC, FPS Stall

v1: Updated tasks and frequency post reset. Added DFPS param update for MAX_FPS and FPS Stall. v2-v3: Rebase. v4: Updated with GuC firmware v9. Signed-off-by: Sagar Arun Kamble --- drivers/gpu/drm/i915/i915_debugfs.c | 2 +- drivers/gpu/drm/i915/intel_slpc.c |

[Intel-gfx] [PATCH v4 24/25] drm/i915: Add sysfs interface to know the HW requested frequency

With SLPC, user can read this value to know SLPC requested frequency. Signed-off-by: Sagar Arun Kamble --- drivers/gpu/drm/i915/i915_sysfs.c | 28 1 file changed, 28 insertions(+) diff --git a/drivers/gpu/drm/i915/i915_sysfs.c

[Intel-gfx] [PATCH v4 21/25] drm/i915/slpc: Update freq min/max softlimits

v2: Removing checks for vma obj and kmap_atomic validity. (Chris) v3: Rebase. v4: Updated to make sure SLPC enable keeps min/max freq softlimits unchanged after initializing once. (Chris) Signed-off-by: Sagar Arun Kamble --- drivers/gpu/drm/i915/intel_slpc.c | 47

[Intel-gfx] [PATCH v4 25/25] drm/i915: Mark GuC load status as PENDING in i915_drm_resume_early

This will help avoid Host to GuC actions being called till GuC gets loaded during i915_drm_resume. v2-v3: Rebase. Signed-off-by: Sagar Arun Kamble --- drivers/gpu/drm/i915/i915_drv.c | 7 +++ 1 file changed, 7 insertions(+) diff --git

[Intel-gfx] [PATCH v4 22/25] drm/i915/slpc: Check GuC load status in SLPC active check

SLPC status has to be linked with GuC load status to make sure SLPC actions get invoked when GuC is loaded. v2: Space and function return convention issues. (Deepak) v3: Rebase. v4: Limiting the check for SLPC actions. Signed-off-by: Sagar Arun Kamble ---

Re: [Intel-gfx] [PATCH] drm: Move property validation to a helper.

Op 07-09-16 om 10:58 schreef Maarten Lankhorst: > Property lifetimes are equal to the device lifetime, so the separate > drm_property_find is not needed. The pointer can be retrieved from > the properties member, which saves us some locking and a extra lookup. > > The lifetime for properties is

[Intel-gfx] [PATCH v6 1/4] drm/i915/debugfs: Move out pipe CRC code

In preparation to using a generic API in the DRM core for continuous CRC generation, move the related code out of i915_debugfs.c into a new file. Eventually, only the Intel-specific code will remain in this new file. v2: Rebased. v6: Rebased. Signed-off-by: Tomeu Vizoso

[Intel-gfx] [PATCH v6 3/4] drm/i915: Use new CRC debugfs API

The core provides now an ABI to userspace for generation of frame CRCs, so implement the ->set_crc_source() callback and reuse as much code as possible with the previous ABI implementation. v2: - Leave the legacy implementation in place as the ABI implementation in the core is

[Intel-gfx] [PATCH v6 4/4] drm/i915: Put "cooked" vlank counters in frame CRC lines

Use drm_accurate_vblank_count so we have the full 32 bit to represent the frame counter and userspace has a simpler way of knowing when the counter wraps around. Signed-off-by: Tomeu Vizoso --- drivers/gpu/drm/i915/i915_irq.c | 6 +++--- 1 file changed, 3

[Intel-gfx] [PATCH v6 0/4] New debugfs API for capturing CRC of frames

Hi, this series basically takes the facility for continuously capturing CRCs of frames from the i915 driver and into the DRM core. The idea is that test suites such as IGT use this information to check that frames that are exected to be identical, also have identical CRC values. Other drivers

Re: [Intel-gfx] [PATCH i-g-t] benchmarks/gem_busy: Fix compile error

Applied. Thanks! On Tue, Sep 06, 2016 at 03:55:41PM +0100, Derek Morton wrote: > The benchmark was failing with: > gem_busy.c:158:8: error: implicit declaration of function 'intel_gen' > is invalid in C99 [-Werror,-Wimplicit-function-declaration] > gen = intel_gen(intel_get_drm_devid(fd)); > >

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

On Tue, 2016-09-06 at 17:13 -0700, Manasi Navare wrote: > 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. > Call the function that loops

[Intel-gfx] [PATCH] drm: Move property validation to a helper.

Property lifetimes are equal to the device lifetime, so the separate drm_property_find is not needed. The pointer can be retrieved from the properties member, which saves us some locking and a extra lookup. The lifetime for properties is until the device is destroyed, which happens late in the

Re: [Intel-gfx] [PATCH v4 10/25] drm/i915/slpc: Allocate/Release/Initialize SLPC shared data

Hi Tom, [auto build test ERROR on drm-intel/for-linux-next] [also build test ERROR on next-20160907] [cannot apply to v4.8-rc5] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] [Suggest to use git(>=2.9.0) format-patch --base= (or --base=a

[Intel-gfx] [PATCH v2 04/22] drm/i915: Compute the ELSP register location once

Similar to the issue with reading from the context status buffer, see commit 26720ab97fea ("drm/i915: Move CSB MMIO reads out of the execlists lock"), we frequently write to the ELSP register (4 writes per interrupt) and know we hold the required spinlock and forcewake throughout. We can further

[Intel-gfx] [PATCH v2 06/22] drm/i915: Simplify ELSP queue request tracking

Emulate HW to track and manage ELSP queue. A set of SW ports are defined and requests are assigned to these ports before submitting them to HW. This helps in cleaning up incomplete requests during reset recovery easier especially after engine reset by decoupling elsp queue management. This will

[Intel-gfx] [PATCH v2 10/22] drm/i915: Mark up all locked waiters

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 must first know whether we hold the struct_mutex. If we do not hold the struct_mtuex we can not perform the reset, but we do not block

[Intel-gfx] [PATCH v2 02/22] drm/i915: Only queue requests during execlists submission

Leave the more complicated request dequeueing to the tasklet and instead just kick start the tasklet if we detect we are adding the first request. v2: Play around with list operators until we agree upon something Signed-off-by: Chris Wilson Cc: Mika Kuoppala

[Intel-gfx] [PATCH v2 15/22] drm/i915: Reorder i915_add_request to separate the phases better

Let's avoid mixing sealing the hardware commands for the request and adding the request to the software tracking. Signed-off-by: Chris Wilson Reviewed-by: Mika Kuoppala --- drivers/gpu/drm/i915/i915_gem_request.c | 28

[Intel-gfx] [PATCH v2 21/22] 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 09/22] drm/i915: Expand bool interruptible to pass flags to i915_wait_request()

We need finer control over wakeup behaviour during i915_wait_request(), so expand the current bool interruptible to a bitmask. Signed-off-by: Chris Wilson Reviewed-by: Joonas Lahtinen --- drivers/gpu/drm/i915/i915_debugfs.c | 2

[Intel-gfx] [PATCH v2 17/22] drm/i915/guc: Prepare for nonblocking execbuf submission

Currently the presumption is that the request construction and its submission to the GuC are all under the same holding of struct_mutex. We wish to relax this to separate the request construction and the later submission to the GuC. This requires us to reserve some space in the GuC command queue

[Intel-gfx] [PATCH v2 01/22] drm/i915: Add a sw fence for collecting up dma fences

This is really a core kernel struct in disguise until we can finally place it in kernel/. There is an immediate need for a fence collection mechanism that is more flexible than fence-array, in particular being able to easily drive request submission via events (and not just interrupt driven). The

[Intel-gfx] [PATCH v2 03/22] drm/i915: Record the position of the workarounds in the tail of the request

Rather than blindly assuming we need to advance the tail for resubmitting the request via the ELSP, record the position. Signed-off-by: Chris Wilson Reviewed-by: Mika Kuoppala --- drivers/gpu/drm/i915/i915_gem_request.h | 15 +--

[Intel-gfx] [PATCH v2 08/22] drm/i915: Drop local struct_mutex around intel_init_emon[ilk]

Access to intel_init_emon() is strictly ordered by gt_powersave, using struct_mutex around it is overkill (and will conflict with the caller holding struct_mutex themselves). Signed-off-by: Chris Wilson Reviewed-by: Mika Kuoppala ---

[Intel-gfx] [PATCH v2 18/22] drm/i915: Ignore valid but unknown semaphores

If we find a ring waiting on a semaphore for another assigned but not yet emitted request, treat it as valid and waiting. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/i915_irq.c | 9 ++--- 1 file changed, 6 insertions(+), 3 deletions(-) diff --git

[Intel-gfx] [PATCH v2 07/22] drm/i915: Separate out reset flags from the reset counter

In preparation for introducing a per-engine reset, we can first separate the mixing of the reset state from the global reset counter. The loss of atomicity in updating the reset state poses a small problem for handling the waiters. For requests, this is solved by advancing the seqno so that a

Re: [Intel-gfx] [RFC] Idleness DRRS test

On Wed, Aug 31, 2016 at 01:46:03PM +0530, Nautiyal Ankit wrote: > From: aknautiy > > Idleness DRRS: > By default the DRRS state will be at DRRS_HIGH_RR. When a Display > content is Idle for more than 1Sec Idleness will be declared and > DRRS_LOW_RR

[Intel-gfx] [PATCH v2 19/22] drm/i915: Nonblocking request submission

Now that we have fences in place to drive request submission, we can employ those to queue requests after their dependencies as opposed to stalling in the middle of an execbuf ioctl. (However, we still choose to spin before enabling the IRQ as that is faster - though contentious.) v2: Do the

[Intel-gfx] [PATCH v2 12/22] drm/i915: Replace wait-on-mutex with wait-on-bit in reset worker

Since we have a cooperative mode now with a direct reset, we can avoid the contention on struct_mutex and instead try then sleep on the I915_RESET_IN_PROGRESS bit. If the mutex is held and that bit is cleared, all is fine. Otherwise, we sleep for a bit and try again. In the worst case we sleep for

[Intel-gfx] [PATCH v2 14/22] drm/i915: Drive request submission through fence callbacks

Drive final request submission from a callback from the fence. This way the request is queued until all dependencies are resolved, at which point it is handed to the backend for queueing to hardware. At this point, no dependencies are set on the request, so the callback is immediate. A

[Intel-gfx] [PATCH v2 05/22] drm/i915: Reorder submitting the requests to ELSP

Just rearrange the code to reduce churn in the next patch. Signed-off-by: Chris Wilson Reviewed-by: Mika Kuoppala --- drivers/gpu/drm/i915/intel_lrc.c | 76 1 file changed, 38 insertions(+), 38

[Intel-gfx] [PATCH v2 13/22] drm/i915: Update reset path to fix incomplete requests

Update reset path in preparation for engine reset which requires identification of incomplete requests and associated context and fixing their state so that engine can resume correctly after reset. The request that caused the hang will be skipped and head is reset to the start of breadcrumb. This

[Intel-gfx] [PATCH v2 20/22] drm/i915: Serialise execbuf operation after a dma-buf reservation object

Now that we can wait upon fences before emitting the request, it becomes trivial to wait upon any implicit fence provided by the dma-buf reservation object. Testcase: igt/prime_vgem/fence-wait Signed-off-by: Chris Wilson Reviewed-by: John Harrison

[Intel-gfx] [PATCH v2 16/22] drm/i915: Prepare object synchronisation for asynchronicity

We are about to specialize object synchronisation to enable nonblocking execbuf submission. First we make a copy of the current object synchronisation for execbuffer. The general i915_gem_object_sync() will be removed following the removal of CS flips in the near future. Signed-off-by: Chris

[Intel-gfx] [PATCH v2 11/22] drm/i915: Perform a direct reset of the GPU from the waiter

If a waiter is holding the struct_mutex, then the reset worker cannot reset the GPU until the waiter returns. We do not want to return -EAGAIN form i915_wait_request as that breaks delicate operations like i915_vma_unbind() which often cannot be restarted easily, and returning -EIO is just as

Re: [Intel-gfx] i915 WARNING: Missing switch case (16) in gen6_check_mailbox_status

On Mon, 29 Aug 2016, Meelis Roos wrote: > Tried 4.8-rc4 on my i5-2400 PC, got this warning: Fixed in drm-intel-fixes by commit fc2780b66b15092ac68272644a522c1624c48547 Author: Chris Wilson Date: Fri Aug 26 11:59:26 2016 +0100 drm/i915: Add

Re: [Intel-gfx] [PATCH v4 10/25] drm/i915/slpc: Allocate/Release/Initialize SLPC shared data

On 07/09/16 14:52, kbuild test robot wrote: Hi Tom, [auto build test ERROR on drm-intel/for-linux-next] [also build test ERROR on next-20160907] [cannot apply to v4.8-rc5] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] [Suggest to use git

Re: [Intel-gfx] Linux 4.8-rc?: WARNING: at drivers/gpu/drm/i915/intel_pm.c:7866 sandybridge_pcode_write Missing switch case (16) in gen6_check_mailbox_status

On Tue, 06 Sep 2016, li...@eikelenboom.it wrote: > On 2016-09-06 11:25, Jani Nikula wrote: >> On Tue, 06 Sep 2016, li...@eikelenboom.it wrote: >>> L.S., >>> >>> Since one of the last 4.8 RC's i'm getting the warning below when >>> booting on my sandybridge based thinkpad. >>> From what it seems

Re: [Intel-gfx] [PATCH v2] tools/intel_guc_logger: Utility for capturing GuC firmware logs in a file

On 07/09/16 16:27, akash.g...@intel.com wrote: From: Akash Goel This patch provides a test utility which helps capture GuC firmware logs and then dump them to file. The logs are pulled from a debugfs file '/sys/kernel/debug/dri/guc_log' and stored into a file

Re: [Intel-gfx] [PATCH 1/1] drm/i915/dsi: silence a warning about uninitialized return value

On 06/09/16 21:36, Nicolas Iooss wrote: On 06/09/16 12:21, Dave Gordon wrote: On 04/09/16 19:58, Nicolas Iooss wrote: When building the kernel with clang and some warning flags, the compiler reports that the return value of dcs_get_backlight() may be uninitialized:

Re: [Intel-gfx] [PATCH] drm: squash lines for simple wrapper functions

> -Original Message- > From: Masahiro Yamada [mailto:yamada.masah...@socionext.com] > Sent: Tuesday, September 06, 2016 7:04 PM > To: David Airlie; dri-de...@lists.freedesktop.org > Cc: Masahiro Yamada; Gustavo Padovan; Yakir Yang; Huang, Ray; Deucher, > Alexander; Liu, Monk; Zhou,

[Intel-gfx] ✗ Fi.CI.BAT: warning for series starting with [01/21] drm/i915: Add a sw fence for collecting up dma fences (rev22)

== Series Details == Series: series starting with [01/21] drm/i915: Add a sw fence for collecting up dma fences (rev22) URL : https://patchwork.freedesktop.org/series/12007/ State : warning == Summary == Series 12007v22 Series without cover letter

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

My only thought is that it seems like we prefix functions skl_, kbl_, etc. just to indicate which generation introduced the feature. Skl uses quite a few sandybridge and haswell functions. If this is a little closer to what most intel devs would expect the naming to be though then: Reviewed-by:

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

On Tue, Sep 06, 2016 at 09:52:14PM -0300, Paulo Zanoni wrote: > 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. IIRC bspec doesn't specify the sagv latency for anything but SKL, and the relevant

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

On Tue, 2016-09-06 at 21:52 -0300, Paulo Zanoni wrote: > 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

[Intel-gfx] [PATCH v2] tools/intel_guc_logger: Utility for capturing GuC firmware logs in a file

From: Akash Goel This patch provides a test utility which helps capture GuC firmware logs and then dump them to file. The logs are pulled from a debugfs file '/sys/kernel/debug/dri/guc_log' and stored into a file '/tmp/guc_log_dump.dat', the name of the output file can be

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

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 the sagv for skylake did happen to get added right before

[Intel-gfx] [PATCH v2 22/22] drm/i915: Support explicit fencing for execbuf

Now that the user can opt-out of implicit fencing, we need to give them back control over the fencing. We employ sync_file to wrap our drm_i915_gem_request and provide an fd that userspace can merge with other sync_file fds and pass back to the kernel to wait upon before future execution.

Re: [Intel-gfx] [PATCH] drm: squash lines for simple wrapper functions

Hi Jani, 2016-09-07 17:34 GMT+09:00 Jani Nikula : > On Wed, 07 Sep 2016, Masahiro Yamada wrote: >> Remove unneeded variables and assignments. >> >> Signed-off-by: Masahiro Yamada > > ... > >> diff --git

Re: [Intel-gfx] [PATCH v8 07/12] drm/i915: Read DP branch device HW revision

On Wed, Aug 17, 2016 at 01:49:43PM +0300, Mika Kahola wrote: > HW revision is mandatory field for DisplayPort branch > devices. This is defined in DPCD register field 0x509. > > v2: move drm_dp_ds_revision structure to be part of > drm_dp_link structure (Daniel) > v3: remove dependency to

Re: [Intel-gfx] [PATCH v8 09/12] Check pixel rate for DP to VGA dongle

On Wed, Aug 17, 2016 at 01:49:45PM +0300, Mika Kahola wrote: > Filter out a mode that exceeds the max pixel rate setting > for DP to VGA dongle. This is defined in DPCD register 0x81 > if detailed cap info i.e. info field is 4 bytes long and > it is available for DP downstream port. > > The

Re: [Intel-gfx] [PATCH v8 12/12] drm/i915: Check TMDS clock DP to HDMI dongle

On Wed, Aug 17, 2016 at 01:49:49PM +0300, Mika Kahola wrote: > Respect max TMDS clock frequency from DPCD for active > DP to HDMI adapters. > > Signed-off-by: Mika Kahola Reviewed-by: Jim Bride > --- > drivers/gpu/drm/i915/intel_drv.h | 3

Re: [Intel-gfx] [PATCH v8 06/12] drm/i915: Cleanup DisplayPort AUX channel initialization

On Wed, Aug 17, 2016 at 01:49:42PM +0300, Mika Kahola wrote: > Let's remove reference to "struct intel_connector *connector" > in intel_dp_aux_init() function as it is no longer required. > > Signed-off-by: Mika Kahola Reviewed-by: Jim Bride >

Re: [Intel-gfx] [PATCH v8 11/12] drm: Add DP branch device info on debugfs

On Wed, Aug 17, 2016 at 01:49:48PM +0300, Mika Kahola wrote: > Read DisplayPort branch device info from through debugfs > interface. > > v2: use drm_dp_helper routines to collect data > v3: cleanup to match the drm_dp_helper.c patches introduced > earlier in this series > v4: move DP branch

Re: [Intel-gfx] [PATCH v8 08/12] drm/i915: Read DP branch device SW revision

On Wed, Aug 17, 2016 at 01:49:44PM +0300, Mika Kahola wrote: > SW revision is mandatory field for DisplayPort branch > devices. This is defined in DPCD register field 0x50A. To be precise, the revision info is in 0x50A and 0x50B. Since both the major and minor versions are called out separately

Re: [Intel-gfx] Linux 4.8-rc?: WARNING: at drivers/gpu/drm/i915/intel_pm.c:7866 sandybridge_pcode_write Missing switch case (16) in gen6_check_mailbox_status

On 2016-09-07 16:49, Jani Nikula wrote: On Tue, 06 Sep 2016, li...@eikelenboom.it wrote: On 2016-09-06 11:25, Jani Nikula wrote: On Tue, 06 Sep 2016, li...@eikelenboom.it wrote: L.S., Since one of the last 4.8 RC's i'm getting the warning below when booting on my sandybridge based thinkpad.

  1   2   >