Re: [Intel-gfx] [REGRESSION] i915: No HDMI output with 4.4

On 2/23/2016 8:38 PM, Ville Syrjälä wrote: On Mon, Feb 22, 2016 at 02:32:32PM +0200, Oleksandr Natalenko wrote: Ville, Daniel, any additional info I could provide? I have to return dual-link DVI cable back, so let me know if I could reveal more details if necessary. Unfortunately I'm out of

Re: [Intel-gfx] [PATCH] drm/i915: Resume DP MST before doing any kind of modesetting

On 2/24/2016 3:41 AM, Lyude wrote: As it turns out, resuming DP MST is racey since we don't make sure MST is ready before we start modesetting, it just usually happens to be ready in time. This isn't the case on all systems, particularly a ThinkPad T560 with displays connected through the

Re: [Intel-gfx] [PATCH] drm/i915: Add two-stage ILK-style watermark programming (v11)

On Tue, Feb 23, 2016 at 05:20:13PM -0800, Matt Roper wrote: > In addition to calculating final watermarks, let's also pre-calculate a > set of intermediate watermark values at atomic check time. These > intermediate watermarks are a combination of the watermarks for the old > state and the new

[Intel-gfx] [PATCH] drm/i915: Add two-stage ILK-style watermark programming (v11)

In addition to calculating final watermarks, let's also pre-calculate a set of intermediate watermark values at atomic check time. These intermediate watermarks are a combination of the watermarks for the old state and the new state; they should satisfy the requirements of both states which means

[Intel-gfx] [PATCH] drm/i915: Resume DP MST before doing any kind of modesetting

As it turns out, resuming DP MST is racey since we don't make sure MST is ready before we start modesetting, it just usually happens to be ready in time. This isn't the case on all systems, particularly a ThinkPad T560 with displays connected through the dock. On these systems, resuming the laptop

Re: [Intel-gfx] [PATCH v5 26/35] drm/i915: Added debugfs interface to scheduler tuning parameters

On 02/18/2016 06:27 AM, john.c.harri...@intel.com wrote: > From: John Harrison > > There are various parameters within the scheduler which can be tuned > to improve performance, reduce memory footprint, etc. This change adds > support for altering these via debugfs. >

Re: [Intel-gfx] [PATCH v5 25/35] drm/i915: Added scheduler queue throttling by DRM file handle

On 02/18/2016 06:27 AM, john.c.harri...@intel.com wrote: > From: John Harrison > > The scheduler decouples the submission of batch buffers to the driver > from their subsequent submission to the hardware. This means that an > application which is continuously

Re: [Intel-gfx] [PATCH v5 24/35] drm/i915: Added trace points to scheduler

On 02/18/2016 06:27 AM, john.c.harri...@intel.com wrote: > From: John Harrison > > Added trace points to the scheduler to track all the various events, > node state transitions and other interesting things that occur. > > v2: Updated for new request completion

Re: [Intel-gfx] [PATCH v5 24/35] drm/i915: Added trace points to scheduler

On 02/18/2016 06:27 AM, john.c.harri...@intel.com wrote: > From: John Harrison > > Added trace points to the scheduler to track all the various events, > node state transitions and other interesting things that occur. > > v2: Updated for new request completion

Re: [Intel-gfx] [PATCH v5 21/35] drm/i915: Added a module parameter to allow the scheduler to be disabled

On 02/18/2016 06:27 AM, john.c.harri...@intel.com wrote: > From: John Harrison > > It can be useful to be able to disable the GPU scheduler via a module > parameter for debugging purposes. > > v5: Converted from a multi-feature 'overrides' mask to a single > 'enable'

Re: [Intel-gfx] [PATCH v5 22/35] drm/i915: Support for 'unflushed' ring idle

On 02/18/2016 06:27 AM, john.c.harri...@intel.com wrote: > From: John Harrison > > When the seqno wraps around zero, the entire GPU is forced to be idle > for some reason (possibly only to work around issues with hardware > semaphores but no-one seems too sure!). This

Re: [Intel-gfx] [PATCH v5 20/35] drm/i915: Add scheduler hook to GPU reset

