Re: [Intel-gfx] [PATCH 2/2] drm/atomic: Cleanup on error properly in the atomic ioctl.

On Wed, Jun 24, 2015 at 08:59:25AM +0200, Maarten Lankhorst wrote: > It's probably allowed to leave old_fb set to garbage when unlocking, > but to prevent undefined behavior unset it just in case. > > Also crtc_state->event could be NULL on memory allocation failure, > in which case event_space is

Re: [Intel-gfx] [PATCH] drm: Update plane->fb also for page_flip

On Tue, Jul 07, 2015 at 08:43:03AM +0200, Daniel Vetter wrote: > The legacy page_flip driver entry point is the only one left which > requires drivers to update plane->fb themselves. All the other entry > hooks will patch things up for the driver as needed since no one seems > to reliable get this

[Intel-gfx] [PATCH] drm: Update plane->fb also for page_flip

The legacy page_flip driver entry point is the only one left which requires drivers to update plane->fb themselves. All the other entry hooks will patch things up for the driver as needed since no one seems to reliable get this right, see e.g. drm_mode_set_config_internal or the plane->fb/old_fb ha

Re: [Intel-gfx] [PATCH] drm/i915: Handle HPD when it has actually occurred

Tested-By: Intel Graphics QA PRTS (Patch Regression Test System Contact: shuang...@intel.com) Task id: 6724 -Summary- Platform Delta drm-intel-nightly Series Applied ILK

Re: [Intel-gfx] [PATCH] drm/i915: Don't dereference NULL plane while setting up scalers

Op 06-07-15 om 18:19 schreef Matt Roper: > intel_atomic_setup_scalers() dereferences 'plane' before the plane has > been assigned. The plane ID assignment doing this dereference is only > needed for debugging messages later in the function, so just move the > assignment farther down the function t

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

Hi all, We're pleased to announce a public update to Intel Graphics Virtualization Technology(Intel GVT-g, formerly known as XenGT). Intel GVT-g is a full GPU virtualization solution with mediated pass-through, starting from 4th generation Intel Core(TM) processors with Intel Graphics process

Re: [Intel-gfx] NULL pointer deferences in drm_mode_copy() and drm_crtc_index()

On 07/06/2015 11:24 AM, Daniel Vetter wrote: > On Fri, Jul 03, 2015 at 02:11:37PM -0400, Michael Kaminsky wrote: >> I few days ago I built a kernel from git (commit 6aaf0da872), and >> noticed a couple of NULL pointer deferences. These seem to be >> regressions as they aren't present in v4.1. >> >

Re: [Intel-gfx] [PATCH 11/15] drm/i915: Interrupt routing for GuC submission

On 07/06/2015 11:21 AM, Daniel Vetter wrote: On Mon, Jul 06, 2015 at 05:07:31PM +0100, Dave Gordon wrote: > On 06/07/15 15:14, Daniel Vetter wrote: > >On Fri, Jul 03, 2015 at 01:30:33PM +0100, Dave Gordon wrote: > >>Turn on interrupt steering to route necessary interrupts to GuC. > >> > >>Issue

Re: [Intel-gfx] [PATCH 1/3] drm/i915: Make fb user dirty operation to invalidate frontbuffer

On Mon, 2015-07-06 at 19:56 +0200, Daniel Vetter wrote: > On Mon, Jul 06, 2015 at 02:11:55PM -0300, Paulo Zanoni wrote: > > 2015-07-06 13:43 GMT-03:00 Vivi, Rodrigo : > > > On Fri, 2015-07-03 at 09:10 +0200, Daniel Vetter wrote: > > >> On Thu, Jul 02, 2015 at 04:41:32PM +, Vivi, Rodrigo wrote:

Re: [Intel-gfx] [PATCH i-g-t 00/16] Introduction of plotting support

On Mon, Jul 06, 2015 at 11:32:47PM +0200, Daniel Vetter wrote: > > Why don't we have some of those benchmarks they have in i-g-t? (using > > OpenGL? they are not open source?) I have the feeling we should at least > > have a single point of contribution, let's make sure it's i-g-t when > > it's abo

Re: [Intel-gfx] [PATCH] drm/i915: RMW register cycles considered evil

On Mon, Jul 06, 2015 at 04:23:23PM -0300, Paulo Zanoni wrote: > 2015-07-06 12:04 GMT-03:00 Daniel Vetter : > > On Mon, Jul 06, 2015 at 03:50:49PM +0300, Ville Syrjälä wrote: > >> On Mon, Jul 06, 2015 at 02:42:02PM +0200, Daniel Vetter wrote: > >> > Especially for workarounds which is stuff that's a

Re: [Intel-gfx] [PATCH i-g-t 00/16] Introduction of plotting support

On Mon, Jul 06, 2015 at 08:58:31PM +0100, Damien Lespiau wrote: > On Mon, Jul 06, 2015 at 08:25:56PM +0200, Daniel Vetter wrote: > > atm QA rolls their own thing, developers on mesa side have ministat, and > > it looks like you want to create something in igt. I know it's easier, but > > I'd like t

Re: [Intel-gfx] [PATCH i-g-t 00/16] Introduction of plotting support

On Mon, Jul 06, 2015 at 08:25:56PM +0200, Daniel Vetter wrote: > atm QA rolls their own thing, developers on mesa side have ministat, and > it looks like you want to create something in igt. I know it's easier, but > I'd like to share as much tooling between QA and devs as possible. And > that kind

Re: [Intel-gfx] [PATCH] drm/i915: Disable LVDS port after the pipe on PCH

On Thu, Jul 02, 2015 at 05:42:46PM +0300, ville.syrj...@linux.intel.com wrote: > From: Ville Syrjälä > > Follow the correct pipe vs port disable sequence for the PCH LVDS > ports, ie. disable the port after the pipe. > > Other PCH port were already converted in the following commits: > 1ea56e26

