[Intel-gfx] [PATCH 2/2] drm/i915/lvds: Use i915.lvds_fixed_mode= as a last resort

If we can find no other reliable source of panel configuration data, turn to the user and see if they have a passed a mode line (ala video=) through the i915.lvds_fixed_mode= string. Signed-off-by: Chris Wilson Cc: Oliver Seitz Cc: Mike Isely Cc: Dave Airlied --- drivers/gpu/drm/i915/i915_drv

[Intel-gfx] [PATCH 1/2] drm: Export the command-line mode parser

In the absence of configuration data for providing the fixed mode for a panel, I would like to be able to pass such modes along a separate module paramenter. To do so, I then need to parse a modeline from a string, which drm is already capable of. Export that capability to the drivers. Signed-off-

[Intel-gfx] _swrast_write_rgba_span calling NULL rb->PutRow

I'm seeing an easily reproducible X crash when unlocking an OpenGL screensaver with KWin compositing enabled. The crash occurs when _swrast_write_rgba_span calls rb->PutRow, which is apparently NULL. More info can be found in these bugs: https://bugs.freedesktop.org/show_bug.cgi?id=32534

[Intel-gfx] [PATCH] drm/i915: Check that the plane points to the pipe's framebuffer before enabling

Knut Petersen reported a GPU hang when he left x11perf running overnight. The error state quite clearly indicates that plane A was enabled without being fully setup: PGTBL_ER: 0x0010 Display A: Invalid GTT PTE Plane [0]: CNTR: c100 STRIDE: 0c80 SIZE: 03ff04ff POS:

Re: [Intel-gfx] [PATCH 18/21] drm/i915: Split out i915_gem_object_move_to_ring() from execbuffer

On Sat, Apr 16, 2011 at 03:18:46PM +0100, Chris Wilson wrote: > On Sat, 16 Apr 2011 15:54:56 +0200, Daniel Vetter wrote: > > On Sat, Apr 16, 2011 at 10:17:42AM +0100, Chris Wilson wrote: > > > As we can make use of the ability to insert semaphores to serialise > > > accessing buffers between ring

Re: [Intel-gfx] [PATCH 19/21] drm/i915: Enable the use of GPU semaphores whilst page-flipping

On Sat, 16 Apr 2011 15:58:52 +0200, Daniel Vetter wrote: > On Sat, Apr 16, 2011 at 10:17:43AM +0100, Chris Wilson wrote: > > As such, being able to use a GPU semaphore and not stall the CPU/GPU > > whilst switching between rings for a pageflip is useful. > > Hey, we could issue flips on the blt r

Re: [Intel-gfx] [PATCH 18/21] drm/i915: Split out i915_gem_object_move_to_ring() from execbuffer

On Sat, 16 Apr 2011 15:54:56 +0200, Daniel Vetter wrote: > On Sat, Apr 16, 2011 at 10:17:42AM +0100, Chris Wilson wrote: > > As we can make use of the ability to insert semaphores to serialise > > accessing buffers between ring elsewhere, separate out the function from > > the execbuffer code and

Re: [Intel-gfx] [PATCH 20/21] drm/i915: Use a slab for object allocation

Reviewed-by: Daniel Vetter -- Daniel Vetter Mail: dan...@ffwll.ch Mobile: +41 (0)79 365 57 48 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 19/21] drm/i915: Enable the use of GPU semaphores whilst page-flipping

