On Tue, Mar 03, 2015 at 02:20:03PM +, Damien Lespiau wrote:
> On Tue, Dec 09, 2014 at 04:53:01PM +, Damien Lespiau wrote:
> > Right that leaves the last point in my answer to v3. With that addressed
> > this is:
> >
> > Reviewed-by: Damien Lespiau
>
> Hum it seems that we've upstreamed t
On Tue, Mar 3, 2015 at 8:31 AM, Daniel Vetter wrote:
>
> Fix this all by applying the same duct-tape as for the legacy setcrtc
> ioctl code and set crtc->primary->crtc properly.
Ack. Tests fine on the machine that showed issues for me.
I'll apply it manually directly to my tree, since I want to
On Tue, Mar 03, 2015 at 09:03:32AM -0800, Linus Torvalds wrote:
> On Tue, Mar 3, 2015 at 8:31 AM, Daniel Vetter wrote:
> >
> > Fix this all by applying the same duct-tape as for the legacy setcrtc
> > ioctl code and set crtc->primary->crtc properly.
>
> Ack. Tests fine on the machine that showed
On Tue, Mar 03, 2015 at 05:05:52PM +, Chris Wilson wrote:
> On Tue, Mar 03, 2015 at 02:20:03PM +, Damien Lespiau wrote:
> > On Tue, Dec 09, 2014 at 04:53:01PM +, Damien Lespiau wrote:
> > > Right that leaves the last point in my answer to v3. With that addressed
> > > this is:
> > >
>
On Tue, Mar 3, 2015 at 9:11 AM, Daniel Vetter wrote:
>
> Fine with me. If you haven't pushed out yet can you maybe clarify the
> commit message?
Oh well. I already applied and tagged it, so it's what it is..
Linus
___
Intel-gfx mai
On Tue, Mar 03, 2015 at 05:13:41PM +, Chris Wilson wrote:
> On Tue, Mar 03, 2015 at 05:11:12PM +, Damien Lespiau wrote:
> > On Tue, Mar 03, 2015 at 05:05:52PM +, Chris Wilson wrote:
> > > On Tue, Mar 03, 2015 at 02:20:03PM +, Damien Lespiau wrote:
> > > > On Tue, Dec 09, 2014 at 04:
Tested-By: PRC QA PRTS (Patch Regression Test System Contact:
shuang...@intel.com)
Task id: 5870
-Summary-
Platform Delta drm-intel-nightly Series Applied
PNV -5 278/278
On Tue, Mar 03, 2015 at 09:12:47AM -0800, Linus Torvalds wrote:
> On Tue, Mar 3, 2015 at 9:11 AM, Daniel Vetter wrote:
> >
> > Fine with me. If you haven't pushed out yet can you maybe clarify the
> > commit message?
>
> Oh well. I already applied and tagged it, so it's what it is..
No biggie, t
On Tue, Mar 03, 2015 at 05:11:12PM +, Damien Lespiau wrote:
> On Tue, Mar 03, 2015 at 05:05:52PM +, Chris Wilson wrote:
> > On Tue, Mar 03, 2015 at 02:20:03PM +, Damien Lespiau wrote:
> > > On Tue, Dec 09, 2014 at 04:53:01PM +, Damien Lespiau wrote:
> > > > Right that leaves the las
On Tue, 03 Mar 2015, "Brian J. Murrell" wrote:
> Slightly off on a tangent... do LCD screens driven through the DSUB have
> the same flicker issues as CRTs or does that somehow get washed out by
> the difference between LCD and CRT technology?
You'll lose the flicker with LCD, but given a digital
On Tue, 2015-03-03 at 20:40 +0200, Jani Nikula wrote:
>
> You'll lose the flicker with LCD,
Even with an analog DSUB input? I only ask again due to the confusion
below...
> but given a digital source
I don't have a digital source. I have a 15-pin DSUB analog source.
> and a
> digital display
Tested-By: PRC QA PRTS (Patch Regression Test System Contact:
shuang...@intel.com)
Task id: 5871
-Summary-
Platform Delta drm-intel-nightly Series Applied
PNV -5 278/278
On Tue, 03 Mar 2015, "Brian J. Murrell" wrote:
> On Tue, 2015-03-03 at 20:40 +0200, Jani Nikula wrote:
>>
>> You'll lose the flicker with LCD,
>
> Even with an analog DSUB input? I only ask again due to the confusion
> below...
Yes. You may get other artefacts due to the D/A-A/D conversions and
On 03/03/2015 09:03 AM, Daniel Vetter wrote:
> This is useful for writing igts to make sure we don't break this,
> without being forced to own a one of these dinosaurs.
>
> Suggested-by: Jesse Barnes
> Cc: Matt Roper
> Signed-off-by: Daniel Vetter
> ---
> drivers/gpu/drm/i915/i915_drv.h| 1
Tested-By: PRC QA PRTS (Patch Regression Test System Contact:
shuang...@intel.com)
Task id: 5872
-Summary-
Platform Delta drm-intel-nightly Series Applied
PNV -7 278/278
On Tue, Mar 03, 2015 at 11:23:53AM -0800, Jesse Barnes wrote:
> On 03/03/2015 09:03 AM, Daniel Vetter wrote:
> > This is useful for writing igts to make sure we don't break this,
> > without being forced to own a one of these dinosaurs.
> >
> > Suggested-by: Jesse Barnes
> > Cc: Matt Roper
> > S
Tested-By: PRC QA PRTS (Patch Regression Test System Contact:
shuang...@intel.com)
Task id: 5873
-Summary-
Platform Delta drm-intel-nightly Series Applied
PNV -5 278/278
On Tue, Mar 3, 2015 at 10:15 PM, Chris Wilson wrote:
> On Tue, Mar 03, 2015 at 11:23:53AM -0800, Jesse Barnes wrote:
>> On 03/03/2015 09:03 AM, Daniel Vetter wrote:
>> > This is useful for writing igts to make sure we don't break this,
>> > without being forced to own a one of these dinosaurs.
>>
On 03/03/2015 04:06 PM, Daniel Vetter wrote:
> On Tue, Mar 3, 2015 at 10:15 PM, Chris Wilson
> wrote:
>> On Tue, Mar 03, 2015 at 11:23:53AM -0800, Jesse Barnes wrote:
>>> On 03/03/2015 09:03 AM, Daniel Vetter wrote:
This is useful for writing igts to make sure we don't break this,
witho
Tested-By: PRC QA PRTS (Patch Regression Test System Contact:
shuang...@intel.com)
Task id: 5874
-Summary-
Platform Delta drm-intel-nightly Series Applied
PNV -4 278/278
Sorry for the long delay here.
Reviewed-by: Rodrigo Vivi
On Fri, Feb 13, 2015 at 11:23 AM, Paulo Zanoni wrote:
> From: Paulo Zanoni
>
> We want to port FBC to the frontbuffer tracking infrastructure, but
> for that we need to know what caused the object invalidation so
> we can react according
Reviewed-by: Rodrigo Vivi
On Fri, Feb 13, 2015 at 11:23 AM, Paulo Zanoni wrote:
> From: Paulo Zanoni
>
> We need this for FBC, and possibly for PSR too.
>
> v2: Don't only flush: invalidate too (Daniel).
>
> Signed-off-by: Paulo Zanoni
> ---
> drivers/gpu/drm/i915/i915_gem.c | 23
On Fri, Feb 13, 2015 at 11:23 AM, Paulo Zanoni wrote:
> From: Paulo Zanoni
>
> Kill the blt/render tracking we currently have and use the frontbuffer
> tracking infrastructure.
>
> Don't enable things by default yet.
>
> v2: (Rodrigo) Fix small conflict on rebase and typo at subject.
> v3: (Paulo
On Sun, Mar 01, 2015 at 10:41:37AM +, Chris Wilson wrote:
> i915.ko depends upon the acpi/video.ko module and so refuses to load if
> ACPI is disabled at runtime if for example the BIOS is broken beyond
> repair. acpi/video provides an optional service for i915.ko and so we
> should just allow
Current ILK-style watermark code assumes the primary plane and cursor
plane are always enabled. This assumption, along with the combination
of two independent commits that got merged at the same time, results in
a NULL dereference. The offending commits are:
commit fd2d61341bf39d1054256c
Universal planes allow us to have an active CRTC without a primary plane
framebuffer bound. Drop the test for primary->fb from
intel_crtc_active() since we can clearly have active CRTC's without a
framebuffer, and this check is now interfering with watermark
calculations when we try to re-enable t
Tested-By: PRC QA PRTS (Patch Regression Test System Contact:
shuang...@intel.com)
Task id: 5875
-Summary-
Platform Delta drm-intel-nightly Series Applied
PNV -5 278/278
On Fri, Feb 20, 2015 at 11:15 PM, Michel Thierry
wrote:
> From: Ben Widawsky
>
> The code for 4lvl works just as one would expect, and nicely it is able
> to call into the existing 3lvl page table code to handle all of the
> lower levels.
>
> PML4 has no special attributes, and there will always
On Fri, Feb 20, 2015 at 11:15 PM, Michel Thierry
wrote:
> From: Ben Widawsky
>
> Up until now, ppgtt->pdp has always been the root of our page tables.
> Legacy 32b addresses acted like it had 1 PDP with 4 PDPEs.
>
> In preparation for 4 level page tables, we need to stop use ppgtt->pdp
> directly
Tested-By: PRC QA PRTS (Patch Regression Test System Contact:
shuang...@intel.com)
Task id: 5876
-Summary-
Platform Delta drm-intel-nightly Series Applied
PNV -8 278/278
101 - 130 of 130 matches
Mail list logo
