Re: [Intel-gfx] [PATCH] Attempt to detect and recover from pageflipping stalls

On Wednesday 1 September 2010, Simon Farnsworth simon.farnswo...@onelan.co.uk wrote: In an attempt to get to the bottom of bug #29798, Chris Wilson gave me a patch that put some details in debugfs. With the clues gathered from that patch, I was able to determine that the page flip is

[Intel-gfx] [PATCH] Attempt to detect and recover from pageflipping stalls

In an attempt to get to the bottom of bug #29798, Chris Wilson gave me a patch that put some details in debugfs. With the clues gathered from that patch, I was able to determine that the page flip is happening, but that we're not seeing the IRQs we'd expect. Work around this by only permitting a

[Intel-gfx] [PATCH 00/23] intel gtt rework, part 1: initialization

Hi all, The goal of this rework is to a) separate the fake agp driver from the hw access and b) dig a direct path from gem to the intel gtt code with the long-term goal to get rid of the fake agp driver for kms. This series does this for the gtt setup code - except for the pte clearing with the

[Intel-gfx] [PATCH 01/23] agp/intel: split out gmch/gtt probe, part 2

This just splits the device list into two and moves the gtt related stuff to intel-gtt.c. The two new devices lists also lose the not longer needed fields. There where only about 5 cases anyway with both a gmch and a possible agp port, so the duplication of entries is rather small. Additionally

[Intel-gfx] [PATCH 03/23] intel-gtt: introduce drm/intel-gtt.h

Add a few definitions to it that are already shared and that will be shared in the future (like the number of stolen entries). No functional changes in here. Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch --- drivers/char/agp/intel-gtt.c| 42 +-

[Intel-gfx] [PATCH 04/23] intel-gtt: store a local pointer to the bridge pci dev

When the intel-gtt code now longer depends on agp, we cannot rely on this. So store a local reference in intel-gtt.c. Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch --- drivers/char/agp/intel-gtt.c | 69 +++--- 1 files changed, 38 insertions(+), 31

[Intel-gfx] [PATCH 06/23] intel-gtt: new function intel_gtt_mappable_entries

This implementation is stolen from drm/i915, but is equivalent to the code sprinkled over intel-gtt.c in the various fetch_size functions. It's not yet used anywhere, though. Also introduce intel_gtt_init which only calls intel_gtt_stolen_entries. Over the course of the next patches, this will

[Intel-gfx] [PATCH 05/23] intel-gtt: s/intel_i830_init_gtt_entries/intel_gtt_stolen_entries

First simple step towards a more generic initialization. This is needed to disentangle the agp stuff from the stuff that is actually needed by drm/i915. Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch --- drivers/char/agp/intel-gtt.c | 12 ++-- 1 files changed, 6 insertions(+), 6

[Intel-gfx] [PATCH 08/23] intel-gtt: sane variable names for intel_gtt_stolen_entries

This somewhat aligns it with the version in drm/i915/i915_dma.c. Changes: - s/gtt_entries/stolen_size - track overhead entries in a separate var (the effective gtt size calculation will be extracted later on). - subtract the overhead at the end instead of in each clause. Signed-off-by: Daniel

[Intel-gfx] [PATCH 07/23] intel-gtt: generic intel_fake_agp_fetch_size

This uses the new mappable gtt size detection from the previous patch. Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch --- drivers/char/agp/intel-gtt.c | 77 +- 1 files changed, 24 insertions(+), 53 deletions(-) diff --git

[Intel-gfx] [PATCH 09/23] intel-gtt: drop unnecessary conditions in intel_gtt_stolen_entries

The detection function in drm/i915/i915_dma.c works without it, so drop it here, too. All the values are distinct, anyway. Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch --- drivers/char/agp/intel-gtt.c | 42 -- 1 files changed, 8 insertions(+), 34

[Intel-gfx] [PATCH 10/23] intel-gtt: adjust overhead entries in intel_gtt_stolen_entries

agp/intel_gtt.c and drm/i915/i915_dma.c don't calculate this the same way: The intel-gtt code seems to use the actual gtt size, the drm module just the mappable. Go with the logic from the drm module because that's the more conservative choice. But conserve the original code in

