Re: [Intel-gfx] [PATCH 42/43] drm/i915: per-ring fault reg

On Wed, Dec 14, 2011 at 05:00:13PM -0200, Eugeni Dodonov wrote: > On Wed, Dec 14, 2011 at 10:57, Daniel Vetter wrote: > > > v2: Chris Wilson suggested to allocate the error_state with kzalloc > > for better paranioa. Also kill existing spurious clears of the > > error_state while at it. > > > > S

Re: [Intel-gfx] [PATCH 0/8] interlaced support v2

On Sat, Jan 28, 2012 at 7:30 PM, Alfonso Fiore wrote: > > i3 2130 connected to a Philips 32pf9731d over HDMI: > - 1920x1080i@30Hz > - 1280x720p@60Hz > - 1024x768p@60Hz Hi guys, after grub, the TV switches to 1920x1080i. Even if I add vga=0x037b to grub menu entry, I get 1280x720p while loading s

Re: [Intel-gfx] VAAPI (master or ext) no deinterlacing with Clarkdale GPU

Hello, I’ve written an email to Haihao Xiang regarding the “no deinterlacing” bug on Clarkdale a week ago and he answered today. He will check this issue. I’ll hope he can fix it. Will the extended vaapi-ext deinterlacers (temporal or spatial I guess) also be available on Clarkdale platform? I

Re: [Intel-gfx] [PATCH 20/43] drm/i915: swizzling support for snb/ivb

On Wed, 14 Dec 2011 13:57:17 +0100, Daniel Vetter wrote: > We have to do this manually. Somebody had a Great Idea. > > Signed-Off-by: Daniel Vetter Acked-by: Chris Wilson Speedups xlib grads-heat-map 211.10 (226.71 5.67%) -> 162.57 (181.59 7.12%): 1.30x speedup xlib

Re: [Intel-gfx] [PATCH 30/43] drm/i915: reject GTT domain in relocations

On Wed, Dec 14, 2011 at 01:57:27PM +0100, Daniel Vetter wrote: > This confuses our domain tracking and can (for gtt write domains) lead > to a subsequent oops. > > Tested by tests/gem_exec_bad_domains from i-g-t. > > Signed-Off-by: Daniel Vetter > Reviewed-by: Eric Anholt > Reviewed-by: Chris W

Re: [Intel-gfx] [PATCH 19/43] drm/i915: add debugfs file for swizzling information

On Wed, 14 Dec 2011 13:57:16 +0100, Daniel Vetter wrote: > This will also come handy for the gen6+ swizzling support, where the > driver is supposed to control swizzling depending upon dram > configuration. > > v2: CxDRB3 are 16 bit regs! Noticed by Chris Wilson. The output isn't quite the colo

Re: [Intel-gfx] [PATCH 24/43] drm/i915: capture error_state also for stuck rings

On Wed, Dec 14, 2011 at 01:57:21PM +0100, Daniel Vetter wrote: > Since quite a while we also the basic output configuration in the > error_state, so it should contain enough information to diagnose > these MI_WAIT hangs. > > Signed-Off-by: Daniel Vetter > Reviewed-and-tested-by: Chris Wilson > R

Re: [Intel-gfx] [PATCH 18/43] drm/i915: fix swizzle detection for gen3

On Wed, 14 Dec 2011 13:57:15 +0100, Daniel Vetter wrote: > It looks like the desktop variants of i915 and i945 also have the DCC > register to control dram channel interleave and cpu side bit6 > swizzling. > > Unfortunately internal Cspec/ConfigDB documentation for these ancient chips > have alr

Re: [Intel-gfx] [PATCH 29/43] drm/i915: remove the i915_batchbuffer_info debugfs file

On Wed, Dec 14, 2011 at 01:57:26PM +0100, Daniel Vetter wrote: > With the error_state facility in place, this has outlived it's > usefulness. It also oopses with the lates llc-reloc patches because > it directly access objects through the gtt without any checks. > > Signed-Off-by: Daniel Vetter >

Re: [Intel-gfx] [PATCH 13/43] drm/i915: refactor debugfs open function

