Re: [Intel-gfx] [Announcement] 2016-Q1 release of XenGT - a Mediated Graphics Passthrough Solution from Intel

Hi all, We are pleased to announce another update of Intel GVT-g for Xen. Intel GVT-g is a full GPU virtualization solution with mediated pass-through, starting from 4th generation Intel Core(TM) processors with Intel Graphics processors. A virtual GPU instance is maintained for each VM, with

[Intel-gfx] linux-next: build failure after merge of the drm tree

Hi Dave, After merging the drm tree, today's linux-next build (x86_64 allmodconfig) failed like this: drivers/gpu/drm/i915/intel_ddi.c: In function 'intel_prepare_ddi_buffer': drivers/gpu/drm/i915/intel_ddi.c:447:15: error: 'struct drm_i915_private' has no member named 'edp_low_vswing' if

[Intel-gfx] [PATCH 04/21] 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 20/21] 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. v2: 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 21/21] drm/i915/slpc: Fail intel_runtime_suspend if SLPC or RPS not active

From: Sagar Arun Kamble intel_runtime_suspend failed with warning if RPS was disabled. With SLPC enabled, RPS is disabled. With SLPC, warning is now changed to consider SLPC active status as well. This will ensure runtime suspend proceeds when SLPC enabled. v2: Commit

[Intel-gfx] [PATCH 08/21] drm/i915/slpc: Allocate/Release/Initialize SLPC shared data

From: Tom O'Rourke SLPC shared data is used to pass information to/from SLPC 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. v2: Update for SLPC interface version

[Intel-gfx] [PATCH 12/21] 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. v2: return void instead of ignored error code (Paulo) Signed-off-by: Tom O'Rourke ---

[Intel-gfx] [PATCH 11/21] drm/i915/slpc: Send reset event

From: Tom O'Rourke Add host2guc SLPC reset event and send reset event during enable. v2: extract host2guc_slpc to handle slpc status code coding style changes (Paulo) Signed-off-by: Tom O'Rourke --- drivers/gpu/drm/i915/intel_slpc.c | 33

[Intel-gfx] [PATCH 15/21] drm/i915/slpc: Notification of Refresh Rate change

From: Sagar Arun Kamble This patch will inform GuC SLPC about changes in the refresh rate due to Seamless DRRS. Refresh rate changes due to Static DRRS will be notified via commit path. v2: Rebased on previous changed patch and printed error message if H2G action

[Intel-gfx] [PATCH 13/21] drm/i915/slpc: Add Display mode event related data structures

From: Sagar Arun Kamble v2: Cleaning up defines for number of pipes and other cosmetic changes. v3: Checkpatch fixes. Signed-off-by: Sagar Arun Kamble Acked-by: Tom O'Rourke --- drivers/gpu/drm/i915/intel_slpc.h |

[Intel-gfx] [PATCH 07/21] 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 09/21] drm/i915/slpc: Setup rps frequency values during SLPC init

From: Tom O'Rourke v2: Add mutex lock/unlock Signed-off-by: Tom O'Rourke --- drivers/gpu/drm/i915/intel_drv.h | 1 + drivers/gpu/drm/i915/intel_pm.c | 2 +- drivers/gpu/drm/i915/intel_slpc.c | 5 + 3 files changed, 7 insertions(+), 1

[Intel-gfx] [PATCH 10/21] drm/i915/slpc: Update current requested frequency

From: Tom O'Rourke When SLPC is controlling requested frequency, the rps.cur_freq value is not used to make the frequency request. Before using rps.cur_freq in sysfs or debugfs, read requested frequency from register to get the value most recently requested by SLPC

[Intel-gfx] [PATCH 14/21] drm/i915/slpc: Notification of Display mode change

From: Sagar Arun Kamble GuC SLPC needs to be sent data related to Active pipes, refresh rates, widi pipes, fullscreen pipes related via host to GuC display mode change event. Based on this, SLPC will track FPS on active pipes. This patch defines the events and

[Intel-gfx] [PATCH 06/21] 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. v2: Use intel_slpc_enabled() (Paulo) Signed-off-by: Tom O'Rourke --- drivers/gpu/drm/i915/intel_guc_loader.c | 3 +++ 1 file changed, 3

[Intel-gfx] [PATCH 01/21] 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. Signed-off-by: Tom O'Rourke ---

[Intel-gfx] [PATCH 02/21] 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. v2: fix whitespace (Sagar) Signed-off-by: Tom O'Rourke ---

[Intel-gfx] [PATCH 05/21] 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. v2: return void instead of ignored error code (Paulo) enable/disable RC6 in SLPC flows (Sagar)

Re: [Intel-gfx] RFC: libdrm: Support Iris Graphics 540 & 550 (Skylake GT3e)