Re: [Intel-gfx] [PATCH] drm/i915: RMW register cycles considered evil

2015-07-06 12:04 GMT-03:00 Daniel Vetter : > On Mon, Jul 06, 2015 at 03:50:49PM +0300, Ville Syrjälä wrote: >> On Mon, Jul 06, 2015 at 02:42:02PM +0200, Daniel Vetter wrote: >> > Especially for workarounds which is stuff that's almost impossible to >> > verify: The initial state from the firmware o

Re: [Intel-gfx] [PATCH] drm/i915: Don't dereference NULL plane while setting up scalers

On Mon, Jul 06, 2015 at 09:19:24AM -0700, Matt Roper wrote: > intel_atomic_setup_scalers() dereferences 'plane' before the plane has > been assigned. The plane ID assignment doing this dereference is only > needed for debugging messages later in the function, so just move the > assignment farther

Re: [Intel-gfx] [PATCH 02/15] drm/i915: Embedded microcontroller (uC) firmware loading support

On Mon, Jul 06, 2015 at 07:24:37PM +0100, Dave Gordon wrote: > On 06/07/15 15:06, Daniel Vetter wrote: > >On Fri, Jul 03, 2015 at 01:30:24PM +0100, Dave Gordon wrote: > >>Current devices may contain one or more programmable microcontrollers > >>that need to have a firmware image (aka "binary blob")

Re: [Intel-gfx] [PATCH] drm/i915: RMW register cycles considered evil

On Mon, Jul 06, 2015 at 04:15:25PM +0100, Damien Lespiau wrote: > On Mon, Jul 06, 2015 at 04:58:19PM +0200, Daniel Vetter wrote: > > On Mon, Jul 06, 2015 at 01:46:19PM +0100, Damien Lespiau wrote: > > > On Mon, Jul 06, 2015 at 02:42:02PM +0200, Daniel Vetter wrote: > > > > Especially for workaround

Re: [Intel-gfx] [PATCH 02/15] drm/i915: Embedded microcontroller (uC) firmware loading support

On 06/07/15 15:06, Daniel Vetter wrote: On Fri, Jul 03, 2015 at 01:30:24PM +0100, Dave Gordon wrote: Current devices may contain one or more programmable microcontrollers that need to have a firmware image (aka "binary blob") loaded from an external medium and transferred to the device's memory.

Re: [Intel-gfx] [PATCH i-g-t 00/16] Introduction of plotting support

On Mon, Jul 06, 2015 at 04:06:05PM +0100, Damien Lespiau wrote: > On Mon, Jul 06, 2015 at 04:54:48PM +0200, Daniel Vetter wrote: > > On Mon, Jul 06, 2015 at 01:35:28PM +0100, Damien Lespiau wrote: > > > Long story short: > > > http://entropy.lespiau.name/intel-gpu-tools/test_simple_plot.png > > >

Re: [Intel-gfx] [PATCH 11/15] drm/i915: Interrupt routing for GuC submission

On Mon, Jul 06, 2015 at 05:07:31PM +0100, Dave Gordon wrote: > On 06/07/15 15:14, Daniel Vetter wrote: > >On Fri, Jul 03, 2015 at 01:30:33PM +0100, Dave Gordon wrote: > >>Turn on interrupt steering to route necessary interrupts to GuC. > >> > >>Issue: VIZ-4884 > >>Signed-off-by: Alex Dai > >>Signe

Re: [Intel-gfx] [PATCH 05/15] drm/i915: GuC-specific firmware loader

On Mon, Jul 06, 2015 at 05:37:57PM +0100, Dave Gordon wrote: > On 06/07/15 15:28, Daniel Vetter wrote: > >On Fri, Jul 03, 2015 at 01:30:27PM +0100, Dave Gordon wrote: > >>From: Alex Dai > >> > >>This uses the common firmware loader to fetch the firmware image, > >>then loads it into the GuC's memo

Re: [Intel-gfx] [PATCH 0/9] drm/i915: Check pixel clock when setting mode

On Mon, Jul 06, 2015 at 06:28:56PM +0300, Ville Syrjälä wrote: > On Mon, Jul 06, 2015 at 05:21:48PM +0200, Daniel Vetter wrote: > > On Fri, Jul 03, 2015 at 01:49:17PM +0100, Chris Wilson wrote: > > > On Fri, Jul 03, 2015 at 02:35:48PM +0300, Mika Kahola wrote: > > > > From EDID we can read and requ

Re: [Intel-gfx] [RFC] drm/i915: Add sync framework support to execbuff IOCTL

On Mon, Jul 06, 2015 at 05:34:22PM +0100, Tvrtko Ursulin wrote: > > On 07/06/2015 04:37 PM, Daniel Vetter wrote: > >On Mon, Jul 06, 2015 at 04:21:28PM +0100, Tvrtko Ursulin wrote: > >> > >>On 07/06/2015 04:12 PM, Daniel Vetter wrote: > >>>On Mon, Jul 06, 2015 at 03:46:49PM +0100, Tvrtko Ursulin wr

Re: [Intel-gfx] [PATCH 1/3] drm/i915: Make fb user dirty operation to invalidate frontbuffer

On Mon, Jul 06, 2015 at 02:11:55PM -0300, Paulo Zanoni wrote: > 2015-07-06 13:43 GMT-03:00 Vivi, Rodrigo : > > On Fri, 2015-07-03 at 09:10 +0200, Daniel Vetter wrote: > >> On Thu, Jul 02, 2015 at 04:41:32PM +, Vivi, Rodrigo wrote: > >> > On Thu, 2015-07-02 at 13:03 -0300, Paulo Zanoni wrote: >

Re: [Intel-gfx] [PATCH 1/3] drm/i915: Make fb user dirty operation to invalidate frontbuffer