On Wed, Dec 14, 2011 at 01:57:10PM +0100, Daniel Vetter wrote: > Only forcewake has an open with special semantics, the other r/w > debugfs only assign the file private pointer. > > Signed-Off-by: Daniel Vetter > Reviewed-by: Ben Widawsky > Reviewed-by: Kenneth Graunke Queued for -next, thanks

Re: [Intel-gfx] [PATCH] drm/i915: Separate fence pin counting from normal bind pin counting

On Wed, Nov 23, 2011 at 01:04:08PM +, Chris Wilson wrote: > In order to correctly account for reserving space in the GTT and fences > for a batch buffer, we need to independently track whether the fence is > pinned due to a fenced GPU access in the batch or whether the buffer is > pinned in the

[Intel-gfx] [PATCH] drm/i915: Remove the upper limit on the bo size for mapping into the CPU domain

The original intention of comparing the bo against the mappable GTT limits was to prevent a subsequent faulting of the bo into the GTT from clearing the entire GTT in vain. However, that was clearly a cut'n'paste mistake as a CPU mapping never binds the bo into the aperture. Whilst there may be som

Re: [Intel-gfx] [PATCH 12/43] drm/i915: don't trash the gtt when running out of fences

On Wed, Dec 14, 2011 at 03:09:24PM +, Chris Wilson wrote: > On Wed, 14 Dec 2011 13:57:09 +0100, Daniel Vetter > wrote: > > With the fence accounting fixed up in the previous commit not finding > > enough fences is a fatal error and userspace bug. Trashing the entire > > gtt is not gonna turn

Re: [Intel-gfx] [PATCH 11/43] drm/i915: Separate fence pin counting from normal bind pin counting

On Wed, Dec 14, 2011 at 01:57:08PM +0100, Daniel Vetter wrote: > From: Chris Wilson > > In order to correctly account for reserving space in the GTT and fences > for a batch buffer, we need to independently track whether the fence is > pinned due to a fenced GPU access in the batch or whether the

Re: [Intel-gfx] [PATCH 10/43] drm/i915/ringbuffer: kill snb blt workaround

On Wed, Dec 14, 2011 at 01:57:07PM +0100, Daniel Vetter wrote: > This was just to facilitate product enablement with pre-production hw. > Allows us to kill quite a bit of cruft. > > Signed-off-by: Daniel Vetter > Signed-off-by: Kenneth Graunke > Reviewed-by: Eric Anholt I've picked this one up

Re: [Intel-gfx] [PATCH 05/43] drm/i915: collect more per ring error state

On Wed, Dec 14, 2011 at 04:43:40PM -0200, Eugeni Dodonov wrote: > On Wed, Dec 14, 2011 at 10:57, Daniel Vetter wrote: > > > Based on a patch by Ben Widawsky, but with different colors > > for the bikeshed. > > > > In contrast to Ben's patch this one doesn't add the fault regs. > > Afaics they're

Re: [Intel-gfx] [PATCH 04/43] drm/i915: refactor ring error state capture to use arrays

On Wed, Dec 14, 2011 at 04:43:08PM -0200, Eugeni Dodonov wrote: > On Wed, Dec 14, 2011 at 10:57, Daniel Vetter wrote: > > > The code already got unwieldy and we want to dump more per-ring > > registers. > > > > Only functional change is that we now also capture the video > > ring registers on ilk

Re: [Intel-gfx] [PATCH 03/43] drm/i915: switch ring->id to be a real id

On Wed, Dec 14, 2011 at 04:42:23PM -0200, Eugeni Dodonov wrote: > On Wed, Dec 14, 2011 at 10:57, Daniel Vetter wrote: > > > ... and add a helpr function for the places where we want a flag. > > > > This way we can use ring->id to index into arrays. > > > > v2: Resurrect the missing beautification

Re: [Intel-gfx] [PATCH][rebased] drm/i915: set AUD_CONFIG N_value_index for DisplayPort

On Sun, Jan 29, 2012 at 09:23:26PM +0800, Wu Fengguang wrote: > > > Daniel, this is now based on linux-next. I use quilt, hope it also > > > works for you :) > > > > On a quick check this patch is missing the hunk to actually write the > > aud configuration into the register. I presume that's not