On Wednesday, April 27, 2016 9:37:07 AM PDT Thorsten Leemhuis wrote: > Thorsten Leemhuis wrote on 26.04.2016 13:41: > > Lo! Below patch adds the PCI-ID for the Intel(R) Iris Graphics 550 (Skylake > > GT3e mobile) to libdrm. It afaics is the last piece that is missing to > > make those GPUs work

[Intel-gfx] [PATCH 17/21] 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. v2: use host2guc_slpc update slcp_param_id enum values for SLPC 2015.2.4 return void instead of ignored error code (Paulo) Signed-off-by: Tom O'Rourke

[Intel-gfx] [PATCH 03/21] drm/i915/slpc: Add slpc_version_check

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 v6 is supported. Other platforms and versions can be added here later. This patch also adds has_slpc

[Intel-gfx] [PATCH 18/21] 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. v2: 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 16/21] drm/i915/slpc: Add slpc_status enum values

From: Tom O'Rourke v2: fix whitespace (Sagar) Signed-off-by: Tom O'Rourke --- drivers/gpu/drm/i915/intel_slpc.h | 27 +++ 1 file changed, 27 insertions(+) diff --git a/drivers/gpu/drm/i915/intel_slpc.h

[Intel-gfx] [PATCH 19/21] 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" v2: update for SLPC v2015.2.4 dfps and

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

From: Tom O'Rourke SLPC (Single Loop Power Controller) is a replacement for some host-based power management features. The SLPC implemenation runs in firmware on GuC. This series has been tested with SKL guc firmware version 6.1. The graphics power management features

Re: [Intel-gfx] [PATCH 01/19] drm/core: Add drm_accurate_vblank_count, v5.

Anyway, although i would have liked the stricter check and warning docs, the v4 patch is ok with me: Reviewed-by: Mario Kleiner -mario On 04/25/2016 08:32 AM, Maarten Lankhorst wrote: This function is useful for gen2 intel devices which have no frame counter, but

Re: [Intel-gfx] [PATCH] i915 suspend/resume_noirq instead of suspend_late/resume_early

On Wed, 2016-04-27 at 22:33 +0200, Lukas Wunner wrote: > Hi, > > On Wed, Apr 27, 2016 at 11:46:22AM -0700, Todd Brandt wrote: > >  I'd like to propose that we push the i915 > > suspend_late/resume_early code > >  into suspend_noirq/resume_noirq in order to reduce the total > > suspend time > >  

Re: [Intel-gfx] [PATCH] i915 suspend/resume_noirq instead of suspend_late/resume_early

On Wed, 2016-04-27 at 23:49 +0300, Ville Syrjälä wrote: > On Wed, Apr 27, 2016 at 01:17:15PM -0700, Todd Brandt wrote: > > On Wed, 2016-04-27 at 22:31 +0300, Ville Syrjälä wrote: > > > On Wed, Apr 27, 2016 at 11:46:22AM -0700, Todd Brandt wrote: > > > > I'd like to propose that we push the i915

Re: [Intel-gfx] [PATCH] i915 suspend/resume_noirq instead of suspend_late/resume_early

On Wed, 2016-04-27 at 13:49 -0700, Todd Brandt wrote: > On Wed, 2016-04-27 at 22:33 +0200, Lukas Wunner wrote: > > Hi, > > > > On Wed, Apr 27, 2016 at 11:46:22AM -0700, Todd Brandt wrote: > > > I'd like to propose that we push the i915 suspend_late/resume_early code > > > into

Re: [Intel-gfx] [PATCH] i915 suspend/resume_noirq instead of suspend_late/resume_early

On Wed, Apr 27, 2016 at 01:17:15PM -0700, Todd Brandt wrote: > On Wed, 2016-04-27 at 22:31 +0300, Ville Syrjälä wrote: > > On Wed, Apr 27, 2016 at 11:46:22AM -0700, Todd Brandt wrote: > > > I'd like to propose that we push the i915 suspend_late/resume_early code > > > into

Re: [Intel-gfx] [PATCH] i915 suspend/resume_noirq instead of suspend_late/resume_early

On Wed, 2016-04-27 at 22:33 +0200, Lukas Wunner wrote: > Hi, > > On Wed, Apr 27, 2016 at 11:46:22AM -0700, Todd Brandt wrote: > > I'd like to propose that we push the i915 suspend_late/resume_early code > > into suspend_noirq/resume_noirq in order to reduce the total suspend time > > by ~15ms.

Re: [Intel-gfx] [PATCH] i915 suspend/resume_noirq instead of suspend_late/resume_early

Hi, On Wed, Apr 27, 2016 at 11:46:22AM -0700, Todd Brandt wrote: > I'd like to propose that we push the i915 suspend_late/resume_early code > into suspend_noirq/resume_noirq in order to reduce the total suspend time > by ~15ms. According to the comments, when i915_pm_suspend_late was first >

