On Tue, Mar 18, 2014 at 07:38:43PM -0700, Ben Widawsky wrote:
On Tue, Mar 18, 2014 at 06:27:03PM -0700, Ben Widawsky wrote:
On Sat, Feb 22, 2014 at 01:37:16PM +, Chris Wilson wrote:
On Mon, Feb 17, 2014 at 07:01:44PM -0800, Ben Widawsky wrote:
The names of the struct members for RPS
On Tue, Mar 18, 2014 at 05:05:45PM -0700, Ben Widawsky wrote:
On Thu, Mar 13, 2014 at 11:57:00AM -0300, Rodrigo Vivi wrote:
From: Chris Wilson ch...@chris-wilson.co.uk
The idea of printing objects used by each process is to judge how each
process is using them. This means that we need to
On Wed, Mar 19, 2014 at 1:41 AM, Ben Widawsky
benjamin.widaw...@intel.com 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
On Wed, Mar 19, 2014 at 2:54 AM, Ben Widawsky b...@bwidawsk.net 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 s...@canb.auug.org.au wrote:
Caused by commit a25ca17c1eac (drm/i915: Do not dereference pointers
from
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 ch...@chris-wilson.co.uk
Date: Thu Mar 13 12:00:29 2014
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
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 paulo.r.zan...@intel.com
Instead of trying to clear it again. It should already be masked and
disabled and zeroed at preinstall/uninstall.
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 paulo.r.zan...@intel.com
Hi
This is basically a rebase of [PATCH 00/19] ILK+ interrupt improvements,
which
was sent to the mailing list
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 james.aus...@intel.com
Signed-off-by: Ben Widawsky b...@bwidawsk.net
On Tue, Mar 18, 2014 at 01:53:56PM -0700, Siva Chandra wrote:
On Tue, Mar 18, 2014 at 1:06 PM, Jesse Barnes jbar...@virtuousgeek.org
wrote:
On Tue, 18 Mar 2014 12:51:07 -0700
Siva Chandra sivachan...@chromium.org wrote:
This property helps one turn PSR on and off via xrandr.
The
On Tue, 18 Mar 2014, Daniel Vetter dan...@ffwll.ch 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 ch...@chris-wilson.co.uk
We have reports of heavy screen corruption if we try to use the
On Wed, Mar 19, 2014 at 03:31:41AM +, Chang, Junxiao wrote:
Reviewed-by: Junxiao Chang junxiao.ch...@intel.com
Queued for -next, thanks for the patchreview.
-Daniel
Thanks,
Junxiao
-Original Message-
From: Dave Airlie [mailto:airl...@gmail.com]
Sent: Wednesday, March 19,
From: Tvrtko Ursulin tvrtko.ursu...@intel.com
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
From: Tvrtko Ursulin tvrtko.ursu...@intel.com
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
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
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
---
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
---
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 damien.lesp...@intel.com
---
qf | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/qf b/qf
index
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
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
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. Those are
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 jbar...@virtuousgeek.org
wrote:
On Tue, 18 Mar 2014 12:51:07 -0700
Siva Chandra sivachan...@chromium.org wrote:
On Fri, 2014-03-07 at 20:08 -0300, Paulo Zanoni wrote:
From: Paulo Zanoni paulo.r.zan...@intel.com
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
On Fri, 2014-03-07 at 20:08 -0300, Paulo Zanoni wrote:
From: Paulo Zanoni paulo.r.zan...@intel.com
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,
On Wed, Mar 19, 2014 at 4:05 PM, Chris Wilson ch...@chris-wilson.co.uk 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
On Fri, 2014-03-07 at 20:08 -0300, Paulo Zanoni wrote:
From: Paulo Zanoni paulo.r.zan...@intel.com
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
On Wed, 19 Mar 2014, Daniel Vetter dan...@ffwll.ch 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 jbar...@virtuousgeek.org
wrote:
On Tue, 18 Mar 2014 12:51:07 -0700
Siva Chandra sivachan...@chromium.org wrote:
This
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 paulo.r.zan...@intel.com
Currently, when our driver becomes idle for i915.pc8_timeout (default:
5s) we enable PC8, so we save some power, but not
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 the
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 paulo.r.zan...@intel.com
Hi
This is basically a rebase of [PATCH 00/19]
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 paulo.r.zan...@intel.com
Instead of trying to clear it again. It should already
On Tue, 2014-03-18 at 14:59 +0200, Jani Nikula wrote:
From: Chris Wilson ch...@chris-wilson.co.uk
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,
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
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
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 that
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
Reviewed-by: Rodrigo Vivi rodrigo.v...@gmail.com
Signed-off-by: Ben Widawsky b...@bwidawsk.net
---
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
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
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
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
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
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 b...@bwidawsk.net
---
drivers/gpu/drm/i915/i915_drv.h | 1 +
drivers/gpu/drm/i915/intel_pm.c | 2 +-
2 files changed, 2
On Mon, Mar 17, 2014 at 07:43:35PM +, Rob Bradford wrote:
From: Rob Bradford r...@linux.intel.com
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
-
On Wed, Mar 19, 2014 at 01:45:46PM +, Chris Wilson wrote:
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
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:
43 matches
Mail list logo