2015-07-06 13:43 GMT-03:00 Vivi, Rodrigo : > On Fri, 2015-07-03 at 09:10 +0200, Daniel Vetter wrote: >> On Thu, Jul 02, 2015 at 04:41:32PM +, Vivi, Rodrigo wrote: >> > On Thu, 2015-07-02 at 13:03 -0300, Paulo Zanoni wrote: >> > > 2015-06-30 20:42 GMT-03:00 Rodrigo Vivi : >> > > > Let's do a fro

Re: [Intel-gfx] [PATCH 1/3] drm/i915: Make fb user dirty operation to invalidate frontbuffer

On Fri, 2015-07-03 at 09:10 +0200, Daniel Vetter wrote: > On Thu, Jul 02, 2015 at 04:41:32PM +, Vivi, Rodrigo wrote: > > On Thu, 2015-07-02 at 13:03 -0300, Paulo Zanoni wrote: > > > 2015-06-30 20:42 GMT-03:00 Rodrigo Vivi : > > > > Let's do a frontbuffer invalidation on dirty fb. > > > > To be

Re: [Intel-gfx] [PATCH 05/15] drm/i915: GuC-specific firmware loader

On 06/07/15 15:28, Daniel Vetter wrote: On Fri, Jul 03, 2015 at 01:30:27PM +0100, Dave Gordon wrote: From: Alex Dai This uses the common firmware loader to fetch the firmware image, then loads it into the GuC's memory via a dedicated DMA engine. This patch is derived from GuC loading work ori

Re: [Intel-gfx] [RFC] drm/i915: Add sync framework support to execbuff IOCTL

On 07/06/2015 04:37 PM, Daniel Vetter wrote: On Mon, Jul 06, 2015 at 04:21:28PM +0100, Tvrtko Ursulin wrote: On 07/06/2015 04:12 PM, Daniel Vetter wrote: On Mon, Jul 06, 2015 at 03:46:49PM +0100, Tvrtko Ursulin wrote: If you have weak references somewhere and need to prevent the object fro

Re: [Intel-gfx] [PATCH] drm/i915: avoid leaking DMA mappings

On ma, 2015-07-06 at 17:04 +0100, Chris Wilson wrote: > On Mon, Jul 06, 2015 at 06:56:00PM +0300, Imre Deak wrote: > > On ma, 2015-07-06 at 16:33 +0100, Chris Wilson wrote: > > > On Mon, Jul 06, 2015 at 05:29:39PM +0200, Daniel Vetter wrote: > > > > On Mon, Jul 06, 2015 at 03:57:44PM +0100, Chris W

[Intel-gfx] [PATCH] drm/i915: Don't dereference NULL plane while setting up scalers

intel_atomic_setup_scalers() dereferences 'plane' before the plane has been assigned. The plane ID assignment doing this dereference is only needed for debugging messages later in the function, so just move the assignment farther down the function to a point where plane will no longer be NULL. Th

[Intel-gfx] [PATCH v2 1/4] drm/i915: Enable WA batch buffers for Gen9

This patch only enables support for Gen9, the actual WA will be initialized in subsequent patches. The WARN that we use to warn user if WA batch support is not available for a particular Gen is replaced with DRM_ERROR as warning here doesn't really add much value. v2: include all infrastructure b

[Intel-gfx] [PATCH v2 0/4] Gen9 WA Batch patches

Compared to v1 changes are only in Patch 1, these changes are to group all infrastructure bits in a single patch. Patch 2 wasn't getting applied cleanly because of this hence sending all patches. Arun Siluvery (4): drm/i915: Enable WA batch buffers for Gen9 drm/i915/gen9: Add WaDisableCtxResto

[Intel-gfx] [PATCH v2 2/4] drm/i915/gen9: Add WaDisableCtxRestoreArbitration workaround

In Indirect and Per context w/a batch buffer, +WaDisableCtxRestoreArbitration Cc: Imre Deak Signed-off-by: Arun Siluvery --- drivers/gpu/drm/i915/intel_lrc.c | 13 +++-- 1 file changed, 11 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i91

[Intel-gfx] [PATCH v2 3/4] drm/i915/gen9: Add WaFlushCoherentL3CacheLinesAtContextSwitch workaround

In Indirect context w/a batch buffer, +WaFlushCoherentL3CacheLinesAtContextSwitch:bdw Cc: Imre Deak Signed-off-by: Arun Siluvery --- drivers/gpu/drm/i915/intel_lrc.c | 5 + 1 file changed, 5 insertions(+) diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c inde

[Intel-gfx] [PATCH v2 4/4] drm/i915/gen9: Add WaSetDisablePixMaskCammingAndRhwoInCommonSliceChicken

