On Tue, Nov 26, 2013 at 9:24 PM, Volkin, Bradley D
wrote:
[snip]
> Which "state setup stuff" are you referring to? Something specific in i-g-t
> or something
> more general?
The state setup 3D commands as opposed to doing actual rendering commands
(with 3D_PRIM). Just to have a bit more reali
On Wed, Dec 04, 2013 at 08:38:08AM +0800, Lv Zheng wrote:
> In Linux kernel, ACPICA is wrapped and safely exported by CONFIG_ACPI. So
> all external modules should depend on CONFIG_ACPI rather than using ACPICA
> header directly for stubbing. But if we moves inclusions
> into "#ifdef CONFIG_ACPI
On Wed, Dec 4, 2013 at 9:13 AM, Daniel Vetter wrote:
>> Ok, I'll look at the hw context code for buffer mgmt. For "purgeable", just
>> via the
>> madv field in the i915 gem object?
>
> Yeah, though I'd extract two tiny helpers (maybe shared with the madvise
> ioctl) to set an object to purgeable
[re-adding intel-gfx]
On Tue, Dec 3, 2013 at 5:05 PM, S, Deepak wrote:
> Hi Daniel/Chris,
>
> I spent some time in digging through the specs and also has chatted with
> couple of people. Below is my understanding of the FIFO.
>
> "On SB, Out of 64 FIFO Entries, 20 Entries will be used by HW and
On Thu, Nov 21, 2013 at 01:47:18PM -0200, Paulo Zanoni wrote:
> From: Paulo Zanoni
>
> Currently, PC8 is enabled at modeset_global_resources, which is called
> after intel_modeset_update_state. Due to this, there's a small race
> condition on the case where we start enabling PC8, then do a modese
* ville.syrj...@linux.intel.com wrote:
> v2: Rewrite to use the TOM-TSEG_SIZE-stolen_size and TOUD methods
I guess v2 is a reaction to my review feedback? I got no reply to my
mail from you so I'm not sure and I'd like to know whether all
feedback was addressed.
Thanks,
Ingo
___
Thanks Daniel.
-Original Message-
From: daniel.vet...@ffwll.ch [mailto:daniel.vet...@ffwll.ch] On Behalf Of
Daniel Vetter
Sent: Wednesday, December 4, 2013 2:10 PM
To: S, Deepak
Cc: Chris Wilson; intel-gfx
Subject: Re: [Intel-gfx] [PATCH v2] drm/i915/vlv: Update Wait for FIFO and wait
f
Whilst looking up the objects required for an execbuffer, an untimely
allocation failure in creating the vma results in the object being
unreferenced from two lists. The ownership during the lookup is meant to
be moved from the list of objects being looked to the vma, and this
double unreference up
It is useful to assert that if the object is bound, then it must have
its pages pinned to prevent the shrinker from reaping its backing store.
This is even more useful with the introduction of real-ppgtt whereupon
we may have the object bound into several vma, with each instance
pinning the backing
On Fri, 22 Nov 2013, Takashi Iwai wrote:
> I got kernel WARNINGs frequently on Haswell laptops complaining about
> invalid max DP link bw. With drm.debug=0x0e, it turned out that the
> obtained DPCD is utterly bogus when it happens:
> [drm:intel_dp_get_dpcd], DPCD: 4d 4d 4d 4d 4d 4d 4d 4d 4d 4d
At Wed, 04 Dec 2013 12:17:03 +0200,
Jani Nikula wrote:
>
> On Fri, 22 Nov 2013, Takashi Iwai wrote:
> > I got kernel WARNINGs frequently on Haswell laptops complaining about
> > invalid max DP link bw. With drm.debug=0x0e, it turned out that the
> > obtained DPCD is utterly bogus when it happens
[Dragging the discussion back to the public.]
I agree that the 20 fifo limit is fairly arbitrary and it's still
racy. Otoh that seems to be a bit that the hw engineers simply
fumbled, so I guess we don't have much choice here.
I've only merged the patch to dinq since there's no real report of
thi
On Wed, Dec 04, 2013 at 09:59:09AM +, Chris Wilson wrote:
> It is useful to assert that if the object is bound, then it must have
> its pages pinned to prevent the shrinker from reaping its backing store.
> This is even more useful with the introduction of real-ppgtt whereupon
> we may have the
Hi Daniel,
Sure, I don't have any contact with the hw engineer yet, I will try to get the
right contact asap.
Thanks
Deepak
-Original Message-
From: daniel.vet...@ffwll.ch [mailto:daniel.vet...@ffwll.ch] On Behalf Of
Daniel Vetter
Sent: Wednesday, December 4, 2013 4:37 PM
To: S, Deepa
On Tue, Dec 03, 2013 at 06:10:05PM +0100, Daniel Vetter wrote:
> On Mon, Dec 02, 2013 at 05:31:53PM +0200, Mika Kuoppala wrote:
> > We used to lean on active_list to handle the references
> > to batch objects. But there are useful cases when same,
> > albeit simple, batch can be executing on multip
As the rings may be processed and their requests deallocated in a
different order to the natural retirement during a reset,
/* Whilst this request exists, batch_obj will be on the
* active_list, and so will hold the active reference. Only when this
* request is retired will the the batch_obj be
On Wed, Dec 4, 2013 at 12:24 PM, Chris Wilson wrote:
> On Tue, Dec 03, 2013 at 06:10:05PM +0100, Daniel Vetter wrote:
>> On Mon, Dec 02, 2013 at 05:31:53PM +0200, Mika Kuoppala wrote:
>> > We used to lean on active_list to handle the references
>> > to batch objects. But there are useful cases whe
On Wed, Dec 04, 2013 at 01:08:56PM +0100, Daniel Vetter wrote:
> On Wed, Dec 4, 2013 at 12:24 PM, Chris Wilson
> wrote:
> > On Tue, Dec 03, 2013 at 06:10:05PM +0100, Daniel Vetter wrote:
> >> On Mon, Dec 02, 2013 at 05:31:53PM +0200, Mika Kuoppala wrote:
> >> > We used to lean on active_list to h
On Wed, Dec 04, 2013 at 11:37:09AM +, Chris Wilson wrote:
> As the rings may be processed and their requests deallocated in a
> different order to the natural retirement during a reset,
>
> /* Whilst this request exists, batch_obj will be on the
> * active_list, and so will hold the active re
On Tue, Nov 26, 2013 at 02:21:32PM +, Chris Wilson wrote:
> On Tue, Nov 26, 2013 at 04:14:33PM +0200, Mika Kuoppala wrote:
> > Doing it early prevents moving and relocating objects in vain
> > for contexts that won't get any GPU time.
> >
> > Reported-by: Chris Wilson
> > Signed-off-by: Mika
On Tue, Nov 26, 2013 at 09:26:17AM +0200, Mika Kuoppala wrote:
> to not run out of filedescs as some tests call gem_quiescent_gpu
> directly.
>
> Signed-off-by: Mika Kuoppala
Applied, thanks.
-Daniel
> ---
> lib/drmtest.c |1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/lib/drmtest
On Wed, Dec 04, 2013 at 01:18:42PM +0100, Daniel Vetter wrote:
> On Wed, Dec 04, 2013 at 11:37:09AM +, Chris Wilson wrote:
> > As the rings may be processed and their requests deallocated in a
> > different order to the natural retirement during a reset,
> >
> > /* Whilst this request exists,
DPIO name still using old name. Change it according to the driver name.
Signed-off-by: Chon Ming Lee
---
tools/quick_dump/vlv_dpio.txt | 104 +-
1 file changed, 51 insertions(+), 53 deletions(-)
diff --git a/tools/quick_dump/vlv_dpio.txt b/tools/quick_du
The extra parameter is for future platform.
Signed-off-by: Chon Ming Lee
---
lib/intel_dpio.c | 19 +++
lib/intel_gpu_tools.h | 4 ++--
tools/intel_dpio_read.c| 2 +-
tools/intel_dpio_write.c | 2 +-
tools/quick_dump/chipset.i | 4 ++--
In i915_gem_reset_ring_lists we reset requests and move objects to the
inactive list. Which means if the active list is the last one to hold a
reference, the object will disappear.
Now the problem is that we do this per-ring, and not in the order that the
objects would have been retired if the gpu
2013/12/4 Daniel Vetter :
> On Thu, Nov 21, 2013 at 01:47:18PM -0200, Paulo Zanoni wrote:
>> From: Paulo Zanoni
>>
>> Currently, PC8 is enabled at modeset_global_resources, which is called
>> after intel_modeset_update_state. Due to this, there's a small race
>> condition on the case where we star
On Wed, Dec 4, 2013 at 2:44 PM, Paulo Zanoni wrote:
> 2013/12/4 Daniel Vetter :
>> On Thu, Nov 21, 2013 at 01:47:18PM -0200, Paulo Zanoni wrote:
>>> From: Paulo Zanoni
>>>
>>> Currently, PC8 is enabled at modeset_global_resources, which is called
>>> after intel_modeset_update_state. Due to this,
From: Mika Kuoppala
This triggers use after free oops on request->batch_obj when
going through the rings and setting reset status on requests,
after a gpu hang.
v2: Streamlined the test and added comments (Daniel)
Signed-off-by: Mika Kuoppala
---
tests/gem_reset_stats.c | 62 +++
Inorder to serialise the closing of the file descriptor and its
subsequent release of client requests with i915_gem_free_request(), we
need to hold the struct_mutex in i915_gem_release(). Failing to do so
has the potential to trigger an OOPS, later with a use-after-free.
Testcase: igt/gem_close_ra
On Wed, Dec 04, 2013 at 10:08:14AM +0100, Ingo Molnar wrote:
>
> * ville.syrj...@linux.intel.com wrote:
>
> > v2: Rewrite to use the TOM-TSEG_SIZE-stolen_size and TOUD methods
>
> I guess v2 is a reaction to my review feedback? I got no reply to my
> mail from you so I'm not sure and I'd like
* Ville Syrjälä wrote:
> On Wed, Dec 04, 2013 at 10:08:14AM +0100, Ingo Molnar wrote:
> >
> > * ville.syrj...@linux.intel.com wrote:
> >
> > > v2: Rewrite to use the TOM-TSEG_SIZE-stolen_size and TOUD methods
> >
> > I guess v2 is a reaction to my review feedback? I got no reply to my
> > m
On Wed, 27 Nov 2013, Antti Koskipaa wrote:
> v2: Reorganize array indexing so that full offsets can be used as
> is. It makes grepping for registers in i915_reg.h much easier. Also
> move offset arrays to intel_device_info.
Overall, I like this approach better than v1. Comments follow.
> Upcomin
On Wed, Dec 04, 2013 at 04:39:09PM +0200, Mika Kuoppala wrote:
> From: Mika Kuoppala
>
> This triggers use after free oops on request->batch_obj when
> going through the rings and setting reset status on requests,
> after a gpu hang.
>
> v2: Streamlined the test and added comments (Daniel)
>
>
On Wed, Dec 04, 2013 at 02:52:06PM +, Chris Wilson wrote:
> Inorder to serialise the closing of the file descriptor and its
> subsequent release of client requests with i915_gem_free_request(), we
> need to hold the struct_mutex in i915_gem_release(). Failing to do so
> has the potential to tri
From: Ville Syrjälä
FBC host modification tracking only works through GTT mmaps, so any
direct CPU access needs to manually nuke the compressed framebuffer
on modifications. Do the nuking from the SW_FINISH ioctl.
v2: nuke from SW_FINISH insted of DIRTYFB ioctl
v3: Call intel_fbc_nuke() only whe
On Wed, Dec 04, 2013 at 09:52:58AM +, Chris Wilson wrote:
> Whilst looking up the objects required for an execbuffer, an untimely
> allocation failure in creating the vma results in the object being
> unreferenced from two lists. The ownership during the lookup is meant to
> be moved from the l
On Wed, Dec 04, 2013 at 09:23:24AM -0800, Ben Widawsky wrote:
> On Wed, Dec 04, 2013 at 09:52:58AM +, Chris Wilson wrote:
> > Whilst looking up the objects required for an execbuffer, an untimely
> > allocation failure in creating the vma results in the object being
> > unreferenced from two li
This causes trouble on some VLV systems, and generally costs power
elsewhere.
If this ends up causing trouble, it could just mean we need to get rid
of VDD force enable everywhere, and move to a pure PPS based DP training
sequence.
References: https://bugs.freedesktop.org/show_bug.cgi?id=69693
Si
2013/12/4 Jesse Barnes :
> This causes trouble on some VLV systems, and generally costs power
> elsewhere.
>
> If this ends up causing trouble, it could just mean we need to get rid
> of VDD force enable everywhere, and move to a pure PPS based DP training
> sequence.
>
> References: https://bugs.f
On Wed, 4 Dec 2013 18:24:56 -0200
Paulo Zanoni wrote:
> 2013/12/4 Jesse Barnes :
> > This causes trouble on some VLV systems, and generally costs power
> > elsewhere.
> >
> > If this ends up causing trouble, it could just mean we need to get rid
> > of VDD force enable everywhere, and move to a p
On Wed, Dec 04, 2013 at 12:13:39AM -0800, Daniel Vetter wrote:
> On Tue, Nov 26, 2013 at 9:24 PM, Volkin, Bradley D
> wrote:
>
> [snip]
>
> > Which "state setup stuff" are you referring to? Something specific in i-g-t
> > or something
> > more general?
>
> The state setup 3D commands as oppos
We had problems with the Intel backlight driver the last time we tried
this, so let's push this through their tree for testing first? Cc:ed
intel-gfx and Daniel Vetter.
On Thu, Dec 05, 2013 at 10:03:57AM +0800, AceLan Kao wrote:
> The native/vendor backlight control interface is hardly fail to
On Thu, Dec 5, 2013 at 2:40 AM, Volkin, Bradley D
wrote:
>> > Ok, I'll look at the hw context code for buffer mgmt. For "purgeable",
>> > just via the
>> > madv field in the i915 gem object?
>>
>> Yeah, though I'd extract two tiny helpers (maybe shared with the madvise
>> ioctl) to set an object
On Thu, Dec 5, 2013 at 3:32 AM, Matthew Garrett wrote:
> We had problems with the Intel backlight driver the last time we tried
> this, so let's push this through their tree for testing first? Cc:ed
> intel-gfx and Daniel Vetter.
Makes sense imo. Or if I just get a branch with just those patches
44 matches
Mail list logo
