[Intel-gfx] [PATCH V3] drm/i915: Add sprite watermark programming for VLV and CHV

2014-08-06 Thread Gajanan Bhat
Program DDL register as part of sprite watermark programming for CHV and VLV. v2: Rename DRAIN_LATENCY_MAX by DRAIN_LATENCY_MASK v3: Addressed review comments by Ville - Changed Sprite DDL definitions to more generic to avoid multiple if-else - Changed bit masking to customary form -

Re: [Intel-gfx] [PATCH 3/3] drm/i915: Add sprite watermark programming for VLV and CHV

2014-08-06 Thread Bhat, Gajanan
On 7/31/2014 7:14 PM, Imre Deak wrote: On Wed, 2014-07-16 at 18:24 +0530, Gajanan Bhat wrote: Program DDL register as part sprite watermark programming for CHV and VLV. Signed-off-by: Gajanan Bhat This looks ok, but could you confirm, ideally referencing some document, that we don't need to

[Intel-gfx] [PATCH] tests/pm_rpm: add subtests for planes and cursors

2014-08-06 Thread Paulo Zanoni
From: Paulo Zanoni These tests should trigger WARNs on Kernels that don't have the most recent fixes. v2: - Merge both the cursor and planes patches into one so it's easier to update them. - Extend the tests a little bit to exercise fences. - Fix bug found by Matt to enable the tes

[Intel-gfx] [PATCH] drm/i915: fix plane/cursor handling when runtime suspended

2014-08-06 Thread Paulo Zanoni
From: Paulo Zanoni If we're runtime suspended and try to use the plane interfaces, we will get a lot of WARNs saying we did the wrong thing. For intel_crtc_update_cursor(), all we need to do is return if the CRTC is not active, since writing the registers won't really have any effect if the scre

Re: [Intel-gfx] [PATCH 1/2] drm/i915: Rework ppgtt init to no require an aliasing ppgtt

2014-08-06 Thread Daniel Vetter
On Wed, Aug 06, 2014 at 08:19:53PM +0200, Daniel Vetter wrote: > Currently we abuse the aliasing ppgtt to set up the ppgtt support in > general. Which is a bit backwards since with full ppgtt we don't ever > need the aliasing ppgtt. > > So untangling this and separate the ppgtt init from the alias

Re: [Intel-gfx] [PATCH] drm: Don't grab an fb reference for the idr

2014-08-06 Thread Daniel Vetter
On Wed, Aug 06, 2014 at 02:59:29PM -0400, Rob Clark wrote: > On Wed, Aug 6, 2014 at 10:07 AM, Daniel Vetter wrote: > > On Wed, Aug 06, 2014 at 09:12:42AM -0400, Rob Clark wrote: > >> On Wed, Aug 6, 2014 at 8:37 AM, Daniel Vetter wrote: > >> > On Wed, Aug 06, 2014 at 07:11:28AM -0400, Rob Clark wr

Re: [Intel-gfx] [PATCH v3] drm/i915: Generalize drain latency computation

2014-08-06 Thread Daniel Vetter
On Wed, Aug 06, 2014 at 06:07:12PM +0300, Ville Syrjälä wrote: > On Thu, Aug 07, 2014 at 01:58:24AM +0530, Gajanan Bhat wrote: > > Modify drain latency computation to use it for any plane. Same function can > > be > > used for primary, cursor and sprite planes. > > > > v2: Adressed review comment

[Intel-gfx] [PATCH 1/2] drm/i915: Rework ppgtt init to no require an aliasing ppgtt

2014-08-06 Thread Daniel Vetter
Currently we abuse the aliasing ppgtt to set up the ppgtt support in general. Which is a bit backwards since with full ppgtt we don't ever need the aliasing ppgtt. So untangling this and separate the ppgtt init from the aliasing ppgtt. While at it drag it out of the context enabling (which just do

[Intel-gfx] [PATCH 2/2] drm/i915: Initialize the aliasing ppgtt as part of global gtt

2014-08-06 Thread Daniel Vetter
Stuffing this into the context setup code doesn't make a lot of sense. Also reusing the real ppgtt setup code makes even less sense since the aliasing ppgtt isn't a real address space. Leaving all that stuff unitialized will make sure that we catch any abusers promptly. This is also a prep work to

Re: [Intel-gfx] [PATCH] drm: Don't grab an fb reference for the idr

2014-08-06 Thread Rob Clark
On Wed, Aug 6, 2014 at 10:07 AM, Daniel Vetter wrote: > On Wed, Aug 06, 2014 at 09:12:42AM -0400, Rob Clark wrote: >> On Wed, Aug 6, 2014 at 8:37 AM, Daniel Vetter wrote: >> > On Wed, Aug 06, 2014 at 07:11:28AM -0400, Rob Clark wrote: >> >> On Wed, Aug 6, 2014 at 3:10 AM, Daniel Vetter >> >> wr

Re: [Intel-gfx] [PATCH v2] drm/i915: Rework GPU reset sequence to match driver load & thaw

2014-08-06 Thread Mika Kuoppala
Hi, alistair.mcau...@intel.com writes: > From: "McAulay, Alistair" > > This patch is to address Daniels concerns over different code during reset: > > http://lists.freedesktop.org/archives/intel-gfx/2014-June/047758.html > > "The reason for aiming as hard as possible to use the exact same code

Re: [Intel-gfx] [PATCH v2 i-g-t] lib/chv: CHV media pipeline command sequence

2014-08-06 Thread Daniel Vetter
On Wed, Aug 06, 2014 at 10:30:50AM +0800, Xiang, Haihao wrote: > > Enable gem_media_fill test for CHV platform. In addition to differences in > > media IP blocks from Broadwell, the command sequence also differs for > > programming the media pipeline, e.g., should not send a MEDIA_STATE_FLUSH > >