Re: [Intel-gfx] [PATCH] i915 suspend/resume_noirq instead of suspend_late/resume_early

On Wed, 2016-04-27 at 22:31 +0300, Ville Syrjälä wrote: > On Wed, Apr 27, 2016 at 11:46:22AM -0700, Todd Brandt wrote: > > I'd like to propose that we push the i915 suspend_late/resume_early code > > into suspend_noirq/resume_noirq in order to reduce the total suspend time > > by ~15ms.

Re: [Intel-gfx] [PATCH] i915 suspend/resume_noirq instead of suspend_late/resume_early

On Wed, Apr 27, 2016 at 11:46:22AM -0700, Todd Brandt wrote: > I'd like to propose that we push the i915 suspend_late/resume_early code > into suspend_noirq/resume_noirq in order to reduce the total suspend time > by ~15ms. According to the comments, when i915_pm_suspend_late was first >

Re: [Intel-gfx] [PATCH] drm/i915: Update RAWCLK_FREQ register on VLV/CHV

On Wed, Apr 27, 2016 at 04:09:53PM +, Vivi, Rodrigo wrote: > On Wed, 2016-04-27 at 19:08 +0300, Ville Syrjälä wrote: > > On Wed, Apr 27, 2016 at 03:54:12PM +, Vivi, Rodrigo wrote: > > > On Wed, 2016-04-27 at 17:43 +0300, ville.syrj...@linux.intel.com wr > > > ote: > > > > From: Ville

Re: [Intel-gfx] [PATCH] drm/i915: Unify VLV/CHV DPOunit clock gating disable/enable

On Mon, Apr 18, 2016 at 08:26:46PM +0300, Jani Nikula wrote: > On Mon, 18 Apr 2016, ville.syrj...@linux.intel.com wrote: > > From: Ville Syrjälä > > > > Check for VLV/CHV instead if !BXT when re-enabling DPOunit clock gating > > after DSI disable. That's what we

Re: [Intel-gfx] [CI-ping 15/15] drm/i915: Late request cancellations are harmful

On 22/04/16 23:57, John Harrison wrote: On 21/04/2016 14:04, John Harrison wrote: On 19/04/2016 13:35, Dave Gordon wrote: On 13/04/16 15:21, John Harrison wrote: On 13/04/2016 10:57, Daniel Vetter wrote: On Tue, Apr 12, 2016 at 09:03:09PM +0100, Chris Wilson wrote: Conceptually, each

[Intel-gfx] [PATCH] i915 suspend/resume_noirq instead of suspend_late/resume_early

I'd like to propose that we push the i915 suspend_late/resume_early code into suspend_noirq/resume_noirq in order to reduce the total suspend time by ~15ms. According to the comments, when i915_pm_suspend_late was first added to the kernel back in April 2014, it was done so to ensure that it

Re: [Intel-gfx] [PATCH v2 2/2] drm/i915/bxt: Fix inadvertent CPU snooping due to incorrect MOCS config

On 27/04/16 15:53, Chris Wilson wrote: On Wed, Apr 27, 2016 at 04:25:09PM +0300, Eero Tamminen wrote: Hi, On 26.04.2016 20:25, Frederick, Michael T wrote: Sorry I'm not tracking all the MOCs discussions. I just want to indicate what the coherency means in SoC for BXT. GTI sets the

Re: [Intel-gfx] Kernel Oops on 3.14.66

2016-04-27 12:03 GMT+02:00 Dave Gordon : On 27/04/16 10:19, Andreas Lampersperger wrote: Hello, has anyone here a hint for me, what can cause this error. The error occures highly sporadic on different machines with intel hd graphics (ivb_gt1). I did also some kernel

[Intel-gfx] [PATCH v2 5/5] DO NOT MERGE: change default to using GuC submission if possible

This patch simply changes the default value of "enable_guc_submission" from 0 (never) to -1 (auto). This means that GuC submission will be used if the platform has a GuC, the GuC supports the request submission protocol, and any required GuC firmwware was successfully loaded. If any of these

[Intel-gfx] [PATCH v2 4/5] drm/i915/guc: rework guc_add_workqueue_item()

Mostly little optimisations; for instance, if the driver is correctly following the submission protocol, the "out of space" condition is impossible, so the previous runtime WARN_ON() is promoted to a GEM_BUG_ON() for a more dramatic effect in development and less impact in end-user systems.

[Intel-gfx] [PATCH v2 3/5] drm/i915/guc: don't spinwait if the GuC's workqueue is full

