On Fri, Oct 23, 2015 at 12:39:31PM -0700, Jesse Barnes wrote:
> On 10/22/2015 01:35 PM, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä
> >
> > Do a dry run with rtcwake first to determine if the system even supports
> > the intended suspend state. If not, skip the test.
> >
> > Fix
On Mon, Oct 26, 2015 at 03:59:24PM -0200, Paulo Zanoni wrote:
> 2015-10-26 15:30 GMT-02:00 David Weinehall :
> > On Mon, Oct 26, 2015 at 02:44:18PM -0200, Paulo Zanoni wrote:
> >> 2015-10-26 12:59 GMT-02:00 David Weinehall
> >> :
> >> > On Fri, Oct 23, 2015 at 11:50:46AM -0200, Paulo Zanoni wrote:
Yes, it doesn't solve all warnings.
Other than fbdev restore, there is one warning which I faced during
DPMS/Hot-plug, which is due to calculation of watermarks twice. Once for
first CRTC "Pipe-A" (during which it consider/calculates watermark for
other pipe "Pipe-B" as well & stores in structu
On Fri, Oct 23, 2015 at 8:22 AM, Ville Syrjälä
wrote:
> The regressing patch change didn't add the message, so there was a clear
> change in behaviour, and now it's papered over.
It did move around the DRM_ERROR for all the others and also added the
SDE one for consistency. At least that's how I
While pinning a fb object to the display plane, only install a fence
if the object is using a normal view. This corresponds with the
behavior found in i915_gem_object_do_pin() where the fencability
criteria is determined only for objects with normal views.
v2:
Look at the object's map_and_fenceabl
On Mon, Oct 26, 2015 at 02:41:00PM +0100, Maarten Lankhorst wrote:
> These calls are unneeded because the previous memset/memcmp already handles
> PLANE_CURSOR too,
> so no need to treat it in a special way.
>
> Signed-off-by: Maarten Lankhorst
> ---
> diff --git a/drivers/gpu/drm/i915/intel_pm.
2015-10-23 12:55 GMT-02:00 Thomas Wood :
> On 23 October 2015 at 12:42, David Weinehall
> wrote:
>> Some tests should not be run by default, due to their slow,
>> and sometimes superfluous, nature.
>>
>> We still want to be able to run these tests though in some cases.
>> Until now there's been no
2015-10-26 15:30 GMT-02:00 David Weinehall :
> On Mon, Oct 26, 2015 at 02:44:18PM -0200, Paulo Zanoni wrote:
>> 2015-10-26 12:59 GMT-02:00 David Weinehall :
>> > On Fri, Oct 23, 2015 at 11:50:46AM -0200, Paulo Zanoni wrote:
>> >
>> > [snip]
>> >
>> >> It's not clear to me, please clarify: now the t
On Mon, Oct 26, 2015 at 04:28:15PM +, Thomas Wood wrote:
> On 26 October 2015 at 15:28, David Weinehall
> wrote:
> > On Fri, Oct 23, 2015 at 03:55:23PM +0100, Thomas Wood wrote:
> >> On 23 October 2015 at 12:42, David Weinehall
> >> wrote:
> >> > Some tests should not be run by default, due t
On Mon, Oct 26, 2015 at 02:44:18PM -0200, Paulo Zanoni wrote:
> 2015-10-26 12:59 GMT-02:00 David Weinehall :
> > On Fri, Oct 23, 2015 at 11:50:46AM -0200, Paulo Zanoni wrote:
> >
> > [snip]
> >
> >> It's not clear to me, please clarify: now the tests that were
> >> previously completely hidden will
On Mon, Oct 26, 2015 at 04:00:20PM +, Tvrtko Ursulin wrote:
>
> Hi,
>
> On 23/10/15 10:50, Tvrtko Ursulin wrote:
> >On 22/10/15 17:07, Chris Wilson wrote:
> >>On Thu, Oct 22, 2015 at 03:15:55PM +0100, Tvrtko Ursulin wrote:
> >>>
> >>>Hi,
> >>>
> >>>On 21/10/15 16:24, Chris Wilson wrote:
> >>>
2015-10-26 12:59 GMT-02:00 David Weinehall :
> On Fri, Oct 23, 2015 at 11:50:46AM -0200, Paulo Zanoni wrote:
>
> [snip]
>
>> It's not clear to me, please clarify: now the tests that were
>> previously completely hidden will be listed in --list-subtests and
>> will be shown as skipped during normal
On 26 October 2015 at 15:28, David Weinehall
wrote:
> On Fri, Oct 23, 2015 at 03:55:23PM +0100, Thomas Wood wrote:
>> On 23 October 2015 at 12:42, David Weinehall
>> wrote:
>> > Some tests should not be run by default, due to their slow,
>> > and sometimes superfluous, nature.
>> >
>> > We still
Hi,
On 23/10/15 10:50, Tvrtko Ursulin wrote:
On 22/10/15 17:07, Chris Wilson wrote:
On Thu, Oct 22, 2015 at 03:15:55PM +0100, Tvrtko Ursulin wrote:
Hi,
On 21/10/15 16:24, Chris Wilson wrote:
Our GPUs impose certain requirements upon buffers that depend upon how
exactly they are used. Typic
On Mon, Oct 26, 2015 at 03:56:33PM +0100, Robert Fekete wrote:
> Hi, thanks for reviewing Maarten.
> See comments inline...
>
> On mån, 2015-10-26 at 09:23 +0100, Maarten Lankhorst wrote:
> > Op 23-10-15 om 16:24 schreef Robert Fekete:
> > > Extends i915_display_info so that for each active crtc a
On Fri, Oct 23, 2015 at 03:55:23PM +0100, Thomas Wood wrote:
> On 23 October 2015 at 12:42, David Weinehall
> wrote:
> > Some tests should not be run by default, due to their slow,
> > and sometimes superfluous, nature.
> >
> > We still want to be able to run these tests though in some cases.
> >
On Fri, Oct 23, 2015 at 03:32:08PM +0100, Thomas Wood wrote:
> gem_concurrent_all is misspelled in the subject.
>
> On 23 October 2015 at 12:42, David Weinehall
> wrote:
> > We'll both rename gem_concurrent_all over gem_concurrent_blit
> > and change gem_concurrent_blit in this changeset. To make
On Fri, Oct 23, 2015 at 11:50:46AM -0200, Paulo Zanoni wrote:
[snip]
> It's not clear to me, please clarify: now the tests that were
> previously completely hidden will be listed in --list-subtests and
> will be shown as skipped during normal runs?
Yes. Daniel and I discussed this and he though
Hi, thanks for reviewing Maarten.
See comments inline...
On mån, 2015-10-26 at 09:23 +0100, Maarten Lankhorst wrote:
> Op 23-10-15 om 16:24 schreef Robert Fekete:
> > Extends i915_display_info so that for each active crtc also print
> > all planes associated with the pipe. This patch shows informa
On Wed, Sep 30, 2015 at 04:58:34PM +0300, Jani Nikula wrote:
> On Fri, 18 Sep 2015, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä
> >
> > Signed-off-by: Ville Syrjälä
> > ---
> > drivers/gpu/drm/i915/i915_reg.h | 2 +-
> > drivers/gpu/drm/i915/intel_ddi.c | 8
> >
On Thu, Oct 22, 2015 at 02:41:29PM +0100, Chris Wilson wrote:
> On Thu, Oct 22, 2015 at 03:34:55PM +0300, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä
> >
> > These patches fell off from my type safe register access series. I
> > figured I'd post them separately since they're a fa
On Fri, Oct 23, 2015 at 02:47:57PM +0200, Daniel Vetter wrote:
> On Fri, Oct 23, 2015 at 12:58:45PM +0100, Chris Wilson wrote:
> > On Fri, Oct 23, 2015 at 02:42:33PM +0300, David Weinehall wrote:
> > > Until now we've had no unified way to handle slow/combinatorial tests.
> > > Most of the time we
These calls are unneeded because the previous memset/memcmp already handles
PLANE_CURSOR too,
so no need to treat it in a special way.
Signed-off-by: Maarten Lankhorst
---
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 0fb0459cf093..efa2b15e8b88 100644
--- a
On 26/10/15 12:10, Chris Wilson wrote:
> On Mon, Oct 26, 2015 at 12:00:06PM +, Tvrtko Ursulin wrote:
>>
>> On 26/10/15 11:23, Chris Wilson wrote:
>>> On Mon, Oct 26, 2015 at 11:05:03AM +, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
In the following commit:
com
On Mon, Oct 26, 2015 at 12:00:06PM +, Tvrtko Ursulin wrote:
>
> On 26/10/15 11:23, Chris Wilson wrote:
> >On Mon, Oct 26, 2015 at 11:05:03AM +, Tvrtko Ursulin wrote:
> >>From: Tvrtko Ursulin
> >>
> >>In the following commit:
> >>
> >> commit e9f24d5fb7cf3628b195b18ff3ac4e37937ceeae
>
On 26/10/15 11:23, Chris Wilson wrote:
On Mon, Oct 26, 2015 at 11:05:03AM +, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
In the following commit:
commit e9f24d5fb7cf3628b195b18ff3ac4e37937ceeae
Author: Tvrtko Ursulin
Date: Mon Oct 5 13:26:36 2015 +0100
drm/i915
On Mon, Oct 26, 2015 at 11:05:03AM +, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin
>
> In the following commit:
>
> commit e9f24d5fb7cf3628b195b18ff3ac4e37937ceeae
> Author: Tvrtko Ursulin
> Date: Mon Oct 5 13:26:36 2015 +0100
>
> drm/i915: Clean up associated VMAs on
From: Tvrtko Ursulin
In the following commit:
commit e9f24d5fb7cf3628b195b18ff3ac4e37937ceeae
Author: Tvrtko Ursulin
Date: Mon Oct 5 13:26:36 2015 +0100
drm/i915: Clean up associated VMAs on context destruction
I added a WARN_ON assertion that VM's active list must be em
From: Tim Gore
Since A1 chips use the same GPU as A0, they need all the
same wa's in the i915 driver. Update some conditionals
to do this.
Signed-off-by: Tim Gore
---
drivers/gpu/drm/i915/intel_guc_loader.c | 2 +-
drivers/gpu/drm/i915/intel_lrc.c| 8
drivers/gpu/drm/i915/inte
Hi,
On 19/09/15 02:57, Vivek Kasireddy wrote:
v2:
Look at the object's map_and_fenceable flag to determine whether to
install a fence or not (Chris).
v1:
While pinning a fb object to the display plane, only install a fence
if the object is using a normal view. This corresponds with the
behavio
On Sat, Oct 24, 2015 at 11:03:05AM +0530, Animesh Manna wrote:
>
>
> On 10/23/2015 3:11 PM, Patrik Jakobsson wrote:
> >The current CSR loading code depends on the CSR program memory to be
> >cleared after boot. This is unfortunately not true on all hardware.
> >Instead make use of the FW_UNINITIA
Op 22-10-15 om 14:58 schreef Daniel Vetter:
> On Thu, Oct 22, 2015 at 01:56:26PM +0200, Maarten Lankhorst wrote:
>> Don't use plane->state directly, use the pointer from commit_plane.
>>
>> Signed-off-by: Maarten Lankhorst
>> ---
>> drivers/gpu/drm/i915/intel_drv.h| 8 ++---
>> drivers/gpu/d
Hi,
On 23 October 2015 at 09:05, Daniel Vetter wrote:
> On Thu, Oct 22, 2015 at 05:27:00PM -0700, Matt Roper wrote:
>> diff --git a/lib/igt_kms.c b/lib/igt_kms.c
>> index 51d735d..53bfc20 100644
>> --- a/lib/igt_kms.c
>> +++ b/lib/igt_kms.c
>> @@ -984,6 +984,9 @@ void igt_display_init(igt_display
Op 22-10-15 om 17:15 schreef Ville Syrjälä:
> On Thu, Oct 22, 2015 at 04:50:05PM +0200, Maarten Lankhorst wrote:
>> Op 22-10-15 om 15:30 schreef Ville Syrjälä:
>>> On Thu, Oct 22, 2015 at 01:56:28PM +0200, Maarten Lankhorst wrote:
By handling this after the atomic helper waits for vblanks ther
Op 23-10-15 om 16:24 schreef Robert Fekete:
> Extends i915_display_info so that for each active crtc also print
> all planes associated with the pipe. This patch shows information
> about each plane wrt format, size, position, rotation, and scaling.
> This is very useful when debugging user space c
On Sun, 2015-10-25 at 10:54 +0530, Thulasimani, Sivakumar wrote:
> This is a good simplification but for a wrong implementation :). we know
> that our current
> implementation is wrong and needs to be done the opposite way to make
> our code compliant with spec. i assume that it will then be a qu
On Mon, 2015-10-26 at 08:27 +0530, Thulasimani, Sivakumar wrote:
>
> On 10/23/2015 5:37 PM, R, Durgadoss wrote:
> > > -Original Message-
> > > From: Ander Conselvan De Oliveira [mailto:conselv...@gmail.com]
> > > Sent: Wednesday, October 21, 2015 9:08 PM
> > > To: R, Durgadoss; intel-gfx@l
37 matches
Mail list logo