Re: [Intel-gfx] [PATCH v3] drm/i915: Generalize drain latency computation

2014-08-06 Thread Ville Syrjälä
On Thu, Aug 07, 2014 at 01:58:24AM +0530, Gajanan Bhat wrote: > Modify drain latency computation to use it for any plane. Same function can be > used for primary, cursor and sprite planes. > > v2: Adressed review comments by Imre and Ville. > - Moved clock round up in separate patch > - Ad

Re: [Intel-gfx] [PATCH 1/2] drm/i915: Slice/Subslice/EU info via GETPARAM

2014-08-06 Thread Daniel Vetter
On Wed, Aug 06, 2014 at 09:43:44AM -0500, Jeff McGee wrote: > On Tue, Aug 05, 2014 at 04:50:16PM +0200, Daniel Vetter wrote: > > On Tue, Aug 5, 2014 at 4:03 PM, Jeff McGee wrote: > > >> Also, usual broken record request: I need open-source userspace using > > >> this (mesa, ddx, libva). > > >> -Da

Re: [Intel-gfx] [PATCH 04/15] drm/i915: honour forced connector modes

2014-08-06 Thread Jesse Barnes
On Tue, 5 Aug 2014 07:51:15 -0700 Rodrigo Vivi wrote: > From: Chris Wilson > > In the move over to use BIOS connector configs, we lost the ability to > force a specific set of connectors on or off. Try to remedy that by > dropping back to the old behavior if we detect a hard coded connector >

[Intel-gfx] [PATCH v3] drm/i915: Generalize drain latency computation

2014-08-06 Thread Gajanan Bhat
Modify drain latency computation to use it for any plane. Same function can be used for primary, cursor and sprite planes. v2: Adressed review comments by Imre and Ville. - Moved clock round up in separate patch - Added WARN check for clock and pixel size - Simplified bit masking -

Re: [Intel-gfx] [PATCH 1/2] drm/i915: Slice/Subslice/EU info via GETPARAM

2014-08-06 Thread Jeff McGee
On Tue, Aug 05, 2014 at 04:50:16PM +0200, Daniel Vetter wrote: > On Tue, Aug 5, 2014 at 4:03 PM, Jeff McGee wrote: > >> Also, usual broken record request: I need open-source userspace using > >> this (mesa, ddx, libva). > >> -Daniel > >> > > > > This is kind of chicken-and-egg problem that I haven

[Intel-gfx] [PATCH 13/15] drm/i915: Extract commmon global gtt cleanup code

2014-08-06 Thread Daniel Vetter
We want to move the aliasing ppgtt cleanup back into the global gtt cleanup code for symmetric, but first we need to create such a place. Signed-off-by: Daniel Vetter --- drivers/gpu/drm/i915/i915_dma.c | 4 ++-- drivers/gpu/drm/i915/i915_gem_gtt.c | 20 drivers/gpu/drm

[Intel-gfx] [PATCH 14/15] drm/i915: Cleanup aliasging ppgtt alongside the global gtt