Rather than wait to see whether more space becomes available in the GuC submission workqueue, we can just return -EAGAIN and let the caller try again in a little while. This gets rid of an uninterruptable sleep in the polling code :) We'll also add a counter to the GuC client statistics, to see

[Intel-gfx] [PATCH v2 2/5] drm/i915/guc: pass request (not client) to i915_guc_{wq_check_space, submit}()

The knowledge of how to derive the relevant client from the request should be localised within i915_guc_submission.c; the LRC code shouldn't have to know about the internal details of the GuC submission process. And all the information the GuC code needs should be encapsulated in (or reachable

[Intel-gfx] [PATCH v2 1/5] drm/i915/guc: add enable_guc_loading parameter

Split the function of "enable_guc_submission" into two separate options. The new one ("enable_guc_loading") controls only the *fetching and loading* of the GuC firmware image. The existing one is redefined to control only the *use* of the GuC for batch submission once the firmware is loaded. In

Re: [Intel-gfx] [PATCH 2/2] drm/i915/guc: default to using GuC submission where possible

On 26/04/16 15:00, Daniel Vetter wrote: On Mon, Apr 25, 2016 at 09:29:42AM +0100, Chris Wilson wrote: On Mon, Apr 25, 2016 at 08:31:07AM +0100, Dave Gordon wrote: On 22/04/16 19:51, Chris Wilson wrote: On Fri, Apr 22, 2016 at 07:45:15PM +0100, Chris Wilson wrote: On Fri, Apr 22, 2016 at

Re: [Intel-gfx] ✗ Fi.CI.BAT: warning for drm/i915: Cdclk related fixes and polish

On Wed, Apr 27, 2016 at 08:28:17PM +0300, Ville Syrjälä wrote: > On Wed, Apr 27, 2016 at 06:19:15AM -, Patchwork wrote: > > == Series Details == > > > > Series: drm/i915: Cdclk related fixes and polish > > URL : https://patchwork.freedesktop.org/series/6354/ > > State : warning > > > > ==

[Intel-gfx] [PATCH] drm/i915: Fix enc_to_dig_port() for MST encoders

For MST encoders, the encoder struct is stored in the intel_dp_mst struct, not a intel_digital_port struct. This fixes issues with hotplugging MST displays that support MST audio, where hotplugging had a surprisingly good chance of accidentally overwriting other parts of the kernel leading to

Re: [Intel-gfx] [PATCH] drm/i915: respect VBT PSR link standby configuration for HSW/BDW.

On Wed, 2016-04-27 at 16:53 +0100, Chris Wilson wrote: > On Wed, Apr 27, 2016 at 08:47:54AM -0700, Rodrigo Vivi wrote: > > We have in the history some changes on this behaviour, but > > there are many platforms out there and we don't know all panels. > > > > VBT might not be reliable but it knows

Re: [Intel-gfx] ✗ Fi.CI.BAT: warning for drm/i915: Cdclk related fixes and polish

On Wed, Apr 27, 2016 at 06:19:15AM -, Patchwork wrote: > == Series Details == > > Series: drm/i915: Cdclk related fixes and polish > URL : https://patchwork.freedesktop.org/series/6354/ > State : warning > > == Summary == > > Series 6354v1 drm/i915: Cdclk related fixes and polish >

Re: [Intel-gfx] [RFC PATCH 2/2] drm/i915/bxt: Adjusting the error in horizontal timings retrieval

On Tue, Apr 19, 2016 at 01:48:14PM +0530, Ramalingam C wrote: > In BXT DSI there is no regs programmed with few horizontal timings > in Pixels but txbyteclkhs.. So retrieval process adds some > ROUND_UP ERRORS in the process of PIXELS<==>txbyteclkhs. > > Actually here for the given adjusted_mode,

Re: [Intel-gfx] [PATCH 07/12] drm/rcar-du: Rename async to nonblock.

Hi Maarten, Thank you for the patch. On Tuesday 26 Apr 2016 16:11:40 Maarten Lankhorst wrote: > The async name is deprecated and should be changed to nonblocking. > > Cc: Laurent Pinchart > Signed-off-by: Maarten Lankhorst

Re: [Intel-gfx] [PATCH 1/2] drm/i915/BXT: Retrieving the horizontal timing for DSI

On ti, 2016-04-19 at 13:48 +0530, Ramalingam C wrote: > Retriving the horizontal timings from the port registers as > part of get_config() > > Signed-off-by: Ramalingam C I saw the crash below with current -nightly on a BXT-M board and Jani pointed me to these two

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: respect VBT PSR link standby configuration for HSW/BDW.

== Series Details == Series: drm/i915: respect VBT PSR link standby configuration for HSW/BDW. URL : https://patchwork.freedesktop.org/series/6416/ State : success == Summary == Series 6416v1 drm/i915: respect VBT PSR link standby configuration for HSW/BDW.

