Re: [Intel-gfx] [PATCH 5/6] drm/i915: Add probe and remove to the gtt ops
On Thu, Jan 24, 2013 at 01:49:57PM -0800, Ben Widawsky wrote: The idea, and much of the code came originally from: commit 0712f0249c3148d8cf42a3703403c278590d4de5 Author: Ben Widawsky b...@bwidawsk.net Date: Fri Jan 18 17:23:16 2013 -0800 drm/i915: Create a vtable for i915 gtt Daniel didn't like the color of that patch series, and so I asked him to start something which appealed to his sense of color. The preceding patches are those, and now this is going on top of that. [extracted from the original commit message] One immediately obvious thing to implement is our gmch probing. The init function was getting massively bloated. Fundamentally, all that's needed from GMCH probing is the GTT size, and the stolen size. It makes design sense to put the mappable calculation in there as well, but the code turns out a bit nicer without it (IMO) The intel_gtt bridge thing is still here, but the subsequent patches will finish ripping that out. Signed-off-by: Ben Widawsky b...@bwidawsk.net Reviewed-by: Damien Lespiau damien.lesp...@intel.com -- Damien ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 6/6] drm/i915: Resume dissecting intel_gtt
On Thu, Jan 24, 2013 at 02:45:00PM -0800, Ben Widawsky wrote: With the probe call in our dispatch table, we can now cut away two of the remaining members in the intel_gtt shared struct. v2: Rebased on top of Daniel's series Signed-off-by: Ben Widawsky b...@bwidawsk.net Shouldn't the commit message be that you get rid of struct intel_gtt entirely? Reviewed-by: Damien Lespiau damien.lesp...@intel.com -- Damien ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/2] drm/i915: Error state should print /sys/kernel/debug
On Mon, Jan 28, 2013 at 03:32:15PM -0800, Ben Widawsky wrote: /sys/kernel/debug has more or less been the standard location of debugfs for several years now. Other parts of DRM already use this location, so we should as well. Signed-off-by: Ben Widawsky b...@bwidawsk.net Reviewed-by: Damien Lespiau damien.lesp...@intel.com -- Damien ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/2] drm/i915: Adding a warning to FBC description
On Mon, Jan 28, 2013 at 03:32:16PM -0800, Ben Widawsky wrote: It should only be used with caution... Signed-off-by: Ben Widawsky b...@bwidawsk.net Isn't that like the general assumption of these module parameters that they can have pretty massive bad side-effects? Meaning I'm routinely checking these already anyway in bug reports, same for non-standard rc6 settings. -Daniel --- drivers/gpu/drm/i915/i915_drv.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c index 9cc8f87..912db3a 100644 --- a/drivers/gpu/drm/i915/i915_drv.c +++ b/drivers/gpu/drm/i915/i915_drv.c @@ -76,6 +76,7 @@ int i915_enable_fbc __read_mostly = -1; module_param_named(i915_enable_fbc, i915_enable_fbc, int, 0600); MODULE_PARM_DESC(i915_enable_fbc, Enable frame buffer compression for power savings + WARNING: FBC has been implicated in hangs over the years, and should likely be left to the default value. (default: -1 (use per-chip default))); unsigned int i915_lvds_downclock __read_mostly = 0; -- 1.8.1.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/2] drm/i915: Error state should print /sys/kernel/debug
On Tue, Jan 29, 2013 at 08:41:12AM +, Damien Lespiau wrote: On Mon, Jan 28, 2013 at 03:32:15PM -0800, Ben Widawsky wrote: /sys/kernel/debug has more or less been the standard location of debugfs for several years now. Other parts of DRM already use this location, so we should as well. Signed-off-by: Ben Widawsky b...@bwidawsk.net Reviewed-by: Damien Lespiau damien.lesp...@intel.com Queued for -next, thanks for the patch. Oh and fixed up a bikeshed from checkpatch.pl while applying: Applying: drm/i915: Error state should print /sys/kernel/debug WARNING: line over 80 characters #22: FILE: drivers/gpu/drm/i915/i915_irq.c:1308: + DRM_INFO(capturing error event; look for more information in /sys/kernel/debug/dri/%d/i915_error_state\n, total: 0 errors, 1 warnings, 8 lines checked Yeah, I've added that OCD thing to my patch apply pipeline, let's see how much fun it is ;-) -Daniel -- Damien ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/6] drm/i915: vfuncs for gtt_clear_range/insert_entries
On Tue, Jan 29, 2013 at 07:42:57AM +, Damien Lespiau wrote: On Thu, Jan 24, 2013 at 02:44:55PM -0800, Ben Widawsky wrote: From: Daniel Vetter daniel.vet...@ffwll.ch We have a few too many differences here, so finally take the prepared abstraction and run with it. A few smaller changes are required to get things into shape: - move i915_cache_level up since we need it in the gt funcs - split up i915_ggtt_clear_range and move the two functions down to where the relevant insert_entries functions are - adjustments to a few function parameter lists Now we have 2 functions which deal with the gen6+ global gtt (gen6_ggtt_ prefix) and 2 functions which deal with the legacy gtt code in the intel-gtt.c fake agp driver (i915_ggtt_ prefix). Init is still a bit a mess, but honestly I don't care about that. One thing I've thought about while deciding on the exact interfaces is a flag parameter for -clear_range: We could use that to decide between writing invalid pte entries or scratch pte entries. In case we ever get around to fixing all our bugs which currently prevent us from filling the gtt with empty ptes for the truly unused ranges ... Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch [bwidawsk: Moved functions to the gtt struct] Signed-off-by: Ben Widawsky b...@bwidawsk.net Reviewed-by: Damien Lespiau damien.lesp...@intel.com Merged the series into dinq, thanks for the review. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/2] drm/i915: Error state should print /sys/kernel/debug
On Tue, 29 Jan 2013, Daniel Vetter dan...@ffwll.ch wrote: Queued for -next, thanks for the patch. Oh and fixed up a bikeshed from checkpatch.pl while applying: Applying: drm/i915: Error state should print /sys/kernel/debug WARNING: line over 80 characters #22: FILE: drivers/gpu/drm/i915/i915_irq.c:1308: + DRM_INFO(capturing error event; look for more information in /sys/kernel/debug/dri/%d/i915_error_state\n, total: 0 errors, 1 warnings, 8 lines checked Yeah, I've added that OCD thing to my patch apply pipeline, let's see how much fun it is ;-) You could go all the way: http://lwn.net/Articles/488992/ ;) J. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC PATCH 3/3] i915: ignore lid open event when resuming
On Mon, Jan 28, 2013 at 06:06:38PM +0800, Zhang Rui wrote: On Mon, 2013-01-28 at 09:31 +0100, Daniel Vetter wrote: On Mon, Jan 28, 2013 at 3:36 AM, Zhang Rui rui.zh...@intel.com wrote: Given that this essentially requires users to manually set this module option to make stuff work I don't like this. sorry, I do not understand. this patch just disables modeset_on_lid during suspend. Pardon me, the misunderstanding is on my side - I've mixed up dev_priv-modeset_on_lid with the corresponding module option. Is my understanding correct that only with the new SCI pm state this can happen, since that still allows acpi events to be processed (and so our lid_notifier being called? yep. I see a few possible options: - plug the races between all the different parts - I've never really understood why acpi sends us events before the resume code has completed ... If that's indeed intentional, we could delay the handling a bit until at least the i915 resume code completed. IMO, the real question is that, during a suspend/resume cycle, if we need to take care of the lid open event or not. To me, the answer is no, because when resuming from STR, i915 is not aware of such an event, and the i915 resume code works well, right? so I do not think it is a problem to ignore the lid event for another lightweight suspend state, which is introduced in Patch 1/3 in this series. - Judging from the diff context you're not on the latest 3.8-rc codebase - we've applied a few fixes to this lid hack recently. Please retest on a kernel with the patch is based on 3.8.0-rc3, which already includes the commit below. And yes, the problem still exists. Ok, I think I see the issue now. But I suspect that we need some additional locking to make this solid, since currently dev_priv-modeset_on_lid updates can race with our lid notifier handler. Let me think about this a bit more. hmm, with this patch, intel_lid_notify() will return immediately if modeset_on_lid is set to -1. So the only problem in my mind is that we got a lid open event during i915_suspend(). Say, lid is opened - i915_lid_notify() is invoked (modeset_on_lid is 1 at this time) - i915_suspend() set modeset_on_lid to -1, just before intel_modeset_setup_hw_state() being invoked in i915_lid_notify() - intel_modeset_setup_hw_state() breaks the system. but my first question would be is this (lid open on suspend) possible in real world? If the answer is yes, then my second question is that, this problem exists for STR as well because SCI is still valid at this time when suspending to memory, have we seen such issues for STR before? Anyway, if the current code does not break STR, this patch should be enough for the new suspend state. what do you think? I think I have two wishlist changes for your patch ;-) - Convert dev_priv-modeset_on_lid to an enum, so that we have descriptive names instead of magic numbers. - I think we can close all races by adding a new lid_notifier mutex (I prefer a new lock instead of overloading an existing one with). If we hold that in the suspend/resume paths just for changing modeset_on_lid and also for the entire lid notifier callback (i.e. grab the lock before first looking at modest_on_lid, only drop it once the modeset fixup has been completed at the end of the function) we should be race-free in all cases. Also, I think we should move the modeset_on_lid updates in the suspend/resume paths to the very beginning/end. Can you pls update your patch with these changes? Or do you see an additional race we need to plug somewhere? Thanks, Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/5] drm/i915: trivial: kill-agp collateral cleanups
On Fri, Jan 25, 2013 at 04:41:03PM -0800, Ben Widawsky wrote:
- i915_gem_init_aliasing_ppgtt should now be static
- move i915_gem_init_ppgtt declaration to the right place
Reviewed-by: Chris Wilson ch...@chris-wilson.co.uk
Signed-off-by: Ben Widawsky b...@bwidawsk.net
I've tried to apply this patch on top of latest dinq, and there's nothing
left after resolving conflicts. Have I screwed something up?
-Daniel
---
drivers/gpu/drm/i915/i915_drv.h | 3 +--
drivers/gpu/drm/i915/i915_gem_gtt.c | 2 +-
2 files changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 09753e5..1af8e73 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1598,7 +1598,6 @@ int __must_check i915_gem_init(struct drm_device *dev);
int __must_check i915_gem_init_hw(struct drm_device *dev);
void i915_gem_l3_remap(struct drm_device *dev);
void i915_gem_init_swizzling(struct drm_device *dev);
-void i915_gem_init_ppgtt(struct drm_device *dev);
void i915_gem_cleanup_ringbuffer(struct drm_device *dev);
int __must_check i915_gpu_idle(struct drm_device *dev);
int __must_check i915_gem_idle(struct drm_device *dev);
@@ -1653,7 +1652,7 @@ int i915_gem_context_destroy_ioctl(struct drm_device
*dev, void *data,
struct drm_file *file);
/* i915_gem_gtt.c */
-int __must_check i915_gem_init_aliasing_ppgtt(struct drm_device *dev);
+void i915_gem_init_ppgtt(struct drm_device *dev);
void i915_gem_cleanup_aliasing_ppgtt(struct drm_device *dev);
void i915_ppgtt_bind_object(struct i915_hw_ppgtt *ppgtt,
struct drm_i915_gem_object *obj,
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index a0ba4a9..462dec9 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -108,7 +108,7 @@ static void i915_ppgtt_clear_range(struct i915_hw_ppgtt
*ppgtt,
}
}
-int i915_gem_init_aliasing_ppgtt(struct drm_device *dev)
+static int i915_gem_init_aliasing_ppgtt(struct drm_device *dev)
{
struct drm_i915_private *dev_priv = dev-dev_private;
struct i915_hw_ppgtt *ppgtt;
--
1.8.1.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/5] drm/i915: Reclaim GTT space for failed PPGTT
On Fri, Jan 25, 2013 at 04:41:04PM -0800, Ben Widawsky wrote: When the PPGTT init fails, we may as well reuse the space that we were reserving for the PPGTT PDEs. This also fixes an extraneous mutex_unlock. Reviewed-by: Chris Wilson ch...@chris-wilson.co.uk Signed-off-by: Ben Widawsky b...@bwidawsk.net Queued for -next, thanks for the patch. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 3/5] drm/i915: Extract gen6 aliasing ppgtt code
On Fri, Jan 25, 2013 at 04:41:05PM -0800, Ben Widawsky wrote: This refactor clearly identifies the GEN specific portion of the aliased ppgtt code. Aside from some of the gen specific parts being extracted, it also preps us for an upcoming patch that pulls out the size, which has some nice benefits. v2: Fix wonky error handling (Chris) Signed-off-by: Ben Widawsky b...@bwidawsk.net Functionally we seem to have this patch already with commit e9ccfd7b94f1ca9b46b992a19d2e8c5af70e4c69 Author: Daniel Vetter daniel.vet...@ffwll.ch Date: Thu Jan 24 13:49:56 2013 -0800 drm/i915: extract hw ppgtt setup/cleanup code Yeah, you're allowed to hate me with the heat of a thousand suns now ;-) -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 4/5 v2] drm/i915: Aliased PPGTT size abstraction
On Mon, Jan 28, 2013 at 12:35:55PM -0800, Ben Widawsky wrote:
Aside from being a nice prep for some work I'm doing in PPGTT, this also
leaves us with a more accurate size in our gtt_total_entries member.
Since we can't actually use the PPGTT reserved part of the GGTT.
This will help some of the existing assertions find issues which would
overwrite the PPGTT PDEs.
Another benefit is for platforms which don't use the entire 2GB GTT,
this will save GTT space. For example if a platform has 1 1GB GTT, this
patch should save 1MB of GTT space (512MB has an even greater savings).
I don't have a platform to easily test this however.
If/when we ever move to real PPGTT, I think allocating the PDEs as
objects will make the most sense.
v2: Change the size calculation for the PDs carved out of the ggtt to be
more explicit. (Daniel)
Reviewed-by: Jani Nikula jani.nik...@intel.com
Cc: Daniel Vetter daniel.vet...@ffwll.ch
Signed-off-by: Ben Widawsky b...@bwidawsk.net
I'm not sold yet on whether this is the interface we want. Furthermore I
have some fading nightmares that maybe the pdes should be naturally
aligned in the GSM. So trying to safe a few of those sounds like a risky
idea. I'll punt on this one for now.
For patch 5 I'd prefer the clearer math over adding a comment (comments
tend to get stale, fast), otherwise all patches of this series merged (or
nothing left after resolving conflicts).
Thanks, Daniel
---
drivers/gpu/drm/i915/i915_debugfs.c | 2 ++
drivers/gpu/drm/i915/i915_drv.h | 3 ++-
drivers/gpu/drm/i915/i915_gem_gtt.c | 35 ++-
3 files changed, 30 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index 384f193..4545357 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -1605,6 +1605,8 @@ static int i915_ppgtt_info(struct seq_file *m, void
*data)
seq_printf(m, aliasing PPGTT:\n);
seq_printf(m, pd gtt offset: 0x%08x\n, ppgtt-pd_offset);
+ seq_printf(m, mapped size: %lldM\n,
+ppgtt-mapped_size20);
}
seq_printf(m, ECOCHK: 0x%08x\n, I915_READ(GAM_ECOCHK));
mutex_unlock(dev-struct_mutex);
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 1af8e73..60ba4ab 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -388,10 +388,11 @@ struct i915_gtt {
struct page *scratch_page;
};
-#define I915_PPGTT_PD_ENTRIES 512
+#define GEN6_MAX_PD_ENTRIES 512
#define I915_PPGTT_PT_ENTRIES 1024
struct i915_hw_ppgtt {
struct drm_device *dev;
+ uint64_t mapped_size;
unsigned num_pd_entries;
struct page **pt_pages;
uint32_t pd_offset;
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index f79f427..7d8c2e5 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -108,7 +108,7 @@ static void i915_ppgtt_clear_range(struct i915_hw_ppgtt
*ppgtt,
}
}
-static int gen6_init_aliasing_ppgtt(struct i915_hw_ppgtt *ppgtt)
+static int gen6_init_ppgtt(struct i915_hw_ppgtt *ppgtt, uint64_t size)
{
struct drm_device *dev = ppgtt-dev;
struct drm_i915_private *dev_priv = dev-dev_private;
@@ -116,15 +116,22 @@ static int gen6_init_aliasing_ppgtt(struct
i915_hw_ppgtt *ppgtt)
int i;
int ret = -ENOMEM;
+ if (dev_priv-mm.aliasing_ppgtt)
+ return -EBUSY;
+
+ /* Each PDE maps 4MB (1k PAGE_SIZE pages)*/
+ ppgtt-mapped_size = round_up(size, 122);
+ ppgtt-num_pd_entries = ppgtt-mapped_size 22;
+ BUG_ON(ppgtt-num_pd_entries GEN6_MAX_PD_ENTRIES);
+
/* ppgtt PDEs reside in the global gtt pagetable, which has 512*1024
* entries. For aliasing ppgtt support we just steal them at the end for
* now. */
- first_pd_entry_in_global_pt = dev_priv-mm.gtt-gtt_total_entries -
I915_PPGTT_PD_ENTRIES;
+ first_pd_entry_in_global_pt = dev_priv-mm.gtt-gtt_total_entries -
+ ppgtt-num_pd_entries;
- ppgtt-num_pd_entries = I915_PPGTT_PD_ENTRIES;
ppgtt-pt_pages = kzalloc(sizeof(struct page *)*ppgtt-num_pd_entries,
GFP_KERNEL);
-
if (!ppgtt-pt_pages)
return -ENOMEM;
@@ -156,7 +163,10 @@ static int gen6_init_aliasing_ppgtt(struct i915_hw_ppgtt
*ppgtt)
i915_ppgtt_clear_range(ppgtt, 0,
ppgtt-num_pd_entries*I915_PPGTT_PT_ENTRIES);
- ppgtt-pd_offset = (first_pd_entry_in_global_pt)*sizeof(gtt_pte_t);
+ ppgtt-pd_offset = first_pd_entry_in_global_pt * sizeof(gtt_pte_t);
+
+ DRM_INFO(Allocated %d PDEs for PPGTT\n, ppgtt-num_pd_entries);
+ DRM_DEBUG_DRIVER(First PDE: %d\n, first_pd_entry_in_global_pt);
return 0;
@@ -192,7 +202,7
[Intel-gfx] [PULL] drm-intel-next
Hi Dave,
The holiday pull fresh from QA. Not much in in, everyone was on vacation.
Highlights:
- Broadcast RBG improvements and reduced color range fixes from Ville
- Ben is on a kill legacy gtt code for good spree, first pile of patches
included.
- no relocs and lut improvements for faster execbuf from Chris.
- some refactorings from Imre
Big regression caugh by QA was the inbalanced unlock in one of the
load-detect paths - you've merged that one already. Otherwise nothing to
report about.
Cheers, Daniel
The following changes since commit b5cc6c0387b2f8d269c1df1e68c97c958dd22fed:
Merge tag 'drm-intel-next-2012-12-21' of
git://people.freedesktop.org/~danvet/drm-intel into drm-next (2013-01-17
20:34:08 +1000)
are available in the git repository at:
git://people.freedesktop.org/~danvet/drm-intel tags/drm-intel-next-2013-01-20
for you to fetch changes up to e5c653777986b40e2986d2c918847fddbcba3a34:
agp/intel: Add gma_bus_addr (2013-01-20 13:11:12 +0100)
Ben Widawsky (10):
drm/i915: Kill gtt_end
drm/i915: Mappable_end can't ever be end
drm/i915: Remove gtt_mappable_total
drm/i915: Create a gtt structure
drm/i915: Remove use on gma_bus_addr on gen6+
drm/i915: Remove use of gtt_mappable_entries
drm/i915: Cut out the infamous ILK w/a from AGP layer
drm/i915: Remove scratch page from shared
drm/i915: Needs_dmar, not
agp/intel: Add gma_bus_addr
Chris Wilson (6):
drm/i915: Add a debug interface to forcibly evict and shrink our object
caches
drm/i915: Bail if we attempt to allocate pages for a purged object
drm/i915: Mark a temporary allocation for copy-from-user as such
drm/i915: Take the handle idr spinlock once for looking up the exec
objects
drm/i915: Move the execbuffer objects list from the stack into the tracker
drm/i915: Use the reloc.handle as an index into the execbuffer array
Daniel Vetter (2):
drm/i915: wake up all pageflip waiters
drm/i915: Allow userspace to hint that the relocations were known
Egbert Eich (1):
drm/i915: Remove pch_rq_mask from struct drm_i915_private.
Imre Deak (3):
drm/i915: merge get_gtt_alignment/get_unfenced_gtt_alignment()
drm/i915: merge {i965, sandybridge}_write_fence_reg()
drm/i915: use gtt_get_size() instead of open coding it
Ville Syrjälä (5):
drm/i915: Fix SPRITE0_FLIP_DONE_INT_EN_VLV and
SPRITE0_FLIPDONE_INT_STATUS_VLV
drm/i915: Fix RGB color range property for PCH platforms
drm/i915: Add Automatic mode for the Broadcast RGB property
drm/edid: Add drm_rgb_quant_range_selectable()
drm/i915: Provide the quantization range in the AVI infoframe
drivers/char/agp/intel-gtt.c | 51 ++---
drivers/gpu/drm/drm_edid.c | 33
drivers/gpu/drm/i915/i915_debugfs.c| 109 ++-
drivers/gpu/drm/i915/i915_dma.c| 35 ++--
drivers/gpu/drm/i915/i915_drv.h| 48 +++--
drivers/gpu/drm/i915/i915_gem.c| 120
drivers/gpu/drm/i915/i915_gem_evict.c |2 +-
drivers/gpu/drm/i915/i915_gem_execbuffer.c | 280
drivers/gpu/drm/i915/i915_gem_gtt.c| 129 +++--
drivers/gpu/drm/i915/i915_gem_tiling.c | 21 +--
drivers/gpu/drm/i915/i915_irq.c| 14 +-
drivers/gpu/drm/i915/i915_reg.h|5 +-
drivers/gpu/drm/i915/intel_display.c | 13 +-
drivers/gpu/drm/i915/intel_dp.c| 39 +++-
drivers/gpu/drm/i915/intel_drv.h | 11 ++
drivers/gpu/drm/i915/intel_fb.c|5 +-
drivers/gpu/drm/i915/intel_hdmi.c | 45 -
drivers/gpu/drm/i915/intel_modes.c |5 +-
drivers/gpu/drm/i915/intel_overlay.c |4 +-
drivers/gpu/drm/i915/intel_ringbuffer.c|2 +-
drivers/gpu/drm/i915/intel_sdvo.c | 59 +-
include/drm/drm_crtc.h |1 +
include/drm/intel-gtt.h|9 -
include/uapi/drm/i915_drm.h| 20 ++
24 files changed, 669 insertions(+), 391 deletions(-)
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 0/6] drm/i915: Avoid stuck page flip waiters on GPU reset
Someone mentioned on irc that intel_crtc_wait_for_pending_flips() was getting stuck in some cases. This rang a bell since I was poking around that stuff last year. The issue that I'm trying to fix here is processes getting stuck in D state when a GPU reset happens while page flips have been scheduled. Testing is easy 1) fire up 'glxgears -fullscreen', run 'gem_hang 0', try to VT switch. Without this series X and some kworker soon get stuck in D state and you're left with a useless box. With the patch set, you wait a while, the GPU hangcheck kicks in, and you get your console back. The irc discussion was apparently about [1], but since the dmesg there doesn't show a GPU hang, I don't see this patch set fixing it. Frankly, I have no idea what's happening there. Additional work after this would involve sending out pending page flip events. Currently if you don't do the VT switch after a hang, glxgears remains stuck because the X server didn't get the page flip event from the kernel. Also we should probably do an explicit intel_pipe_set_base() with the current fb, to make sure we show the correct fb after the hang. But I'm not going to touch these right now. Actually I'm hoping someone else will volunteer for these tasks ;) [1] https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/1097315 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/6] drm/i915: Don't wait for page flips if there was GPU reset
From: Ville Syrjälä ville.syrj...@linux.intel.com
If a GPU reset occurs while a page flip has been submitted to the ring,
the flip will never complete once the ring has been reset.
The GPU reset can be detected by sampling the reset_counter before the
flip is submitted, and then while waiting for the flip, the sampled
counter is compared with the current reset_counter value.
Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
---
drivers/gpu/drm/i915/intel_display.c | 14 +-
drivers/gpu/drm/i915/intel_drv.h | 3 +++
2 files changed, 16 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 4097118..e348a68 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -2862,10 +2862,12 @@ static bool intel_crtc_has_pending_flip(struct drm_crtc
*crtc)
{
struct drm_device *dev = crtc-dev;
struct drm_i915_private *dev_priv = dev-dev_private;
+ struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
unsigned long flags;
bool pending;
- if (i915_reset_in_progress(dev_priv-gpu_error))
+ if (i915_reset_in_progress(dev_priv-gpu_error) ||
+ intel_crtc-reset_counter !=
atomic_read(dev_priv-gpu_error.reset_counter))
return false;
spin_lock_irqsave(dev-event_lock, flags);
@@ -6912,6 +6914,8 @@ static int intel_gen2_queue_flip(struct drm_device *dev,
if (ret)
goto err_unpin;
+ intel_crtc-reset_counter =
atomic_read(dev_priv-gpu_error.reset_counter);
+
/* Can't queue multiple flips, so wait for the previous
* one to finish before executing the next.
*/
@@ -6956,6 +6960,8 @@ static int intel_gen3_queue_flip(struct drm_device *dev,
if (ret)
goto err_unpin;
+ intel_crtc-reset_counter =
atomic_read(dev_priv-gpu_error.reset_counter);
+
if (intel_crtc-plane)
flip_mask = MI_WAIT_FOR_PLANE_B_FLIP;
else
@@ -6997,6 +7003,8 @@ static int intel_gen4_queue_flip(struct drm_device *dev,
if (ret)
goto err_unpin;
+ intel_crtc-reset_counter =
atomic_read(dev_priv-gpu_error.reset_counter);
+
/* i965+ uses the linear or tiled offsets from the
* Display Registers (which do not change across a page-flip)
* so we need only reprogram the base address.
@@ -7045,6 +7053,8 @@ static int intel_gen6_queue_flip(struct drm_device *dev,
if (ret)
goto err_unpin;
+ intel_crtc-reset_counter =
atomic_read(dev_priv-gpu_error.reset_counter);
+
intel_ring_emit(ring, MI_DISPLAY_FLIP |
MI_DISPLAY_FLIP_PLANE(intel_crtc-plane));
intel_ring_emit(ring, fb-pitches[0] | obj-tiling_mode);
@@ -7111,6 +7121,8 @@ static int intel_gen7_queue_flip(struct drm_device *dev,
if (ret)
goto err_unpin;
+ intel_crtc-reset_counter =
atomic_read(dev_priv-gpu_error.reset_counter);
+
intel_ring_emit(ring, MI_DISPLAY_FLIP_I915 | plane_bit);
intel_ring_emit(ring, (fb-pitches[0] | obj-tiling_mode));
intel_ring_emit(ring, obj-gtt_offset + intel_crtc-dspaddr_offset);
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index fcdfe42..a5521d9 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -235,6 +235,9 @@ struct intel_crtc {
/* We can share PLLs across outputs if the timings match */
struct intel_pch_pll *pch_pll;
uint32_t ddi_pll_sel;
+
+ /* reset counter value when the last flip was submitted */
+ unsigned int reset_counter;
};
struct intel_plane {
--
1.7.12.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 3/6] drm/i915: Wake up pending_flip_queue as part of reset handling
From: Ville Syrjälä ville.syrj...@linux.intel.com Someone may be waiting for a flip that will never complete due to a GPU reset. Wake up all such waiters when the hang is first detected, and after the reset processing has finished. Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com --- drivers/gpu/drm/i915/i915_irq.c | 4 1 file changed, 4 insertions(+) diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c index 13bb8d3..8b1146b 100644 --- a/drivers/gpu/drm/i915/i915_irq.c +++ b/drivers/gpu/drm/i915/i915_irq.c @@ -915,6 +915,8 @@ static void i915_error_work_func(struct work_struct *work) for_each_ring(ring, dev_priv, i) wake_up_all(ring-irq_queue); + wake_up_all(dev_priv-pending_flip_queue); + wake_up_all(dev_priv-gpu_error.reset_queue); } } @@ -1540,6 +1542,8 @@ void i915_handle_error(struct drm_device *dev, bool wedged) */ for_each_ring(ring, dev_priv, i) wake_up_all(ring-irq_queue); + + wake_up_all(dev_priv-pending_flip_queue); } queue_work(dev_priv-wq, dev_priv-gpu_error.work); -- 1.7.12.4 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 4/6] drm/i915: Move intel_crtc_has_pending_flip() earlier
From: Ville Syrjälä ville.syrj...@linux.intel.com
Just shuffle the code around. No functional changes.
Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
---
drivers/gpu/drm/i915/intel_display.c | 38 ++--
1 file changed, 19 insertions(+), 19 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index e348a68..6c21985 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -2262,6 +2262,25 @@ static void intel_crtc_update_sarea_pos(struct drm_crtc
*crtc, int x, int y)
}
}
+static bool intel_crtc_has_pending_flip(struct drm_crtc *crtc)
+{
+ struct drm_device *dev = crtc-dev;
+ struct drm_i915_private *dev_priv = dev-dev_private;
+ struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
+ unsigned long flags;
+ bool pending;
+
+ if (i915_reset_in_progress(dev_priv-gpu_error) ||
+ intel_crtc-reset_counter !=
atomic_read(dev_priv-gpu_error.reset_counter))
+ return false;
+
+ spin_lock_irqsave(dev-event_lock, flags);
+ pending = to_intel_crtc(crtc)-unpin_work != NULL;
+ spin_unlock_irqrestore(dev-event_lock, flags);
+
+ return pending;
+}
+
static int
intel_pipe_set_base(struct drm_crtc *crtc, int x, int y,
struct drm_framebuffer *fb)
@@ -2858,25 +2877,6 @@ static void ironlake_fdi_disable(struct drm_crtc *crtc)
udelay(100);
}
-static bool intel_crtc_has_pending_flip(struct drm_crtc *crtc)
-{
- struct drm_device *dev = crtc-dev;
- struct drm_i915_private *dev_priv = dev-dev_private;
- struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
- unsigned long flags;
- bool pending;
-
- if (i915_reset_in_progress(dev_priv-gpu_error) ||
- intel_crtc-reset_counter !=
atomic_read(dev_priv-gpu_error.reset_counter))
- return false;
-
- spin_lock_irqsave(dev-event_lock, flags);
- pending = to_intel_crtc(crtc)-unpin_work != NULL;
- spin_unlock_irqrestore(dev-event_lock, flags);
-
- return pending;
-}
-
static void intel_crtc_wait_for_pending_flips(struct drm_crtc *crtc)
{
struct drm_device *dev = crtc-dev;
--
1.7.12.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 5/6] drm/i915: Add intel_crtc_wait_for_pending_flips_locked()
From: Ville Syrjälä ville.syrj...@linux.intel.com
Move the functionality of intel_crtc_wait_for_pending_flips()
into intel_crtc_wait_for_pending_flips_locked().
intel_crtc_wait_for_pending_flips() is now just a wrapper that
grab struct_mutex and calls intel_crtc_wait_for_pending_flips_locked().
This changes the behaviour of intel_crtc_wait_for_pending_flips()
so that it now holds struct_mutex while waiting for pending flips.
Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
---
drivers/gpu/drm/i915/intel_display.c | 24 +---
1 file changed, 17 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 6c21985..a2e04f7 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -2281,6 +2281,22 @@ static bool intel_crtc_has_pending_flip(struct drm_crtc
*crtc)
return pending;
}
+static void intel_crtc_wait_for_pending_flips_locked(struct drm_crtc *crtc)
+{
+ struct drm_device *dev = crtc-dev;
+ struct drm_i915_private *dev_priv = dev-dev_private;
+
+ if (crtc-fb == NULL)
+ return;
+
+ WARN_ON(waitqueue_active(dev_priv-pending_flip_queue));
+
+ wait_event(dev_priv-pending_flip_queue,
+ !intel_crtc_has_pending_flip(crtc));
+
+ intel_finish_fb(crtc-fb);
+}
+
static int
intel_pipe_set_base(struct drm_crtc *crtc, int x, int y,
struct drm_framebuffer *fb)
@@ -2880,18 +2896,12 @@ static void ironlake_fdi_disable(struct drm_crtc *crtc)
static void intel_crtc_wait_for_pending_flips(struct drm_crtc *crtc)
{
struct drm_device *dev = crtc-dev;
- struct drm_i915_private *dev_priv = dev-dev_private;
if (crtc-fb == NULL)
return;
- WARN_ON(waitqueue_active(dev_priv-pending_flip_queue));
-
- wait_event(dev_priv-pending_flip_queue,
- !intel_crtc_has_pending_flip(crtc));
-
mutex_lock(dev-struct_mutex);
- intel_finish_fb(crtc-fb);
+ intel_crtc_wait_for_pending_flips_locked(crtc);
mutex_unlock(dev-struct_mutex);
}
--
1.7.12.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 6/6] drm/i915: Really wait for pending flips in intel_pipe_set_base()
From: Ville Syrjälä ville.syrj...@linux.intel.com
Since obj-pending_flips was never set, intel_pipe_set_base() never
actually waited for pending page flips to complete.
We really do want to wait for the pending flips, because otherwise the
mmio surface base address update could overtake the flip, and you
could end up with an old frame on the screen once the flip really
completes.
Just call intel_crtc_wait_pending_flips_locked() instead of
intel_finish_fb() from intel_pipe_set_base() to achieve the
desired result.
Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
---
drivers/gpu/drm/i915/intel_display.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index a2e04f7..7e047c1 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -2330,8 +2330,7 @@ intel_pipe_set_base(struct drm_crtc *crtc, int x, int y,
return ret;
}
- if (crtc-fb)
- intel_finish_fb(crtc-fb);
+ intel_crtc_wait_for_pending_flips_locked(crtc);
ret = dev_priv-display.update_plane(crtc, fb, x, y);
if (ret) {
--
1.7.12.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/6] drm/i915: Kill obj-pending_flip
From: Ville Syrjälä ville.syrj...@linux.intel.com
The pending flip mask no longer set anywhere, so trying to wait for
while it's non-zero is a no-op. Remove it completely.
Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
---
drivers/gpu/drm/i915/i915_drv.h | 7 ---
drivers/gpu/drm/i915/intel_display.c | 6 --
2 files changed, 13 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 4a4d8bd..3a08a3a 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1208,13 +1208,6 @@ struct drm_i915_gem_object {
/** for phy allocated objects */
struct drm_i915_gem_phys_object *phys_obj;
-
- /**
-* Number of crtcs where this object is currently the fb, but
-* will be page flipped away on the next vblank. When it
-* reaches 0, dev_priv-pending_flip_queue will be woken up.
-*/
- atomic_t pending_flip;
};
#define to_gem_object(obj) (((struct drm_i915_gem_object *)(obj))-base)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 796090e..4097118 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -2220,12 +2220,6 @@ intel_finish_fb(struct drm_framebuffer *old_fb)
bool was_interruptible = dev_priv-mm.interruptible;
int ret;
- WARN_ON(waitqueue_active(dev_priv-pending_flip_queue));
-
- wait_event(dev_priv-pending_flip_queue,
- i915_reset_in_progress(dev_priv-gpu_error) ||
- atomic_read(obj-pending_flip) == 0);
-
/* Big Hammer, we also need to ensure that any pending
* MI_WAIT_FOR_EVENT inside a user batch buffer on the
* current scanout is retired before unpinning the old
--
1.7.12.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC PATCH 1/3] PM: Introduce suspend state PM_SUSPEND_FREEZE
Hi, first, thanks a lot for advancing PM infrastructure! #define PM_SUSPEND_ON((__force suspend_state_t) 0) -#define PM_SUSPEND_STANDBY ((__force suspend_state_t) 1) +#define PM_SUSPEND_FREEZE((__force suspend_state_t) 1) +#define PM_SUSPEND_STANDBY ((__force suspend_state_t) 2) #define PM_SUSPEND_MEM ((__force suspend_state_t) 3) +#define PM_SUSPEND_MIN PM_SUSPEND_FREEZE #define PM_SUSPEND_MAX ((__force suspend_state_t) 4) I'll just pretend to be hopeful that you managed to hunt down all relevant code sites (possibly even splattered around drivers?) which may have made illegally hard-coded assumptions about the number of PM_SUSPEND state enums ;) (e.g. comparisons - such as ==, = etc. - come into mind) Review of your patch was all fine, nothing to object about. Thanks, Andreas Mohr ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 0/6] drm/i915: Avoid stuck page flip waiters on GPU reset
On Tue, Jan 29, 2013 at 06:13:32PM +0200, ville.syrj...@linux.intel.com wrote: Someone mentioned on irc that intel_crtc_wait_for_pending_flips() was getting stuck in some cases. This rang a bell since I was poking around that stuff last year. The issue that I'm trying to fix here is processes getting stuck in D state when a GPU reset happens while page flips have been scheduled. Testing is easy 1) fire up 'glxgears -fullscreen', run 'gem_hang 0', try to VT switch. Without this series X and some kworker soon get stuck in D state and you're left with a useless box. With the patch set, you wait a while, the GPU hangcheck kicks in, and you get your console back. Broken record maintainer request: Can you please bake that into an i-g-t? I think (hope) that running one of the delayed flip tests vs. the hangman (gem_hang is a bit evil since it can kill boxes for real) should do the trick. Then maybe also run one of the wf-vblank tests vs. hangman to check that we cancel those correctly, too. The irc discussion was apparently about [1], but since the dmesg there doesn't show a GPU hang, I don't see this patch set fixing it. Frankly, I have no idea what's happening there. Additional work after this would involve sending out pending page flip events. Currently if you don't do the VT switch after a hang, glxgears remains stuck because the X server didn't get the page flip event from the kernel. Also we should probably do an explicit intel_pipe_set_base() with the current fb, to make sure we show the correct fb after the hang. But I'm not going to touch these right now. Actually I'm hoping someone else will volunteer for these tasks ;) Hm ... I guess we need to walk the file_priv event list somewhere an fire them all off, indicating somehow that things went kaboom. I think we should aim for a drm generic way to singal those even. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 0/6] drm/i915: Avoid stuck page flip waiters on GPU reset
On Tue, Jan 29, 2013 at 05:39:46PM +0100, Daniel Vetter wrote: On Tue, Jan 29, 2013 at 06:13:32PM +0200, ville.syrj...@linux.intel.com wrote: Someone mentioned on irc that intel_crtc_wait_for_pending_flips() was getting stuck in some cases. This rang a bell since I was poking around that stuff last year. The issue that I'm trying to fix here is processes getting stuck in D state when a GPU reset happens while page flips have been scheduled. Testing is easy 1) fire up 'glxgears -fullscreen', run 'gem_hang 0', try to VT switch. Without this series X and some kworker soon get stuck in D state and you're left with a useless box. With the patch set, you wait a while, the GPU hangcheck kicks in, and you get your console back. Broken record maintainer request: Can you please bake that into an i-g-t? I think (hope) that running one of the delayed flip tests vs. the hangman (gem_hang is a bit evil since it can kill boxes for real) should do the trick. Then maybe also run one of the wf-vblank tests vs. hangman to check that we cancel those correctly, too. Actually for the case you're fixing here we probably need a delayed flip vs. modeset (without flip event checks) against a simulated gpu hang. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/2] drm/i915: Adding a warning to FBC description
On Tue, 29 Jan 2013 09:49:13 +0100 Daniel Vetter dan...@ffwll.ch wrote: On Mon, Jan 28, 2013 at 03:32:16PM -0800, Ben Widawsky wrote: It should only be used with caution... Signed-off-by: Ben Widawsky b...@bwidawsk.net Isn't that like the general assumption of these module parameters that they can have pretty massive bad side-effects? Meaning I'm routinely checking these already anyway in bug reports, same for non-standard rc6 settings. -Daniel I felt that way too, until we got a complain in #intel-gfx and it changed my mind. Whatevs, I ain't gonna fight for this one, I'll just punt the bug reporter to you next time. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/2] drm/i915: Error state should print /sys/kernel/debug
On Tue, 29 Jan 2013 09:54:18 +0100 Daniel Vetter dan...@ffwll.ch wrote: On Tue, Jan 29, 2013 at 08:41:12AM +, Damien Lespiau wrote: On Mon, Jan 28, 2013 at 03:32:15PM -0800, Ben Widawsky wrote: /sys/kernel/debug has more or less been the standard location of debugfs for several years now. Other parts of DRM already use this location, so we should as well. Signed-off-by: Ben Widawsky b...@bwidawsk.net Reviewed-by: Damien Lespiau damien.lesp...@intel.com Queued for -next, thanks for the patch. Oh and fixed up a bikeshed from checkpatch.pl while applying: Applying: drm/i915: Error state should print /sys/kernel/debug WARNING: line over 80 characters #22: FILE: drivers/gpu/drm/i915/i915_irq.c:1308: + DRM_INFO(capturing error event; look for more information in /sys/kernel/debug/dri/%d/i915_error_state\n, total: 0 errors, 1 warnings, 8 lines checked Yeah, I've added that OCD thing to my patch apply pipeline, let's see how much fun it is ;-) I've not looked at the final patch yet, but I think breaking up constant strings is considered bad form, and lines above 80 are generally favored for grepability. At least James Bottomley said that in his talk and LPC, and a bunch of other maintainers seemed to agree. (and I agree) -Daniel -- Damien ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/2] drm/i915: Error state should print /sys/kernel/debug
On Tue, Jan 29, 2013 at 08:52:36AM -0800, Ben Widawsky wrote: On Tue, 29 Jan 2013 09:54:18 +0100 Daniel Vetter dan...@ffwll.ch wrote: On Tue, Jan 29, 2013 at 08:41:12AM +, Damien Lespiau wrote: On Mon, Jan 28, 2013 at 03:32:15PM -0800, Ben Widawsky wrote: /sys/kernel/debug has more or less been the standard location of debugfs for several years now. Other parts of DRM already use this location, so we should as well. Signed-off-by: Ben Widawsky b...@bwidawsk.net Reviewed-by: Damien Lespiau damien.lesp...@intel.com Queued for -next, thanks for the patch. Oh and fixed up a bikeshed from checkpatch.pl while applying: Applying: drm/i915: Error state should print /sys/kernel/debug WARNING: line over 80 characters #22: FILE: drivers/gpu/drm/i915/i915_irq.c:1308: + DRM_INFO(capturing error event; look for more information in /sys/kernel/debug/dri/%d/i915_error_state\n, total: 0 errors, 1 warnings, 8 lines checked Yeah, I've added that OCD thing to my patch apply pipeline, let's see how much fun it is ;-) I've not looked at the final patch yet, but I think breaking up constant strings is considered bad form, and lines above 80 are generally favored for grepability. At least James Bottomley said that in his talk and LPC, and a bunch of other maintainers seemed to agree. (and I agree) I routinely ignore the 80 cols warnings. I'm sure a significant part of my patches violate it, even the ones w/o long strings. -- Ville Syrjälä Intel OTC ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/3] drm/i915: don't send DP idle pattern before normal on HSW PORT_A
From: Paulo Zanoni paulo.r.zan...@intel.com
The DP_TP_STATUS register for PORT_A doesn't exist. Our documentation
will be fixed soon, so the code does not match it for now.
This solves Timed out waiting for DP idle patterns and unclaimed
register messages on eDP.
V1: Was called drm/i915: don't read DP_TP_STATUS(PORT_A)
V2: Was called drm/i915: don't send DP idle pattern before normal
pattern on HSW
V3: Only change the code that touches PORT_A.
Signed-off-by: Paulo Zanoni paulo.r.zan...@intel.com
---
drivers/gpu/drm/i915/intel_dp.c | 16 ++--
1 file changed, 10 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 51fd797..1b76b04 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -1785,14 +1785,18 @@ intel_dp_set_link_train(struct intel_dp *intel_dp,
temp = ~DP_TP_CTL_LINK_TRAIN_MASK;
switch (dp_train_pat DP_TRAINING_PATTERN_MASK) {
case DP_TRAINING_PATTERN_DISABLE:
- temp |= DP_TP_CTL_LINK_TRAIN_IDLE;
- I915_WRITE(DP_TP_CTL(port), temp);
- if (wait_for((I915_READ(DP_TP_STATUS(port))
- DP_TP_STATUS_IDLE_DONE), 1))
- DRM_ERROR(Timed out waiting for DP idle
patterns\n);
+ if (port != PORT_A) {
+ temp |= DP_TP_CTL_LINK_TRAIN_IDLE;
+ I915_WRITE(DP_TP_CTL(port), temp);
+
+ if (wait_for((I915_READ(DP_TP_STATUS(port))
+ DP_TP_STATUS_IDLE_DONE), 1))
+ DRM_ERROR(Timed out waiting for DP
idle patterns\n);
+
+ temp = ~DP_TP_CTL_LINK_TRAIN_MASK;
+ }
- temp = ~DP_TP_CTL_LINK_TRAIN_MASK;
temp |= DP_TP_CTL_LINK_TRAIN_NORMAL;
break;
--
1.7.10.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 3/3] drm/i915: dynamic Haswell display power well support
From: Daniel Vetter daniel.vet...@ffwll.ch
We can disable (almost) all the display hw if we only use pipe A, with
the integrated edp transcoder on port A. Because we don't set the cpu
transcoder that early (yet), we need to help us with a trick to simply
check for any edp encoders.
v2: Paulo Zanoni pointed out that we also need to configure the eDP
cpu transcoder correctly.
v3: Made by Paulo Zanoni
- Rebase patch to be on top of fix intel_init_power_wells patch
- Fix typos
- Fix a small bug by adding a connectors_active check
- Restore the initial code that unconditionally enables the power
well when taking over from the BIOS
v4: Made by Paulo Zanoni
- One more typo spotted by Jani Nikula
v5: Made by Paulo Zanoni
- Rebase
Signed-off-by: Paulo Zanoni paulo.r.zan...@intel.com
---
drivers/gpu/drm/i915/intel_ddi.c |8 +++-
drivers/gpu/drm/i915/intel_display.c | 31 +++
2 files changed, 38 insertions(+), 1 deletion(-)
I know we might not want to apply this right now, but at least there's an
updated version on the list :)
diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index 33b9112..cedf4ab 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -988,7 +988,13 @@ void intel_ddi_enable_pipe_func(struct drm_crtc *crtc)
if (cpu_transcoder == TRANSCODER_EDP) {
switch (pipe) {
case PIPE_A:
- temp |= TRANS_DDI_EDP_INPUT_A_ONOFF;
+ /* Can only use the always-on power well for eDP when
+* not using the panel fitter, and when not using motion
+ * blur mitigation (which we don't support). */
+ if (dev_priv-pch_pf_size)
+ temp |= TRANS_DDI_EDP_INPUT_A_ONOFF;
+ else
+ temp |= TRANS_DDI_EDP_INPUT_A_ON;
break;
case PIPE_B:
temp |= TRANS_DDI_EDP_INPUT_B_ONOFF;
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index de3efdd..d204ed2 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -5607,6 +5607,35 @@ static int ironlake_crtc_mode_set(struct drm_crtc *crtc,
return fdi_config_ok ? ret : -EINVAL;
}
+static void haswell_modeset_global_resources(struct drm_device *dev)
+{
+ struct drm_i915_private *dev_priv = dev-dev_private;
+ bool enable = false;
+ struct intel_crtc *crtc;
+ struct intel_encoder *encoder;
+
+ list_for_each_entry(crtc, dev-mode_config.crtc_list, base.head) {
+ if (crtc-pipe != PIPE_A crtc-base.enabled)
+ enable = true;
+ /* XXX: Should check for edp transcoder here, but thanks to init
+* sequence that's not yet available. Just in case desktop eDP
+* on PORT D is possible on haswell, too. */
+ }
+
+ list_for_each_entry(encoder, dev-mode_config.encoder_list,
+ base.head) {
+ if (encoder-type != INTEL_OUTPUT_EDP
+ encoder-connectors_active)
+ enable = true;
+ }
+
+ /* Even the eDP panel fitter is outside the always-on well. */
+ if (dev_priv-pch_pf_size)
+ enable = true;
+
+ intel_set_power_well(dev, enable);
+}
+
static int haswell_crtc_mode_set(struct drm_crtc *crtc,
struct drm_display_mode *mode,
struct drm_display_mode *adjusted_mode,
@@ -8486,6 +8515,8 @@ static void intel_init_display(struct drm_device *dev)
} else if (IS_HASWELL(dev)) {
dev_priv-display.fdi_link_train = hsw_fdi_link_train;
dev_priv-display.write_eld = haswell_write_eld;
+ dev_priv-display.modeset_global_resources =
+ haswell_modeset_global_resources;
}
} else if (IS_G4X(dev)) {
dev_priv-display.write_eld = g4x_write_eld;
--
1.7.10.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/5] drm/i915: trivial: kill-agp collateral cleanups
On Tue, Jan 29, 2013 at 01:49:22PM +0100, Daniel Vetter wrote: On Fri, Jan 25, 2013 at 04:41:03PM -0800, Ben Widawsky wrote: - i915_gem_init_aliasing_ppgtt should now be static - move i915_gem_init_ppgtt declaration to the right place Reviewed-by: Chris Wilson ch...@chris-wilson.co.uk Signed-off-by: Ben Widawsky b...@bwidawsk.net I've tried to apply this patch on top of latest dinq, and there's nothing left after resolving conflicts. Have I screwed something up? -Daniel No, I think you're right. I think it no longer applies. -- Ben Widawsky, Intel Open Source Technology Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 3/5] drm/i915: Extract gen6 aliasing ppgtt code
On Tue, Jan 29, 2013 at 01:55:46PM +0100, Daniel Vetter wrote: On Fri, Jan 25, 2013 at 04:41:05PM -0800, Ben Widawsky wrote: This refactor clearly identifies the GEN specific portion of the aliased ppgtt code. Aside from some of the gen specific parts being extracted, it also preps us for an upcoming patch that pulls out the size, which has some nice benefits. v2: Fix wonky error handling (Chris) Signed-off-by: Ben Widawsky b...@bwidawsk.net Functionally we seem to have this patch already with commit e9ccfd7b94f1ca9b46b992a19d2e8c5af70e4c69 Author: Daniel Vetter daniel.vet...@ffwll.ch Date: Thu Jan 24 13:49:56 2013 -0800 drm/i915: extract hw ppgtt setup/cleanup code Yeah, you're allowed to hate me with the heat of a thousand suns now ;-) -Daniel I already did. I guess when I rebased the series, you hadn't merged those yet. -- Ben Widawsky, Intel Open Source Technology Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 6/6] drm/i915: Resume dissecting intel_gtt
On Tue, Jan 29, 2013 at 08:40:06AM +, Damien Lespiau wrote: On Thu, Jan 24, 2013 at 02:45:00PM -0800, Ben Widawsky wrote: With the probe call in our dispatch table, we can now cut away two of the remaining members in the intel_gtt shared struct. v2: Rebased on top of Daniel's series Signed-off-by: Ben Widawsky b...@bwidawsk.net Shouldn't the commit message be that you get rid of struct intel_gtt entirely? Yes, I corrected this info on IRC a few days ago. Daniel, please fix that up if/when you take the patch. Reviewed-by: Damien Lespiau damien.lesp...@intel.com -- Damien -- Ben Widawsky, Intel Open Source Technology Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 3/3] drm/i915: clear the FPGA_DBG_RM_NOCLAIM bit at driver init
From: Paulo Zanoni paulo.r.zan...@intel.com
Otherwise, if the BIOS did anything wrong, our first I915_{WRITE,READ}
will give us unclaimed register messages.
V2: Even earlier.
Bugzilla: http://bugs.freedesktop.org/show_bug.cgi?id=58897
Signed-off-by: Paulo Zanoni paulo.r.zan...@intel.com
---
drivers/gpu/drm/i915/i915_dma.c |4
1 file changed, 4 insertions(+)
If no one is opposed, I'd like to suggest applying patches 1-3 from this series
first, then we worry about the others later.
diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
index cf06103..d295445 100644
--- a/drivers/gpu/drm/i915/i915_dma.c
+++ b/drivers/gpu/drm/i915/i915_dma.c
@@ -1542,6 +1542,10 @@ int i915_driver_load(struct drm_device *dev, unsigned
long flags)
goto put_gmch;
}
+ /* This must happen before any I915_{READ,WRITE}: */
+ if (IS_HASWELL(dev))
+ I915_WRITE_NOTRACE(FPGA_DBG, FPGA_DBG_RM_NOCLAIM);
+
aperture_size = dev_priv-gtt.mappable_end;
dev_priv-gtt.mappable =
--
1.7.10.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Fix CAGF for HSW
The shift changed, hurray. WARNING: only compile tested Reported-by: Kenneth Graunke kenn...@whitecape.org Cc: Paulo Zanoni przan...@gmail.com Signed-off-by: Ben Widawsky b...@bwidawsk.net --- drivers/gpu/drm/i915/i915_debugfs.c | 10 +++--- drivers/gpu/drm/i915/i915_reg.h | 2 ++ 2 files changed, 9 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_debugfs.c b/drivers/gpu/drm/i915/i915_debugfs.c index 384f193..7491148 100644 --- a/drivers/gpu/drm/i915/i915_debugfs.c +++ b/drivers/gpu/drm/i915/i915_debugfs.c @@ -957,7 +957,7 @@ static int i915_cur_delayinfo(struct seq_file *m, void *unused) u32 gt_perf_status = I915_READ(GEN6_GT_PERF_STATUS); u32 rp_state_limits = I915_READ(GEN6_RP_STATE_LIMITS); u32 rp_state_cap = I915_READ(GEN6_RP_STATE_CAP); - u32 rpstat; + u32 rpstat, cagf; u32 rpupei, rpcurup, rpprevup; u32 rpdownei, rpcurdown, rpprevdown; int max_freq; @@ -976,6 +976,11 @@ static int i915_cur_delayinfo(struct seq_file *m, void *unused) rpdownei = I915_READ(GEN6_RP_CUR_DOWN_EI); rpcurdown = I915_READ(GEN6_RP_CUR_DOWN); rpprevdown = I915_READ(GEN6_RP_PREV_DOWN); + if (IS_HASWELL(dev)) + cagf = (rpstat HSW_CAGF_MASK) HSW_CAGF_SHIFT; + else + cagf = (rpstat GEN6_CAGF_MASK) GEN6_CAGF_SHIFT; + cagf *= GT_FREQUENCY_MULTIPLIER; gen6_gt_force_wake_put(dev_priv); mutex_unlock(dev-struct_mutex); @@ -988,8 +993,7 @@ static int i915_cur_delayinfo(struct seq_file *m, void *unused) gt_perf_status 0xff); seq_printf(m, Render p-state limit: %d\n, rp_state_limits 0xff); - seq_printf(m, CAGF: %dMHz\n, ((rpstat GEN6_CAGF_MASK) - GEN6_CAGF_SHIFT) * GT_FREQUENCY_MULTIPLIER); + seq_printf(m, CAGF: %dMHz\n, cagf); seq_printf(m, RP CUR UP EI: %dus\n, rpupei GEN6_CURICONT_MASK); seq_printf(m, RP CUR UP: %dus\n, rpcurup diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h index 0c89cf5..9a3cd04 100644 --- a/drivers/gpu/drm/i915/i915_reg.h +++ b/drivers/gpu/drm/i915/i915_reg.h @@ -4196,7 +4196,9 @@ #define GEN6_RP_INTERRUPT_LIMITS 0xA014 #define GEN6_RPSTAT1 0xA01C #define GEN6_CAGF_SHIFT 8 +#define HSW_CAGF_SHIFT 7 #define GEN6_CAGF_MASK (0x7f GEN6_CAGF_SHIFT) +#define HSW_CAGF_MASK(0x7f HSW_CAGF_SHIFT) #define GEN6_RP_CONTROL0xA024 #define GEN6_RP_MEDIA_TURBO (111) #define GEN6_RP_MEDIA_MODE_MASK (39) -- 1.8.1.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] intel-gpu-tools patches for read/write MMIO
Can you just post them externally to intel-gfx@lists.freedesktop.org? It's best to use git send-email to do it, that way the changelogs are preserved and posted to the ml along with the patches. Not sure if there's a bunch of duplication between the two, but you could split them up a bit. I still don't like the idea of silently adding the display offset on vlv; these are just debug tools and the developer should get the absolute offset they asked for no matter what. Jesse On Tue, 29 Jan 2013 00:16:51 -0800 Cheah, Vincent Beng Keat vincent.beng.keat.ch...@intel.com wrote: Hi Attached refers to two different patches that I have made for Benjamin Windawsky’s branch (bwidawsk_branch.patch) and intel-gpu-tools (master branch - intel-gpu-tools_master.patch). Alternative link: (\\pglvm2008-v03.png.intel.com\automation\binary\Linux\Automation\patches ) patches: • intel-gpu-tools-1.3_master.patch o To be applied on latest intel-gpu-tools-1.3 (git clone git://anongit.freedesktop.org/xorg/app/intel-gpu-tools ) o The patches added are VLV chipset support + correcting intel_read_reg.c, intel_reg_wirte.c and intel_gtt.c o Web link: http://cgit.freedesktop.org/xorg/app/intel-gpu-tools/ • bwidawsk_branch.patch o To be applied on Benjamin Windawsky’s branch (git clone git://people.freedesktop.org/~bwidawsk/intel-gpu-tools -b dump_util o The patches added are VLV chipset support + correcting intel_read_reg.c, intel_reg_wirte.c and intel_gtt.c + merge in change(s) from intel-gpu-tools-1.3 o Web link: http://cgit.freedesktop.org/~bwidawsk/intel-gpu-tools/?h=dump_util Could somebody you please help to upstream this? Thanks. Best regards, Vincent -Original Message- From: Ben Widawsky [mailto:benjamin.widaw...@intel.com] Sent: Tuesday, January 15, 2013 2:55 PM To: Teres Alexis, Alan Previn Cc: Barnes, Jesse; Cheah, Vincent Beng Keat; Vetter, Daniel Subject: Re: intel-gpu-tools patches for read/write MMIO On Mon, Jan 14, 2013 at 10:42 PM, Teres Alexis, Alan Previn alan.previn.teres.ale...@intel.com wrote: Ben, point us to that infrastructure ur working on - and since ur currently maintaining the intel-gpu-tools, let us know if that framework is still being worked on for VLV support or if someone else is working on adding VLV support in some form into the intel-gpu-tools. Vincent is already starting to work on adding IS_DISPLAY_REG for VLV. Don’t want any overlap - let us know if so. I am too lazy to find the mailing list post, but here it is: http://cgit.freedesktop.org/~bwidawsk/intel-gpu-tools/log/?h=dump_util I made some changed during PO which I probably never pushed. I'd have to look. IMO, this is the way to go though. (see vlv_display.txt) On the intel_reg_read/write should only do what the user asks - I agree with that. But if that function is being re-used by other internal tests like dump display regs or something, then an internal function could pass in that value - i.e. the option to explicitly say if its display or not should still be there. We don't have the kind of capability you're referring to there. It would be nice to have, but not there yet. Anyway, I agree with you. Also, the option to have a text file define the range sounds excellent - but should stop the one-off cmd line drive reg read / write - which I am sure is not being removed by anyone in any branch for any reason :P Yeah, I think Daniel gave up arguing against it, I forget if I was supposed to resubmit the patch. It came up at our London meeting. Anyone remember? ...alan -Original Message- From: Ben Widawsky [mailto:benjamin.widaw...@intel.com] Sent: Tuesday, January 15, 2013 12:49 PM To: Teres Alexis, Alan Previn Cc: Barnes, Jesse; Cheah, Vincent Beng Keat; Vetter, Daniel Subject: Re: intel-gpu-tools patches for read/write MMIO This is what that infrastructure I worked on was meant to do (where a text file defines the registers you want to read), you know, the one Daniel more or less nak'd ;-) ... intel_reg_read/write shouldn't ever do anything except what the user asked. Personally, I think the dump range never belonged in read/write, but that predated me. intel_reg_dumper is a bit of another story though, see first sentenc. There is no need to work with Daniel directly if you don't want. Simply submit them to the intel-gfx mailing lists. If we have patches that cannot be me public yet, we have an internal list for that which we can point you to (and I am currently maintaining that intel-gpu-tools repository). Anyway, I wasn't directly addressed, so I'll butt out having left my $.02 :-) On Mon, Jan 14, 2013 at 6:19 PM, Teres Alexis, Alan Previn alan.previn.teres.ale...@intel.com wrote:
Re: [Intel-gfx] intel-gpu-tools patches for read/write MMIO
On 29/01/2013 21:01, Jesse Barnes wrote: Can you just post them externally tointel-...@lists.freedesktop.org? It's best to use git send-email to do it, that way the changelogs are preserved and posted to the ml along with the patches. Public intel-gfx is already on the cc list, just in case you get the urge to spill some secrets ;-) Not sure if there's a bunch of duplication between the two, but you could split them up a bit. I still don't like the idea of silently adding the display offset on vlv; these are just debug tools and the developer should get the absolute offset they asked for no matter what. On that topic of silently adding display offset - with Ville's kernel work we'll have switched away completely from such tricks in the kernel. So I think i-g-t shouldn't automatically add the offset. Which essentially just leaves us with intel_reg_dumper. Now for that I'm somewhat hopefully that we will be able to (eventually) dump registers using the bspec xml sources (there should be bspec xmls around for just the open-source approved parts). In the meantime, can't we just adjust the relevant offsets of the register blocks? IIrc their all somewhat usefully grouped together, so this would amount to adding a quick function to add the offset to a given table (put keep all the names) and then feed the adjusted table to the dumper functions ... -Daniel Intel Semiconductor AG Registered No. 020.30.913.786-7 Registered Office: World Trade Center, Leutschenbachstrasse 95, 8050 Zurich, Switzerland This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] intel-gpu-tools patches for read/write MMIO
On Tue, Jan 29, 2013 at 09:15:22PM +0100, Daniel Vetter wrote: On 29/01/2013 21:01, Jesse Barnes wrote: Can you just post them externally tointel-...@lists.freedesktop.org? It's best to use git send-email to do it, that way the changelogs are preserved and posted to the ml along with the patches. Public intel-gfx is already on the cc list, just in case you get the urge to spill some secrets ;-) Not sure if there's a bunch of duplication between the two, but you could split them up a bit. I still don't like the idea of silently adding the display offset on vlv; these are just debug tools and the developer should get the absolute offset they asked for no matter what. On that topic of silently adding display offset - with Ville's kernel work we'll have switched away completely from such tricks in the kernel. So I think i-g-t shouldn't automatically add the offset. Which essentially just leaves us with intel_reg_dumper. Now for that I'm somewhat hopefully that we will be able to (eventually) dump registers using the bspec xml sources (there should be bspec xmls around for just the open-source approved parts). In the meantime, can't we just adjust the relevant offsets of the register blocks? IIrc their all somewhat usefully grouped together, so this would amount to adding a quick function to add the offset to a given table (put keep all the names) and then feed the adjusted table to the dumper functions ... -Daniel As we discussed in private, even if we get to the point of having bspec xml, we would still want a tool similar to the one that was proposed for parsing the XML (as opposed to the text). Reg dumper as has been mentioned in several threads is pretty inflexible, and a pain to modify for person use. As we also discussed in private, I'd like Jesse to either fight or not for this because I don't think he has to butt heads with you enough. -- Ben Widawsky, Intel Open Source Technology Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Increase the RC6p threshold.
This increases GEN6_RC6p_THRESHOLD from 10 to 15. For some reason this avoids the gen6_gt_check_fifodbg.isra warnings and associated GPU lockups, which makes my ivy bridge machine stable. Signed-off-by: Stéphane Marchesin marc...@chromium.org --- drivers/gpu/drm/i915/intel_pm.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c index 3280cff..dde0ded 100644 --- a/drivers/gpu/drm/i915/intel_pm.c +++ b/drivers/gpu/drm/i915/intel_pm.c @@ -2572,7 +2572,7 @@ static void gen6_enable_rps(struct drm_device *dev) I915_WRITE(GEN6_RC_SLEEP, 0); I915_WRITE(GEN6_RC1e_THRESHOLD, 1000); I915_WRITE(GEN6_RC6_THRESHOLD, 5); - I915_WRITE(GEN6_RC6p_THRESHOLD, 10); + I915_WRITE(GEN6_RC6p_THRESHOLD, 15); I915_WRITE(GEN6_RC6pp_THRESHOLD, 64000); /* unused */ /* Check if we are enabling RC6 */ -- 1.8.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