Re: [Intel-gfx] [PATCH][rebased] drm/i915: set AUD_CONFIG N_value_index for DisplayPort

> > Daniel, this is now based on linux-next. I use quilt, hope it also > > works for you :) > > On a quick check this patch is missing the hunk to actually write the > aud configuration into the register. I presume that's not intentional, > so can you please resend? This is weird, my outbox has t

Re: [Intel-gfx] [PATCH 8/8] drm/i915: allow interlaced mode output on the HDMI connector

On Sat, Jan 28, 2012 at 11:49, Daniel Vetter wrote: > From: Peter Ross > > Signed-off-by: Peter Ross > Signed-off-by: Daniel Vetter > Reviewed-by: Eugeni Dodonov -- Eugeni Dodonov ___ Intel-gfx mailing list Intel-gfx@

Re: [Intel-gfx] [PATCH 7/8] drm/i915: allow interlaced mode output on the SDVO connector

On Sat, Jan 28, 2012 at 11:49, Daniel Vetter wrote: > From: Peter Ross > > Signed-off-by: Peter Ross > Signed-off-by: Daniel Vetter > Reviewed-by: Eugeni Dodonov -- Eugeni Dodonov ___ Intel-gfx mailing list Intel-gfx@

Re: [Intel-gfx] [PATCH 5/8] drm/i915: don't allow interlaced pipeconf on gen2

On Sat, Jan 28, 2012 at 11:49, Daniel Vetter wrote: > gen2 doesn't support it, so be a bit more paranoid and add a check to > ensure that we never ever set an unsupported interlaced bit. > > Ensure that userspace can't set an interlaced mode by resetting > interlace_allowed for the crt on gen2. d

Re: [Intel-gfx] [PATCH 1/8] drm/i915: clean up interlaced pipeconf bit definitions

On Sun, Jan 29, 2012 at 12:09:05PM -0200, Eugeni Dodonov wrote: > On Sat, Jan 28, 2012 at 11:49, Daniel Vetter wrote: > > > +#define PIPECONF_PROGRESSIVE (0 << 21) > > +#define PIPECONF_INTERLACE_W_SYNC_SHIFT_PANEL(4 << 21) /* gen4 > > only */ > > +#define PIPECONF_I

Re: [Intel-gfx] [PATCH 3/8] drm/i915: fixup interlaced vertical timings confusion, part 2

On Sat, Jan 28, 2012 at 11:49, Daniel Vetter wrote: > According to bspec, we need to subtract an additional line from vtotal > for interlaced modes and vblank_end needs to equal vtotal. All other > timing fields do not need this special treatment, so kill it. > > Bspec says that this is irrespect

Re: [Intel-gfx] [PATCH 2/8] drm/i915: fixup interlaced vertical timings confusion, part 1

On Sat, Jan 28, 2012 at 11:49, Daniel Vetter wrote: > We have a pretty decent confusion about vertical timings of interlaced > modes. Peter Ross has written a patch that makes interlace modes work > on a lot more platforms/output combinations by doubling the vertical > timings. > > The issue with

Re: [Intel-gfx] [PATCH 1/8] drm/i915: clean up interlaced pipeconf bit definitions

On Sat, Jan 28, 2012 at 11:49, Daniel Vetter wrote: > +#define PIPECONF_PROGRESSIVE (0 << 21) > +#define PIPECONF_INTERLACE_W_SYNC_SHIFT_PANEL(4 << 21) /* gen4 > only */ > +#define PIPECONF_INTERLACE_W_SYNC_SHIFT (5 << 21) /* gen4 only */ > +#define PIPECONF_I

Re: [Intel-gfx] [PATCH][rebased] drm/i915: set AUD_CONFIG N_value_index for DisplayPort

On Sun, Jan 29, 2012 at 05:44, Wu Fengguang wrote: > It should be programmed to "0" for HDMI or "1" for DisplayPort. > > This enables DisplayPort audio for > > - HP EliteBook 8460p >  (whose BIOS does not set the N_value_index bit for us) > > - DisplayPort monitor hot plugged after boot >  (otherw