Re: [Intel-gfx] [PATCH] drm/i915: Update RAWCLK_FREQ register on VLV/CHV

On Wed, 2016-04-27 at 19:08 +0300, Ville Syrjälä wrote: > On Wed, Apr 27, 2016 at 03:54:12PM +, Vivi, Rodrigo wrote: > > On Wed, 2016-04-27 at 17:43 +0300, ville.syrj...@linux.intel.com wr > > ote: > > > From: Ville Syrjälä > > > > > > I just noticed that

Re: [Intel-gfx] [PATCH] drm/i915: Update RAWCLK_FREQ register on VLV/CHV

On Wed, Apr 27, 2016 at 03:54:12PM +, Vivi, Rodrigo wrote: > On Wed, 2016-04-27 at 17:43 +0300, ville.syrj...@linux.intel.com wrote: > > From: Ville Syrjälä > > > > I just noticed that VLV/CHV have a RAWCLK_FREQ register just like PCH > > platforms. It lives in

Re: [Intel-gfx] [PATCH] drm/i915: Update RAWCLK_FREQ register on VLV/CHV

On Wed, 2016-04-27 at 17:43 +0300, ville.syrj...@linux.intel.com wrote: > From: Ville Syrjälä > > I just noticed that VLV/CHV have a RAWCLK_FREQ register just like PCH > platforms. It lives in the display power well, so we should update it > when enabling the power

Re: [Intel-gfx] [PATCH] drm/i915: respect VBT PSR link standby configuration for HSW/BDW.

On Wed, Apr 27, 2016 at 08:47:54AM -0700, Rodrigo Vivi wrote: > We have in the history some changes on this behaviour, but > there are many platforms out there and we don't know all panels. > > VBT might not be reliable but it knows the platform better than > us usually. Or at least it should. >

[Intel-gfx] [PATCH] drm/i915: respect VBT PSR link standby configuration for HSW/BDW.

We have in the history some changes on this behaviour, but there are many platforms out there and we don't know all panels. VBT might not be reliable but it knows the platform better than us usually. Or at least it should. So, first of all let's respect the VBT. If something bad happens again

Re: [Intel-gfx] ✗ Fi.CI.BAT: warning for drm/i915: Unify VLV/CHV DPOunit clock gating disable/enable

On Wed, Apr 27, 2016 at 03:02:01PM -, Patchwork wrote: > == Series Details == > > Series: drm/i915: Unify VLV/CHV DPOunit clock gating disable/enable > URL : https://patchwork.freedesktop.org/series/5886/ > State : warning > > == Summary == > > Series 5886v1 drm/i915: Unify VLV/CHV

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Update RAWCLK_FREQ register on VLV/CHV

== Series Details == Series: drm/i915: Update RAWCLK_FREQ register on VLV/CHV URL : https://patchwork.freedesktop.org/series/6410/ State : success == Summary == Series 6410v1 drm/i915: Update RAWCLK_FREQ register on VLV/CHV

[Intel-gfx] [PATCH i-g-t 3/3] kms_flip: Reduce dmesg spam by not calling drmModeGetResources too much

From: Tvrtko Ursulin Configuration reported in drmModeGetResources is static - pass it into kmstest_get_connector_config so it can be reused there. Signed-off-by: Tvrtko Ursulin --- tests/kms_flip.c | 6 +++--- 1 file changed, 3

[Intel-gfx] [PATCH i-g-t 2/3] igt_kms: Allow kmstest_get_connector_config to take provided drmModeGetResources

From: Tvrtko Ursulin This will enable the following patch to generate less dmesg spam. Signed-off-by: Tvrtko Ursulin --- lib/igt_kms.c | 33 +++-- lib/igt_kms.h | 3 ++- tests/kms_3d.c | 2 +-

[Intel-gfx] [PATCH i-g-t 1/3] igt_kms: Fix use after free in kmstest_get_pipe_from_crtc_id

From: Tvrtko Ursulin Signed-off-by: Tvrtko Ursulin --- lib/igt_kms.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/lib/igt_kms.c b/lib/igt_kms.c index ef24a4965567..7557bdc20fa4 100644 --- a/lib/igt_kms.c +++

Re: [Intel-gfx] [PATCH] drm/i915: Unify VLV/CHV DPOunit clock gating disable/enable

On Wednesday 27 April 2016 17:49:26 Ville Syrjälä wrote: > On Mon, Apr 18, 2016 at 07:18:25PM +0300, ville.syrj...@linux.intel.com wrote: > > From: Ville Syrjälä > > > > Check for VLV/CHV instead if !BXT when re-enabling DPOunit clock gating > > after DSI disable.

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Set legacy properties when using legacy gamma set IOCTL. (rev2)

