On Thu, Jun 19, 2014 at 3:47 AM, Alex Williamson
alex.william...@redhat.com wrote:
Finding some more specs... the MGGC0 register (50h) seems to indicate
the GTT stolen memory size is 2M, which sounds suspiciously like the 2M
that the RMRR is reporting. However, from the IvyBridge MMIO, Media
On Thu, Jun 19, 2014 at 12:13 AM, Volkin, Bradley D
bradley.d.vol...@intel.com wrote:
+void intel_lr_context_free(struct intel_context *ctx)
+{
+ int i;
+
+ for (i = 0; i I915_NUM_RINGS; i++) {
+ struct drm_i915_gem_object *ctx_obj = ctx-engine[i].obj;
+ if
From: Sagar Kamble sagar.a.kam...@intel.com
Signed-off-by: Sagar Kamble sagar.a.kam...@intel.com
Cc: Daniel Vetter daniel.vet...@ffwll.ch
Cc: Ville Syrjälä ville.syrj...@linux.intel.com
Cc: linux-...@vger.kernel.org (open list:DOCUMENTATION)
Cc: linux-ker...@vger.kernel.org (open list)
---
On Thu, Jun 19, 2014 at 12:38 AM, Konrad Zapalowicz
bergo.tor...@gmail.com wrote:
This commit add check for return value of init_ring_common() in the
init_render_ring(). Now, when failure is detected the error code is
propagated to the caller layer instead of being ignored.
I believe that
On 6/18/2014 10:32 PM, Damien Lespiau wrote:
On Wed, Jun 18, 2014 at 02:27:26PM +0530, sonika.jin...@intel.com wrote:
From: Sonika Jindal sonika.jin...@intel.com
Primary planes support 180 degree rotation. Expose the feature
through rotation drm property.
v2: Calculating linear/tiled
On Tue, Jun 10, 2014 at 06:21:35PM +0200, David Herrmann wrote:
Hi
On Thu, May 29, 2014 at 5:57 PM, Thomas Wood thomas.w...@intel.com wrote:
Introduce generic functions to register and unregister connectors. This
provides a common place to add and remove associated user space
interfaces.
On Thu, Jun 19, 2014 at 12:13:54PM +0530, Jindal, Sonika wrote:
On 6/18/2014 10:32 PM, Damien Lespiau wrote:
On Wed, Jun 18, 2014 at 02:27:26PM +0530, sonika.jin...@intel.com wrote:
From: Sonika Jindal sonika.jin...@intel.com
diff --git a/drivers/gpu/drm/i915/i915_dma.c
When using remap_pfn_range() from a fault handler, we are exposed to
races between concurrent faults. Rather than hitting a BUG, report the
error back to the caller, like vm_insert_pfn().
v2: Fix the pte address for unmapping along the error path.
v3: Report the error back and cleanup partial
On Wed, Jun 18, 2014 at 10:03:27PM +0200, Daniel Vetter wrote:
Just very cursory look at it, but this conflicts badly (well the
integration with the driver) with my frontbuffer tracking stuff. My idea
was to essentially hide all the fbc integration points we have sprinkled
all over behind that
On Wed, Jun 18, 2014 at 11:28:09PM +0200, Daniel Vetter wrote:
So from just a quick look we seem to have enough information to
accurately figure out whether a given gem bo is used as a frontbuffer
and where exactly: We have obj-pin_count as a first check with no
false negatives and only
On Wed, Jun 18, 2014 at 10:04:48PM +0300, ville.syrj...@linux.intel.com wrote:
From: Ville Syrjälä ville.syrj...@linux.intel.com
We're forgetting to unpin the last_context from the ggtt at GPU reset
time. This leads to the vma pin_count leaking at every reset if the
last context wasn't the
On 6/19/2014 12:37 PM, Daniel Vetter wrote:
On Thu, Jun 19, 2014 at 12:13:54PM +0530, Jindal, Sonika wrote:
On 6/18/2014 10:32 PM, Damien Lespiau wrote:
On Wed, Jun 18, 2014 at 02:27:26PM +0530, sonika.jin...@intel.com wrote:
From: Sonika Jindal sonika.jin...@intel.com
diff --git
On Thu, Jun 19, 2014 at 9:52 AM, Jindal, Sonika sonika.jin...@intel.com wrote:
No, this really should be done in
drm_fb_helper_restore_fbdev_mode_unlocked in drm_fb_helper.c. Well, in the
restore_fbdev_mode function in there. Once that's done and once omap is
also using the generic rotation
On Wed, Jun 18, 2014 at 05:16:39PM +0100, oscar.ma...@intel.com wrote:
From: Daniele Ceraolo Spurio daniele.ceraolospu...@intel.com
These tracepoints are useful for observing the creation and
destruction of Full PPGTTs.
Signed-off-by: Oscar Mateo oscar.ma...@intel.com
---
On 6/19/2014 1:25 PM, Daniel Vetter wrote:
On Thu, Jun 19, 2014 at 9:52 AM, Jindal, Sonika sonika.jin...@intel.com wrote:
No, this really should be done in
drm_fb_helper_restore_fbdev_mode_unlocked in drm_fb_helper.c. Well, in the
restore_fbdev_mode function in there. Once that's done and
On Thu, Jun 19, 2014 at 01:39:17PM +0530, Jindal, Sonika wrote:
On 6/19/2014 1:25 PM, Daniel Vetter wrote:
On Thu, Jun 19, 2014 at 9:52 AM, Jindal, Sonika sonika.jin...@intel.com
wrote:
No, this really should be done in
drm_fb_helper_restore_fbdev_mode_unlocked in drm_fb_helper.c. Well,
-Original Message-
From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of Daniel
Vetter
Sent: Wednesday, June 18, 2014 9:16 PM
To: Mateo Lozano, Oscar
Cc: intel-gfx@lists.freedesktop.org
Subject: Re: [Intel-gfx] [PATCH 06/53] drm/i915/bdw: Introduce one context
backing
-Original Message-
From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of Daniel
Vetter
Sent: Wednesday, June 18, 2014 9:17 PM
To: Mateo Lozano, Oscar
Cc: intel-gfx@lists.freedesktop.org
Subject: Re: [Intel-gfx] [PATCH 07/53] drm/i915/bdw: New file for Logical
Ring
-Original Message-
From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of Daniel
Vetter
Sent: Wednesday, June 18, 2014 9:19 PM
To: Mateo Lozano, Oscar
Cc: intel-gfx@lists.freedesktop.org
Subject: Re: [Intel-gfx] [PATCH 08/53] drm/i915/bdw: Macro for LRCs and
module option
-Original Message-
From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of Daniel
Vetter
Sent: Wednesday, June 18, 2014 9:25 PM
To: Mateo Lozano, Oscar
Cc: intel-gfx@lists.freedesktop.org
Subject: Re: [Intel-gfx] [PATCH 09/53] drm/i915/bdw: Initialization for
Logical Ring
-Original Message-
From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of Daniel
Vetter
Sent: Wednesday, June 18, 2014 9:50 PM
To: Mateo Lozano, Oscar
Cc: intel-gfx@lists.freedesktop.org
Subject: Re: [Intel-gfx] [PATCH 42/53] drm/i915/bdw: Make sure gpu reset
still works
We need this to avoid hitting the slowpath and ending up with a
presumed_offset == -1. Regression reported by PRTS, bisected to
commit eb36fc993d7ae1988c80ba5b767989059c91d0ec
Author: Chris Wilson ch...@chris-wilson.co.uk
AuthorDate: Mon Jun 16 10:49:16 2014 +0100
Commit: Chris Wilson
Hi Brad,
On 06/18/2014 05:36 PM, bradley.d.vol...@intel.com wrote:
From: Brad Volkin bradley.d.vol...@intel.com
This adds a small module for managing a pool of batch buffers.
The only current use case is for the command parser, as described
in the kerneldoc in the patch. The code is simple,
-Original Message-
From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of Daniel
Vetter
Sent: Wednesday, June 18, 2014 10:01 PM
To: Mateo Lozano, Oscar
Cc: intel-gfx@lists.freedesktop.org
Subject: Re: [Intel-gfx] [PATCH 53/53] !UPSTREAM: drm/i915: Use MMIO
flips
On
Originally the reason to probe ISA bridge instead of Dev31:Fun0
is to make graphics device passthrough work easy for VMM, that
only need to expose ISA bridge to let driver know the real
hardware underneath. This is a requirement from virtualization
team. Especially in that virtualized
On Thu, Jun 19, 2014 at 11:50 AM, Mateo Lozano, Oscar
oscar.ma...@intel.com wrote:
-Original Message-
From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of Daniel
Vetter
Sent: Wednesday, June 18, 2014 10:01 PM
To: Mateo Lozano, Oscar
Cc: intel-gfx@lists.freedesktop.org
On Thu, Jun 19, 2014 at 01:22:25PM +0530, Jindal, Sonika wrote:
I see that in omap driver too it is done in lastclose of the driver. Also,
from driver fbdev_restore is only called during lastclose.
Again I don't have more knowledge on this.
Can we keep it here in this lastclose function to
On Thu, Jun 19, 2014 at 11:23 AM, Mateo Lozano, Oscar
oscar.ma...@intel.com wrote:
-static bool hw_context_enabled(struct drm_device *dev)
+static bool contexts_enabled(struct drm_device *dev)
{
- return to_i915(dev)-hw_context_size;
+ struct drm_i915_private *dev_priv =
-Original Message-
From: daniel.vet...@ffwll.ch [mailto:daniel.vet...@ffwll.ch] On Behalf Of
Daniel Vetter
Sent: Thursday, June 19, 2014 11:08 AM
To: Mateo Lozano, Oscar
Cc: intel-gfx@lists.freedesktop.org
Subject: Re: [Intel-gfx] [PATCH 09/53] drm/i915/bdw: Initialization for
On Thu, Jun 19, 2014 at 09:50:33AM +, Mateo Lozano, Oscar wrote:
-Original Message-
From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of Daniel
Vetter
Sent: Wednesday, June 18, 2014 10:01 PM
To: Mateo Lozano, Oscar
Cc: intel-gfx@lists.freedesktop.org
Subject:
Signed-off-by: Damien Lespiau damien.lesp...@intel.com
---
include/drm/i915_drm.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/drm/i915_drm.h b/include/drm/i915_drm.h
index 980dbf8..8eb0cb3 100644
--- a/include/drm/i915_drm.h
+++ b/include/drm/i915_drm.h
@@ -722,7
Cc: Bradley Volkin bradley.d.vol...@intel.com
Signed-off-by: Damien Lespiau damien.lesp...@intel.com
---
include/drm/i915_drm.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/include/drm/i915_drm.h b/include/drm/i915_drm.h
index 2f4eb8c..980dbf8 100644
--- a/include/drm/i915_drm.h
+++
-Original Message-
From: Chris Wilson [mailto:ch...@chris-wilson.co.uk]
Sent: Thursday, June 19, 2014 11:14 AM
To: Mateo Lozano, Oscar
Cc: Daniel Vetter; intel-gfx@lists.freedesktop.org
Subject: Re: [Intel-gfx] [PATCH 53/53] !UPSTREAM: drm/i915: Use MMIO
flips
On Thu, Jun 19,
On Thu, Jun 19, 2014 at 12:10 PM, Mateo Lozano, Oscar
oscar.ma...@intel.com wrote:
So green light to the enum idea? It´ll look better than the current
dev_priv-hw_context_size + dev_priv-lrc_enabled and I can send it early as
prep-work...
Yeah if you like it I'm ok with it, so please go
On Thu, Jun 19, 2014 at 12:07 PM, Damien Lespiau
damien.lesp...@intel.com wrote:
On Thu, Jun 19, 2014 at 01:22:25PM +0530, Jindal, Sonika wrote:
I see that in omap driver too it is done in lastclose of the driver. Also,
from driver fbdev_restore is only called during lastclose.
Again I don't
-Original Message-
From: Volkin, Bradley D
Sent: Wednesday, June 18, 2014 10:39 PM
To: Mateo Lozano, Oscar
Cc: intel-gfx@lists.freedesktop.org
Subject: Re: [Intel-gfx] [PATCH 04/53] drm/i915: Extract ringbuffer destroy
make alloc outside accesible
On Fri, Jun 13, 2014 at
-Original Message-
From: Volkin, Bradley D
Sent: Thursday, June 19, 2014 1:04 AM
To: Mateo Lozano, Oscar
Cc: intel-gfx@lists.freedesktop.org
Subject: Re: [Intel-gfx] [PATCH 19/53] drm/i915: Extract pipe control fini
make init outside accesible
On Fri, Jun 13, 2014 at 08:37:37AM
On Thu, Jun 19, 2014 at 10:52 AM, Mateo Lozano, Oscar
oscar.ma...@intel.com wrote:
v2: Leave the old backing object pointer behind. Daniel Vetter
suggested using a union, but it makes more sense to keep render_obj as
a NULL pointer behind, to make sure no one uses it incorrectly when
On Wed, Feb 26, 2014 at 04:41:41PM +, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin tvrtko.ursu...@intel.com
Allow userptr objects to be created and used via libdrm_intel.
At the moment tiling and mapping to GTT aperture is not supported
due hardware limitations across different
On Thu, Jun 19, 2014 at 12:13:20PM +0100, Damien Lespiau wrote:
On Wed, Feb 26, 2014 at 04:41:41PM +, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin tvrtko.ursu...@intel.com
Allow userptr objects to be created and used via libdrm_intel.
At the moment tiling and mapping to GTT aperture
Chris Wilson wrote:
When using remap_pfn_range() from a fault handler, we are exposed to
races between concurrent faults. Rather than hitting a BUG, report the
error back to the caller, like vm_insert_pfn().
v2: Fix the pte address for unmapping along the error path.
v3: Report the error
On Thu, Jun 19, 2014 at 02:50:18PM +0300, Kirill A. Shutemov wrote:
+ if (err) {
untrack_pfn(vma, pfn, PAGE_ALIGN(size));
+ if (err != -EBUSY)
+ zap_page_range_single(vma, addr, size, NULL);
Hm. If I read it correctly, you zap whole range, not
From: Deepak S deepa...@linux.intel.com
We might be leaving the GPU Frequency (and thus vnn) high during the suspend.
Force gt to move to lowest freq while suspending.
v2: Fixed typo in commit message (Deepak)
v3: Force gt to lowest freq in suspend_gt_powersave (Daniel)
Signed-off-by: Deepak S
On Fri, Jun 20, 2014 at 1:59 PM, deepa...@linux.intel.com wrote:
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 2043c4b..6bbb90b 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -4881,6 +4881,9 @@ void
From: Rob Bradford r...@linux.intel.com
The aim is that this is functionally equivalent to using the
I915_GEM_MMAP ioctl.
v2: Add aperture check limit, limit to SNB+ and improve error handling.
v3 (anderco): Map without using the GTT.
Signed-off-by: Rob Bradford r...@linux.intel.com
On Thu, Jun 19, 2014 at 03:34:34PM +0300, Ander Conselvan de Oliveira wrote:
From: Rob Bradford r...@linux.intel.com
The aim is that this is functionally equivalent to using the
I915_GEM_MMAP ioctl.
v2: Add aperture check limit, limit to SNB+ and improve error handling.
v3 (anderco):
So these are the guts of the new beast. This tracks when a frontbuffer
gets invalidated (due to frontbuffer rendering) and hence should be
constantly scaned out, and when it's flushed again and can be
compressed/one-shot-upload.
Rules for flushing are simple: The frontbuffer needs one more full
From: Sonika Jindal sonika.jin...@intel.com
Reset rotation to 0 wherever applicable
Cc: dri-de...@lists.freedesktop.org
Signed-off-by: Sonika Jindal sonika.jin...@intel.com
---
drivers/gpu/drm/drm_fb_helper.c |8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git
On Thu, Jun 19, 2014 at 03:34:34PM +0300, Ander Conselvan de Oliveira wrote:
From: Rob Bradford r...@linux.intel.com
The aim is that this is functionally equivalent to using the
I915_GEM_MMAP ioctl.
v2: Add aperture check limit, limit to SNB+ and improve error handling.
v3 (anderco):
Chris Wilson wrote:
On Thu, Jun 19, 2014 at 02:50:18PM +0300, Kirill A. Shutemov wrote:
+ if (err) {
untrack_pfn(vma, pfn, PAGE_ALIGN(size));
+ if (err != -EBUSY)
+ zap_page_range_single(vma, addr, size, NULL);
Hm. If I read it correctly, you zap
On Thu, Jun 19, 2014 at 02:41:27PM +0200, Daniel Vetter wrote:
@@ -3626,6 +3628,8 @@ i915_gem_object_set_to_gtt_domain(struct
drm_i915_gem_object *obj, bool write)
obj-dirty = 1;
}
+ intel_fb_obj_invalidate(obj, NULL);
We should only invalidate when we start
On Wed, 2014-06-18 at 09:52 -0700, Jesse Barnes wrote:
We don't need to uninstall the full handler, simply disabling interrupts
ought to be enough.
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
Reviewed-by: Imre Deak imre.d...@intel.com
For follow-up:
I agree with Daniel that we
On Thu, Jun 19, 2014 at 03:57:46PM +0300, Kirill A. Shutemov wrote:
Chris Wilson wrote:
On Thu, Jun 19, 2014 at 02:50:18PM +0300, Kirill A. Shutemov wrote:
+ if (err) {
untrack_pfn(vma, pfn, PAGE_ALIGN(size));
+ if (err != -EBUSY)
+
On Wed, 2014-06-18 at 09:52 -0700, Jesse Barnes wrote:
We should be taking the right power well refs these days, so this
shouldn't be necessary. It also gets in the way of re-using these
routines for S0iX states, as those need all the power saving features
enabled.
Signed-off-by: Jesse
On Thu, Jun 19, 2014 at 02:02:26PM +0100, Chris Wilson wrote:
On Thu, Jun 19, 2014 at 02:41:27PM +0200, Daniel Vetter wrote:
@@ -3626,6 +3628,8 @@ i915_gem_object_set_to_gtt_domain(struct
drm_i915_gem_object *obj, bool write)
obj-dirty = 1;
}
+
Chris Wilson wrote:
On Thu, Jun 19, 2014 at 03:57:46PM +0300, Kirill A. Shutemov wrote:
One possible option is to create a variant of remap_pfn_range() which will
return how many PTEs it was able to setup, before hitting the !pte_none().
Caller will decide what to do with partially filled
-Original Message-
From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of Daniel
Vetter
Sent: Wednesday, June 18, 2014 8:51 PM
To: Mateo Lozano, Oscar
Cc: intel-gfx@lists.freedesktop.org
Subject: Re: [Intel-gfx] [PATCH 1/8] drm/i915: Get rid of the synchronous flag
in
So these are the guts of the new beast. This tracks when a frontbuffer
gets invalidated (due to frontbuffer rendering) and hence should be
constantly scaned out, and when it's flushed again and can be
compressed/one-shot-upload.
Rules for flushing are simple: The frontbuffer needs one more full
-Original Message-
From: Chris Wilson [mailto:ch...@chris-wilson.co.uk]
Sent: Thursday, June 19, 2014 8:57 AM
To: Mateo Lozano, Oscar
Cc: intel-gfx@lists.freedesktop.org
Subject: Re: [Intel-gfx] [PATCH 1/3] drm/i915: Add ppgtt init/release trace
points
On Wed, Jun 18, 2014 at
On Thu, 2014-06-19 at 08:10 +0200, Daniel Vetter wrote:
On Thu, Jun 19, 2014 at 3:47 AM, Alex Williamson
alex.william...@redhat.com wrote:
Finding some more specs... the MGGC0 register (50h) seems to indicate
the GTT stolen memory size is 2M, which sounds suspiciously like the 2M
that the
On Thursday 19 June 2014 06:04 PM, Daniel Vetter wrote:
On Fri, Jun 20, 2014 at 1:59 PM, deepa...@linux.intel.com wrote:
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 2043c4b..6bbb90b 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++
Hm, that's a bit unexpected. You are on a gen4 device, which means
we'll return the right error in the same function after a few more
register writes. But those are harmless.
On gen5+ we do more (call the pipe_control setup code), which could
potentially clobber the error code. So your patch
On Thu, Jun 19, 2014 at 4:35 PM, Daniel Vetter daniel.vet...@ffwll.ch wrote:
The actual bug we seem to have is blowing up on the ggtt_unpin in
context_fini. Which is doubly-impossible: Gen4 doesn't have hw
contexts, so should have dctx-obj == NULL. And ring init failures
fail earlier so
On Thu, Jun 19, 2014 at 4:29 PM, Alex Williamson
alex.william...@redhat.com wrote:
But is there a way for software to discover its location from the
device? If so, then I think we can recreate all the identity maps we'd
need for a guest from the device. If not, then we'd need to figure out
From: Deepak S deepa...@linux.intel.com
We might be leaving the GPU Frequency (and thus vnn) high during the suspend.
Force gt to move to lowest freq while suspending.
v2: Fixed typo in commit message (Deepak)
v3: Force gt to lowest freq in suspend_gt_powersave (Daniel)
v4: Add GPU min freq
From: Tvrtko Ursulin tvrtko.ursu...@intel.com
Signed-off-by: Tvrtko Ursulin tvrtko.ursu...@intel.com
---
include/drm/i915_drm.h | 16
1 file changed, 16 insertions(+)
diff --git a/include/drm/i915_drm.h b/include/drm/i915_drm.h
index 2f4eb8c..bf75596 100644
---
From: Tvrtko Ursulin tvrtko.ursu...@intel.com
Allow userptr objects to be created and used via libdrm_intel.
At the moment tiling and mapping to GTT aperture is not supported
due hardware limitations across different generations and uncertainty
about its usefulness.
v2: Improved error handling
On Thu, Jun 19, 2014 at 04:01:59PM +0200, Daniel Vetter wrote:
diff --git a/drivers/gpu/drm/i915/intel_overlay.c
b/drivers/gpu/drm/i915/intel_overlay.c
index 99b6c142a095..1c002196ed47 100644
--- a/drivers/gpu/drm/i915/intel_overlay.c
+++ b/drivers/gpu/drm/i915/intel_overlay.c
@@ -787,6
On 19 June 2014 15:22, Mateo Lozano, Oscar oscar.ma...@intel.com wrote:
-Original Message-
From: Chris Wilson [mailto:ch...@chris-wilson.co.uk]
Sent: Thursday, June 19, 2014 8:57 AM
To: Mateo Lozano, Oscar
Cc: intel-gfx@lists.freedesktop.org
Subject: Re: [Intel-gfx] [PATCH
On Thu, Jun 19, 2014 at 05:36:55PM +0200, Joerg Roedel wrote:
Hey Chris,
recently I had a look at i915_gem_userptr.c in order to extend the
mmu_notifier call-backs implemented there. My goal is to implement the
change_pte call-back where it is necessary to get rid of it being
wrapped
On Thu, Jun 19, 2014 at 02:00:24PM +, Mateo Lozano, Oscar wrote:
-Original Message-
From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of Daniel
Vetter
Sent: Wednesday, June 18, 2014 8:51 PM
To: Mateo Lozano, Oscar
Cc: intel-gfx@lists.freedesktop.org
Subject:
On Thu, Jun 19, 2014 at 04:41:50PM +0100, Daniele Ceraolo Spurio wrote:
Regarding the client, my idea is to print the task pid and/or the
process name; would that look good for you?
Going off an tangent. We have a problem with file-pid. In the dri3,
or rendernodes, future all pids belong to the
On Thu, Jun 19, 2014 at 04:25:55PM +0300, Imre Deak wrote:
On Wed, 2014-06-18 at 09:52 -0700, Jesse Barnes wrote:
We should be taking the right power well refs these days, so this
shouldn't be necessary. It also gets in the way of re-using these
routines for S0iX states, as those need all
Hi Robert,
This information is helpful. I am able to query the frequencies as you
mentioned. My primary interest though is in getting support added to
intel_gpu_top. It seems to me that intel_gpu_top has been coded to support
providing clock frequency data for a subset of Intel GPUs and that
On 06/19, Daniel Vetter wrote:
On Thu, Jun 19, 2014 at 12:38 AM, Konrad Zapalowicz
bergo.tor...@gmail.com wrote:
This commit add check for return value of init_ring_common() in the
init_render_ring(). Now, when failure is detected the error code is
propagated to the caller layer instead of
On 06/19, Daniel Vetter wrote:
On Thu, Jun 19, 2014 at 4:35 PM, Daniel Vetter daniel.vet...@ffwll.ch wrote:
The actual bug we seem to have is blowing up on the ggtt_unpin in
context_fini. Which is doubly-impossible: Gen4 doesn't have hw
contexts, so should have dctx-obj == NULL. And ring
Hey Chris,
recently I had a look at i915_gem_userptr.c in order to extend the
mmu_notifier call-backs implemented there. My goal is to implement the
change_pte call-back where it is necessary to get rid of it being
wrapped mn_invalidate_range_start/end() calls (for the reason see
commit
This commit add check for return value of init_ring_common() in the
init_render_ring(). Now, when failure is detected the error code is
propagated to the caller layer instead of being ignored.
I believe that this fix will have a positive impact on the oops that
I hit recently and which starts
Is this a known problem?
On my T540p, occasionally the display will go black and then be
completely locked. One time when this happened, the display started
glitching and tearing (like what you might see if an analog display had
a loose connector and it was being wiggled) when the system locked
On Wed, Jun 18, 2014 at 12:14:55PM -0400, Theodore Ts'o wrote:
Is this a known problem?
On my T540p, occasionally the display will go black and then be
completely locked. One time when this happened, the display started
glitching and tearing (like what you might see if an analog display had
On Thu, Jun 19, 2014 at 04:12:08PM +0100, Chris Wilson wrote:
On Thu, Jun 19, 2014 at 04:01:59PM +0200, Daniel Vetter wrote:
diff --git a/drivers/gpu/drm/i915/intel_overlay.c
b/drivers/gpu/drm/i915/intel_overlay.c
index 99b6c142a095..1c002196ed47 100644
---
On Thu, Jun 19, 2014 at 11:31:53AM +0100, Damien Lespiau wrote:
Cc: Bradley Volkin bradley.d.vol...@intel.com
Signed-off-by: Damien Lespiau damien.lesp...@intel.com
Thanks for taking care of this Damien.
Reviewed-by: Brad Volkin bradley.d.vol...@intel.com
---
include/drm/i915_drm.h | 1 +
-Original Message-
From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf
Of Chris Wilson
Sent: Thursday, June 19, 2014 8:47 AM
To: ville.syrj...@linux.intel.com
Cc: intel-gfx@lists.freedesktop.org
Subject: Re: [Intel-gfx] [PATCH] drm/i915: Unpin last_context at
This commit add check for return value of init_ring_common() in the
init_render_ring(). Now, when failure is detected the error code is
propagated to the caller instead of being ignored.
Signed-off-by: Konrad Zapalowicz bergo.tor...@gmail.com
---
v2:
- remove from commit message references
On 06/18/14 23:16, Stephen Rothwell wrote:
Hi all,
The powerpc allyesconfig is again broken more than usual.
Changes since 20140618:
on i386:
CONFIG_ACPI is not enabled.
CC drivers/gpu/drm/i915/i915_drv.o
../drivers/gpu/drm/i915/i915_drv.c: In function 'i915_drm_freeze':
On Thu, Jun 19, 2014 at 09:28:08AM -0700, Volkin, Bradley D wrote:
On Thu, Jun 19, 2014 at 11:31:53AM +0100, Damien Lespiau wrote:
Cc: Bradley Volkin bradley.d.vol...@intel.com
Signed-off-by: Damien Lespiau damien.lesp...@intel.com
Thanks for taking care of this Damien.
Reviewed-by:
On Thu, Jun 19, 2014 at 02:48:29AM -0700, Tvrtko Ursulin wrote:
Hi Brad,
On 06/18/2014 05:36 PM, bradley.d.vol...@intel.com wrote:
From: Brad Volkin bradley.d.vol...@intel.com
This adds a small module for managing a pool of batch buffers.
The only current use case is for the command
On Thu, Jun 19, 2014 at 03:48:34PM +0100, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin tvrtko.ursu...@intel.com
Signed-off-by: Tvrtko Ursulin tvrtko.ursu...@intel.com
Reviewed-by: Damien Lespiau damien.lesp...@intel.com
And pushed, thanks for the patch.
--
Damien
---
Jani, can you review this one? It's still needed for us to conform to
the eDP timing spec.
Thanks,
Jesse
On Mon, 31 Mar 2014 11:13:56 -0700
Jesse Barnes jbar...@virtuousgeek.org wrote:
With the new checks in place, we can see we're doing things backwards,
so fix them up per the spec.
On Thu, Jun 19, 2014 at 07:07:15PM +0200, Konrad Zapalowicz wrote:
This commit add check for return value of init_ring_common() in the
init_render_ring(). Now, when failure is detected the error code is
propagated to the caller instead of being ignored.
Signed-off-by: Konrad Zapalowicz
We are already using the size to determine whether or not to free the
object, so there is no functional change there. Almost everything else
has changed to static allocations of the drm_mm_node too.
Aside from bringing this inline with much of our other code, this makes
error paths slightly
Right now, there is no threshold (0 means fail, 1 means 1:1 compression
limit). This is to split the function/non-functional change of the next
patch.
The next patch will start to attempt to reduce the amount of CFB space
we need for dire situations. It will be contained within this function.
This is one part in a few fixes needed to make FBC work with limited
stolen memory and large resolution displays. It is not the full
solution, but one (easy) step.
The patch is straight-forward, it attempts to check there will be room
for FBC before trying to reclaim
This modifies behavior
The GEN FBC unit provides the ability to set a low pass on frames it
attempts to compress. If a frame is less than a certain amount
compressibility (2:1, 4:1) it will not bother. This allows the driver to
reduce the size it requests out of stolen memory.
Unluckily, a few months ago, Ville
On Thu, Jun 19, 2014 at 10:35:44AM -0700, Volkin, Bradley D wrote:
On Thu, Jun 19, 2014 at 02:48:29AM -0700, Tvrtko Ursulin wrote:
Hi Brad,
On 06/18/2014 05:36 PM, bradley.d.vol...@intel.com wrote:
From: Brad Volkin bradley.d.vol...@intel.com
This adds a small module for
On Thu, Jun 19, 2014 at 12:06:13PM -0700, Ben Widawsky wrote:
This is one part in a few fixes needed to make FBC work with limited
stolen memory and large resolution displays. It is not the full
solution, but one (easy) step.
The patch is straight-forward, it attempts to check there will be
On Thu, Jun 19, 2014 at 08:28:11PM +0100, Chris Wilson wrote:
On Thu, Jun 19, 2014 at 12:06:13PM -0700, Ben Widawsky wrote:
This is one part in a few fixes needed to make FBC work with limited
stolen memory and large resolution displays. It is not the full
solution, but one (easy) step.
On Thu, Jun 19, 2014 at 3:10 PM, Chris Healy cphe...@gmail.com wrote:
Hi Robert,
This information is helpful. I am able to query the frequencies as you
mentioned. My primary interest though is in getting support added to
intel_gpu_top. It seems to me that intel_gpu_top has been coded to
On Thu, Jun 19, 2014 at 09:33:44PM +0100, Bragg, Robert wrote:
On Thu, Jun 19, 2014 at 3:10 PM, Chris Healy [1]cphe...@gmail.com
wrote:
Hi Robert,
This information is helpful. I am able to query the frequencies as
you mentioned. My primary interest though is in getting
On 20 June 2014 02:09, Daniel Vetter dan...@ffwll.ch wrote:
On Wed, Jun 18, 2014 at 12:14:55PM -0400, Theodore Ts'o wrote:
Is this a known problem?
On my T540p, occasionally the display will go black and then be
completely locked. One time when this happened, the display started
glitching
1 - 100 of 102 matches
Mail list logo