On Sat, Apr 16, 2011 at 10:17:43AM +0100, Chris Wilson wrote: > The 2D driver unfortunately uses the BLT ring in order to perform blits, > and will often blit between buffers in the course of a pageflip. (Though > usually it is from the post-flipped scanout to the window frontbuffer > for reasons k

Re: [Intel-gfx] [PATCH 18/21] drm/i915: Split out i915_gem_object_move_to_ring() from execbuffer

On Sat, Apr 16, 2011 at 10:17:42AM +0100, Chris Wilson wrote: > As we can make use of the ability to insert semaphores to serialise > accessing buffers between ring elsewhere, separate out the function from > the execbuffer code and make it generic. Perhaps add a small note somewhere that move_to_

Re: [Intel-gfx] [PATCH 17/21] drm/i915: Repeat retiring of requests until the seqno is stable

I'm gonna trust you not to have fat-fingered the indent change ;-) Reviewed-by: Daniel Vetter -- Daniel Vetter Mail: dan...@ffwll.ch Mobile: +41 (0)79 365 57 48 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mai

Re: [Intel-gfx] [PATCH 16/21] drm/i915: Retire requests before disabling pagefaults

On Sat, Apr 16, 2011 at 10:17:40AM +0100, Chris Wilson wrote: > As we cannot wait upon an object to be released by the GPU once we have > disabled pagefaults, process any pending retirements first in the hope > that we move any potential relocations off the active list. I have a hard time believin

Re: [Intel-gfx] [PATCH 07/21] drm/i915: Track fence setup separately from fenced object lifetime

On Sat, Apr 16, 2011 at 10:17:31AM +0100, Chris Wilson wrote: > This fixes a bookkeeping error causing an OOPS whilst waiting for an > object to finish using a fence. Now we can simply wait for the fence to > be written independent of the objects currently inhabiting it (past, > present and future)

Re: [Intel-gfx] [PATCH] drm/i915: Combine pinning with setting to the display plane

On Sat, 16 Apr 2011 12:52:35 +0200, Daniel Vetter wrote: > One small comment-nitpick below. > > > diff --git a/drivers/gpu/drm/i915/i915_gem.c > > b/drivers/gpu/drm/i915/i915_gem.c > > index 7271956..c73eeaf 100644 > > --- a/drivers/gpu/drm/i915/i915_gem.c > > +++ b/drivers/gpu/drm/i915/i915_gem

Re: [Intel-gfx] [PATCH 1/4] drm/i915: embed struct drm_mm_node into struct drm_i915_gem_object

On Sat, Apr 16, 2011 at 09:01:12AM +1000, Dave Airlie wrote: > On Sat, Apr 16, 2011 at 4:57 AM, Daniel Vetter wrote: > > Why? seriously patches need to start having some information in them. It's the drm/i915 portion of the drm_mm free space tracking rework you've merged for .39. The i915 part m

Re: [Intel-gfx] [PATCH 2/2] drm/i915: Use the uncached domain for the display planes

Now that the pinning and display plane domain changes settle ... Reviewed-by: Daniel Vetter -- Daniel Vetter Mail: dan...@ffwll.ch Mobile: +41 (0)79 365 57 48 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailm

Re: [Intel-gfx] [PATCH] drm/i915: Combine pinning with setting to the display plane

On Sat, Apr 16, 2011 at 07:27:31AM +0100, Chris Wilson wrote: > We need to perform a few operations in order to move the object into the > display plane (where it can be accessed coherently by the display > engine) that are important for future safety to forbid whilst pinned. As a > result, we want

[Intel-gfx] [PATCH] drm/i915: Release object along create user fb error path

Reported-by: Alan Cox Signed-off-by: Chris Wilson Cc: sta...@kernel.org --- drivers/gpu/drm/i915/intel_display.c |4 +++- 1 files changed, 3 insertions(+), 1 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c index 54ee551..73cec21 100644

[Intel-gfx] [PATCH 03/21] drm/i915: s/addr & ~PAGE_MASK/offset_in_page(addr)/

Convert our open coded offset_in_page() to the common macro. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/i915_gem.c | 21 ++--- 1 files changed, 10 insertions(+), 11 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c index 140d

[Intel-gfx] [PATCH 04/21] drm/i915: Maintain fenced gpu access until we flush the fence

We only want to mark the transition from unfenced GPU access by an execbuffer, so that we are forced to flush any pending writes through the fence before updating the register. In applying this fix for a corruption bug, we do lose the ability to detect the earliest end of GPU fenced access, thus d

[Intel-gfx] [PATCH 05/21] drm/i915: Invalidate fenced read domains upon flush

Whenever we finish reading an object through a fence, for safety we clear any GPU read domain and so invalidate any TLBs associated with the fenced region upon its next use. As we now always flush writes through an existing fence before it is released and then trigger the invalidation of the GPU do

[Intel-gfx] [PATCH 06/21] drm/i915: Pass the fence register number to be written

This simplifies a later change where we want to successfully write (or pipeline) the fence update prior to updating the bo. Signed-off-by: Chris Wilson Reviewed-by: Daniel Vetter --- drivers/gpu/drm/i915/i915_gem.c | 61 ++ drivers/gpu/drm/i915/i915_reg.h |

[Intel-gfx] [PATCH 01/21] drm/i915: Cache GT fifo count for SandyBridge

The read back of the available FIFO entries is vital for system stability, but extremely costly. However, we only need a guide so as to avoid eating into the reserved entries and since we are the only consumer we can cache the read of the count from the last write. Signed-off-by: Chris Wilson Rev

[Intel-gfx] [PATCH 08/21] drm/i915: Only print out the actual number of fences for i915_error_state

From: Daniel Vetter Signed-off-by: Daniel Vetter Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/i915_debugfs.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_debugfs.c b/drivers/gpu/drm/i915/i915_debugfs.c index 52d2306..4c72407 10064

[Intel-gfx] [PATCH 12/21] drm/i915: Replace ironlake_compute_wm0 with g4x_compute_wm0

The computation of the first-level watermarks for g4x and gen5+ are based on the same algorithm, so we can refactor those code paths to use a single function. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/intel_display.c | 88 -- 1 files changed, 20 inser

[Intel-gfx] [PATCH 02/21] drm/i915: Refactor pwrite/pread to use single copy of get_user_pages

Replace the three nearly identical copies of the code with a single function. And take advantage of the opportunity to do some micro-optimisation: avoid the vmalloc if at all possible and also avoid dropping the lock unless we are forced to acquire the mm semaphore. Measuring the impact of the opt

[Intel-gfx] [PATCH 09/21] drm/i915: Implement direct support for 24 bit LVDS pixel format

From: Mike Isely LVDS digital data can be formatted as 18 bits/pixel or one of two 24 bits/pixel possibilities. All are incompatible with one another, so the GPU's LVDS output has to be configured to match the format expected by the display device. In many (most) cases this is generally not a p

[Intel-gfx] [PATCH 13/21] drm/i915/crt: Explicitly return false if connected to a digital monitor

Rather than proceed on and silently return false by default, mention why we rejected the presence of an EDID as implying the presence of a VGA monitor. (The question arises whether there is a broken EDID which falsely reports a digital connection when attached by VGA.) Signed-off-by: Chris Wilson

[Intel-gfx] [PATCH 10/21] drm/i915: Implement manual override of LVDS single/dual channel mode

From: Mike Isely The logic for LVDS setup in the Intel driver needs to know whether the LVDS port should be in single or dual channel mode when calculating video timing. It had been answering this question by probing the current hardware configuration, under the assumption that the video BIOS wo

[Intel-gfx] [PATCH 11/21] drm/i915/tv: Use a direct pointer for tv_mode

Instead of scanning through the static array using strcmp to find our matching tv_mode, just keep a direct link around. The historical reason for the strcmp was to match the connection property "tv format", but now that property is translated for us into an index by the drm core. Signed-off-by: Ch

[Intel-gfx] [PATCH 14/21] drm/i915/i2c: Convert from using GMBUS1 + reg_offset idiom to reg + 0

Keith complained that GMBUSx + reg_offset was ugly. An alternative naming scheme which is more consistent with the reset of the code base is to store the address of the GMBUS0 and then reference each of the GMBUSx registers as an offset from GMBUS0. Signed-off-by: Chris Wilson --- drivers/gpu/dr

[Intel-gfx] [PATCH 16/21] drm/i915: Retire requests before disabling pagefaults

As we cannot wait upon an object to be released by the GPU once we have disabled pagefaults, process any pending retirements first in the hope that we move any potential relocations off the active list. References: https://bugs.freedesktop.org/show_bug.cgi?id=35733 Signed-off-by: Chris Wilson ---

[Intel-gfx] [PATCH 17/21] drm/i915: Repeat retiring of requests until the seqno is stable

The list walking over objects and requests to retire may take a significant amount of time, enough time for the GPU to have finished more batches. So repeat the list walking until the GPU seqno is stable. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/i915_gem.c | 66

[Intel-gfx] [PATCH 18/21] drm/i915: Split out i915_gem_object_move_to_ring() from execbuffer

As we can make use of the ability to insert semaphores to serialise accessing buffers between ring elsewhere, separate out the function from the execbuffer code and make it generic. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/i915_drv.h|5 +++ drivers/gpu/drm/i915/i915_g

[Intel-gfx] [PATCH 21/21] drm/i915: Introduce vmap (mapping of user pages into video memory) ioctl

By exporting the ability to map user address and inserting PTEs representing their backing pages into the GTT, we can exploit UMA in order to utilize normal application data as a texture source or even as a render target (depending upon the capabilities of the chipset). This has a number of uses, w

[Intel-gfx] [PATCH 15/21] drm/i915/gmbus: Reset the controller on initialisation

Toggle the Software Clear Interrupt bit which resets the controller to clear any prior BUS_ERROR condition before we begin to use the controller in earnest. Suggested-by: Ben Widawsky Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/intel_i2c.c | 12 1 files changed, 8 insert

[Intel-gfx] [PATCH 20/21] drm/i915: Use a slab for object allocation

The primary purpose of this was to debug some use-after-free memory corruption that was causing an OOPS inside drm/i915. As it turned out the corruption was being caused elsewhere and i915.ko as a major user of many objects was being hit hardest. Indeed as we do frequent the generic kmalloc caches

[Intel-gfx] [PATCH 19/21] drm/i915: Enable the use of GPU semaphores whilst page-flipping

The 2D driver unfortunately uses the BLT ring in order to perform blits, and will often blit between buffers in the course of a pageflip. (Though usually it is from the post-flipped scanout to the window frontbuffer for reasons known only to itself, maintaining the front buffer in case of 2D access

[Intel-gfx] [PATCH 07/21] drm/i915: Track fence setup separately from fenced object lifetime

This fixes a bookkeeping error causing an OOPS whilst waiting for an object to finish using a fence. Now we can simply wait for the fence to be written independent of the objects currently inhabiting it (past, present and future). A large amount of the change is to delay updating the information a

[Intel-gfx] i915 next, post-llc

So continuing the -next discussion, I have a few more patches for review. 1-8: The last set of post-llc patches, which I think are close to being accepted. I need to debate the finer points of fence lifetime with Daniel and capture the explanations so that we don't repeat our mistake

Re: [Intel-gfx] [PATCH 24/30] drm/i915: Refactor pwrite/pread to use single copy of get_user_pages

On Fri, 15 Apr 2011 11:48:33 +0200, Paul Menzel wrote: > Am Donnerstag, den 14.04.2011, 16:23 -0700 schrieb Ben Widawsky: > > On Wed, Apr 13, 2011 at 08:56:26PM +0100, Chris Wilson wrote: > > > * First, we try the lockless variant of gup whilst continuing to hold the > > I do not know what »gu

Re: [Intel-gfx] [PATCH 3/3] drm/i915: userspace interface to the forcewake

On Thu, 14 Apr 2011 21:56:02 +0200, Paul Menzel wrote: > Dear Ben, > > > Am Donnerstag, den 14.04.2011, 11:13 -0700 schrieb Ben Widawsky: > > userspace to the forcewake reference count via debugfs. > > > > v2: > > use new spin_locks instead of struct_mutex > > in my opinion these remarks shou