== Series Details == Series: drm/i915: Set legacy properties when using legacy gamma set IOCTL. (rev2) URL : https://patchwork.freedesktop.org/series/5466/ State : failure == Summary == HOSTCC scripts/basic/fixdep HOSTCC scripts/kconfig/conf.o SHIPPED scripts/kconfig/zconf.tab.c

[Intel-gfx] ✗ Fi.CI.BAT: warning for drm/i915: Unify VLV/CHV DPOunit clock gating disable/enable

== Series Details == Series: drm/i915: Unify VLV/CHV DPOunit clock gating disable/enable URL : https://patchwork.freedesktop.org/series/5886/ State : warning == Summary == Series 5886v1 drm/i915: Unify VLV/CHV DPOunit clock gating disable/enable

Re: [Intel-gfx] [PATCH v2 2/2] drm/i915/bxt: Fix inadvertent CPU snooping due to incorrect MOCS config

On Wed, Apr 27, 2016 at 04:25:09PM +0300, Eero Tamminen wrote: > Hi, > > On 26.04.2016 20:25, Frederick, Michael T wrote: > >Sorry I'm not tracking all the MOCs discussions. I just want to indicate > >what the coherency means in SoC for BXT. > > > >GTI sets the non-inclusive bit on the IDI

Re: [Intel-gfx] [PATCH] drm/i915: Unify VLV/CHV DPOunit clock gating disable/enable

On Mon, Apr 18, 2016 at 07:18:25PM +0300, ville.syrj...@linux.intel.com wrote: > From: Ville Syrjälä > > Check for VLV/CHV instead if !BXT when re-enabling DPOunit clock gating > after DSI disable. That's what we checked when disabling the clock > gating when

[Intel-gfx] [PATCH] drm/i915: Update RAWCLK_FREQ register on VLV/CHV

From: Ville Syrjälä I just noticed that VLV/CHV have a RAWCLK_FREQ register just like PCH platforms. It lives in the display power well, so we should update it when enabling the power well. Interestingly the BIOS seems to leave it at the reset value (125) which

Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for Unduplicate CHV phy code (rev5)

Hello, On Wednesday 27 April 2016 16:36:13 Ander Conselvan De Oliveira wrote: > > Subgroup suspend-read-crc-pipe-a: > > pass -> INCOMPLETE (hsw-gt2) > > dmesg ends with > > [ 505.669959] kms_pipe_crc_basic: starting subtest suspend-read-crc-pipe-A > > Seems very

Re: [Intel-gfx] [PATCH 04/19] drm/i915: Add support for detecting vblanks when hw frame counter is unavailable.

On Wed, Apr 27, 2016 at 04:06:16PM +0200, Patrik Jakobsson wrote: > On Tue, Apr 19, 2016 at 09:52:24AM +0200, Maarten Lankhorst wrote: > > This uses the newly created drm_accurate_vblank_count_and_time to accurately > > get a vblank count when the hw counter is unavailable. > > --- > >

Re: [Intel-gfx] [PATCH 04/19] drm/i915: Add support for detecting vblanks when hw frame counter is unavailable.

On Tue, Apr 19, 2016 at 09:52:24AM +0200, Maarten Lankhorst wrote: > This uses the newly created drm_accurate_vblank_count_and_time to accurately > get a vblank count when the hw counter is unavailable. > --- > drivers/gpu/drm/i915/intel_display.c | 10 ++ >

Re: [Intel-gfx] [PATCH 3/3] drm/i915: Fix comments about GMBUSFREQ register

On Wed, Apr 27, 2016 at 04:30:14PM +0300, Mika Kahola wrote: > s/Programmng/Programming It's straight from the spec, hence the [sic] > > With this nitpick fixed, this is > > Reviewed-by: Mika Kahola > > On Tue, 2016-04-26 at 19:46 +0300, ville.syrj...@linux.intel.com

Re: [Intel-gfx] [PATCH] drm/i915: In render_state_init reset obj in teardown path

On ti, 2016-04-26 at 11:04 +0100, Dave Gordon wrote: > On 26/04/16 10:21, Matthew Auld wrote: > > > > The teardown path in render_state_init leaves so->obj != NULL. > > > > Suggested-by: Joonas Lahtinen > > Signed-off-by: Matthew Auld >

Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Propagate error from drm_gem_object_init() (rev2)

On Wed, Apr 27, 2016 at 04:35:33PM +0300, Joonas Lahtinen wrote: > On ma, 2016-04-25 at 13:24 +, Patchwork wrote: > > == Series Details == > > > > Series: drm/i915: Propagate error from drm_gem_object_init() (rev2) > > URL   : https://patchwork.freedesktop.org/series/6149/ > > State : failure

Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for Unduplicate CHV phy code (rev5)