In Indirect context w/a batch buffer, +WaSetDisablePixMaskCammingAndRhwoInCommonSliceChicken Cc: Imre Deak Signed-off-by: Arun Siluvery --- drivers/gpu/drm/i915/intel_lrc.c| 9 + drivers/gpu/drm/i915/intel_ringbuffer.c | 7 +-- 2 files changed, 14 insertions(+), 2 deletions(

Re: [Intel-gfx] [PATCH 11/15] drm/i915: Interrupt routing for GuC submission

On 06/07/15 15:14, Daniel Vetter wrote: On Fri, Jul 03, 2015 at 01:30:33PM +0100, Dave Gordon wrote: Turn on interrupt steering to route necessary interrupts to GuC. Issue: VIZ-4884 Signed-off-by: Alex Dai Signed-off-by: Dave Gordon --- drivers/gpu/drm/i915/i915_reg.h | 11 +--

Re: [Intel-gfx] [PATCH] drm/i915: avoid leaking DMA mappings

On Mon, Jul 06, 2015 at 06:56:00PM +0300, Imre Deak wrote: > On ma, 2015-07-06 at 16:33 +0100, Chris Wilson wrote: > > On Mon, Jul 06, 2015 at 05:29:39PM +0200, Daniel Vetter wrote: > > > On Mon, Jul 06, 2015 at 03:57:44PM +0100, Chris Wilson wrote: > > > > On Mon, Jul 06, 2015 at 05:50:37PM +0300,

Re: [Intel-gfx] [PATCH] drm/i915: avoid leaking DMA mappings

On ma, 2015-07-06 at 16:33 +0100, Chris Wilson wrote: > On Mon, Jul 06, 2015 at 05:29:39PM +0200, Daniel Vetter wrote: > > On Mon, Jul 06, 2015 at 03:57:44PM +0100, Chris Wilson wrote: > > > On Mon, Jul 06, 2015 at 05:50:37PM +0300, Imre Deak wrote: > > > > We have 3 types of DMA mappings for GEM o

Re: [Intel-gfx] [RFC] drm/i915: Add sync framework support to execbuff IOCTL

On Mon, Jul 06, 2015 at 04:21:28PM +0100, Tvrtko Ursulin wrote: > > On 07/06/2015 04:12 PM, Daniel Vetter wrote: > >On Mon, Jul 06, 2015 at 03:46:49PM +0100, Tvrtko Ursulin wrote: > >>On 07/06/2015 03:26 PM, John Harrison wrote: > >>>On 06/07/2015 14:59, Daniel Vetter wrote: > On Mon, Jul 06,

Re: [Intel-gfx] [PATCH] drm/i915: Update WaFlushCoherentL3CacheLinesAtContextSwitch

On Mon, Jul 06, 2015 at 04:33:05PM +0200, Daniel Vetter wrote: > On Mon, Jul 06, 2015 at 02:16:54PM +0100, Dave Gordon wrote: > > On 06/07/15 13:38, Daniel Vetter wrote: > > >On Mon, Jul 06, 2015 at 12:52:51PM +0100, Dave Gordon wrote: > > >>On 03/07/15 16:42, Chris Wilson wrote: > > >>>On Fri, Jul

Re: [Intel-gfx] [PATCH] drm/i915: Restore all GGTT VMAs on resume

On Mon, Jul 06, 2015 at 04:29:12PM +0100, Tvrtko Ursulin wrote: > > On 07/06/2015 04:19 PM, Chris Wilson wrote: > >On Mon, Jul 06, 2015 at 03:15:01PM +0100, Tvrtko Ursulin wrote: > >>From: Tvrtko Ursulin > >> > >>When rotated and partial views were added no one spotted the resume > >>path which a

Re: [Intel-gfx] [PATCH 0/9] drm/i915: Check pixel clock when setting mode

On Mon, Jul 06, 2015 at 05:21:48PM +0200, Daniel Vetter wrote: > On Fri, Jul 03, 2015 at 01:49:17PM +0100, Chris Wilson wrote: > > On Fri, Jul 03, 2015 at 02:35:48PM +0300, Mika Kahola wrote: > > > From EDID we can read and request higher pixel clock than > > > our HW can support. This set of patch

[Intel-gfx] [PATCH 1/2] drm/i915: Convert execlist_submit_contexts() for requests

Make execlist_submit_context() accept requests instead of engine context objects, also renaming it to execlist_submit_requests() to better reflect the functionality. Keep passing requests as first class objects, all the way down to where elsps are written. The benefits are that with requests, we c

Re: [Intel-gfx] [PATCH] drm/i915: avoid leaking DMA mappings

On Mon, Jul 06, 2015 at 05:29:39PM +0200, Daniel Vetter wrote: > On Mon, Jul 06, 2015 at 03:57:44PM +0100, Chris Wilson wrote: > > On Mon, Jul 06, 2015 at 05:50:37PM +0300, Imre Deak wrote: > > > We have 3 types of DMA mappings for GEM objects: > > > 1. physically contiguous for stolen and for obje

Re: [Intel-gfx] [PATCH] drm/i915: avoid leaking DMA mappings

On ma, 2015-07-06 at 16:28 +0100, Chris Wilson wrote: > On Mon, Jul 06, 2015 at 06:11:40PM +0300, Imre Deak wrote: > > On ma, 2015-07-06 at 15:57 +0100, Chris Wilson wrote: > > > On Mon, Jul 06, 2015 at 05:50:37PM +0300, Imre Deak wrote: > > > > We have 3 types of DMA mappings for GEM objects: > >

Re: [Intel-gfx] [PATCH] drm/i915: avoid leaking DMA mappings

On ma, 2015-07-06 at 17:29 +0200, Daniel Vetter wrote: > On Mon, Jul 06, 2015 at 03:57:44PM +0100, Chris Wilson wrote: > > On Mon, Jul 06, 2015 at 05:50:37PM +0300, Imre Deak wrote: > > > We have 3 types of DMA mappings for GEM objects: > > > 1. physically contiguous for stolen and for objects need

Re: [Intel-gfx] [PATCH] drm/i915: Restore all GGTT VMAs on resume

On 07/06/2015 04:19 PM, Chris Wilson wrote: On Mon, Jul 06, 2015 at 03:15:01PM +0100, Tvrtko Ursulin wrote: From: Tvrtko Ursulin When rotated and partial views were added no one spotted the resume path which assumes only one GGTT VMA per object and hence is now skipping rebind of alternative

Re: [Intel-gfx] [PATCH 0/9] drm/i915: Check pixel clock when setting mode

On Mon, Jul 06, 2015 at 05:21:48PM +0200, Daniel Vetter wrote: > On Fri, Jul 03, 2015 at 01:49:17PM +0100, Chris Wilson wrote: > > On Fri, Jul 03, 2015 at 02:35:48PM +0300, Mika Kahola wrote: > > > From EDID we can read and request higher pixel clock than > > > our HW can support. This set of patch

Re: [Intel-gfx] [PATCH] drm/i915: avoid leaking DMA mappings

On Mon, Jul 06, 2015 at 06:11:40PM +0300, Imre Deak wrote: > On ma, 2015-07-06 at 15:57 +0100, Chris Wilson wrote: > > On Mon, Jul 06, 2015 at 05:50:37PM +0300, Imre Deak wrote: > > > We have 3 types of DMA mappings for GEM objects: > > > 1. physically contiguous for stolen and for objects needing

Re: [Intel-gfx] [PATCH] drm/i915: avoid leaking DMA mappings

On Mon, Jul 06, 2015 at 03:57:44PM +0100, Chris Wilson wrote: > On Mon, Jul 06, 2015 at 05:50:37PM +0300, Imre Deak wrote: > > We have 3 types of DMA mappings for GEM objects: > > 1. physically contiguous for stolen and for objects needing contiguous > >memory > > 2. DMA-buf mappings imported v

Re: [Intel-gfx] [PATCH] drm/i915: Update WaFlushCoherentL3CacheLinesAtContextSwitch

On 06/07/15 15:33, Daniel Vetter wrote: On Mon, Jul 06, 2015 at 02:16:54PM +0100, Dave Gordon wrote: On 06/07/15 13:38, Daniel Vetter wrote: On Mon, Jul 06, 2015 at 12:52:51PM +0100, Dave Gordon wrote: On 03/07/15 16:42, Chris Wilson wrote: On Fri, Jul 03, 2015 at 02:27:31PM +0100, Arun Siluv

Re: [Intel-gfx] [RFC] drm/i915: Add sync framework support to execbuff IOCTL

On 07/06/2015 04:12 PM, Daniel Vetter wrote: On Mon, Jul 06, 2015 at 03:46:49PM +0100, Tvrtko Ursulin wrote: On 07/06/2015 03:26 PM, John Harrison wrote: On 06/07/2015 14:59, Daniel Vetter wrote: On Mon, Jul 06, 2015 at 01:58:25PM +0100, John Harrison wrote: On 06/07/2015 10:29, Daniel Vette

Re: [Intel-gfx] NULL pointer deferences in drm_mode_copy() and drm_crtc_index()

On Fri, Jul 03, 2015 at 02:11:37PM -0400, Michael Kaminsky wrote: > I few days ago I built a kernel from git (commit 6aaf0da872), and > noticed a couple of NULL pointer deferences. These seem to be > regressions as they aren't present in v4.1. > > I did a bisect between v4.1 and 6aaf0da872, and c

Re: [Intel-gfx] [PATCH] drm/i915: avoid leaking DMA mappings

On ma, 2015-07-06 at 16:11 +0100, Tvrtko Ursulin wrote: > Hi, > > On 07/06/2015 03:50 PM, Imre Deak wrote: > > We have 3 types of DMA mappings for GEM objects: > > 1. physically contiguous for stolen and for objects needing contiguous > > memory > > 2. DMA-buf mappings imported via a DMA-buf a

Re: [Intel-gfx] [PATCH] drm/i915: Restore all GGTT VMAs on resume

On Mon, Jul 06, 2015 at 03:15:01PM +0100, Tvrtko Ursulin wrote: > From: Tvrtko Ursulin > > When rotated and partial views were added no one spotted the resume > path which assumes only one GGTT VMA per object and hence is now > skipping rebind of alternative views. > > Signed-off-by: Tvrtko Ursu

Re: [Intel-gfx] [PATCH 0/9] drm/i915: Check pixel clock when setting mode

On Fri, Jul 03, 2015 at 01:49:17PM +0100, Chris Wilson wrote: > On Fri, Jul 03, 2015 at 02:35:48PM +0300, Mika Kahola wrote: > > From EDID we can read and request higher pixel clock than > > our HW can support. This set of patches add checks if > > requested pixel clock is lower than the one suppor

Re: [Intel-gfx] [PATCH] drm/i915: RMW register cycles considered evil

On Mon, Jul 06, 2015 at 04:58:19PM +0200, Daniel Vetter wrote: > On Mon, Jul 06, 2015 at 01:46:19PM +0100, Damien Lespiau wrote: > > On Mon, Jul 06, 2015 at 02:42:02PM +0200, Daniel Vetter wrote: > > > Especially for workarounds which is stuff that's almost impossible to > > > verify: The initial s

Re: [Intel-gfx] [PATCH] drm/i915: avoid leaking DMA mappings

On ma, 2015-07-06 at 15:57 +0100, Chris Wilson wrote: > On Mon, Jul 06, 2015 at 05:50:37PM +0300, Imre Deak wrote: > > We have 3 types of DMA mappings for GEM objects: > > 1. physically contiguous for stolen and for objects needing contiguous > >memory > > 2. DMA-buf mappings imported via a DMA

Re: [Intel-gfx] [PATCH] drm/i915: avoid leaking DMA mappings

Hi, On 07/06/2015 03:50 PM, Imre Deak wrote: We have 3 types of DMA mappings for GEM objects: 1. physically contiguous for stolen and for objects needing contiguous memory 2. DMA-buf mappings imported via a DMA-buf attach operation 3. SG DMA mappings for shmem backed and userptr objects Fo

Re: [Intel-gfx] [RFC] drm/i915: Add sync framework support to execbuff IOCTL

On Mon, Jul 06, 2015 at 03:46:49PM +0100, Tvrtko Ursulin wrote: > > On 07/06/2015 03:26 PM, John Harrison wrote: > >On 06/07/2015 14:59, Daniel Vetter wrote: > >>On Mon, Jul 06, 2015 at 01:58:25PM +0100, John Harrison wrote: > >>>On 06/07/2015 10:29, Daniel Vetter wrote: > On Fri, Jul 03, 2015

Re: [Intel-gfx] [PATCH i-g-t 00/16] Introduction of plotting support

On Mon, Jul 06, 2015 at 04:54:48PM +0200, Daniel Vetter wrote: > On Mon, Jul 06, 2015 at 01:35:28PM +0100, Damien Lespiau wrote: > > Long story short: > > http://entropy.lespiau.name/intel-gpu-tools/test_simple_plot.png > > http://entropy.lespiau.name/intel-gpu-tools/test_two_plots.png > > > >

Re: [Intel-gfx] [PATCH] drm/i915: RMW register cycles considered evil

On Mon, Jul 06, 2015 at 03:50:49PM +0300, Ville Syrjälä wrote: > On Mon, Jul 06, 2015 at 02:42:02PM +0200, Daniel Vetter wrote: > > Especially for workarounds which is stuff that's almost impossible to > > verify: The initial state from the firmware on boot-up and after > > resume could be differen

Re: [Intel-gfx] [PATCH] drm/i915: RMW register cycles considered evil

On Mon, Jul 06, 2015 at 03:07:16PM +0100, Dave Gordon wrote: > On 06/07/15 13:50, Ville Syrjälä wrote: > >On Mon, Jul 06, 2015 at 02:42:02PM +0200, Daniel Vetter wrote: > >>Especially for workarounds which is stuff that's almost impossible to > >>verify: The initial state from the firmware on boot-

Re: [Intel-gfx] [PATCH] drm/i915: avoid leaking DMA mappings

On Mon, Jul 06, 2015 at 05:50:37PM +0300, Imre Deak wrote: > We have 3 types of DMA mappings for GEM objects: > 1. physically contiguous for stolen and for objects needing contiguous >memory > 2. DMA-buf mappings imported via a DMA-buf attach operation > 3. SG DMA mappings for shmem backed and

Re: [Intel-gfx] [PATCH] drm/i915: RMW register cycles considered evil

On Mon, Jul 06, 2015 at 01:46:19PM +0100, Damien Lespiau wrote: > On Mon, Jul 06, 2015 at 02:42:02PM +0200, Daniel Vetter wrote: > > Especially for workarounds which is stuff that's almost impossible to > > verify: The initial state from the firmware on boot-up and after > > resume could be differe

Re: [Intel-gfx] [PATCH i-g-t 00/16] Introduction of plotting support

On Mon, Jul 06, 2015 at 01:35:28PM +0100, Damien Lespiau wrote: > Long story short: > http://entropy.lespiau.name/intel-gpu-tools/test_simple_plot.png > http://entropy.lespiau.name/intel-gpu-tools/test_two_plots.png > > I had fun with the previous week-end errand around igt_stats so did it aga

[Intel-gfx] [PATCH] drm/i915: avoid leaking DMA mappings

We have 3 types of DMA mappings for GEM objects: 1. physically contiguous for stolen and for objects needing contiguous memory 2. DMA-buf mappings imported via a DMA-buf attach operation 3. SG DMA mappings for shmem backed and userptr objects For 1. and 2. the lifetime of the DMA mapping matche

Re: [Intel-gfx] [PATCH 7/7] drm/i915: Mark elsps submitted when they are pushed to hw

On Mon, Jul 06, 2015 at 10:32:11AM +0100, Chris Wilson wrote: > On Mon, Jul 06, 2015 at 10:25:17AM +0100, Chris Wilson wrote: > > On Mon, Jul 06, 2015 at 11:09:25AM +0300, Mika Kuoppala wrote: > > > Now when we have requests this deep on call chain, we can mark > > > the elsp being submitted when i

Re: [Intel-gfx] [RFC] drm/i915: Add sync framework support to execbuff IOCTL

On 07/06/2015 03:26 PM, John Harrison wrote: On 06/07/2015 14:59, Daniel Vetter wrote: On Mon, Jul 06, 2015 at 01:58:25PM +0100, John Harrison wrote: On 06/07/2015 10:29, Daniel Vetter wrote: On Fri, Jul 03, 2015 at 12:17:33PM +0100, Tvrtko Ursulin wrote: On 07/02/2015 04:55 PM, Chris Wilson

Re: [Intel-gfx] [PATCH v3 4/5] drm: Add decoding of i915 ioctls

On Mon, 6 Jul 2015 12:35:52 +0200 Patrik Jakobsson wrote: > On Fri, Jul 03, 2015 at 03:36:09AM +0300, Dmitry V. Levin wrote: > > On Wed, Jul 01, 2015 at 02:52:47PM +0200, Patrik Jakobsson wrote: > > [...] > > > --- a/drm.c > > > +++ b/drm.c > > > @@ -35,6 +35,9 @@ > > > > > > #define DRM_MAX_N

Re: [Intel-gfx] [RFC] drm/i915: Add sync framework support to execbuff IOCTL

On Mon, Jul 06, 2015 at 03:26:12PM +0100, John Harrison wrote: > On 06/07/2015 14:59, Daniel Vetter wrote: > >On Mon, Jul 06, 2015 at 01:58:25PM +0100, John Harrison wrote: > >>On 06/07/2015 10:29, Daniel Vetter wrote: > >>>On Fri, Jul 03, 2015 at 12:17:33PM +0100, Tvrtko Ursulin wrote: > On 07

Re: [Intel-gfx] [PATCH 2/3] igt/gem_pread: Support to verify pread/pwrite for non-shmem backed obj

On 03/07/15 10:37, Tvrtko Ursulin wrote: On 07/01/2015 10:26 AM, ankitprasad.r.sha...@intel.com wrote: From: Ankitprasad Sharma This patch adds support to verify pread/pwrite for non-shmem backed objects. It also shows the pread/pwrite speed. It also tests speeds for pread with and without u

Re: [Intel-gfx] [RFC] drm/i915: Add sync framework support to execbuff IOCTL

On 06/07/2015 14:59, Daniel Vetter wrote: On Mon, Jul 06, 2015 at 01:58:25PM +0100, John Harrison wrote: On 06/07/2015 10:29, Daniel Vetter wrote: On Fri, Jul 03, 2015 at 12:17:33PM +0100, Tvrtko Ursulin wrote: On 07/02/2015 04:55 PM, Chris Wilson wrote: It would be nice if we could reuse one

Re: [Intel-gfx] [PATCH] drm/i915: Update WaFlushCoherentL3CacheLinesAtContextSwitch

On Mon, Jul 06, 2015 at 02:16:54PM +0100, Dave Gordon wrote: > On 06/07/15 13:38, Daniel Vetter wrote: > >On Mon, Jul 06, 2015 at 12:52:51PM +0100, Dave Gordon wrote: > >>On 03/07/15 16:42, Chris Wilson wrote: > >>>On Fri, Jul 03, 2015 at 02:27:31PM +0100, Arun Siluvery wrote: > In this WA we n

Re: [Intel-gfx] [PATCH 00/15 v3] Batch submission via GuC

On Fri, Jul 03, 2015 at 01:30:22PM +0100, Dave Gordon wrote: > This patch series enables command submission via the GuC. In this mode, > instead of the host CPU driving the execlist port directly, it hands > over work items to the GuC, using a doorbell mechanism to tell the GuC > that new items hav

Re: [Intel-gfx] [PATCH 05/15] drm/i915: GuC-specific firmware loader

On Fri, Jul 03, 2015 at 01:30:27PM +0100, Dave Gordon wrote: > From: Alex Dai > > This uses the common firmware loader to fetch the firmware image, > then loads it into the GuC's memory via a dedicated DMA engine. > > This patch is derived from GuC loading work originally done by > Vinit Azad an

[Intel-gfx] [PATCH] drm/i915: Restore all GGTT VMAs on resume

From: Tvrtko Ursulin When rotated and partial views were added no one spotted the resume path which assumes only one GGTT VMA per object and hence is now skipping rebind of alternative views. Signed-off-by: Tvrtko Ursulin Cc: Daniel Vetter Cc: Chris Wilson Cc: Joonas Lahtinen --- Similarly t

Re: [Intel-gfx] [PATCH 14/15] Documentation/drm: kerneldoc for GuC

On Fri, Jul 03, 2015 at 01:30:36PM +0100, Dave Gordon wrote: > From: Alex Dai > > Add overview design of GuC, plus some key points related to > the implementation. > > Signed-off-by: Alex Dai > Signed-off-by: Dave Gordon Oops here it is, you can disregard my ask for kerneldoc integration. Nex

Re: [Intel-gfx] [PATCH 11/15] drm/i915: Interrupt routing for GuC submission

On Fri, Jul 03, 2015 at 01:30:33PM +0100, Dave Gordon wrote: > Turn on interrupt steering to route necessary interrupts to GuC. > > Issue: VIZ-4884 > Signed-off-by: Alex Dai > Signed-off-by: Dave Gordon > --- > drivers/gpu/drm/i915/i915_reg.h | 11 +-- > drivers/gpu/drm/i915/intel_g

Re: [Intel-gfx] [PATCH 02/15] drm/i915: Embedded microcontroller (uC) firmware loading support

On Fri, Jul 03, 2015 at 01:30:24PM +0100, Dave Gordon wrote: > Current devices may contain one or more programmable microcontrollers > that need to have a firmware image (aka "binary blob") loaded from an > external medium and transferred to the device's memory. > > This file provides common suppo

Re: [Intel-gfx] [PATCH 10/15] drm/i915: Implementation of GuC client

On Fri, Jul 03, 2015 at 01:30:32PM +0100, Dave Gordon wrote: > A GuC client has its own doorbell and workqueue. It maintains the > doorbell cache line, process description object and work queue item. > > A default guc_client is created for the i915 driver to use for > normal-priority in-order subm

Re: [Intel-gfx] [PATCH] drm/i915: RMW register cycles considered evil

On 06/07/15 13:50, Ville Syrjälä wrote: On Mon, Jul 06, 2015 at 02:42:02PM +0200, Daniel Vetter wrote: Especially for workarounds which is stuff that's almost impossible to verify: The initial state from the firmware on boot-up and after resume could be different, which will hide bugs when we do

Re: [Intel-gfx] [PATCH 03/15] drm/i915: Add GuC-related module parameters

On Fri, Jul 03, 2015 at 01:30:25PM +0100, Dave Gordon wrote: > From: Alex Dai > > Two new module parameters: "enable_guc_submission" which will turn > on submission of batchbuffers via the GuC (when implemented), and > "guc_log_level" which controls the level of debugging logged by the > GuC and

Re: [Intel-gfx] [RFC] drm/i915: Add sync framework support to execbuff IOCTL

On Mon, Jul 06, 2015 at 01:58:25PM +0100, John Harrison wrote: > On 06/07/2015 10:29, Daniel Vetter wrote: > >On Fri, Jul 03, 2015 at 12:17:33PM +0100, Tvrtko Ursulin wrote: > >>On 07/02/2015 04:55 PM, Chris Wilson wrote: > >>>It would be nice if we could reuse one seqno both for internal/external

Re: [Intel-gfx] [PATCH v4 2/2] drm/i915: On fb alloc failure, unref gem object where it gets refed

On Mon, Jul 06, 2015 at 02:59:02PM +0200, Lukas Wunner wrote: > Hi Daniel, > > On Mon, Jul 06, 2015 at 09:41:51AM +0200, Daniel Vetter wrote: > > Please keep a record of the changes you do to the patch so I know what to > > look out for. Just reving the patch revision alone doesn't add much > > in

[Intel-gfx] [PATCH v2 5/7] drm/i915: Move intel_dp->lane_count into pipe_config

From: Ville Syrjälä Currently we clobber intel_dp->lane_count in compute config, which means after a rejected modeset we may no longer be able to retrain the current link. Move lane_count into pipe_config to avoid that. v2: Add missing ':' to the pipe config debug dump Signed-off-by: Ville Syrj

Re: [Intel-gfx] [PATCH 02/15] drm/i915: Embedded microcontroller (uC) firmware loading support

On Mon, Jul 06, 2015 at 01:44:10PM +0100, Dave Gordon wrote: > On 24/06/15 11:29, Daniel Vetter wrote: > >On Fri, Jun 19, 2015 at 09:43:11AM +0100, Dave Gordon wrote: > >>On 18/06/15 15:49, Daniel Vetter wrote: > >>>On Thu, Jun 18, 2015 at 01:11:34PM +0100, Dave Gordon wrote: > On 17/06/15 13:0

Re: [Intel-gfx] [PATCH] drm/i915: Update WaFlushCoherentL3CacheLinesAtContextSwitch

On 06/07/15 13:38, Daniel Vetter wrote: On Mon, Jul 06, 2015 at 12:52:51PM +0100, Dave Gordon wrote: On 03/07/15 16:42, Chris Wilson wrote: On Fri, Jul 03, 2015 at 02:27:31PM +0100, Arun Siluvery wrote: In this WA we need to set GEN8_L3SQCREG4[21:21] and reset it after PIPE_CONTROL instruction

Re: [Intel-gfx] [PATCH v4 2/2] drm/i915: On fb alloc failure, unref gem object where it gets refed

Hi Daniel, On Mon, Jul 06, 2015 at 09:41:51AM +0200, Daniel Vetter wrote: > Please keep a record of the changes you do to the patch so I know what to > look out for. Just reving the patch revision alone doesn't add much > information for reviewers/maintainers. There's a changelog in the first pat

Re: [Intel-gfx] [RFC] drm/i915: Add sync framework support to execbuff IOCTL

On 06/07/2015 10:29, Daniel Vetter wrote: On Fri, Jul 03, 2015 at 12:17:33PM +0100, Tvrtko Ursulin wrote: On 07/02/2015 04:55 PM, Chris Wilson wrote: It would be nice if we could reuse one seqno both for internal/external fences. If you need to expose a fence ordering within a timeline that is

Re: [Intel-gfx] [PATCH v2] drm/i915: Per-DDI I_boost override

On Fri, Jul 03, 2015 at 06:35:55PM +0300, Ville Syrjälä wrote: > On Fri, Jul 03, 2015 at 04:25:15PM +0100, Damien Lespiau wrote: > > On Fri, Jul 03, 2015 at 06:21:58PM +0300, Ville Syrjälä wrote: > > > > In the old VBT spec I have, each child_dev_config is supposed to have > > > > only 33 bytes. Bu

Re: [Intel-gfx] [PATCH] drm/i915: RMW register cycles considered evil

On Mon, Jul 06, 2015 at 02:42:02PM +0200, Daniel Vetter wrote: > Especially for workarounds which is stuff that's almost impossible to > verify: The initial state from the firmware on boot-up and after > resume could be different, which will hide bugs when we do an RMW > cycle. If you're really wo

Re: [Intel-gfx] [CABC PATCH v1 3/3][RFC] drm/i915: CABC support for backlight control

On Mon, Jul 06, 2015 at 09:46:07AM +0530, Deepak M wrote: > In CABC (Content Adaptive Brightness Control) content grey level > scale can be increased while simultaneously decreasing > brightness of the backlight to achieve same perceived brightness. > > The CABC is not standardized and panel vendo

Re: [Intel-gfx] [PATCH] drm/i915: RMW register cycles considered evil

On Mon, Jul 06, 2015 at 02:42:02PM +0200, Daniel Vetter wrote: > Especially for workarounds which is stuff that's almost impossible to > verify: The initial state from the firmware on boot-up and after > resume could be different, which will hide bugs when we do an RMW > cycle. > > Hence never do

Re: [Intel-gfx] [PATCH 02/15] drm/i915: Embedded microcontroller (uC) firmware loading support

On 24/06/15 11:29, Daniel Vetter wrote: On Fri, Jun 19, 2015 at 09:43:11AM +0100, Dave Gordon wrote: On 18/06/15 15:49, Daniel Vetter wrote: On Thu, Jun 18, 2015 at 01:11:34PM +0100, Dave Gordon wrote: On 17/06/15 13:05, Daniel Vetter wrote: On Mon, Jun 15, 2015 at 07:36:20PM +0100, Dave Gord

[Intel-gfx] [PATCH] drm/i915: RMW register cycles considered evil

Especially for workarounds which is stuff that's almost impossible to verify: The initial state from the firmware on boot-up and after resume could be different, which will hide bugs when we do an RMW cycle. Hence never do them, and if it's required we need a special mask. Cc: Damien Lespiau Cc:

Re: [Intel-gfx] [PATCH] drm/i915: set FDI translations to NULL on SKL

On Mon, Jul 06, 2015 at 01:47:44PM +0300, David Weinehall wrote: > On Fri, Jul 03, 2015 at 12:31:30PM -0300, Paulo Zanoni wrote: > > From: Paulo Zanoni > > > > drivers/gpu/drm/i915/intel_ddi.c: In function ‘intel_prepare_ddi’: > > drivers/gpu/drm/i915/intel_ddi.c:517:6: warning: > > ‘ddi_translat

[Intel-gfx] [PATCH i-g-t 14/16] plot: Write simple plot with debug rectangles as well

Not only useful for inspection but also to check we can re-start a drawing just fine. Signed-off-by: Damien Lespiau --- lib/tests/igt_plot.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/lib/tests/igt_plot.c b/lib/tests/igt_plot.c index a178fbf..7091cef 100644 --- a/lib/tests/igt_plot.c

[Intel-gfx] NULL pointer deferences in drm_mode_copy() and drm_crtc_index()

I few days ago I built a kernel from git (commit 6aaf0da872), and noticed a couple of NULL pointer deferences. These seem to be regressions as they aren't present in v4.1. I did a bisect between v4.1 and 6aaf0da872, and came up with the following commit as the first bad one: d5432a9d drm/i915:

  1   2   >