[Intel-gfx] [PATCH 13/23] intel-gtt: introduce intel_gtt_driver

Same idea as INTEL_INFO from drm/i915. This - reduces the dependancy on agp_driver - stops the what-does-IS_I965G-mean confusion (here it's just gen4, in drm/i915 it's gen =4) - further prepares the separation of the fake agp driver from the rest. Signed-off-by: Daniel Vetter

[Intel-gfx] [PATCH 14/23] intel-gtt: i915: use detected gtt size for mapping

Slight reordering of the init sequence required. Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch --- drivers/char/agp/intel-gtt.c | 58 ++--- 1 files changed, 9 insertions(+), 49 deletions(-) diff --git a/drivers/char/agp/intel-gtt.c

[Intel-gfx] [PATCH 16/23] intel-gtt: i830: adjust ioremap of regs and gtt to i9xx

This way around this can be extracted into common code. Also use a common cleanup function (and give it a generic name). Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch --- drivers/char/agp/intel-gtt.c | 41 +++-- 1 files changed, 23 insertions(+), 18

[Intel-gfx] [PATCH 15/23] intel-gtt: i965: use detected gtt size for mapping

Also move the Sandybdridge size detection into gtt_total_entries, like the rest. Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch --- drivers/char/agp/intel-gtt.c | 75 +++--- 1 files changed, 34 insertions(+), 41 deletions(-) diff --git

[Intel-gfx] [PATCH 17/23] intel-gtt: consolidate the gtt ioremap calls

Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch --- drivers/char/agp/intel-gtt.c | 70 +++-- 1 files changed, 26 insertions(+), 44 deletions(-) diff --git a/drivers/char/agp/intel-gtt.c b/drivers/char/agp/intel-gtt.c index f4308d3..0ebb76a 100644 ---

[Intel-gfx] [PATCH 18/23] intel-gtt: consolidate i830 setup

Slightly reordered sequence was necessary. Also don't set agp_bridge-gatt_bus_addr anymore. Only used by generic agp helper functions, hence unnecessary for the intel fake agp driver. Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch --- drivers/char/agp/intel-gtt.c | 83

[Intel-gfx] [PATCH 20/23] intel-gtt: call init_gtt_init in probe function

This way create_gatt_table become dummy glue functions for the fake agp driver - rename them accordingly (and kill the now unnecessary i9xx copy). With this change, the gtt initialization code is almost independant from the agp stuff. Two things are still missing: - the scratch page is created by

[Intel-gfx] [PATCH 19/23] intel-gtt: consolidate i9xx setup

The only difference between i915 and i965 was the calculation of the gtt address. So merge these two paths into one. Otherwise the same changes as in the i830 setup consolidation. Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch --- drivers/char/agp/intel-gtt.c | 154

[Intel-gfx] [PATCH 23/23] drm/i915: die, i915_probe_agp, die

Use the detection from intel-gtt.ko instead. Hooray! Also move the stolen mem allocator to the other gtt stuff in dev_priv-mem. Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch --- drivers/char/agp/intel-gtt.c|6 ++ drivers/gpu/drm/i915/i915_dma.c | 187

Re: [Intel-gfx] [PATCH 00/23] intel gtt rework, part 1: initialization

On Thu, Sep 2, 2010 at 6:29 AM, Daniel Vetter daniel.vet...@ffwll.ch wrote: Hi all, The goal of this rework is to a) separate the fake agp driver from the hw access and b) dig a direct path from gem to the intel gtt code with the long-term goal to get rid of the fake agp driver for kms.

[Intel-gfx] [intel-gfx][PATCH 2/2] drm/i915: Add a new ring buffer on Sandybridge

This ring buffer is used for video decoding/encoding on Sandybridge. Signed-off-by: Xiang, Haihao haihao.xi...@intel.com --- drivers/gpu/drm/i915/i915_drv.h |2 +- drivers/gpu/drm/i915/i915_gem.c |6 ++- drivers/gpu/drm/i915/i915_irq.c | 15 +++--