On Wed, 2016-04-27 at 13:23 +, Patchwork wrote: > == Series Details == > > Series: Unduplicate CHV phy code (rev5) > URL : https://patchwork.freedesktop.org/series/5463/ > State : failure > > == Summary == > > Series 5463v5 Unduplicate CHV phy code >

Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Propagate error from drm_gem_object_init() (rev2)

On ma, 2016-04-25 at 13:24 +, Patchwork wrote: > == Series Details == > > Series: drm/i915: Propagate error from drm_gem_object_init() (rev2) > URL   : https://patchwork.freedesktop.org/series/6149/ > State : failure > > == Summary == > > Series 6149v2 drm/i915: Propagate error from

Re: [Intel-gfx] i951 ERRORs and WARN_ON()s (was: blank screen on boot with i915/DRM_FBDEV_EMULATION)

On Wed, 27 Apr 2016, Florian Zumbiehl wrote: >> Florian, if you're using drm-intel-nigthly submit a bug at >> https://bugs.freedesktop.org/enter_bug.cgi?product=DRI, with DRM/intel >> as component. This way we can track some kind of progress/regress. The FIFO > > Gee ... is there

Re: [Intel-gfx] [PATCH 3/3] drm/i915: Fix comments about GMBUSFREQ register

s/Programmng/Programming With this nitpick fixed, this is Reviewed-by: Mika Kahola On Tue, 2016-04-26 at 19:46 +0300, ville.syrj...@linux.intel.com wrote: > From: Ville Syrjälä > > The comment about GMBUSFREQ is confused. The spec

Re: [Intel-gfx] [PATCH v6 15/25] drm/i915: Preallocate enough space for the average request

On Wed, Apr 27, 2016 at 02:15:29PM +0100, Tvrtko Ursulin wrote: > > On 26/04/16 21:06, Chris Wilson wrote: > >Rather than being interrupted when we run out of space halfway through > >the request, and having to restart from the beginning (and returning to > >userspace), flush a little more free

Re: [Intel-gfx] [PATCH 02/19] drm/i915: Remove stallcheck special handling, v2.

On Tue, Apr 19, 2016 at 09:52:22AM +0200, Maarten Lankhorst wrote: > Both intel_unpin_work.pending and intel_unpin_work.enable_stall_check > were used to see if work should be enabled. By only using pending > some special cases are gone, and access to unpin_work can be simplified. > > Use this to

[Intel-gfx] ✗ Fi.CI.BAT: failure for Unduplicate CHV phy code (rev5)

== Series Details == Series: Unduplicate CHV phy code (rev5) URL : https://patchwork.freedesktop.org/series/5463/ State : failure == Summary == Series 5463v5 Unduplicate CHV phy code http://patchwork.freedesktop.org/api/1.0/series/5463/revisions/5/mbox/ Test drv_module_reload_basic:

Re: [Intel-gfx] [PATCH v6 16/25] drm/i915: Update execlists context descriptor format commentary

On 26/04/16 21:06, Chris Wilson wrote: The comments describing the Context Descriptor Format are off by a bit for the size of the context ID. Signed-off-by: Chris Wilson Cc: Dave Gordon Cc: Tvrtko Ursulin ---

Re: [Intel-gfx] [PATCH v6 15/25] drm/i915: Preallocate enough space for the average request

On 26/04/16 21:06, Chris Wilson wrote: Rather than being interrupted when we run out of space halfway through the request, and having to restart from the beginning (and returning to userspace), flush a little more free space when we prepare the request. Signed-off-by: Chris Wilson

Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: tidy up gen8_init_scratch (rev2)

On ke, 2016-04-27 at 12:49 +, Patchwork wrote: > == Series Details == > > Series: drm/i915: tidy up gen8_init_scratch (rev2) > URL   : https://patchwork.freedesktop.org/series/6315/ > State : failure > > == Summary == > > Series 6315v2 drm/i915: tidy up gen8_init_scratch >

Re: [Intel-gfx] [PATCH v2 2/2] drm/i915/bxt: Fix inadvertent CPU snooping due to incorrect MOCS config

Hi, On 26.04.2016 20:25, Frederick, Michael T wrote: Sorry I'm not tracking all the MOCs discussions. I just want to indicate what the coherency means in SoC for BXT. GTI sets the non-inclusive bit on the IDI interface based on how it treats the memory. In BXT case where there is no uncore

Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: tidy up gen8_init_scratch (rev2)

Patchwork writes: > [ text/plain ] > == Series Details == > > Series: drm/i915: tidy up gen8_init_scratch (rev2) > URL : https://patchwork.freedesktop.org/series/6315/ > State : failure > > == Summary == > > Series 6315v2 drm/i915: tidy up gen8_init_scratch >

