Re: [Intel-gfx] [PATCH] drm/i915: Fix up the forcewake timer initialization

2014-03-19 Thread Daniel Vetter
On Wed, Mar 19, 2014 at 1:41 AM, Ben Widawsky wrote: >> diff --git a/drivers/gpu/drm/i915/i915_dma.c >> b/drivers/gpu/drm/i915/i915_dma.c >> index e4d2b9f15ae2..9faee49f210d 100644 >> --- a/drivers/gpu/drm/i915/i915_dma.c >> +++ b/drivers/gpu/drm/i915/i915_dma.c >> @@ -1608,8 +1608,6 @@ int i915_

Re: [Intel-gfx] linux-next: build failure after merge of the drm-intel tree

2014-03-19 Thread Daniel Vetter
On Wed, Mar 19, 2014 at 2:54 AM, Ben Widawsky wrote: > On Tue, Mar 18, 2014 at 09:18:42PM -0400, Steven Rostedt wrote: >> On Wed, 19 Mar 2014 11:53:50 +1100 >> Stephen Rothwell wrote: >> >> >> > Caused by commit a25ca17c1eac ("drm/i915: Do not dereference pointers >> > from ring buffer in evict e

Re: [Intel-gfx] [PATCH] drm/i915: Fix up the forcewake timer initialization

2014-03-19 Thread Chris Wilson
On Tue, Mar 18, 2014 at 05:41:54PM -0700, Ben Widawsky wrote: > On Tue, Mar 18, 2014 at 04:31:03PM +0100, Daniel Vetter wrote: > > This is a regression introduced in > > > > commit 0294ae7b44bba7ab0d4cef9a8736287f38bdb4fd > > Author: Chris Wilson > > Date: Thu Mar 13 12:00:29 2014 + > > >

Re: [Intel-gfx] [PATCH] drm/i915: Fix up the forcewake timer initialization

2014-03-19 Thread Daniel Vetter
On Wed, Mar 19, 2014 at 8:26 AM, Chris Wilson wrote: > On Tue, Mar 18, 2014 at 05:41:54PM -0700, Ben Widawsky wrote: >> On Tue, Mar 18, 2014 at 04:31:03PM +0100, Daniel Vetter wrote: >> > This is a regression introduced in >> > >> > commit 0294ae7b44bba7ab0d4cef9a8736287f38bdb4fd >> > Author: Chri

Re: [Intel-gfx] [RFCv3 13/14] drm/i915: Split cursor update code from cursor ioctl handling

2014-03-19 Thread Chris Wilson
On Tue, Mar 18, 2014 at 05:22:58PM -0700, Matt Roper wrote: > Legacy cursor ioctls took GEM buffer handles from userspace directly > whereas the new unified plane handling assigns drm_framebuffer's to > cursor planes. Splitting the code that actually updates the cursor > plane from the code that h

Re: [Intel-gfx] [PATCH 08/20] drm/i915: check if IIR is still zero at postinstall on Gen5+

2014-03-19 Thread Daniel Vetter
On Tue, Mar 18, 2014 at 11:20:09AM -0700, Ben Widawsky wrote: > On Fri, Mar 07, 2014 at 08:10:24PM -0300, Paulo Zanoni wrote: > > From: Paulo Zanoni > > > > Instead of trying to clear it again. It should already be masked and > > disabled and zeroed at preinstall/uninstall. > > > > Signed-off-by

Re: [Intel-gfx] [PATCH 00/20] ILK+ interrupt improvements, v2

2014-03-19 Thread Daniel Vetter
On Tue, Mar 18, 2014 at 01:53:53PM -0700, Ben Widawsky wrote: > On Fri, Mar 07, 2014 at 08:10:16PM -0300, Paulo Zanoni wrote: > > From: Paulo Zanoni > > > > Hi > > > > This is basically a rebase of "[PATCH 00/19] ILK+ interrupt improvements", > > which > > was sent to the mailing list on Januar

Re: [Intel-gfx] [PATCH] drm/i915/bdw: Restore PPAT on thaw

2014-03-19 Thread Timo Aaltonen
On 19.03.2014 01:09, Ben Widawsky wrote: > Apparently it is wiped out from under us, and we get some really fun > caching artifacts upon resume (it seems to be WB for all types by > default). > > Reported-by: James Ausmus > Signed-off-by: Ben Widawsky Excellent! Bugzilla: https://bugs.freedesk

Re: [Intel-gfx] [PATCH] drm/i915: Add a DRM property "psr"

2014-03-19 Thread Daniel Vetter
On Tue, Mar 18, 2014 at 01:53:56PM -0700, Siva Chandra wrote: > On Tue, Mar 18, 2014 at 1:06 PM, Jesse Barnes > wrote: > > On Tue, 18 Mar 2014 12:51:07 -0700 > > Siva Chandra wrote: > > > >> This property helps one turn PSR "on" and "off" via xrandr. > >> The default value is same as that of the

Re: [Intel-gfx] [PATCH] drm/i915/bdw: Restore PPAT on thaw

2014-03-19 Thread Daniel Vetter
On Wed, Mar 19, 2014 at 10:39:03AM +0200, Timo Aaltonen wrote: > On 19.03.2014 01:09, Ben Widawsky wrote: > > Apparently it is wiped out from under us, and we get some really fun > > caching artifacts upon resume (it seems to be WB for all types by > > default). > > > > Reported-by: James Ausmus

Re: [Intel-gfx] [PATCH v2 for -fixes] drm/i915: Disable stolen memory when DMAR is active

2014-03-19 Thread Jani Nikula
On Tue, 18 Mar 2014, Daniel Vetter wrote: > On Tue, Mar 18, 2014 at 05:48:28PM +0100, Daniel Vetter wrote: >> On Tue, Mar 18, 2014 at 02:59:04PM +0200, Jani Nikula wrote: >> > From: Chris Wilson >> > >> > We have reports of heavy screen corruption if we try to use the stolen >> > memory reserved

Re: [Intel-gfx] [PATCH] drm/i915/vlv: no MCHBAR on VLV

2014-03-19 Thread Daniel Vetter
On Wed, Mar 19, 2014 at 03:31:41AM +, Chang, Junxiao wrote: > Reviewed-by: Junxiao Chang Queued for -next, thanks for the patch&review. -Daniel > > Thanks, > Junxiao > > -Original Message- > From: Dave Airlie [mailto:airl...@gmail.com] > Sent: Wednesday, March 19, 2014 10:32 AM > T

[Intel-gfx] [PATCH 3/3] tests/gem_userptr_benchmark: Benchmarking userptr surfaces and impact

2014-03-19 Thread Tvrtko Ursulin
From: Tvrtko Ursulin This adds a small benchmark for the new userptr functionality. Apart from basic surface creation and destruction, also tested is the impact of having userptr surfaces in the process address space. Reason for that is the impact of MMU notifiers on common address space operati

[Intel-gfx] [PATCH 0/3] tests: New userptr test case

2014-03-19 Thread Tvrtko Ursulin
From: Tvrtko Ursulin This patch series replaces the old vmap with the new userptr test case and also adds a benchmark for the new feature. Tested against version 21 of the kernel patch. Tvrtko Ursulin (3): tests/gem_userptr_blits: Expanded userptr test cases tests/gem_vmap_blits: Remove obs

[Intel-gfx] [PATCH 1/3] tests/gem_userptr_blits: Expanded userptr test cases

2014-03-19 Thread Tvrtko Ursulin
From: Tvrtko Ursulin A set of userptr test cases to support the new feature. For the eviction and swapping stress testing I have extracted some common behaviour from gem_evict_everything and made both test cases use it to avoid duplicating the code. Both unsynchronized and synchronized userptr

[Intel-gfx] [PATCH 2/3] tests/gem_vmap_blits: Remove obsolete test case

2014-03-19 Thread Tvrtko Ursulin
From: Tvrtko Ursulin No need for the old test case once the new one was added. Signed-off-by: Tvrtko Ursulin --- tests/.gitignore | 1 - tests/Makefile.sources | 1 - tests/gem_vmap_blits.c | 344 - 3 files changed, 346 deletions(-) de

Re: [Intel-gfx] [RFCv3 10/14] drm/i915: Rename similar plane functions to avoid confusion

2014-03-19 Thread Daniel Vetter
On Tue, Mar 18, 2014 at 05:22:55PM -0700, Matt Roper wrote: > The name 'update_plane' was used both for the primary plane functions in > intel_display.c and the sprite/overlay functions in intel_sprite.c. > Rename the primary plane functions to 'update_primary_plane' to avoid > confusion. > > On a

Re: [Intel-gfx] [RFCv3 11/14] drm/i915: Intel-specific primary plane handling

2014-03-19 Thread Daniel Vetter
On Tue, Mar 18, 2014 at 05:22:56PM -0700, Matt Roper wrote: > Intel hardware allows the primary plane to be disabled independently of > the CRTC. Provide custom primary plane handling to allow this. > > Cc: Intel Graphics Development > Signed-off-by: Matt Roper Overall this is imo a new featur

[Intel-gfx] [PATCH 1/2] drm/i915: Per-process stats work better when evaluated per-process

2014-03-19 Thread Chris Wilson
The idea of printing objects used by each process is to judge how each process is using them. This means that we need to evaluate whether the object is bound for that particular process, rather than just whether it is bound into the global GTT. v2: Restore the non-full-ppgtt path for simplicity as

[Intel-gfx] [PATCH 2/2] drm/i915: Print how many objects are shared in per-process stats

2014-03-19 Thread Chris Wilson
Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/i915_debugfs.c | 10 -- 1 file changed, 8 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_debugfs.c b/drivers/gpu/drm/i915/i915_debugfs.c index 4e1787ee8f37..9cc1c9360238 100644 --- a/drivers/gpu/drm/i915/i915_deb

[Intel-gfx] [PATCH] qf: Fully specify the push to the upsream hidden quilt branch

2014-03-19 Thread Damien Lespiau
On its own, "git push origin" will do something different depending on the the push.default option. So let's speficy the full local:remote branch here. Signed-off-by: Damien Lespiau --- qf | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/qf b/qf index 9838ffc..2e856b5 100755 -

Re: [Intel-gfx] [RFCv3 11/14] drm/i915: Intel-specific primary plane handling

2014-03-19 Thread Daniel Vetter
On Wed, Mar 19, 2014 at 01:11:26PM +0100, Daniel Vetter wrote: > On Tue, Mar 18, 2014 at 05:22:56PM -0700, Matt Roper wrote: > > Intel hardware allows the primary plane to be disabled independently of > > the CRTC. Provide custom primary plane handling to allow this. > > > > Cc: Intel Graphics De

[Intel-gfx] [PULL] drm-intel-fixes

2014-03-19 Thread Jani Nikula
Hi Dave - Two additional fixes on top of my last pull as promised, one for a 3.14 specific regression, one cc: stable. This clears up my backlog, at least of anything non-controversial. BR, Jani. The following changes since commit 5c673b60a9b3b23486f4eda75c72e91d31d26a2b: drm/i915: Don't e

Re: [Intel-gfx] [PATCH] drm/i915: make semaphore signaller detection more robust

2014-03-19 Thread Chris Wilson
On Tue, Mar 18, 2014 at 10:26:04AM +0100, Daniel Vetter wrote: > Extract all this logic into a new helper function > semaphore_wait_to_signaller_ring because: > > - The current code has way too much magic. > > - The current code doesn't look at bi16, which encodes VECS signallers > on HSW. Thos

Re: [Intel-gfx] [PATCH] drm/i915: Add a DRM property "psr"

2014-03-19 Thread Damien Lespiau
On Wed, Mar 19, 2014 at 09:44:38AM +0100, Daniel Vetter wrote: > On Tue, Mar 18, 2014 at 01:53:56PM -0700, Siva Chandra wrote: > > On Tue, Mar 18, 2014 at 1:06 PM, Jesse Barnes > > wrote: > > > On Tue, 18 Mar 2014 12:51:07 -0700 > > > Siva Chandra wrote: > > > > > >> This property helps one turn

Re: [Intel-gfx] [PATCH 02/16] drm/i915: make PC8 be part of runtime PM suspend/resume

2014-03-19 Thread Imre Deak
On Fri, 2014-03-07 at 20:08 -0300, Paulo Zanoni wrote: > From: Paulo Zanoni > > Currently, when our driver becomes idle for i915.pc8_timeout (default: > 5s) we enable PC8, so we save some power, but not everything we can. > Then, while PC8 is enabled, if we stay idle for more > autosuspend_delay_

Re: [Intel-gfx] [PATCH 3/4] drm/i915: Enabling pre-multiplied alpha drm property

2014-03-19 Thread Damien Lespiau
On Sat, Mar 08, 2014 at 01:51:18PM +0530, sagar.a.kam...@intel.com wrote: > From: Sagar Kamble > > This patch enables property for changin the pixel format > of plane to enable/disable pre-multiplied alpha format. > Client has to set BIT(DRM_BLEND_PREMULTIPLIED_ALPHA) | 0x0/0x1 > to disable/enabl

Re: [Intel-gfx] [PATCH 04/16] drm/i915: remove dev_priv->pc8.requirements_met

2014-03-19 Thread Imre Deak
On Fri, 2014-03-07 at 20:08 -0300, Paulo Zanoni wrote: > From: Paulo Zanoni > > The requirements_met variable was used to track two things: enabled > CRTCs and the power well. After the latest chagnes, we get a runtime > PM reference whenever we get any of the power domains, and we get > power do

Re: [Intel-gfx] [PATCH] drm/i915: make semaphore signaller detection more robust

2014-03-19 Thread Daniel Vetter
On Wed, Mar 19, 2014 at 4:05 PM, Chris Wilson wrote: > On Tue, Mar 18, 2014 at 10:26:04AM +0100, Daniel Vetter wrote: >> Extract all this logic into a new helper function >> semaphore_wait_to_signaller_ring because: >> >> - The current code has way too much magic. >> >> - The current code doesn't

Re: [Intel-gfx] [PATCH 09/16] drm/i915: make intel_aux_display_runtime_get get runtime PM, not PC8

2014-03-19 Thread Imre Deak
On Fri, 2014-03-07 at 20:08 -0300, Paulo Zanoni wrote: > From: Paulo Zanoni > > Because we merged the PC8 and runtime PM features, so calling > intel_runtime_pm_get now has the same meaning, and we plan to just > remove hsw_disable_package_c8 for this exact reason. > > My first patch tried to co

Re: [Intel-gfx] [PATCH] drm/i915: Add a DRM property "psr"

2014-03-19 Thread Jani Nikula
On Wed, 19 Mar 2014, Daniel Vetter wrote: > On Tue, Mar 18, 2014 at 01:53:56PM -0700, Siva Chandra wrote: >> On Tue, Mar 18, 2014 at 1:06 PM, Jesse Barnes >> wrote: >> > On Tue, 18 Mar 2014 12:51:07 -0700 >> > Siva Chandra wrote: >> > >> >> This property helps one turn PSR "on" and "off" via xr

Re: [Intel-gfx] [PATCH 02/16] drm/i915: make PC8 be part of runtime PM suspend/resume

2014-03-19 Thread Daniel Vetter
On Wed, Mar 19, 2014 at 05:07:53PM +0200, Imre Deak wrote: > On Fri, 2014-03-07 at 20:08 -0300, Paulo Zanoni wrote: > > From: Paulo Zanoni > > > > Currently, when our driver becomes idle for i915.pc8_timeout (default: > > 5s) we enable PC8, so we save some power, but not everything we can. > > Th

Re: [Intel-gfx] [PATCH 1/2] drm/i915: Per-process stats work better when evaluated per-process

2014-03-19 Thread Ben Widawsky
On Wed, Mar 19, 2014 at 01:45:45PM +, Chris Wilson wrote: > The idea of printing objects used by each process is to judge how each > process is using them. This means that we need to evaluate whether the > object is bound for that particular process, rather than just whether it > is bound into

Re: [Intel-gfx] [PATCH 00/20] ILK+ interrupt improvements, v2

2014-03-19 Thread Ben Widawsky
On Wed, Mar 19, 2014 at 09:36:04AM +0100, Daniel Vetter wrote: > On Tue, Mar 18, 2014 at 01:53:53PM -0700, Ben Widawsky wrote: > > On Fri, Mar 07, 2014 at 08:10:16PM -0300, Paulo Zanoni wrote: > > > From: Paulo Zanoni > > > > > > Hi > > > > > > This is basically a rebase of "[PATCH 00/19] ILK+ i

Re: [Intel-gfx] [PATCH 08/20] drm/i915: check if IIR is still zero at postinstall on Gen5+

2014-03-19 Thread Ben Widawsky
On Wed, Mar 19, 2014 at 09:28:32AM +0100, Daniel Vetter wrote: > On Tue, Mar 18, 2014 at 11:20:09AM -0700, Ben Widawsky wrote: > > On Fri, Mar 07, 2014 at 08:10:24PM -0300, Paulo Zanoni wrote: > > > From: Paulo Zanoni > > > > > > Instead of trying to clear it again. It should already be masked an

Re: [Intel-gfx] [PATCH v2 for -fixes] drm/i915: Disable stolen memory when DMAR is active

2014-03-19 Thread David Woodhouse
On Tue, 2014-03-18 at 14:59 +0200, Jani Nikula wrote: > From: Chris Wilson > > We have reports of heavy screen corruption if we try to use the stolen > memory reserved by the BIOS whilst the DMA-Remapper is active. This > quirk may be only specific to a few machines or BIOSes, but first lets > ap

[Intel-gfx] [PATCH] drm/i915: bdw expands ACTHD to 64bit

2014-03-19 Thread Chris Wilson
As Broadwell has an increased virtual address size, it requires more than 32 bits to store offsets into its address space. This includes the debug registers to track the current HEAD of the individual rings, which may be anywhere within the per-process address spaces. In order to find the full loca

Re: [Intel-gfx] [PATCH] drm/i915: bdw expands ACTHD to 64bit

2014-03-19 Thread Ben Widawsky
On Wed, Mar 19, 2014 at 09:54:48PM +, Chris Wilson wrote: > As Broadwell has an increased virtual address size, it requires more > than 32 bits to store offsets into its address space. This includes the > debug registers to track the current HEAD of the individual rings, which > may be anywhere

Re: [Intel-gfx] [PATCH 11/11] [v4] drm/i915/bdw: Ensure a context is loaded before RC6

2014-03-19 Thread Ben Widawsky
On Tue, Mar 04, 2014 at 03:30:14PM +0100, Daniel Vetter wrote: > On Wed, Feb 19, 2014 at 10:27:20PM -0800, Ben Widawsky wrote: > > RC6 works a lot like HW contexts in that when the GPU enters RC6 it > > saves away the state to a context, and loads it upon wake. > > > > It's to be somewhat expected

[Intel-gfx] [PATCH 05/12] drm/i915: Remove extraneous MMIO for RPS

2014-03-19 Thread Ben Widawsky
The values created at initialization must always exist to use the interface. Reading them again is confusing, and pointless. More cleanups are coming in the next patch. Since I am not 100% certain, moreover on BYT, (though I am extremely close to that) that there is no need to leave the MMIO here,

[Intel-gfx] [PATCH 10/12] drm/i915/bdw: Implement a basic PM interrupt handler

2014-03-19 Thread Ben Widawsky
Almost all of it is reusable from the existing code. The primary difference is we need to do even less in the interrupt handler, since interrupts are not shared in the same way. The patch is mostly a copy-paste of the existing snb+ code, with updates to the relevant parts requiring changes to the

[Intel-gfx] [PATCH 08/12] drm/i915/bdw: Extract rp_state_caps logic

2014-03-19 Thread Ben Widawsky
We have a need for duplicated parsing of the RP_STATE_CAPS register (and the setting of the associated fields). To reuse some code, we can extract the function into a simple helper. This patch also addresses the fact that we missed doing this for gen8, something we should have done anyway. This c

[Intel-gfx] [PATCH 12/12] drm/i915/bdw: Enable RC6

2014-03-19 Thread Ben Widawsky
It is tested and looking fairly stable now, so turn it on. It wasn't intentionally turned off originally :P Reviewed-by: Rodrigo Vivi Signed-off-by: Ben Widawsky --- drivers/gpu/drm/i915/intel_pm.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/intel_pm

[Intel-gfx] [PATCH 00/12] [v3] BDW RPS + RC6 + rps fixlets

2014-03-19 Thread Ben Widawsky
Ben Widawsky (12): drm/i915: Reorganize the overclock code drm/i915: Fix coding style for RPS drm/i915: Store the HW min frequency as min_freq drm/i915: Rename and comment all the RPS *stuff* drm/i915: Remove extraneous MMIO for RPS drm/i915: remove rps local variables drm/i915/bdw:

[Intel-gfx] [PATCH 02/12] drm/i915: Fix coding style for RPS

2014-03-19 Thread Ben Widawsky
Introduced: commit b8a5ff8d7c676a04e0da5ec16bb068dd39459042 Author: Jeff McGee Date: Tue Feb 4 11:37:01 2014 -0600 drm/i915: Update rps interrupt limits Cc: Jeff McGee Signed-off-by: Ben Widawsky --- drivers/gpu/drm/i915/i915_sysfs.c | 20 ++-- 1 file changed, 10 inserti

[Intel-gfx] [PATCH 11/12] drm/i915/bdw: Ensure a context is loaded before RC6

2014-03-19 Thread Ben Widawsky
RC6 works a lot like HW contexts in that when the GPU enters RC6 it saves away the state to a context, and loads it upon wake. It's to be somewhat expected that BIOS will not set up valid GPU state. As a result, if loading bad state can cause the GPU to get angry, it would make sense then that we

[Intel-gfx] [PATCH 09/12] drm/i915/bdw: RPS frequency bits are the same as HSW

2014-03-19 Thread Ben Widawsky
Reviewed-by: Rodrigo Vivi Signed-off-by: Ben Widawsky --- 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 ab9e992..9486396 100644 --- a/drivers/gpu/drm/i915/intel_pm.c +++

[Intel-gfx] [PATCH 01/12] drm/i915: Reorganize the overclock code

2014-03-19 Thread Ben Widawsky
The existing code (which I changed last) was very convoluted. I believe it was attempting to skip the overclock portion if the previous pcode write failed. When I last touched the code, I was preserving this behavior. There is some benefit to doing it that way in that if the first pcode access fail

[Intel-gfx] [PATCH 06/12] drm/i915: remove rps local variables

2014-03-19 Thread Ben Widawsky
With the renamed RPS struct members, it's easier to skip the local variables which no longer clarify anything, and if anything just make the code harder to read. The real motivation for this patch is actually the next patch, which attempts to consolidate some of the functionality. Cc: Jeff McGee

[Intel-gfx] [PATCH 04/12] drm/i915: Rename and comment all the RPS *stuff*

2014-03-19 Thread Ben Widawsky
The names of the struct members for RPS are stupid. Every time I need to do anything in this code I have to spend a significant amount of time to remember what it all means. By renaming the variables (and adding the comments) I hope to clear up the situation. Indeed doing this make some upcoming pa

[Intel-gfx] [PATCH 07/12] drm/i915/bdw: Set initial rps freq to RP0

2014-03-19 Thread Ben Widawsky
Programming it outside of the rp0-rp1 range is considered a programming error. Since we do not know that the previous value would actually be in the range, program something we've read from the hardware, and therefore know will work. This is potentially an issue for platforms whose ranges are outs

[Intel-gfx] [PATCH 03/12] drm/i915: Store the HW min frequency as min_freq

2014-03-19 Thread Ben Widawsky
this leaves a temporarily awkward min_delay (the soft limit) with the new min_freq (the hardware limit). It's fixed in the next patch. Signed-off-by: Ben Widawsky --- drivers/gpu/drm/i915/i915_drv.h | 1 + drivers/gpu/drm/i915/intel_pm.c | 2 +- 2 files changed, 2 insertions(+), 1 deletion(-) d

Re: [Intel-gfx] [PATCH] prime_mmap: Add new test for calling mmap() on dma-buf fds

2014-03-19 Thread Ben Widawsky
On Mon, Mar 17, 2014 at 07:43:35PM +, Rob Bradford wrote: > From: Rob Bradford > > This test has the following subtests: > - test_correct for correctness of the data > - test_map_unmap checks for mapping idempotency > - test_reprime checks for dma-buf creation idempotency > - test_forked chec

Re: [Intel-gfx] [PATCH 2/2] drm/i915: Print how many objects are shared in per-process statsg

2014-03-19 Thread Ben Widawsky
On Wed, Mar 19, 2014 at 01:45:46PM +, Chris Wilson wrote: > Signed-off-by: Chris Wilson Any clue how you intend to use this for a commit message (I'm actually curious)? Also, the subject is wrong, you're counting size, not quantity. Anyhoo, looks correct. Reviewed-by: Ben Widawsky > --- >