On 02/18/2016 06:27 AM, john.c.harri...@intel.com wrote: > From: John Harrison > > When the watchdog resets the GPU, all interrupts get disabled despite > the reference count remaining. As the scheduler probably had > interrupts enabled during the reset (it would have

Re: [Intel-gfx] [BUG] HDMI 12bpc causing occasional flickering and blanking

Hi Ville, > "The monitor is connected with a DP+-to-HDMI cable" > This and some reading of the DP dual mode spec gave me another idea; > The DP->HDMI adaptor may simply be degrading the signal quality too > much. According to the DP dual mode spec we're supposed to limit the > TMDS clock based on

Re: [Intel-gfx] [PATCH v2] drm/i915: Avoid selecting unavailable BSD2 ring

On 23/02/16 14:39, Tvrtko Ursulin wrote: On 23/02/16 14:03, Chris Wilson wrote: On Tue, Feb 23, 2016 at 01:31:17PM +, Tvrtko Ursulin wrote: On 23/02/16 13:06, Gabriel Feceoru wrote: On 23.02.2016 13:05, Tvrtko Ursulin wrote: Hi, On 23/02/16 10:52, Gabriel Feceoru wrote: Return

Re: [Intel-gfx] [BUG] [REGRESSION] [BISECTED] -rc1 breaks audio over HDMI for i915

Am 2016-02-23 um 18:14 schrieb Ville Syrjälä: > On Tue, Feb 23, 2016 at 05:57:40PM +0100, Takashi Iwai wrote: >> On Mon, 22 Feb 2016 22:37:28 +0100, >> Martin Kepplinger wrote: >>> >>> Am 2016-02-22 um 20:10 schrieb Takashi Iwai: On Mon, 22 Feb 2016 19:58:18 +0100, Martin Kepplinger

Re: [Intel-gfx] [PATCH 2/5] drm/i915: Do not read GAMMA_MODE register

On Tue, Feb 23, 2016 at 10:36:36AM +, Lionel Landwerlin wrote: > On 23/02/16 00:38, Matt Roper wrote: > >On Mon, Feb 22, 2016 at 02:18:08PM +, Lionel Landwerlin wrote: > >>Implement Daniel Stone's recommendation to not read registers to infer > >>the hardware's state. > >> >

[Intel-gfx] ✗ Fi.CI.BAT: warning for drm: DP++ adaptor support

== Series Details == Series: drm: DP++ adaptor support URL : https://patchwork.freedesktop.org/series/3735/ State : warning == Summary == Series 3735v1 drm: DP++ adaptor support http://patchwork.freedesktop.org/api/1.0/series/3735/revisions/1/mbox/ Test gem_cs_prefetch: Subgroup

Re: [Intel-gfx] [BUG] [REGRESSION] [BISECTED] -rc1 breaks audio over HDMI for i915

Am 2016-02-23 um 17:57 schrieb Takashi Iwai: > On Mon, 22 Feb 2016 22:37:28 +0100, > Martin Kepplinger wrote: >> >> Am 2016-02-22 um 20:10 schrieb Takashi Iwai: >>> On Mon, 22 Feb 2016 19:58:18 +0100, >>> Martin Kepplinger wrote: Am 2016-02-22 um 15:12 schrieb Takashi Iwai: > On Mon,

Re: [Intel-gfx] [BUG] [REGRESSION] [BISECTED] -rc1 breaks audio over HDMI for i915

On Tue, Feb 23, 2016 at 05:57:40PM +0100, Takashi Iwai wrote: > On Mon, 22 Feb 2016 22:37:28 +0100, > Martin Kepplinger wrote: > > > > Am 2016-02-22 um 20:10 schrieb Takashi Iwai: > > > On Mon, 22 Feb 2016 19:58:18 +0100, > > > Martin Kepplinger wrote: > > >> > > >> Am 2016-02-22 um 15:12 schrieb

Re: [Intel-gfx] [BUG] [REGRESSION] [BISECTED] -rc1 breaks audio over HDMI for i915

On Mon, 22 Feb 2016 22:37:28 +0100, Martin Kepplinger wrote: > > Am 2016-02-22 um 20:10 schrieb Takashi Iwai: > > On Mon, 22 Feb 2016 19:58:18 +0100, > > Martin Kepplinger wrote: > >> > >> Am 2016-02-22 um 15:12 schrieb Takashi Iwai: > >>> On Mon, 22 Feb 2016 15:02:56 +0100, > >>> Martin

Re: [Intel-gfx] [RFC] drm/i915: Check if we hold a wakeref during ioread32/iowrite32

On Tue, Feb 23, 2016 at 05:09:29PM +0200, Imre Deak wrote: > On ti, 2016-02-23 at 14:55 +, Chris Wilson wrote: > > On Tue, Feb 23, 2016 at 04:47:17PM +0200, Imre Deak wrote: > > > The device needs to be in D0 state whenever we call these > > > functions, so > > > add the corresponding assert

[Intel-gfx] [PATCH 4/4] drm/i915: Determine DP++ type 1 DVI adaptor presence based on VBT

From: Ville Syrjälä DP dual mode type 1 DVI adaptors aren't required to implement any registers, so it's a bit hard to detect them. The best way would be to check the state of the CONFIG1 pin, but we have no way to do that. So as a last resort, check the VBT to see

[Intel-gfx] [PATCH 1/4] drm: Add helper for DP++ adaptors

From: Ville Syrjälä Add a helper which aids in he identification of DP dual mode (aka. DP++) adaptors. There are several types of adaptors specified: type 1 DVI, type 1 HDMI, type 2 DVI, type 2 HDMI Type 1 adaptors have a max TMDS clock limit of 165MHz, type 2

[Intel-gfx] [PATCH 3/4] drm/i915: Enable/disable TMDS output buffers in DP++ adaptor as needed

From: Ville Syrjälä To save a bit of power, let's try to turn off the TMDS output buffers in DP++ adaptors when we're not driving the port. Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/intel_drv.h | 1 +

[Intel-gfx] [PATCH 2/4] drm/i915: Respect DP++ adaptor TMDS clock limit

From: Ville Syrjälä Try to detect the max TMDS clock limit for the DP++ adaptor (if any) and take it into account when checking the port clock. Note that as with the sink (HDMI vs. DVI) TMDS clock limit we'll ignore the adaptor TMDS clock limit in the modeset

Re: [Intel-gfx] [RFC i-g-t] tests/drv_hangman: test for acthd increasing through invalid VM space

On 18/02/16 21:10, Chris Wilson wrote: On Thu, Feb 18, 2016 at 05:34:50PM +, daniele.ceraolospu...@intel.com wrote: +static void ppgtt_walking(void) +{ + memset(, 0, sizeof(execbuf)); + execbuf.buffers_ptr = (uintptr_t)_exec; + execbuf.buffer_count = 1; +

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Updating the CPU_TRANSCODER for BXT DSI

== Series Details == Series: drm/i915: Updating the CPU_TRANSCODER for BXT DSI URL : https://patchwork.freedesktop.org/series/3730/ State : failure == Summary == Series 3730v1 drm/i915: Updating the CPU_TRANSCODER for BXT DSI 2016-02-23T15:07:40.910533

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Check if we hold a wakeref during ioread32/iowrite32

== Series Details == Series: drm/i915: Check if we hold a wakeref during ioread32/iowrite32 URL : https://patchwork.freedesktop.org/series/3728/ State : failure == Summary == Series 3728v1 drm/i915: Check if we hold a wakeref during ioread32/iowrite32

[Intel-gfx] Intel Graphics for Linux (Release Date: 16 Feb, 2016)

Hi, what packages with versions is recent "Intel Graphics for Linux" (2016-02-16) shipping? Version "2015q4" [2] was giving some detailed informations, but recent version does not. Its release-notes are pointing to a installer [3]. BTW, when will there be a new intel-ddx v2.99.918? Thanks in

[Intel-gfx] [IGT PATCH] tests/kms_setmode: Add tests when not stealing encoders on same crtc.

Excercise connector stealing harder. There is a border case in atomic currently where encoder stealing is not prevented on the same crtc when the encoder is not reassigned. The following testcase excercises that path and causes a OOPS on my system with nightly. Signed-off-by: Maarten

[Intel-gfx] ✗ Fi.CI.BAT: failure for Pipe level color management (rev7)

== Series Details == Series: Pipe level color management (rev7) URL : https://patchwork.freedesktop.org/series/2720/ State : failure == Summary == Series 2720v7 Pipe level color management http://patchwork.freedesktop.org/api/1.0/series/2720/revisions/7/mbox/ Test gem_cs_prefetch:

Re: [Intel-gfx] [RFC] drm/i915: Check if we hold a wakeref during ioread32/iowrite32

On ti, 2016-02-23 at 14:55 +, Chris Wilson wrote: > On Tue, Feb 23, 2016 at 04:47:17PM +0200, Imre Deak wrote: > > The device needs to be in D0 state whenever we call these > > functions, so > > add the corresponding assert checks. > > No. In quite a few of those cases we are calling iowrite

[Intel-gfx] [PATCH] drm/i915: Updating the CPU_TRANSCODER for BXT DSI

In case of BXT DSI we are updating the CPU_TRANSCODER with appropriate value. We are defining the POWER DOMAIN bits for the MIPI transcoders. V2: Adding the power domain bits and mapping them to the corresponding Powerwell. Signed-off-by: Ramalingam C

Re: [Intel-gfx] [REGRESSION] i915: No HDMI output with 4.4

On Mon, Feb 22, 2016 at 02:32:32PM +0200, Oleksandr Natalenko wrote: > Ville, Daniel, > > any additional info I could provide? I have to return dual-link DVI > cable back, so let me know if I could reveal more details if necessary. Unfortunately I'm out of ideas for now. Daniel is on vacation.

Re: [Intel-gfx] [RFC] drm/i915: Check if we hold a wakeref during ioread32/iowrite32

On Tue, Feb 23, 2016 at 04:47:17PM +0200, Imre Deak wrote: > The device needs to be in D0 state whenever we call these functions, so > add the corresponding assert checks. No. In quite a few of those cases we are calling iowrite to non-device memory, even normal pages. How's the separation of

[Intel-gfx] [RFC] drm/i915: Check if we hold a wakeref during ioread32/iowrite32

The device needs to be in D0 state whenever we call these functions, so add the corresponding assert checks. I had to move around some helpers due to dependencies added by nested includes. Signed-off-by: Imre Deak --- drivers/gpu/drm/i915/i915_drv.h| 117

Re: [Intel-gfx] [PATCH] drm/i915/lrc: Only set RS ctx enable in ctx control reg if there is a RS

On 23/02/2016 13:56, Michel Thierry wrote: The driver should only set the "RS context enable" bit in the context image if we plan to use the resource streamer. Signed-off-by: Michel Thierry --- drivers/gpu/drm/i915/intel_lrc.c | 3 ++- 1 file changed, 2

Re: [Intel-gfx] [BUG] HDMI 12bpc causing occasional flickering and blanking

On Fri, Feb 19, 2016 at 08:55:02PM +0100, Tore Anderson wrote: > * Tore Anderson > > > * Ville Syrjälä > > > > > Could you test the following hack while using a 1920x1080 mode with > > > 148.5 MHz dotclock, and see if there's any improvement? > > > > I think it might be an improvement, that

Re: [Intel-gfx] [PATCH 4/5] drm/i915: Implement color management on bdw/skl/bxt/kbl

On 23/02/16 00:52, Matt Roper wrote: On Mon, Feb 22, 2016 at 02:18:10PM +, Lionel Landwerlin wrote: Patch based on a previous series by Shashank Sharma. v2: Do not read GAMMA_MODE register to figure what mode we're in v3: Program PREC_PAL_GC_MAX to clamp pixel values > 1.0 Add

Re: [Intel-gfx] [PATCH v2] drm/i915: Avoid selecting unavailable BSD2 ring

On 23/02/16 14:03, Chris Wilson wrote: On Tue, Feb 23, 2016 at 01:31:17PM +, Tvrtko Ursulin wrote: On 23/02/16 13:06, Gabriel Feceoru wrote: On 23.02.2016 13:05, Tvrtko Ursulin wrote: Hi, On 23/02/16 10:52, Gabriel Feceoru wrote: Return error when I915_EXEC_BSD_RING2 flag is set

Re: [Intel-gfx] [PATCH 3/3] drm/i915: Updating the CPU_TRANSCODER for BXT DSI

On Friday 19 February 2016 02:37 PM, Jani Nikula wrote: On Thu, 11 Feb 2016, Ramalingam C wrote: In case of BXT DSI we are updating the CPU_TRANSCODER with appropriate value. Signed-off-by: Ramalingam C Signed-off-by: Uma Shankar

[Intel-gfx] [PATCH 5/5] drm/i915: Implement color management on chv

Patch based on a previous series by Shashank Sharma. v2: Update contributors v3: Refactor degamma/gamma LUTs load into a single function v4: Remove unused variable Signed-off-by: Shashank Sharma Signed-off-by: Lionel Landwerlin

[Intel-gfx] [PATCH 2/5] drm/i915: Do not read GAMMA_MODE register

Implement Daniel Stone's recommendation to not read registers to infer the hardware's state. v2: Read GAMMA_MODE register value at init Signed-off-by: Lionel Landwerlin --- drivers/gpu/drm/i915/intel_color.c | 17 +

[Intel-gfx] [PATCH 0/5] Pipe level color management V7

This series introduces pipe level color management through a set of properties attached to the CRTC. It also provides an implementation for some Intel platforms. This series is based of a previous set of patches by Shashank Sharma. Cheers, Lionel Lionel Landwerlin (5): drm/i915: Extract out

[Intel-gfx] [PATCH 4/5] drm/i915: Implement color management on bdw/skl/bxt/kbl

Patch based on a previous series by Shashank Sharma. v2: Do not read GAMMA_MODE register to figure what mode we're in v3: Program PREC_PAL_GC_MAX to clamp pixel values > 1.0 Add documentation on how the Broadcast RGB property is affected by CTM v4: Update contributors v5: Refactor

[Intel-gfx] [PATCH 3/5] drm: introduce pipe color correction properties

Patch based on a previous series by Shashank Sharma. This introduces optional properties to enable color correction at the pipe level. It relies on 3 transformations applied to every pixels displayed. First a lookup into a degamma table, then a multiplication of the rgb components by a 3x3 matrix

[Intel-gfx] [PATCH 1/5] drm/i915: Extract out gamma table and CSC to their own file

The moves a couple of functions programming the gamma LUT and CSC units into their own file. On generations prior to Haswell there is only a gamma LUT. From haswell on there is also a new enhanced color correction unit that isn't used yet. This is why we need to set the GAMMA_MODE register,

Re: [Intel-gfx] [PATCH] drm/i915: Use SWF06 to figure out max cdclk for BDW

On Tue, Feb 23, 2016 at 06:40:37PM +0530, Thulasimani, Sivakumar wrote: > > > On 2/23/2016 4:35 PM, Ville Syrjälä wrote: > > On Tue, Feb 23, 2016 at 04:22:01PM +0530, Thulasimani, Sivakumar wrote: > >> > >> On 2/16/2016 3:35 PM, Ville Syrjälä wrote: > >>> On Tue, Feb 16, 2016 at 07:13:05AM

Re: [Intel-gfx] [PATCH v2] drm/i915: Avoid selecting unavailable BSD2 ring

On Tue, Feb 23, 2016 at 01:31:17PM +, Tvrtko Ursulin wrote: > > On 23/02/16 13:06, Gabriel Feceoru wrote: > > > > > > On 23.02.2016 13:05, Tvrtko Ursulin wrote: > >> > >> Hi, > >> > >> On 23/02/16 10:52, Gabriel Feceoru wrote: > >>> Return error when I915_EXEC_BSD_RING2 flag is set but BSD2

[Intel-gfx] [PATCH] drm/i915/lrc: Only set RS ctx enable in ctx control reg if there is a RS

The driver should only set the "RS context enable" bit in the context image if we plan to use the resource streamer. Signed-off-by: Michel Thierry --- drivers/gpu/drm/i915/intel_lrc.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git

Re: [Intel-gfx] [PATCH v2] drm/i915: Avoid selecting unavailable BSD2 ring

On 23/02/16 13:06, Gabriel Feceoru wrote: > > > On 23.02.2016 13:05, Tvrtko Ursulin wrote: >> >> Hi, >> >> On 23/02/16 10:52, Gabriel Feceoru wrote: >>> Return error when I915_EXEC_BSD_RING2 flag is set but BSD2 ring >>> is not available in the HW. >> >> What is the reasoning behind this? So

Re: [Intel-gfx] [RFCv2 03/14] drm/i915: Introduce host graphics memory/fence partition for GVT-g

On ti, 2016-02-23 at 15:16 +0200, Joonas Lahtinen wrote: > > > > On to, 2016-02-18 at 19:42 +0800, Zhi Wang wrote: > > From: Bing Niu > > > > This patch introduces host graphics memory/fence partition when GVT-g > > is enabled. > > > > Under GVT-g, i915 host driver only

Re: [Intel-gfx] [RFCv2 03/14] drm/i915: Introduce host graphics memory/fence partition for GVT-g

On 02/23/16 21:16, Joonas Lahtinen wrote: On to, 2016-02-18 at 19:42 +0800, Zhi Wang wrote: From: Bing Niu This patch introduces host graphics memory/fence partition when GVT-g is enabled. Under GVT-g, i915 host driver only owned limited graphics resources, others are

Re: [Intel-gfx] [RFCv2 03/14] drm/i915: Introduce host graphics memory/fence partition for GVT-g

On to, 2016-02-18 at 19:42 +0800, Zhi Wang wrote: > From: Bing Niu > > This patch introduces host graphics memory/fence partition when GVT-g > is enabled. > > Under GVT-g, i915 host driver only owned limited graphics resources, > others are managed by GVT-g resource

Re: [Intel-gfx] [PATCH] drm/i915: Use SWF06 to figure out max cdclk for BDW

On 2/23/2016 4:35 PM, Ville Syrjälä wrote: On Tue, Feb 23, 2016 at 04:22:01PM +0530, Thulasimani, Sivakumar wrote: On 2/16/2016 3:35 PM, Ville Syrjälä wrote: On Tue, Feb 16, 2016 at 07:13:05AM +0530, Thulasimani, Sivakumar wrote: On 2/12/2016 8:36 PM, ville.syrj...@linux.intel.com wrote:

Re: [Intel-gfx] ✗ Fi.CI.BAT: warning for drm/i915/gen9: Set value of Indirect Context Offset based on gen version (rev4)

On Tue, Feb 23, 2016 at 11:21 AM, Patchwork wrote: == Series Details == Series: drm/i915/gen9: Set value of Indirect Context Offset based on gen version (rev4) URL : https://patchwork.freedesktop.org/series/3629/ State : warning == Summary == Series 3629v4

Re: [Intel-gfx] [PATCH v2] drm/i915: Avoid selecting unavailable BSD2 ring

On 23.02.2016 13:05, Tvrtko Ursulin wrote: Hi, On 23/02/16 10:52, Gabriel Feceoru wrote: Return error when I915_EXEC_BSD_RING2 flag is set but BSD2 ring is not available in the HW. What is the reasoning behind this? So far kernel was allowing userspace to select these bits and execute on

Re: [Intel-gfx] [PATCH v4 2/3] drm/i915: refactor duplicate object vmap functions (reworked)

On Tue, Feb 23, 2016 at 12:25:29PM +, Tvrtko Ursulin wrote: > > On 23/02/16 11:52, Chris Wilson wrote: > >On Tue, Feb 23, 2016 at 11:38:02AM +, Chris Wilson wrote: > >>Indeed, we would need a new notifier, pretty much for the sole use of > >>32b. Grr, that will be a nuisance. > > > >Core

Re: [Intel-gfx] [RFCv2 02/14] drm/i915/gvt: Introduce the basic architecture of GVT-g

A one more note below. On to, 2016-02-18 at 19:42 +0800, Zhi Wang wrote: > This patch introduces the very basic framework of GVT-g device model, > includes basic prototypes, definitions, initialization. > > v2: > - Introduce i915_gvt.c. > It's necessary to introduce the stubs between i915 driver

[Intel-gfx] [PATCH] drm/i915: factor out i915_pvinfo.h

As the PVINFO page definition is used by both GVT-g guest (vGPU) and GVT-g host (GVT-g kernel device model), factor it out for better code structure. v2: - Use offsetof() to calculate the offset of PVINFO member(Joonas) Signed-off-by: Zhi Wang ---

Re: [Intel-gfx] [RFCv2 02/14] drm/i915/gvt: Introduce the basic architecture of GVT-g

Hi, Code is looking a lot better. A general question still; why you seem to be preferring multi-stage alloc and destroy? Are there going to be scenarios when things will be allocated but not initialized? I don't see a such use scenario. I wouldn't split the init functions down as much as you

Re: [Intel-gfx] [PATCH v4 2/3] drm/i915: refactor duplicate object vmap functions (reworked)

On 23/02/16 11:52, Chris Wilson wrote: On Tue, Feb 23, 2016 at 11:38:02AM +, Chris Wilson wrote: Indeed, we would need a new notifier, pretty much for the sole use of 32b. Grr, that will be a nuisance. Core changes: diff --git a/include/linux/vmalloc.h b/include/linux/vmalloc.h index

[Intel-gfx] ✗ Fi.CI.BAT: warning for kernfs: Move faulting copy_user operations outside of the mutex

== Series Details == Series: kernfs: Move faulting copy_user operations outside of the mutex URL : https://patchwork.freedesktop.org/series/3722/ State : warning == Summary == Series 3722v1 kernfs: Move faulting copy_user operations outside of the mutex

Re: [Intel-gfx] [PATCH v4 2/3] drm/i915: refactor duplicate object vmap functions (reworked)

On Tue, Feb 23, 2016 at 11:38:02AM +, Chris Wilson wrote: > Indeed, we would need a new notifier, pretty much for the sole use of > 32b. Grr, that will be a nuisance. Core changes: diff --git a/include/linux/vmalloc.h b/include/linux/vmalloc.h index d1f1d338af20..542a91c2785f 100644 ---

[Intel-gfx] ✗ Fi.CI.BAT: warning for drm/i915: Avoid selecting unavailable BSD2 ring (rev2)

== Series Details == Series: drm/i915: Avoid selecting unavailable BSD2 ring (rev2) URL : https://patchwork.freedesktop.org/series/3678/ State : warning == Summary == Series 3678v2 drm/i915: Avoid selecting unavailable BSD2 ring

[Intel-gfx] [PATCH] kernfs: Move faulting copy_user operations outside of the mutex

A fault in a user provided buffer may lead anywhere, and lockdep warns that we have a potential deadlock between the mm->mmap_sem and the kernfs file mutex: [ 82.811702] == [ 82.811705] [ INFO: possible circular locking dependency detected ]

Re: [Intel-gfx] [PATCH v4 2/3] drm/i915: refactor duplicate object vmap functions (reworked)

On Tue, Feb 23, 2016 at 10:31:08AM +, Tvrtko Ursulin wrote: > > On 23/02/16 10:06, Chris Wilson wrote: > >On Mon, Feb 22, 2016 at 04:06:39PM +, Tvrtko Ursulin wrote: > >> > >>[Cc Chris as the author of the idea.] > >> > >>Hi, > >> > >>On 22/02/16 15:18, Dave Gordon wrote: > >>>This is

[Intel-gfx] ✗ Fi.CI.BAT: warning for drm/i915/gen9: Set value of Indirect Context Offset based on gen version (rev4)

== Series Details == Series: drm/i915/gen9: Set value of Indirect Context Offset based on gen version (rev4) URL : https://patchwork.freedesktop.org/series/3629/ State : warning == Summary == Series 3629v4 drm/i915/gen9: Set value of Indirect Context Offset based on gen version

Re: [Intel-gfx] System freeze apparently due to GPU memory exhaustion - why?

> Can you attach a full dmesg from boot until the problem appears? Attached, thanks for your reply. You can ignore the problem at T=1032000, that was a broken floppy disk in a USB floppy drive. The first possibly-GPU-related problem starts at T=2121945 then the same problem happens immediately

Re: [Intel-gfx] [PATCH v5 09/35] drm/i915: Force MMIO flips when scheduler enabled

On Mon, Feb 22, 2016 at 12:42:48PM -0800, Jesse Barnes wrote: > On 02/20/2016 01:22 AM, Chris Wilson wrote: > > On Fri, Feb 19, 2016 at 11:28:05AM -0800, Jesse Barnes wrote: > >> On 02/18/2016 06:26 AM, john.c.harri...@intel.com wrote: > >>> From: John Harrison > >>> >

Re: [Intel-gfx] [PATCH] drm/i915: Use SWF06 to figure out max cdclk for BDW

On Tue, Feb 23, 2016 at 04:22:01PM +0530, Thulasimani, Sivakumar wrote: > > > On 2/16/2016 3:35 PM, Ville Syrjälä wrote: > > On Tue, Feb 16, 2016 at 07:13:05AM +0530, Thulasimani, Sivakumar wrote: > >> > >> On 2/12/2016 8:36 PM, ville.syrj...@linux.intel.com wrote: > >>> From: Ville Syrjälä

Re: [Intel-gfx] [PATCH v2] drm/i915: Avoid selecting unavailable BSD2 ring

Hi, On 23/02/16 10:52, Gabriel Feceoru wrote: Return error when I915_EXEC_BSD_RING2 flag is set but BSD2 ring is not available in the HW. What is the reasoning behind this? So far kernel was allowing userspace to select these bits and execute on the first engine. With this patch it would

[Intel-gfx] ✗ Fi.CI.BAT: failure for Reorganise calls to vmap() GEM objects

== Series Details == Series: Reorganise calls to vmap() GEM objects URL : https://patchwork.freedesktop.org/series/3688/ State : failure == Summary == Series 3688v1 Reorganise calls to vmap() GEM objects http://patchwork.freedesktop.org/api/1.0/series/3688/revisions/1/mbox/ Test

[Intel-gfx] ✗ Fi.CI.BAT: failure for Possible 4.5 i915 Skylake regression

== Series Details == Series: Possible 4.5 i915 Skylake regression URL : https://patchwork.freedesktop.org/series/3713/ State : failure == Summary == Series 3713v1 Possible 4.5 i915 Skylake regression http://patchwork.freedesktop.org/api/1.0/series/3713/revisions/1/mbox/ Test gem_cs_prefetch:

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Change WARN_ON(!wm_changed) to I915_STATE_WARN_ON()

== Series Details == Series: drm/i915: Change WARN_ON(!wm_changed) to I915_STATE_WARN_ON() URL : https://patchwork.freedesktop.org/series/3698/ State : failure == Summary == Series 3698v1 drm/i915: Change WARN_ON(!wm_changed) to I915_STATE_WARN_ON()

Re: [Intel-gfx] [PATCH] drm/i915: Use SWF06 to figure out max cdclk for BDW

On 2/16/2016 3:35 PM, Ville Syrjälä wrote: On Tue, Feb 16, 2016 at 07:13:05AM +0530, Thulasimani, Sivakumar wrote: On 2/12/2016 8:36 PM, ville.syrj...@linux.intel.com wrote: From: Ville Syrjälä Bspec tells us that we can allow cdclk up to 540Mhz on BDW ULX,

[Intel-gfx] [PATCH v2] drm/i915: Avoid selecting unavailable BSD2 ring

Return error when I915_EXEC_BSD_RING2 flag is set but BSD2 ring is not available in the HW. v2: Reworked Signed-off-by: Gabriel Feceoru --- drivers/gpu/drm/i915/i915_gem_execbuffer.c | 7 +++ 1 file changed, 7 insertions(+) diff --git

Re: [Intel-gfx] [PATCH 2/5] drm/i915: Do not read GAMMA_MODE register

On 23/02/16 00:38, Matt Roper wrote: On Mon, Feb 22, 2016 at 02:18:08PM +, Lionel Landwerlin wrote: Implement Daniel Stone's recommendation to not read registers to infer the hardware's state. Signed-off-by: Lionel Landwerlin Do we need to ensure that

Re: [Intel-gfx] [PATCH v4 2/3] drm/i915: refactor duplicate object vmap functions (reworked)

On 23/02/16 10:06, Chris Wilson wrote: On Mon, Feb 22, 2016 at 04:06:39PM +, Tvrtko Ursulin wrote: [Cc Chris as the author of the idea.] Hi, On 22/02/16 15:18, Dave Gordon wrote: This is essentially Chris Wilson's patch of a similar name, reworked on top of Alex Dai's recent patch:

[Intel-gfx] [PATCH RESEND FOR CI] drm/i915/gen9: Set value of Indirect Context Offset based on gen version

The cache line offset for the Indirect CS context (0x21C8) varies from gen to gen. v2: Move it into a function (Arun), use MISSING_CASE (Chris) v3: Rebased (catched by ci bat) Cc: Arun Siluvery Cc: Chris Wilson Reviewed-by: Arun Siluvery

Re: [Intel-gfx] [PATCH 136/190] drm/i915: Move ioremap_wc tracking onto VMA

On Mon, Feb 22, 2016 at 03:29:57PM +, Tvrtko Ursulin wrote: > > On 19/02/16 15:11, Chris Wilson wrote: > >On Thu, Feb 11, 2016 at 02:10:19PM +, Tvrtko Ursulin wrote: > >> > >>On 11/02/16 13:29, Chris Wilson wrote: > >>>On Thu, Feb 11, 2016 at 01:20:46PM +, Tvrtko Ursulin wrote: >

Re: [Intel-gfx] [PATCH v4 3/3] drm/i915: optimise i915_gem_object_vmap_range() for small objects

On Mon, Feb 22, 2016 at 03:18:28PM +, Dave Gordon wrote: > Now that we use this function for ringbuffers and other "small" objects, > it's worth avoiding an extra kmalloc()/kfree() cycle if the page array > is small enough to put on the stack. Here we've chosen an arbitrary > cutoff of 32 (4k)

Re: [Intel-gfx] [PATCH libdrm] intel/skl: Add missing SKL PCI IDs

On 17/02/16 10:40, Michał Winiarski wrote: Used by production devices: Intel(R) HD Graphics 510 Intel(R) HD Graphics 535 Intel(R) Iris(TM) Graphics 550 Intel(R) Iris(TM) Graphics P555 Signed-off-by: Michał Winiarski Tested-by: Lionel Landwerlin

Re: [Intel-gfx] [PATCH v4 2/3] drm/i915: refactor duplicate object vmap functions (reworked)

On Mon, Feb 22, 2016 at 04:06:39PM +, Tvrtko Ursulin wrote: > > [Cc Chris as the author of the idea.] > > Hi, > > On 22/02/16 15:18, Dave Gordon wrote: > >This is essentially Chris Wilson's patch of a similar name, reworked on > >top of Alex Dai's recent patch: > > drm/i915: Add

[Intel-gfx] ✗ Fi.CI.BAT: failure for Possible 4.5 i915 Skylake regression

== Series Details == Series: Possible 4.5 i915 Skylake regression URL : https://patchwork.freedesktop.org/series/3713/ State : failure == Summary == Series 3713v1 Possible 4.5 i915 Skylake regression http://patchwork.freedesktop.org/api/1.0/series/3713/revisions/1/mbox/ Test core_prop_blob:

Re: [Intel-gfx] [PATCH] drm/i915: Avoid divbyzero in modesetting

On 23/02/16 08:38, Maarten Lankhorst wrote: > Op 22-02-16 om 15:27 schreef Tvrtko Ursulin: >> [ 10.062881] [] skl_update_pipe_wm+0x102/0x8c0 [i915] >> [ 10.062942] [] skl_update_wm+0xff/0x5f0 [i915] >> [ 10.063027] [] intel_update_watermarks+0x1e/0x30 [i915] >> [ 10.063087] []

Re: [Intel-gfx] System freeze apparently due to GPU memory exhaustion - why?

Hi, On ti, 2016-02-23 at 11:55 +1000, Adam Nielsen wrote: > Hi all, > > I'm an end user and I'm having problems which I believe are ultimately > caused by an issue with the Intel kernel driver. > > When I am running programs that use a lot of images (e.g. GIMP, Firefox > with YouTube and Google

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Change WARN_ON(!wm_changed) to I915_STATE_WARN_ON()

== Series Details == Series: drm/i915: Change WARN_ON(!wm_changed) to I915_STATE_WARN_ON() URL : https://patchwork.freedesktop.org/series/3698/ State : failure == Summary == Series 3698v1 drm/i915: Change WARN_ON(!wm_changed) to I915_STATE_WARN_ON()

[Intel-gfx] ✗ Fi.CI.BAT: failure for Reorganise calls to vmap() GEM objects

== Series Details == Series: Reorganise calls to vmap() GEM objects URL : https://patchwork.freedesktop.org/series/3688/ State : failure == Summary == Series 3688v1 Reorganise calls to vmap() GEM objects http://patchwork.freedesktop.org/api/1.0/series/3688/revisions/1/mbox/ Test

Re: [Intel-gfx] [PATCH] drm/i915: Avoid divbyzero in modesetting

Op 22-02-16 om 15:27 schreef Tvrtko Ursulin: > [ 10.062881] [] skl_update_pipe_wm+0x102/0x8c0 [i915] > [ 10.062942] [] skl_update_wm+0xff/0x5f0 [i915] > [ 10.063027] [] intel_update_watermarks+0x1e/0x30 [i915] > [ 10.063087] [] intel_crtc_disable_noatomic+0xd2/0x150 > [i915] > [