Re: [Intel-gfx] [PATCH] drm/i915: tidy up gen8_init_scratch

On ke, 2016-04-27 at 15:30 +0300, Mika Kuoppala wrote: > Matthew Auld writes: > > > > > [ text/plain ] > > Prefer a goto teardown path to do all the required cleanup. > > > > v2: > > (Joonas Lahtinen) > >   - remove NULL assignments > >   - rename goto labels > > > >

Re: [Intel-gfx] [PATCH 2/3] drm/i915: Use cached cdclk value in i915_audio_component_get_cdclk_freq()

Looks reasonable. Reviewed-by: Mika Kahola On Tue, 2016-04-26 at 19:46 +0300, ville.syrj...@linux.intel.com wrote: > From: Ville Syrjälä > > No point in reading the cdclk out from the hardware every single time > since we have it cached

Re: [Intel-gfx] [PATCH v6 14/25] drm/i915: Manually unwind after a failed request allocation

On 27/04/16 13:58, Chris Wilson wrote: On Wed, Apr 27, 2016 at 01:51:38PM +0100, Tvrtko Ursulin wrote: On 26/04/16 21:06, Chris Wilson wrote: In the next patches, we want to move the work out of freeing the request and into its retirement (so that we can free the request without requiring

Re: [Intel-gfx] [PATCH v6 14/25] drm/i915: Manually unwind after a failed request allocation

On Wed, Apr 27, 2016 at 01:51:38PM +0100, Tvrtko Ursulin wrote: > > On 26/04/16 21:06, Chris Wilson wrote: > >In the next patches, we want to move the work out of freeing the request > >and into its retirement (so that we can free the request without > >requiring the struct_mutex). This means

Re: [Intel-gfx] [PATCH 1/9] drm: Add drm_mode_debug_printmodeline_raw

On 27/04/16 13:35, Jani Nikula wrote: On Wed, 27 Apr 2016, Tvrtko Ursulin wrote: From: Tvrtko Ursulin Purpose is to enable drivers to print out just the mode string with their own formatting. Some alternatives that preserve the use

Re: [Intel-gfx] [PATCH v6 14/25] drm/i915: Manually unwind after a failed request allocation

On 26/04/16 21:06, Chris Wilson wrote: In the next patches, we want to move the work out of freeing the request and into its retirement (so that we can free the request without requiring the struct_mutex). This means that we cannot rely on unreferencing the request to completely teardown the

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: tidy up gen8_init_scratch (rev2)

== Series Details == Series: drm/i915: tidy up gen8_init_scratch (rev2) URL : https://patchwork.freedesktop.org/series/6315/ State : failure == Summary == Series 6315v2 drm/i915: tidy up gen8_init_scratch http://patchwork.freedesktop.org/api/1.0/series/6315/revisions/2/mbox/ Test

Re: [Intel-gfx] [PATCH v6 01/25] drm/i915/fbdev: Call intel_unpin_fb_obj() on release

On 26/04/16 21:05, Chris Wilson wrote: When releasing the intel_fbdev, we should unpin the framebuffer that we pinned during construction. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/intel_display.c | 2 +- drivers/gpu/drm/i915/intel_drv.h | 1 +

[Intel-gfx] [PATCH v4 08/10] drm/i915: Unduplicate VLV phy pre pll enabling code

The code used by the DP and HDMI paths was very similar, so make them share it. Note that this removes the write to signal level registers from the HDMI pre pll enable path, but that's OK since those are set in vlv_hdmi_pre_enable() function. Signed-off-by: Ander Conselvan de Oliveira

[Intel-gfx] [PATCH v4 04/10] drm/i915: Unduplicate CHV phy-releated pre pll enabling code

The same logic is used for DP and HDMI so move it to intel_dpio_phy.c. v2: Rebase Signed-off-by: Ander Conselvan de Oliveira Reviewed-by: Jim Bride --- drivers/gpu/drm/i915/i915_drv.h | 1 +

[Intel-gfx] [PATCH v4 02/10] drm/i915: Unduplicate CHV signal level code

The code for programming voltage swing and emphasis was duplicated between DP and HDMI code. Move that to a new file, intel_dpio_phy.c. v2: Keep the "Use 800mV-0dB" comment in the HDMI code. (Ville) Signed-off-by: Ander Conselvan de Oliveira Reviewed-by:

[Intel-gfx] [PATCH v4 03/10] drm/i915: Unduplicate chv_data_lane_soft_reset()

The function chv_data_lane_soft_reset() was duplicated in DP and HDMI code. Move it to intel_dpio_phy.c. Signed-off-by: Ander Conselvan de Oliveira Reviewed-by: Jim Bride --- drivers/gpu/drm/i915/i915_drv.h | 2 ++

  1   2   3   >