On Thursday 12 June 2014 03:02 PM, Daniel Vetter wrote:
Adding Deepak for testing, this hopefully alleviates the bad
side-effects of the gpu booster he's seeing.
-Daniel
On Thu, Jun 12, 2014 at 11:28 AM, Chris Wilson wrote:
Make the assumption that media workloads are not as latency sensitive
On Mon, May 26, 2014 at 05:26:47PM +0300, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> Add a flag to drm_device which will cause the vblank code to bypass the
> disable timer and always disable the vblank interrupt immediately when
> the last reference is dropped.
>
> Signed-of
On 20 June 2014 02:09, Daniel Vetter 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 and te
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 get
On Thu, Jun 19, 2014 at 3:10 PM, Chris Healy 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 support
> prov
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) ste
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
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
> > >
> > > This adds a small module for managing a pool
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 actually
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 orig
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.
Sig
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 simple
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
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 wrote:
> With the new checks in place, we can see we're doing things backwards,
> so fix them up per the spec.
>
> Signed-off-by: Jesse Barn
On Thu, Jun 19, 2014 at 03:48:34PM +0100, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin
>
> Signed-off-by: Tvrtko Ursulin
Reviewed-by: Damien Lespiau
And pushed, thanks for the patch.
--
Damien
> ---
> include/drm/i915_drm.h | 16
> 1 file changed, 16 insertions(+)
>
> di
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
> >
> > This adds a small module for managing a pool of batch buffers.
> > The only current use case is for the command parser, as desc
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
> > Signed-off-by: Damien Lespiau
>
> Thanks for taking care of this Damien.
>
> Reviewed-by: Brad Volkin
Thanks for the review, pushed b
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':
..
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
---
v2:
- remove from commit message references to the Oops.
drivers/
On Thu, Jun 19, 2014 at 11:31:53AM +0100, Damien Lespiau wrote:
> Cc: Bradley Volkin
> Signed-off-by: Damien Lespiau
Thanks for taking care of this Damien.
Reviewed-by: Brad Volkin
> ---
> include/drm/i915_drm.h | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/include/drm/i915_drm.h
> -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_conte
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
> > --- a/drivers/gpu/drm/i915
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
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 6bdb913f).
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 u
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 th
On 06/19, Daniel Vetter wrote:
> On Thu, Jun 19, 2014 at 12:38 AM, 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 layer instead of being ignored.
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 when
On 06/19, Daniel Vetter wrote:
> On Thu, Jun 19, 2014 at 4:35 PM, Daniel Vetter 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
> >
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 nee
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 t
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
>
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 m
On 19 June 2014 15:22, Mateo Lozano, Oscar 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 1/3] drm/i91
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,
From: Tvrtko Ursulin
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 in feature detection per
From: Tvrtko Ursulin
Signed-off-by: Tvrtko Ursulin
---
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
--- a/include/drm/i915_drm.h
+++ b/include/drm/i915_drm.h
@@ -223,6 +
From: Deepak S
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 set _after_ we've cancelled
On Thu, Jun 19, 2014 at 4:29 PM, Alex Williamson
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
> some IOMMU API extension
On Thu, Jun 19, 2014 at 4:35 PM, Daniel Vetter 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 shouldn't even hit the 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 looks
On Thursday 19 June 2014 06:04 PM, Daniel Vetter wrote:
On Fri, Jun 20, 2014 at 1:59 PM, 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 +
On Thu, 2014-06-19 at 08:10 +0200, Daniel Vetter wrote:
> On Thu, Jun 19, 2014 at 3:47 AM, Alex Williamson
> 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.
> -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, 201
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
up
> -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
>
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 fi
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;
> > }
> >
> > + intel_
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: Jess
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 don't need to uninstall the full handler, simply disabling interrupts
> ought to be enough.
>
> Signed-off-by: Jesse Barnes
Reviewed-by: Imre Deak
For follow-up:
I agree with Daniel that we should add a new helper and use it instead
o
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
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 co
On Thu, Jun 19, 2014 at 03:34:34PM +0300, Ander Conselvan de Oliveira wrote:
> From: Rob Bradford
>
> 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 usi
From: Sonika Jindal
Reset rotation to 0 wherever applicable
Cc: dri-de...@lists.freedesktop.org
Signed-off-by: Sonika Jindal
---
drivers/gpu/drm/drm_fb_helper.c |8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_f
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
up
On Thu, Jun 19, 2014 at 03:34:34PM +0300, Ander Conselvan de Oliveira wrote:
> From: Rob Bradford
>
> 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 usi
From: Rob Bradford
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
Signed-off-by: Ander Conselvan de Oliveira
---
d
On Fri, Jun 20, 2014 at 1:59 PM, 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 intel_suspend_gt_powersave(struct
From: Deepak S
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
---
drivers/gpu/drm/i9
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 ran
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 err
On Fri, Jun 06, 2014 at 08:37:48PM +0300, Imre Deak wrote:
> On Fri, 2014-06-06 at 19:19 +0200, Daniel Vetter wrote:
> > On Thu, Jun 05, 2014 at 08:31:47PM +0300, Imre Deak wrote:
> > > Jesse noticed that the punit communication needed to query the VLV power
> > > well status can cause substantial
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
> >
> > Allow userptr objects to be created and used via libdrm_intel.
> >
> > At the moment tiling and mapping to GTT aperture is not suppor
On Wed, Feb 26, 2014 at 04:41:41PM +, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin
>
> 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
On Thu, Jun 19, 2014 at 10:52 AM, Mateo Lozano, Oscar
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
>> > Execlists are e
> -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
> -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 a
On Thu, Jun 19, 2014 at 12:07 PM, Damien Lespiau
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 have more kno
On Thu, Jun 19, 2014 at 12:10 PM, Mateo Lozano, Oscar
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 ahead.
-Daniel
--
Da
> -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
Signed-off-by: Damien Lespiau
---
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 +722,7 @@ struct drm_i915_
Cc: Bradley Volkin
Signed-off-by: Damien Lespiau
---
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
+++ b/include/drm/i915_drm.h
@@ -337,6 +337,7 @@ typedef stru
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
> -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 11:23 AM, Mateo Lozano, Oscar
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 = to_i915(dev);
>>
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 func
On Thu, Jun 19, 2014 at 11:50 AM, 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: R
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 environments,
> -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
>
Hi Brad,
On 06/18/2014 05:36 PM, bradley.d.vol...@intel.com wrote:
From: Brad Volkin
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, but separating
it out makes
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
AuthorDate: Mon Jun 16 10:49:16 2014 +0100
Commit: Chris Wilson
CommitDate: Mon Jun 16 10:5
> -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
> -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
> Logica
> -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
> -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: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
> bac
On Wed, Jun 18, 2014 at 10:03:27PM +0200, Daniel Vetter wrote:
> On Wed, Jun 18, 2014 at 08:58:33PM +0300, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä
> >
> > This series rewrites the FBC code to actually work. It utilizes the
> > hardware tracking/nuking as much as possible, eg.
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
> >wrote:
> >>>No, this really should be done in
> >>>drm_fb_helper_restore_fbdev_mode_unlocked in drm_fb_helper.c. Well, in the
>
On 6/19/2014 1:25 PM, Daniel Vetter wrote:
On Thu, Jun 19, 2014 at 9:52 AM, Jindal, Sonika 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
On Wed, Jun 18, 2014 at 05:16:39PM +0100, oscar.ma...@intel.com wrote:
> From: Daniele Ceraolo Spurio
>
> These tracepoints are useful for observing the creation and
> destruction of Full PPGTTs.
>
> Signed-off-by: Oscar Mateo
> ---
> drivers/gpu/drm/i915/i915_gem_context.c | 5 +
> drive
On Thu, Jun 19, 2014 at 9:52 AM, Jindal, Sonika 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 properties (I thin
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
diff --git a/drivers/gpu/drm/i915/i915_dm
On Wed, Jun 18, 2014 at 10:04:48PM +0300, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> 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 ring default context. Furt
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 ne
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 t
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 rema
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
> >>diff --git a/drivers/gpu/drm/i915/i915_dma.c
> >>b/drivers/gpu/drm/i915/i915_dma
98 matches
Mail list logo