2014-08-06 Thread Daniel Vetter
Also remove related WARN_ONs which seem to have been hit since a rather long time. But apperently no one noticed since our module reload is already WARNING-infested :( Signed-off-by: Daniel Vetter --- drivers/gpu/drm/i915/i915_dma.c | 4 drivers/gpu/drm/i915/i915_gem_gtt.c | 7 +++

[Intel-gfx] [PATCH 15/15] drm/i915: don't touch console_lock for I915_FBDEV=n

2014-08-06 Thread Daniel Vetter
We still have locking hilarity between the console_lock and the world, so really don't bother with it if at all possible. This shuts up a locdep splat I'm seeing after a system s/r cycle followed by reloading i915. Signed-off-by: Daniel Vetter --- drivers/gpu/drm/i915/i915_drv.c | 4 1 file

[Intel-gfx] [PATCH 10/15] drm/i915: Only track real ppgtt for a context

2014-08-06 Thread Daniel Vetter
There's a bit a confusion since we track the global gtt, the aliasing and real ppgtt in the ctx->vm pointer. And not all callers really bother to check for the different cases and just presume that it points to a real ppgtt. Now looking closely we don't actually need ->vm to always point at an add

[Intel-gfx] [PATCH 12/15] drm/i915: Extract common cleanup into i915_ppgtt_release

2014-08-06 Thread Daniel Vetter
Address space cleanup isn't really a job for the low-level cleanup callbacks. Without this change we can't reuse the low-level cleanup callback for the aliasing ppgtt cleanup. Signed-off-by: Daniel Vetter --- drivers/gpu/drm/i915/i915_gem_gtt.c | 8 +++- 1 file changed, 3 insertions(+), 5 de

[Intel-gfx] [PATCH 09/15] drm/i915: Initialize the aliasing ppgtt as part of global gtt

2014-08-06 Thread Daniel Vetter
Stuffing this into the context setup code doesn't make a lot of sense. Also reusing the real ppgtt setup code makes even less sense since the aliasing ppgtt isn't a real address space. Leaving all that stuff unitialized will make sure that we catch any abusers promptly. This is also a prep work to

[Intel-gfx] [PATCH 11/15] drm/i915: Drop create_vm argument to i915_gem_create_context

2014-08-06 Thread Daniel Vetter
Now that all the flow is streamlined the rule is simple: We create a new ppgtt for a new context when we have full ppgtt enabled. Signed-off-by: Daniel Vetter --- drivers/gpu/drm/i915/i915_gem_context.c | 11 +-- 1 file changed, 5 insertions(+), 6 deletions(-) diff --git a/drivers/gpu/d

[Intel-gfx] [PATCH 03/15] drm/i915: Move i915_gem_chipset_flush to where it belongs

2014-08-06 Thread Daniel Vetter
Include depency hell ftw! So need to move this into a real function. Also fix up the header include order in i915_drv.h: The rule is to always include core headers first, then local stuff. Signed-off-by: Daniel Vetter --- drivers/gpu/drm/i915/i915_drv.h | 7 --- drivers/gpu/drm/i915/i91

[Intel-gfx] [PATCH 02/15] drm/i915: Some cleanups for the ppgtt lifetime handling

2014-08-06 Thread Daniel Vetter
So when reviewing Michel's patch I've noticed a few things and cleaned them up: - The early checks in ppgtt_release are now redundant: The inactive list should always be empty now, so we can ditch these checks. Even for the aliasing ppgtt (though that's a different confusion) since we tear th

[Intel-gfx] [PATCH 07/15] drm/i915: Allow i915_gem_setup_global_gtt to fail

2014-08-06 Thread Daniel Vetter
We already needs this just as a safety check in case the preallocation reservation dance fails. But we definitely need this to be able to move tha aliasing ppgtt setup back out of the context code to this place, where it belongs. Signed-off-by: Daniel Vetter --- drivers/gpu/drm/i915/i915_gem.c

[Intel-gfx] [PATCH 04/15] drm/i915: Track file_priv, not ctx in the ppgtt structure

2014-08-06 Thread Daniel Vetter
Hardware contexts reference a ppgtt, not the other way round. And the only user of this (in debugfs) actually only cares about which file the ppgtt is associated with. So give it what it wants. While at it give the ppgtt create function a proper name&place. Reviewed-by: Michel Thierry Signed-off

[Intel-gfx] [PATCH 08/15] drm/i915: Fix up checks for aliasing ppgtt

2014-08-06 Thread Daniel Vetter
A subsequent patch will no longer initialize the aliasing ppgtt if we have full ppgtt enabled, since we simply don't need that any more. Unfortunately a few places check for the aliasing ppgtt instead of checking for ppgtt in general. Fix them up. One special case are the gtt offset and size macr

[Intel-gfx] [PATCH 06/15] drm/i915: Add proper prefix to obj_to_ggtt

2014-08-06 Thread Daniel Vetter
Stuff in headers really aught to have this. Reviewed-by: Michel Thierry Signed-off-by: Daniel Vetter --- drivers/gpu/drm/i915/i915_drv.h | 11 ++- drivers/gpu/drm/i915/i915_gem.c | 2 +- 2 files changed, 7 insertions(+), 6 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_drv.h b/dr

[Intel-gfx] [PATCH 05/15] drm/i915: Only refcount ppgtt if it actually is one

2014-08-06 Thread Daniel Vetter
This essentially unbreaks non-ppgtt operation where we'd scribble over random memory. While at it give the vm_to_ppgtt function a proper prefix and make it a bit more paranoid. Signed-off-by: Daniel Vetter --- drivers/gpu/drm/i915/i915_drv.h | 10 +- drivers/gpu/drm/i915/i915_gem.c

[Intel-gfx] [PATCH 01/15] drm/i915: vma/ppgtt lifetime rules

2014-08-06 Thread Daniel Vetter
From: Michel Thierry VMAs should take a reference of the address space they use. Now, when the fd is closed, it will release the ref that the context was holding, but it will still be referenced by any vmas that are still active. ppgtt_release() should then only be called when the last thing re

Re: [Intel-gfx] [PATCH 2/2] drm/i915/chv: Implement SSEU info for CHV

2014-08-06 Thread Jeff McGee
On Tue, Aug 05, 2014 at 02:41:54PM +0100, Damien Lespiau wrote: > On Tue, Aug 05, 2014 at 08:47:54AM -0500, Jeff McGee wrote: > > > > + > > > > + /* Copy SSEU info to the const device info with pointer magic */ > > > > + *(struct intel_sseu_info *)&dev_priv->info.sseu = sseu_info; > > >

Re: [Intel-gfx] [PATCH 2/2] tests/pm_rpm: add planes subtests

2014-08-06 Thread Daniel Vetter
On Wed, Aug 06, 2014 at 11:11:41AM -0300, Paulo Zanoni wrote: > 2014-08-05 18:51 GMT-03:00 Matt Roper : > > On Tue, Aug 05, 2014 at 06:34:38PM -0300, Paulo Zanoni wrote: > >> 2014-07-28 20:47 GMT-03:00 Matt Roper : > >> > On Mon, Jul 28, 2014 at 03:37:15PM -0300, Paulo Zanoni wrote: > >> >> From: P

Re: [Intel-gfx] [PATCH 15/19] drm: Update vblank->last in drm_update_vblank_count()

2014-08-06 Thread Daniel Vetter
On Wed, Aug 06, 2014 at 04:30:29PM +0300, Ville Syrjälä wrote: > On Wed, Aug 06, 2014 at 03:08:25PM +0200, Daniel Vetter wrote: > > On Wed, Aug 06, 2014 at 02:49:58PM +0300, ville.syrj...@linux.intel.com > > wrote: > > > From: Ville Syrjälä > > > > > > We should update the last in drm_update_vbl

Re: [Intel-gfx] [PATCH 2/2] tests/pm_rpm: add planes subtests

2014-08-06 Thread Paulo Zanoni
2014-08-05 18:51 GMT-03:00 Matt Roper : > On Tue, Aug 05, 2014 at 06:34:38PM -0300, Paulo Zanoni wrote: >> 2014-07-28 20:47 GMT-03:00 Matt Roper : >> > On Mon, Jul 28, 2014 at 03:37:15PM -0300, Paulo Zanoni wrote: >> >> From: Paulo Zanoni >> >> >> >> Just like the cursor subtests, these also trigg

Re: [Intel-gfx] [PATCH 2/2] drm/i915: Free pending page flip events at .preclose()

2014-08-06 Thread Daniel Vetter
On Wed, Aug 06, 2014 at 02:02:51PM +0300, ville.syrj...@linux.intel.com wrote: > From: Ville Syrjälä > > If there are pending page flips when the fd gets closed those page > flips may have events associated to them. When the page flip eventually > completes it will queue the event to file_priv->e

Re: [Intel-gfx] [PATCH] drm: Don't grab an fb reference for the idr

2014-08-06 Thread Daniel Vetter
On Wed, Aug 06, 2014 at 09:12:42AM -0400, Rob Clark wrote: > On Wed, Aug 6, 2014 at 8:37 AM, Daniel Vetter wrote: > > On Wed, Aug 06, 2014 at 07:11:28AM -0400, Rob Clark wrote: > >> On Wed, Aug 6, 2014 at 3:10 AM, Daniel Vetter > >> wrote: > >> > The current refcounting scheme is that the fb loo

Re: [Intel-gfx] [PATCH 17/19] drm/i915: Clear .last vblank count before drm_vblank_off() when sanitizing crtc state

2014-08-06 Thread Ville Syrjälä
On Wed, Aug 06, 2014 at 03:30:17PM +0200, Daniel Vetter wrote: > On Wed, Aug 06, 2014 at 02:50:00PM +0300, ville.syrj...@linux.intel.com wrote: > > From: Ville Syrjälä > > > > We call drm_vblank_off() during crtc sanitation to make sure the > > software and hardware states agree. However drm_vbla

Re: [Intel-gfx] [PATCH 09/19] drm: Fix race between drm_vblank_off() and drm_queue_vblank_event()

2014-08-06 Thread Ville Syrjälä
On Wed, Aug 06, 2014 at 03:23:01PM +0200, Daniel Vetter wrote: > On Wed, Aug 06, 2014 at 02:49:52PM +0300, ville.syrj...@linux.intel.com wrote: > > From: Ville Syrjälä > > > > Currently it's possible that the following will happen: > > 1. drm_wait_vblank() calls drm_vblank_get() > > 2. drm_vblank

Re: [Intel-gfx] [PATCH 15/19] drm: Update vblank->last in drm_update_vblank_count()

2014-08-06 Thread Ville Syrjälä
On Wed, Aug 06, 2014 at 03:08:25PM +0200, Daniel Vetter wrote: > On Wed, Aug 06, 2014 at 02:49:58PM +0300, ville.syrj...@linux.intel.com wrote: > > From: Ville Syrjälä > > > > We should update the last in drm_update_vblank_count() to avoid applying > > the diff more than once. This could occur eg

Re: [Intel-gfx] [PATCH 17/19] drm/i915: Clear .last vblank count before drm_vblank_off() when sanitizing crtc state

2014-08-06 Thread Daniel Vetter
On Wed, Aug 06, 2014 at 02:50:00PM +0300, ville.syrj...@linux.intel.com wrote: > From: Ville Syrjälä > > We call drm_vblank_off() during crtc sanitation to make sure the > software and hardware states agree. However drm_vblank_off() will > try to update the vblank timestamp and sequence number wh

Re: [Intel-gfx] [PATCH 09/19] drm: Fix race between drm_vblank_off() and drm_queue_vblank_event()

2014-08-06 Thread Daniel Vetter
On Wed, Aug 06, 2014 at 02:49:52PM +0300, ville.syrj...@linux.intel.com wrote: > From: Ville Syrjälä > > Currently it's possible that the following will happen: > 1. drm_wait_vblank() calls drm_vblank_get() > 2. drm_vblank_off() gets called > 3. drm_wait_vblank() calls drm_queue_vblank_event() wh

[Intel-gfx] [PATCH igt] tests: Add kms_flip_event_leak test

2014-08-06 Thread ville . syrjala
From: Ville Syrjälä kms_flip_event_leak will issue a page flip and close the file descriptor before the flip has finished. This may cause the kernel to leak the page flip event. The test itself won't actually fail but if the kernel notices the leak and WARNs piglit will report a failure. Signed-

Re: [Intel-gfx] [PATCH] drm: Don't grab an fb reference for the idr

2014-08-06 Thread Rob Clark
On Wed, Aug 6, 2014 at 8:37 AM, Daniel Vetter wrote: > On Wed, Aug 06, 2014 at 07:11:28AM -0400, Rob Clark wrote: >> On Wed, Aug 6, 2014 at 3:10 AM, Daniel Vetter wrote: >> > The current refcounting scheme is that the fb lookup idr also holds a >> > reference. This works out nicely bacause thus f

Re: [Intel-gfx] [PATCH 16/19] drm: Store the vblank timestamp when adjusting the counter during disable

2014-08-06 Thread Daniel Vetter
On Wed, Aug 06, 2014 at 02:49:59PM +0300, ville.syrj...@linux.intel.com wrote: > From: Ville Syrjälä > > During vblank disable the code tries to guess based on the > timestamps whether we just missed one vblank or not. And if so > it increments the counter. However it forgets to store the new > t

Re: [Intel-gfx] [PATCH 14/19] drm: Don't update vblank timestamp when the counter didn't change

2014-08-06 Thread Daniel Vetter
On Wed, Aug 06, 2014 at 02:56:14PM +0200, Daniel Vetter wrote: > On Wed, Aug 06, 2014 at 02:49:57PM +0300, ville.syrj...@linux.intel.com wrote: > > From: Ville Syrjälä > > > > If we already have a timestamp for the current vblank counter, don't > > update it with a new timestmap. Small errors can

Re: [Intel-gfx] [PATCH 15/19] drm: Update vblank->last in drm_update_vblank_count()

2014-08-06 Thread Daniel Vetter
On Wed, Aug 06, 2014 at 02:49:58PM +0300, ville.syrj...@linux.intel.com wrote: > From: Ville Syrjälä > > We should update the last in drm_update_vblank_count() to avoid applying > the diff more than once. This could occur eg. if drm_vblank_off() gets > called multiple times for the crtc. > > Sig

Re: [Intel-gfx] [PATCH v2] drm/i915: Rework GPU reset sequence to match driver load & thaw

2014-08-06 Thread Mcaulay, Alistair
Hi Daniel, I think this new patch fixes your issues with the previous one, can you please let me know. Thanks, Alistair. > -Original Message- > From: Mcaulay, Alistair > Sent: Tuesday, August 05, 2014 9:47 AM > To: intel-gfx@lists.freedesktop.org > Cc: Mcaulay, Alistair > Subject: [PAT

Re: [Intel-gfx] [PATCH 14/19] drm: Don't update vblank timestamp when the counter didn't change

2014-08-06 Thread Daniel Vetter
On Wed, Aug 06, 2014 at 02:49:57PM +0300, ville.syrj...@linux.intel.com wrote: > From: Ville Syrjälä > > If we already have a timestamp for the current vblank counter, don't > update it with a new timestmap. Small errors can creep in between two > timestamp queries for the same vblank count, whic

[Intel-gfx] [PATCH 1/2] video/fbdev: Always built-in video= cmdline parsing

2014-08-06 Thread Daniel Vetter
In drm/i915 we want to get at the video= cmdline modes even when we don't have fbdev support enabled, so that users can always override the kernel's initial mode selection. But that gives us a direct depency upon the parsing code in the fbdev subsystem. Since it's so little code just extract these

[Intel-gfx] [PATCH 2/2] drm: Perform cmdline mode parsing during connector initialisation

2014-08-06 Thread Daniel Vetter
From: Chris Wilson i915.ko has a custom fbdev initialisation routine that aims to preserve the current mode set by the BIOS, unless overruled by the user. The user's wishes are determined by what, if any, mode is specified on the command line (via the video= parameter). However, that command line

Re: [Intel-gfx] [PATCH 2/2] drm/i915: Free pending page flip events at .preclose()

2014-08-06 Thread Daniel Vetter
On Wed, Aug 06, 2014 at 02:02:51PM +0300, ville.syrj...@linux.intel.com wrote: > From: Ville Syrjälä > > If there are pending page flips when the fd gets closed those page > flips may have events associated to them. When the page flip eventually > completes it will queue the event to file_priv->e

Re: [Intel-gfx] [PATCH] video/fbdev: Always built-in video= cmdline parsing

2014-08-06 Thread Daniel Vetter
On Wed, Aug 06, 2014 at 12:27:32PM +0200, Geert Uytterhoeven wrote: > On Wed, Aug 6, 2014 at 11:43 AM, Daniel Vetter wrote: > > In drm/i915 we want to get at the video= cmdline modes even when we > > don't have fbdev support enabled, so that users can always override > > the kernel's initial mode

Re: [Intel-gfx] [PATCH] drm: Don't grab an fb reference for the idr

2014-08-06 Thread Daniel Vetter
On Wed, Aug 06, 2014 at 07:11:28AM -0400, Rob Clark wrote: > On Wed, Aug 6, 2014 at 3:10 AM, Daniel Vetter wrote: > > The current refcounting scheme is that the fb lookup idr also holds a > > reference. This works out nicely bacause thus far we've always > > explicitly cleaned up idr entries for f

[Intel-gfx] [PATCH] video/fbdev: Always built-in video= cmdline parsing

2014-08-06 Thread Daniel Vetter
In drm/i915 we want to get at the video= cmdline modes even when we don't have fbdev support enabled, so that users can always override the kernel's initial mode selection. But that gives us a direct depency upon the parsing code in the fbdev subsystem. Since it's so little code just extract these

[Intel-gfx] [PATCH 18/19] drm/i915: Update scanline_offset only for active crtcs

2014-08-06 Thread ville . syrjala
From: Ville Syrjälä update_scanline_offset() in intel_sanitize_crtc() was supposed to be called only for active crtcs. But due to some underrun patches it now gets updated for all crtcs on gmch platforms. Move the update_scanline_offset() to the very beginning of intel_sanitize_crtc() where we u

[Intel-gfx] [PATCH 19/19] drm: Fix confusing debug message in drm_update_vblank_count()

2014-08-06 Thread ville . syrjala
From: Ville Syrjälä Now that drm_update_vblank_count() can be called even when we're not about to enable the vblank interrupts we shouldn't print debug messages stating otherwise. Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/drm_irq.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)

[Intel-gfx] [PATCH igt] tests/kms_flip: Assert that vblank timestamps aren't zeroed

2014-08-06 Thread ville . syrjala
From: Ville Syrjälä The kernel might mistakenly send out a zeroed vblank timestamp when the vblank wait gets terminated early due to crtc disable. Add an assertion to catch that. Signed-off-by: Ville Syrjälä --- tests/kms_flip.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/tests/kms_

[Intel-gfx] [PATCH 17/19] drm/i915: Clear .last vblank count before drm_vblank_off() when sanitizing crtc state

2014-08-06 Thread ville . syrjala
From: Ville Syrjälä We call drm_vblank_off() during crtc sanitation to make sure the software and hardware states agree. However drm_vblank_off() will try to update the vblank timestamp and sequence number which lands us in some trouble. As the pipe is disabled the hardware frame counter query w

[Intel-gfx] [PATCH 12/19] drm/i915: Opt out of vblank disable timer on >gen2

2014-08-06 Thread ville . syrjala
From: Ville Syrjälä Now that the vblank races are plugged, we can opt out of using the vblank disable timer and just let vblank interrupts get disabled immediately when the last reference is dropped. Gen2 is the exception since it has no hardware frame counter. Reviewed-by: Matt Roper Reviewed

[Intel-gfx] [PATCH 15/19] drm: Update vblank->last in drm_update_vblank_count()

2014-08-06 Thread ville . syrjala
From: Ville Syrjälä We should update the last in drm_update_vblank_count() to avoid applying the diff more than once. This could occur eg. if drm_vblank_off() gets called multiple times for the crtc. Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/drm_irq.c | 2 ++ 1 file changed, 2 insertion

[Intel-gfx] [PATCH 16/19] drm: Store the vblank timestamp when adjusting the counter during disable

2014-08-06 Thread ville . syrjala
From: Ville Syrjälä During vblank disable the code tries to guess based on the timestamps whether we just missed one vblank or not. And if so it increments the counter. However it forgets to store the new timestamp to the approriate slot in our timestamp ring buffer. So anyone querying the timest

[Intel-gfx] [PATCH 14/19] drm: Don't update vblank timestamp when the counter didn't change

2014-08-06 Thread ville . syrjala
From: Ville Syrjälä If we already have a timestamp for the current vblank counter, don't update it with a new timestmap. Small errors can creep in between two timestamp queries for the same vblank count, which could be confusing to userspace when it queries the timestamp for the same vblank seque

[Intel-gfx] [PATCH v2 13/19] drm: Kick start vblank interrupts at drm_vblank_on()

2014-08-06 Thread ville . syrjala
From: Ville Syrjälä If the user is interested in getting accurate vblank sequence numbers all the time they may disable the vblank disable timer entirely. In that case it seems appropriate to kick start the vblank interrupts already from drm_vblank_on(). v2: Adapt to the drm_vblank_offdelay ==0

[Intel-gfx] [PATCH 06/19] drm: Avoid random vblank counter jumps if the hardware counter has been reset

2014-08-06 Thread ville . syrjala
From: Ville Syrjälä When drm_vblank_on() is called the hardware vblank counter may have been reset, so we can't trust that the old values sampled prior to drm_vblank_off() have anything to do with the new values. So update the .last count in drm_vblank_on() to make the first drm_vblank_enable()

[Intel-gfx] [PATCH v2 11/19] drm: Add dev->vblank_disable_immediate flag

2014-08-06 Thread ville . syrjala
From: Ville Syrjälä Add a flag to drm_device which will cause the vblank code to bypass the disable timer and always disable the vblank interrupt immediately when the last reference is dropped. v2: Add some notes about the flag to the kernel doc Reviewed-by: Matt Roper Reviewed-by: Daniel Vett

[Intel-gfx] [PATCH 09/19] drm: Fix race between drm_vblank_off() and drm_queue_vblank_event()

2014-08-06 Thread ville . syrjala
From: Ville Syrjälä Currently it's possible that the following will happen: 1. drm_wait_vblank() calls drm_vblank_get() 2. drm_vblank_off() gets called 3. drm_wait_vblank() calls drm_queue_vblank_event() which adds the event to the queue event though vblank interrupts are currently disabled

[Intel-gfx] [PATCH v2 10/19] drm: Disable vblank interrupt immediately when drm_vblank_offdelay<0

2014-08-06 Thread ville . syrjala
From: Ville Syrjälä Make drm_vblank_put() disable the vblank interrupt immediately when the refcount drops to zero and drm_vblank_offdelay<0. v2: Preserve the current drm_vblank_offdelay==0 'never disable' behaviur Reviewed-by: Matt Roper Signed-off-by: Ville Syrjälä --- Documentation/DocBoo

[Intel-gfx] [PATCH v2 07/19] drm: Reduce the amount of dev->vblank[crtc] in the code

2014-08-06 Thread ville . syrjala
From: Ville Syrjälä Declare a local struct drm_vblank_crtc * and use that instead of having to do dig it out via 'dev->vblank[crtc]' everywhere. Performed with the following coccinelle incantation, and a few manual whitespace cleanups: @@ identifier func,member; expression num_crtcs; struct drm

[Intel-gfx] [PATCH 08/19] drm: Fix deadlock between event_lock and vbl_lock/vblank_time_lock

2014-08-06 Thread ville . syrjala
From: Ville Syrjälä Currently both drm_irq.c and several drivers call drm_vblank_put() while holding event_lock. Now that drm_vblank_put() can disable the vblank interrupt directly it may need to grab vbl_lock and vblank_time_lock. That causes deadlocks since we take the locks in the opposite ord

[Intel-gfx] [PATCH 05/19] drm: Have the vblank counter account for the time between vblank irq disable and drm_vblank_off()

2014-08-06 Thread ville . syrjala
From: Ville Syrjälä If the vblank irq has already been disabled (via the disable timer) when we call drm_vblank_off() sample the counter and timestamp one last time. This will make the sure that the user space visible counter will account for time between vblank irq disable and drm_vblank_off().

[Intel-gfx] [PATCH 04/19] drm: Move drm_update_vblank_count()

2014-08-06 Thread ville . syrjala
From: Ville Syrjälä Move drm_update_vblank_count() to avoid forward a declaration. No functional change. Reviewed-by: Matt Roper Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/drm_irq.c | 128 +++--- 1 file changed, 64 insertions(+), 64 deletions(-)

[Intel-gfx] [PATCH 03/19] drm: Don't clear vblank timestamps when vblank interrupt is disabled

2014-08-06 Thread ville . syrjala
From: Ville Syrjälä Clearing the timestamps causes us to send zeroed timestamps to userspace if they get sent out in response to the drm_vblank_off(). It's better to send the very latest timestamp and count instead. Testcase: igt/kms_flip/modeset-vs-vblank-race Reviewed-by: Matt Roper Reviewed-

[Intel-gfx] [PATCH v2 02/19] drm/i915: Warn if drm_vblank_get() still works after drm_vblank_off()

2014-08-06 Thread ville . syrjala
From: Ville Syrjälä v2: Drop the drm_vblank_off() (Daniel) Use drm_crtc_vblank_{get,put}() Reviewed-by: Matt Roper Reviewed-by: Daniel Vetter Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/intel_display.c | 10 ++ 1 file changed, 10 insertions(+) diff --git a/drivers/gpu/

[Intel-gfx] [PATCH v2 01/19] drm: Always reject drm_vblank_get() after drm_vblank_off()

2014-08-06 Thread ville . syrjala
From: Ville Syrjälä Make sure drm_vblank_get() never succeeds when called between drm_vblank_off() and drm_vblank_on(). Borrow a trick from the old drm_vblank_{pre,post}_modeset() functions and just bump the refcount in drm_vblank_off() and drop it in drm_vblank_on(). When drm_vblank_get() encou

[Intel-gfx] [PATCH v2 00/19] drm: More vblank on/off work

2014-08-06 Thread ville . syrjala
From: Ville Syrjälä This is mostly a repost of the earlier series [1]. Most of the patches have been reviewed, but I have added quite a few new ones to the end to fix various issues. [1] http://lists.freedesktop.org/archives/dri-devel/2014-May/060518.html Ville Syrjälä (19): drm: Always rejec

[Intel-gfx] [PATCH] drm: Renaming DP training vswing/pre-emph defines

2014-08-06 Thread sonika . jindal
From: Sonika Jindal Rename the defines to have levels instead of values for vswing and pre-emph levels as the values may differ in other scenarios like low vswing of eDP 1.4 where the values are different. v2: Keeping old and new defines (Danvet), adding description in the commit message Cc: dr

Re: [Intel-gfx] [PATCH] drm: Don't grab an fb reference for the idr

2014-08-06 Thread Rob Clark
On Wed, Aug 6, 2014 at 3:10 AM, Daniel Vetter wrote: > The current refcounting scheme is that the fb lookup idr also holds a > reference. This works out nicely bacause thus far we've always > explicitly cleaned up idr entries for framebuffers: > - Userspace fbs get removed in the rmfb ioctl or whe

[Intel-gfx] [PATCH 1/2] drm: Warn when leaking flip events on close

2014-08-06 Thread ville . syrjala
From: Ville Syrjälä Warn when there are events on the file_priv->event_list just before file_priv gets freed. This can occur if the driver doesn't clean up pending page flip events in ->preclose(). Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/drm_fops.c | 2 ++ 1 file changed, 2 insertions

[Intel-gfx] [PATCH 2/2] drm/i915: Free pending page flip events at .preclose()

2014-08-06 Thread ville . syrjala
From: Ville Syrjälä If there are pending page flips when the fd gets closed those page flips may have events associated to them. When the page flip eventually completes it will queue the event to file_priv->event_list, but that may be too late and file_priv->event_list has already been cleaned up

Re: [Intel-gfx] [PATCH] video/fbdev: Always built-in video= cmdline parsing

2014-08-06 Thread Geert Uytterhoeven
On Wed, Aug 6, 2014 at 11:43 AM, Daniel Vetter wrote: > In drm/i915 we want to get at the video= cmdline modes even when we > don't have fbdev support enabled, so that users can always override > the kernel's initial mode selection. > > But that gives us a direct depency upon the parsing code in t

[Intel-gfx] [PATCH] video/fbdev: Always built-in video= cmdline parsing

2014-08-06 Thread Daniel Vetter
In drm/i915 we want to get at the video= cmdline modes even when we don't have fbdev support enabled, so that users can always override the kernel's initial mode selection. But that gives us a direct depency upon the parsing code in the fbdev subsystem. Since it's so little code just extract these

Re: [Intel-gfx] [PATCH 34/43] drm/i915/bdw: Make sure gpu reset still works with Execlists

2014-08-06 Thread Daniel, Thomas
> -Original Message- > From: Lespiau, Damien > Sent: Friday, August 01, 2014 3:46 PM > To: Daniel, Thomas > Cc: intel-gfx@lists.freedesktop.org > Subject: Re: [Intel-gfx] [PATCH 34/43] drm/i915/bdw: Make sure gpu reset > still works with Execlists > > On Thu, Jul 24, 2014 at 05:04:42PM +

Re: [Intel-gfx] [PATCH 34/43] drm/i915/bdw: Make sure gpu reset still works with Execlists

2014-08-06 Thread Daniel, Thomas
> -Original Message- > From: Lespiau, Damien > Sent: Friday, August 01, 2014 3:42 PM > To: Daniel, Thomas > Cc: intel-gfx@lists.freedesktop.org > Subject: Re: [Intel-gfx] [PATCH 34/43] drm/i915/bdw: Make sure gpu reset > still works with Execlists > > On Thu, Jul 24, 2014 at 05:04:42PM +01

Re: [Intel-gfx] [PATCH 14/15] drm/i915: capture_reg_state interrupt registers for Gen8

2014-08-06 Thread Thierry, Michel
> -Original Message- > From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf > Of Daniel Vetter > Sent: Wednesday, August 06, 2014 9:28 AM > To: Vivi, Rodrigo > Cc: intel-gfx@lists.freedesktop.org > Subject: Re: [Intel-gfx] [PATCH 14/15] drm/i915: capture_reg_state in

Re: [Intel-gfx] [PATCH] drm/i915: Initialize the aliasing ppgtt as part of global gtt

2014-08-06 Thread Daniel Vetter
On Wed, Aug 06, 2014 at 08:44:34AM +, Thierry, Michel wrote: > > > > -Original Message- > > From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of Daniel > > Vetter > > Sent: Wednesday, August 06, 2014 9:31 AM > > To: Thierry, Michel > > Cc: Daniel Vetter; Intel Graphics Dev

Re: [Intel-gfx] [PATCH] drm/i915: Initialize the aliasing ppgtt as part of global gtt

2014-08-06 Thread Thierry, Michel
> -Original Message- > From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of Daniel > Vetter > Sent: Wednesday, August 06, 2014 9:31 AM > To: Thierry, Michel > Cc: Daniel Vetter; Intel Graphics Development > Subject: Re: [PATCH] drm/i915: Initialize the aliasing ppgtt as part o

Re: [Intel-gfx] [PATCH 6/6] drm: Resetting rotation property

2014-08-06 Thread Daniel Vetter
On Wed, Aug 06, 2014 at 01:26:00PM +0530, sonika.jin...@intel.com wrote: > From: Sonika Jindal > > Reset rotation property to 0. > > v2: Resetting after disabling the plane > > Cc: dri-de...@lists.freedesktop.org > Signed-off-by: Sonika Jindal > Reviewed-by: Ville Syrjälä I've pulled in thes

Re: [Intel-gfx] [PATCH 03/15] drm/i915: Upgrade execbuffer fail after resume failure to EIO

2014-08-06 Thread Daniel Vetter
On Wed, Aug 06, 2014 at 09:12:32AM +0100, Chris Wilson wrote: > On Wed, Aug 06, 2014 at 09:56:45AM +0200, Daniel Vetter wrote: > > On Tue, Aug 05, 2014 at 07:51:14AM -0700, Rodrigo Vivi wrote: > > > From: Chris Wilson > > > > > > If we try to execute on a known ring, but it has failed to be > > >

[Intel-gfx] [PATCH] drm: Don't grab an fb reference for the idr

2014-08-06 Thread Daniel Vetter
The current refcounting scheme is that the fb lookup idr also holds a reference. This works out nicely bacause thus far we've always explicitly cleaned up idr entries for framebuffers: - Userspace fbs get removed in the rmfb ioctl or when the drm file gets closed. - Kernel fbs (for fbdev emulatio

Re: [Intel-gfx] [PATCH] drm/i915: Initialize the aliasing ppgtt as part of global gtt

2014-08-06 Thread Daniel Vetter
On Wed, Aug 06, 2014 at 08:18:52AM +, Thierry, Michel wrote: > > > > -Original Message- > > From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] > > Sent: Monday, August 04, 2014 3:19 PM > > To: Intel Graphics Development > > Cc: Daniel Vetter; Thierry, Michel; Ville Syrjälä > > Subjec

Re: [Intel-gfx] [PATCH 14/15] drm/i915: capture_reg_state interrupt registers for Gen8

2014-08-06 Thread Daniel Vetter
On Tue, Aug 05, 2014 at 07:51:25AM -0700, Rodrigo Vivi wrote: > From: Michel Thierry > > After unclaimed register detection was enabled for BDW, I started seeing > warnings while reading registers 0x4400c (DEIER) and 0x4401c (GTIER). > > From Gen8, DEIER has been split per display engine pipe, a

Re: [Intel-gfx] [PATCH 12/15] drm/i915: State readout and cross-checking for dp_m2_n2

2014-08-06 Thread Daniel Vetter
On Tue, Aug 05, 2014 at 07:51:23AM -0700, Rodrigo Vivi wrote: > From: Vandana Kannan > > Adding relevant read out comparison code, in check_crtc_state, for the new > member of crtc_config, dp_m2_n2, which was introduced to store link_m_n > values for a DP downclock mode (if available). Suggested

Re: [Intel-gfx] [PATCH 09/15] drm/i915: Bring GPU Freq to min while suspending.

2014-08-06 Thread Daniel Vetter
On Tue, Aug 05, 2014 at 07:51:20AM -0700, Rodrigo Vivi wrote: > From: Deepak S > > We might be leaving the PGU Frequency (and thus vnn) high during the suspend. > Flusing the delayed work queue should take care of this. > > Signed-off-by: Deepak S > Signed-off-by: Rodrigo Vivi Queued for -nex

Re: [Intel-gfx] [PATCH 08/15] drm/i915: re-order ppgtt sanitize logic v2

2014-08-06 Thread Daniel Vetter
On Tue, Aug 05, 2014 at 07:51:19AM -0700, Rodrigo Vivi wrote: > From: Jesse Barnes > > Put hw limitations first, disabling ppgtt if necessary right away. > After that, check user passed args or auto-detect and do the right > thing, falling back to aliasing PPGTT if the user tries to enable full >

Re: [Intel-gfx] [PATCH 07/15] drm/i915: clean up PPGTT checking logic

2014-08-06 Thread Daniel Vetter
On Tue, Aug 05, 2014 at 07:51:18AM -0700, Rodrigo Vivi wrote: > From: Jesse Barnes > > sanitize_enable_ppgtt is the function that checks all the conditions, > honoring a forced ppgtt status or doing auto-detect as necessary. Just > make sure it returns the right value in all cases and use that i

Re: [Intel-gfx] [PATCH] drm/i915: Initialize the aliasing ppgtt as part of global gtt

2014-08-06 Thread Thierry, Michel
> -Original Message- > From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] > Sent: Monday, August 04, 2014 3:19 PM > To: Intel Graphics Development > Cc: Daniel Vetter; Thierry, Michel; Ville Syrjälä > Subject: [PATCH] drm/i915: Initialize the aliasing ppgtt as part of global gtt > > Stu

Re: [Intel-gfx] [PATCH 06/15] drm/i915: Refactor the physical and virtual page hws setup

2014-08-06 Thread Daniel Vetter
On Tue, Aug 05, 2014 at 07:51:17AM -0700, Rodrigo Vivi wrote: > From: Chris Wilson > > We duplicated the legacy physical HWS setup routine for no good reason. > Combine it with the more recent virtual HWS setup for simplicity. > > Signed-off-by: Chris Wilson > Signed-off-by: Rodrigo Vivi The

Re: [Intel-gfx] [PATCH 04/15] drm/i915: honour forced connector modes

2014-08-06 Thread Daniel Vetter
On Tue, Aug 05, 2014 at 07:51:15AM -0700, Rodrigo Vivi wrote: > From: Chris Wilson > > In the move over to use BIOS connector configs, we lost the ability to > force a specific set of connectors on or off. Try to remedy that by > dropping back to the old behavior if we detect a hard coded connec

  1   2   >