Tested-By: PRC QA PRTS (Patch Regression Test System Contact:
shuang...@intel.com)
-Summary-
Platform: baseline_drm_intel_nightly_pass_rate->patch_applied_pass_rate
BYT: pass/total=290/290->290/290
PNV: pass/total=362/362->362
From: Gustavo Padovan
After some refactor intel_primary_plane_setplane() does the same
as intel_pipe_set_base() so we can get rid of it and replace the calls
with intel_primary_plane_setplane().
v2: take Ville's comments:
- get the right arguments for update_plane()
- use drm_crt
When using the universal plane interface, the source rectangle
coordinates define the panning offset for the primary plane, which needs
to be stored in crtc->{x,y}. The original universal plane code
negelected to set these panning offset fields, which was partially
remedied in:
commit ccc
Another iteration of the i915 display refactoring work in preparation for
atomic. The last patchset was posted here:
http://lists.freedesktop.org/archives/intel-gfx/2014-November/055702.html
This set incorporates the feedback from the last review and also adds an
additional patch at the
From: Gustavo Padovan
Merge it into the plane update_plane() callback and make other
users use the update_plane() functions instead.
The fb != crtc->cursor->fb was already inside intel_crtc_cursor_set_obj()
so we fold intel_crtc_cursor_set_obj() inside intel_commit_cursor_plane()
and merge both
From: Gustavo Padovan
We need to get hdisplay and vdisplay in a few places so create a
helper to make our job easier.
v2 (by Matt): Use new stereo doubling function (suggested by Ville)
v3 (by Matt):
- Add missing kerneldoc (Daniel)
- Use drm_mode_copy() (Jani)
v4 (by Matt):
- Drop stereo d
Primary and sprite planes have already been refactored to include a
'prepare' step which handles all the commit-time operations that could
fail (i.e., pinning buffers and such). Refactor the cursor commit in a
similar manner.
For simplicity and consistency with other plane types, we also switch t
Tested-By: PRC QA PRTS (Patch Regression Test System Contact:
shuang...@intel.com)
-Summary-
Platform: baseline_drm_intel_nightly_pass_rate->patch_applied_pass_rate
BYT: pass/total=290/290->290/290
PNV: pass/total=362/362->362
On Tue, Nov 18, 2014 at 3:18 PM, Eoff, Ullysses A
wrote:
> Thanks Jesse for the ack.
>
> Unfortunately I just learned from Stéphane that there
> are certain devices which only support 256 levels, so this
> patch would do us no good at solving the real issue for
> such devices.
>
> Why can't we jus
> -Original Message-
> From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of
> Eoff, Ullysses A
> Sent: Tuesday, November 18, 2014 3:19 PM
> To: Jani Nikula; Jesse Barnes
> Cc: stephane.marche...@gmail.com; intel-gfx@lists.freedesktop.org
> Subject: Re: [Intel-gfx]
We can still map 1000 entries back to 256, it will just mean some of
them won't result in any brightness change.
If that's not acceptable, I guess a dynamic 1:1 mapping is sufficient.
Jesse
On Tue, 18 Nov 2014 23:18:35 +
"Eoff, Ullysses A" wrote:
> Thanks Jesse for the ack.
>
> Unfortunat
Thanks Jesse for the ack.
Unfortunately I just learned from Stéphane that there
are certain devices which only support 256 levels, so this
patch would do us no good at solving the real issue for
such devices.
Why can't we just use a dynamic 1:1 mapping as was
suggested before? I would vote for t
On Mon, 17 Nov 2014 18:10:39 -0800
Matt Roper wrote:
> -static int
> -intel_pipe_set_base(struct drm_crtc *crtc, int x, int y,
> - struct drm_framebuffer *fb)
> -{
I'm gonna miss this old function... But on the plus side I won't
confuse pipe_set_base and set_pipe_base anymore, a
Might be helpful for debugging places where userspace ends up boosting
or waiting where it doesn't intend to.
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/i915_gem.c | 6 --
drivers/gpu/drm/i915/i915_trace.h | 15 +++
drivers/gpu/drm/i915/intel_pm.c | 9 +++--
3
On 2014-11-03 16:25, Daniel Vetter wrote:
> On Sat, Nov 01, 2014 at 06:08:00PM +0100, Christian Kastner wrote:
>>
>> [after upgrading dual-booted OSX to Yosemite, wich included firmware updates]
>>
>> Here's what I see [in Linux 3.16, 3.17]:
>>
>> $ GPE=/sys/firmware/acpi/interrupts/gpe66
>> $
On Mon, Nov 17, 2014 at 06:10:39PM -0800, Matt Roper wrote:
> From: Gustavo Padovan
>
> After some refactor intel_primary_plane_setplane() does the same
> as intel_pipe_set_base() so we can get rid of it and replace the calls
> with intel_primary_plane_setplane().
>
> v2: take Ville's comments:
On Tue, Nov 18, 2014 at 09:12:49AM -0800, Matt Roper wrote:
> From: Gustavo Padovan
>
> We need to get hdisplay and vdisplay in a few places so create a
> helper to make our job easier.
>
> v2 (by Matt): Use new stereo doubling function (suggested by Ville)
>
> v3 (by Matt):
> - Add missing ke
The logical ring code was updating the software ring 'head' value
by reading the hardware 'HEAD' register. In LRC mode, this is not
valid as the hardware is not necessarily executing the same context
that is being processed by the software. Thus reading the h/w HEAD
could put an unrelated (undefine
There are numerous places in the code where the driver's idea of
how much space is left in a ring is updated using the driver's
latest notions of the positions of 'head' and 'tail' for the ring.
Among them are some that update one or both of these values before
(re)doing the calculation. In particu
The request queue is per-engine, and may therefore contain requests
from several different contexts/ringbuffers. In determining which
request to wait for, this function should only consider requests
from the ringbuffer that it's checking for space, and ignore any
that it finds that belong to other
Fixes to both the LRC and the legacy ringbuffer code to correctly
calculate and update the available space in a ring.
The logical ring code was updating the software ring 'head' value
by reading the hardware 'HEAD' register. In LRC mode, this is not
valid as the hardware is not necessarily executi
On Mon, Nov 17, 2014 at 06:10:38PM -0800, Matt Roper wrote:
> When using the universal plane interface, the source rectangle
> coordinates define the panning offset for the primary plane, which needs
> to be stored in crtc->{x,y}. The original universal plane code
> negelected to set these panning
On 18/11/14 15:00, Deepak S wrote:
>
> On Monday 03 November 2014 06:59 PM, Dave Gordon wrote:
>> Fixes to both the LRC and the legacy ringbuffer code to correctly
>> calculate and update the available space in a ring.
>>
>> The logical ring code was updating the software ring 'head' value
>> by r
On Thu, Nov 13, 2014 at 06:50:10PM -0800, Tom.O'rou...@intel.com wrote:
> From: Tom O'Rourke
>
> In sandybridge_pcode_read and sandybridge_pcode_write,
> extend the mbox parameter from u8 to u32.
>
> On Haswell and Sandybridge, bits 7:0 encode the mailbox
> command and bits 28:8 are used for add
Tested-By: PRC QA PRTS (Patch Regression Test System Contact:
shuang...@intel.com)
-Summary-
Platform: baseline_drm_intel_nightly_pass_rate->patch_applied_pass_rate
BYT: pass/total=290/290->290/290
PNV: pass/total=362/362->362
>-Original Message-
>From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of
>Rodrigo Vivi
>Sent: Friday, November 14, 2014 10:23 PM
>To: intel-gfx@lists.freedesktop.org
>Cc: Vivi, Rodrigo
>Subject: [Intel-gfx] [PATCH 14/15] drm/i915: VLV/CHV PSR debugfs.
>
>Add debug
>-Original Message-
>From: Vivi, Rodrigo
>Sent: Friday, November 14, 2014 10:23 PM
>To: intel-gfx@lists.freedesktop.org
>Cc: Vivi, Rodrigo; R, Durgadoss
>Subject: [PATCH 13/15] drm/i915: VLV/CHV PSR: Increase wait delay time before
>active PSR.
>
>Since active function on VLV immediately a
>-Original Message-
>From: Vivi, Rodrigo
>Sent: Friday, November 14, 2014 10:23 PM
>To: intel-gfx@lists.freedesktop.org
>Cc: Vivi, Rodrigo; R, Durgadoss
>Subject: [PATCH 12/15] drm/i915: VLV/CHV PSR Software timer mode
>
>This patch introduces exit/activate functions for PSR
>on VLV+. Since
>-Original Message-
>From: Vivi, Rodrigo
>Sent: Friday, November 14, 2014 10:23 PM
>To: intel-gfx@lists.freedesktop.org
>Cc: Vivi, Rodrigo; R, Durgadoss
>Subject: [PATCH 11/15] drm/i915: PSR VLV/CHV: Introduce setup, enable and
>disable functions
>
>The biggest difference from HSW/BDW PSR
>-Original Message-
>From: Vivi, Rodrigo
>Sent: Friday, November 14, 2014 10:23 PM
>To: intel-gfx@lists.freedesktop.org
>Cc: Vivi, Rodrigo; R, Durgadoss
>Subject: [PATCH 10/15] drm/i915: Add PSR registers for PSR VLV/CHV.
>
>Baytrail (Valleyview) and Braswell (Cherryview) uses a complete di
>-Original Message-
>From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of
>Rodrigo Vivi
>Sent: Friday, November 14, 2014 10:23 PM
>To: intel-gfx@lists.freedesktop.org
>Cc: Vivi, Rodrigo
>Subject: [Intel-gfx] [PATCH 09/15] drm/i915: Fix intel_psr_is_enabled function
>-Original Message-
>From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of
>Rodrigo Vivi
>Sent: Friday, November 14, 2014 10:23 PM
>To: intel-gfx@lists.freedesktop.org
>Cc: Vivi, Rodrigo
>Subject: [Intel-gfx] [PATCH 08/15] drm/i915: remove PSR BDW single frame
>upd
>-Original Message-
>From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of
>Rodrigo Vivi
>Sent: Friday, November 14, 2014 10:23 PM
>To: intel-gfx@lists.freedesktop.org
>Cc: Vivi, Rodrigo
>Subject: [Intel-gfx] [PATCH 06/15] drm/i915: PSR get full link off x standby
>-Original Message-
>From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of
>Rodrigo Vivi
>Sent: Friday, November 14, 2014 10:22 PM
>To: intel-gfx@lists.freedesktop.org
>Cc: Daniel Vetter; Vivi, Rodrigo
>Subject: [Intel-gfx] [PATCH 03/15] drm/i915: Add PSR docbook
>
>-Original Message-
>From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of
>Rodrigo Vivi
>Sent: Friday, November 14, 2014 10:22 PM
>To: intel-gfx@lists.freedesktop.org
>Cc: Vivi, Rodrigo
>Subject: [Intel-gfx] [PATCH 02/15] drm/i915: Introduce intel_psr.c
>
>No funct
Just like we do in the HDMI code, set the infoframe flag if we detect
that infoframes are enabled.
v2: check for actual infoframe status as in hdmi code (Daniel)
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/intel_ddi.c | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/
On Tue, 11 Nov 2014 12:30:38 -0800
"U. Artie Eoff" wrote:
> A userspace brightness range that is larger than the hardware
> brightness range does not have a 1:1 mapping and can result
> in brightness != actual_brightness for some values.
>
> Expose a fixed brightness range of [0..1000] to usersp
Jani/Jesse,
Does this patch look reasonable to you for merging?
-- U. Artie
> -Original Message-
> From: Eoff, Ullysses A
> Sent: Tuesday, November 11, 2014 12:31 PM
> To: intel-gfx@lists.freedesktop.org
> Cc: Eoff, Ullysses A
> Subject: [PATCH] drm/i915: expose a fixed brightness range
From: Gustavo Padovan
We need to get hdisplay and vdisplay in a few places so create a
helper to make our job easier.
v2 (by Matt): Use new stereo doubling function (suggested by Ville)
v3 (by Matt):
- Add missing kerneldoc (Daniel)
- Use drm_mode_copy() (Jani)
Cc: dri-de...@lists.freedeskto
On Tue, 18 Nov 2014 09:14:05 +0100
Daniel Vetter wrote:
> On Mon, Nov 17, 2014 at 01:08:46PM -0800, Jesse Barnes wrote:
> > Just like we do in the HDMI code, set the infoframe flag if we detect an
> > HDMI sink.
> >
> > Reported-by: Paulo Zanoni
> > Signed-off-by: Jesse Barnes
> > ---
> > dri
Tested-By: PRC QA PRTS (Patch Regression Test System Contact:
shuang...@intel.com)
-Summary-
Platform: baseline_drm_intel_nightly_pass_rate->patch_applied_pass_rate
BYT: pass/total=290/290->290/290
PNV: pass/total=362/362->362
On Tue, 2014-11-18 at 14:04 -0200, Paulo Zanoni wrote:
> 2014-11-05 16:48 GMT-02:00 Imre Deak :
> > While fixing [1] I noticed that we can simplify a couple of things in
> > the RPS enabling/disabling code. So I did that and also fixed one WARN
> > that we can hit with some of the pm_rpm subtests.
2014-11-05 16:48 GMT-02:00 Imre Deak :
> While fixing [1] I noticed that we can simplify a couple of things in
> the RPS enabling/disabling code. So I did that and also fixed one WARN
> that we can hit with some of the pm_rpm subtests. Hopefully these
> changes also makes it clearer how we avoid th
> -Original Message-
> From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of Daniel
> Vetter
> Sent: Tuesday, November 18, 2014 3:11 PM
> To: Daniel, Thomas
> Cc: Daniel Vetter; intel-gfx@lists.freedesktop.org
> Subject: Re: [Intel-gfx] [PATCH v5 3/4] drm/i915/bdw: Pin the contex
Tested-By: PRC QA PRTS (Patch Regression Test System Contact:
shuang...@intel.com)
-Summary-
Platform: baseline_drm_intel_nightly_pass_rate->patch_applied_pass_rate
BYT: pass/total=290/290->290/290
PNV: pass/total=362/362->362
On Tue, Nov 18, 2014 at 03:03:28PM +, tim.g...@intel.com wrote:
> From: Tim Gore
>
> gem_fence_upload implements some performance measurements,
> but fails on both android and linux systems and does not
> generally seem to be a usefull test, so exclude it.
>
> Signed-off-by: Tim Gore
Nack.
On Tue, Nov 18, 2014 at 02:51:52PM +, Daniel, Thomas wrote:
> > -Original Message-
> > From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of Daniel
> > Vetter
> > Sent: Tuesday, November 18, 2014 2:33 PM
> > To: Daniel, Thomas
> > Cc: Daniel Vetter; intel-gfx@lists.freedeskto
From: Tim Gore
gem_fence_upload implements some performance measurements,
but fails on both android and linux systems and does not
generally seem to be a usefull test, so exclude it.
Signed-off-by: Tim Gore
---
tests/Android.mk | 3 +++
1 file changed, 3 insertions(+)
diff --git a/tests/Andro
From: Tim Gore
kms_pwrite_crc was recently added and requires cairo, so
add this to the list of tests to exclude if cairo is not
avaiable
Signed-off-by: Tim Gore
---
tests/Android.mk | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/tests/Android.mk b/tests/Android.mk
index
> -Original Message-
> From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of Daniel
> Vetter
> Sent: Tuesday, November 18, 2014 2:33 PM
> To: Daniel, Thomas
> Cc: Daniel Vetter; intel-gfx@lists.freedesktop.org
> Subject: Re: [Intel-gfx] [PATCH v5 3/4] drm/i915/bdw: Pin the contex
On Tue, Nov 18, 2014 at 03:34:15PM +0100, Daniel Vetter wrote:
> On Tue, Nov 18, 2014 at 02:04:23PM +, Chris Wilson wrote:
> > On Tue, Nov 18, 2014 at 01:28:38PM +0100, Daniel Vetter wrote:
> > > This goes back to
> > >
> > > commit 362b8af7ad1d91266aa4931e62be45c1e5cf753b
> > > Author: Ben Wi
On Tue, Nov 18, 2014 at 03:35:33PM +0100, Daniel Vetter wrote:
> On Tue, Nov 18, 2014 at 02:06:37PM +, Chris Wilson wrote:
> > On Tue, Nov 18, 2014 at 02:40:28PM +0100, Daniel Vetter wrote:
> > > The only thing the kernel can do is pin the buffers, which essentially
> > > means no swapped tiled
So skip those.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=86236
Signed-off-by: Daniel Vetter
---
tests/kms_render.c | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/tests/kms_render.c b/tests/kms_render.c
index d96ceea45149..a3487dd88fe9 100644
--- a/tests/
On Tue, Nov 18, 2014 at 02:01:37PM +, Chris Wilson wrote:
> On Tue, Nov 18, 2014 at 02:41:22PM +0100, Daniel Vetter wrote:
> > struct intel_fbdev;
> > struct intel_fbc_work;
> > diff --git a/drivers/gpu/drm/i915/i915_gem.c
> > b/drivers/gpu/drm/i915/i915_gem.c
> > index 1de94cc63517..196ebd0
On Tue, Nov 18, 2014 at 02:06:37PM +, Chris Wilson wrote:
> On Tue, Nov 18, 2014 at 02:40:28PM +0100, Daniel Vetter wrote:
> > The only thing the kernel can do is pin the buffers, which essentially
> > means no swapped tiled objects.
> >
> > Signed-off-by: Daniel Vetter
> > ---
> > tests/gem
On Tue, Nov 18, 2014 at 02:04:23PM +, Chris Wilson wrote:
> On Tue, Nov 18, 2014 at 01:28:38PM +0100, Daniel Vetter wrote:
> > This goes back to
> >
> > commit 362b8af7ad1d91266aa4931e62be45c1e5cf753b
> > Author: Ben Widawsky
> > Date: Thu Jan 30 00:19:38 2014 -0800
> >
> > drm/i915: M
On Tue, Nov 18, 2014 at 10:48:09AM +, Daniel, Thomas wrote:
> > -Original Message-
> > From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf
> > Of Daniel, Thomas
> > Sent: Tuesday, November 18, 2014 9:28 AM
> > To: Daniel Vetter
> > Cc: intel-gfx@lists.freedesktop.
On Tue, Nov 18, 2014 at 02:40:28PM +0100, Daniel Vetter wrote:
> The only thing the kernel can do is pin the buffers, which essentially
> means no swapped tiled objects.
>
> Signed-off-by: Daniel Vetter
> ---
> tests/gem_tiled_swapping.c | 22 ++
> 1 file changed, 22 insertio
On Tue, Nov 18, 2014 at 01:28:38PM +0100, Daniel Vetter wrote:
> This goes back to
>
> commit 362b8af7ad1d91266aa4931e62be45c1e5cf753b
> Author: Ben Widawsky
> Date: Thu Jan 30 00:19:38 2014 -0800
>
> drm/i915: Move per ring error state to ring_error
>
> Spotted while reading error states
On Tue, Nov 18, 2014 at 02:41:22PM +0100, Daniel Vetter wrote:
> struct intel_fbdev;
> struct intel_fbc_work;
> diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
> index 1de94cc63517..196ebd07d118 100644
> --- a/drivers/gpu/drm/i915/i915_gem.c
> +++ b/drivers/gpu/drm/
The only thing the kernel can do is pin the buffers, which essentially
means no swapped tiled objects.
Signed-off-by: Daniel Vetter
---
tests/gem_tiled_swapping.c | 22 ++
1 file changed, 22 insertions(+)
diff --git a/tests/gem_tiled_swapping.c b/tests/gem_tiled_swapping.c
i
Let's just throw in the towel on this one and take the cheap way out.
Based on a patch from Chris Wilson, but checking for a different bit.
Chris' patch checked for even bank layout, this one here for a magic
bit. Given the evidence we've gathered (not much) both work I think,
but checking for the
drm_open_any keeps a buffer handle around for the cleanup sync work,
so we can only grab the buffer count after the latst drm_open_any
call. Otherwise we'll detect a fake leak.
This broke in
commit 2f2c491cf3167befe7c79e4b17afb4f6284dfc84
Author: Mika Kuoppala
Date: Fri Mar 28 10:52:46 2014 +0
This goes back to
commit 362b8af7ad1d91266aa4931e62be45c1e5cf753b
Author: Ben Widawsky
Date: Thu Jan 30 00:19:38 2014 -0800
drm/i915: Move per ring error state to ring_error
Spotted while reading error states.
Cc: Ben Widawsky
Cc: Chris Wilson
Signed-off-by: Daniel Vetter
---
drivers
> -Original Message-
> From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf
> Of Daniel, Thomas
> Sent: Tuesday, November 18, 2014 9:28 AM
> To: Daniel Vetter
> Cc: intel-gfx@lists.freedesktop.org
> Subject: Re: [Intel-gfx] [PATCH v5 3/4] drm/i915/bdw: Pin the context
On Tue, Nov 18, 2014 at 11:33:23AM +0100, Daniel Vetter wrote:
> On Tue, Nov 18, 2014 at 09:50:23AM +, Chris Wilson wrote:
> > We should be able to execute batches up to the full GTT size (give or
> > take fragmentation), so let's try!
> >
> > Signed-off-by: Chris Wilson
> > ---
> > tests/ge
On Tue, Nov 18, 2014 at 09:50:23AM +, Chris Wilson wrote:
> We should be able to execute batches up to the full GTT size (give or
> take fragmentation), so let's try!
>
> Signed-off-by: Chris Wilson
> ---
> tests/gem_exec_big.c | 28 ++--
> 1 file changed, 18 insertio
On Tue, Nov 18, 2014 at 12:11:29PM +0200, Jani Nikula wrote:
> Indicate the monitor has been disconnected on disable.
>
> The regression has been introduced in
>
> commit 5fad84a7530f8e7664cdc6f490cb90653fed1266
> Author: Jani Nikula
> Date: Tue Nov 4 10:30:23 2014 +0200
>
> drm/i915: rew
Indicate the monitor has been disconnected on disable.
The regression has been introduced in
commit 5fad84a7530f8e7664cdc6f490cb90653fed1266
Author: Jani Nikula
Date: Tue Nov 4 10:30:23 2014 +0200
drm/i915: rewrite hsw/bdw audio codec enable/disable sequences
Bugzilla: https://bugs.freed
We should be able to execute batches up to the full GTT size (give or
take fragmentation), so let's try!
Signed-off-by: Chris Wilson
---
tests/gem_exec_big.c | 28 ++--
1 file changed, 18 insertions(+), 10 deletions(-)
diff --git a/tests/gem_exec_big.c b/tests/gem_exec_b
> -Original Message-
> From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf
> Of john.c.harri...@intel.com
> Sent: Friday, November 14, 2014 12:19 PM
> To: Intel-GFX@Lists.FreeDesktop.Org
> Subject: [Intel-gfx] [PATCH v2 25/28] drm/i915: Interrupt driven request
> comp
> -Original Message-
> From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf
> Of john.c.harri...@intel.com
> Sent: Friday, November 14, 2014 12:19 PM
> To: Intel-GFX@Lists.FreeDesktop.Org
> Subject: [Intel-gfx] [PATCH v2 11/28] drm/i915: Add IRQ friendly request
> defe
> -Original Message-
> From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of Daniel
> Vetter
> Sent: Monday, November 17, 2014 6:09 PM
> To: Daniel, Thomas
> Cc: intel-gfx@lists.freedesktop.org
> Subject: Re: [Intel-gfx] [PATCH v5 3/4] drm/i915/bdw: Pin the context
> backing obje
On Tue, 18 Nov 2014, Matt Roper wrote:
> From: Gustavo Padovan
>
> We need to get hdisplay and vdisplay in a few places so create a
> helper to make our job easier.
>
> v2 (by Matt): Use new stereo doubling function (suggested by Ville)
>
> Cc: dri-de...@lists.freedesktop.org
> Suggested-by: Vill
Tested-By: PRC QA PRTS (Patch Regression Test System Contact:
shuang...@intel.com)
-Summary-
Platform: baseline_drm_intel_nightly_pass_rate->patch_applied_pass_rate
BYT: pass/total=290/291->291/291
PNV: pass/total=356/356->356
On Mon, Nov 17, 2014 at 07:28:28PM +0100, Daniel Vetter wrote:
> On Fri, Nov 14, 2014 at 05:24:35PM +, Damien Lespiau wrote:
> > Signed-off-by: Damien Lespiau
> > ---
> > drivers/gpu/drm/i915/intel_ddi.c | 8
> > 1 file changed, 8 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/i
On Mon, Nov 17, 2014 at 01:08:47PM -0800, Jesse Barnes wrote:
> The lack of a break here wasn't for falling through to some other
> important code, so made me do a double take. Add a break just to make
> things a little less confusing.
>
> Signed-off-by: Jesse Barnes
Confusing indeed. Queued fo
> -Original Message-
> From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of Daniel Vetter
> Sent: Monday, November 17, 2014 11:03 PM
> To: Lespiau, Damien
> Cc: He, Shuang; intel-gfx@lists.freedesktop.org
> Subject: Re: [Intel-gfx] [PATCH 4/4] drm/i915/skl: Read out crtl1 for
>
On Mon, Nov 17, 2014 at 01:08:46PM -0800, Jesse Barnes wrote:
> Just like we do in the HDMI code, set the infoframe flag if we detect an
> HDMI sink.
>
> Reported-by: Paulo Zanoni
> Signed-off-by: Jesse Barnes
> ---
> drivers/gpu/drm/i915/intel_ddi.c | 1 +
> 1 file changed, 1 insertion(+)
>
>
> -Original Message-
> From: Lespiau, Damien
> Sent: Saturday, November 15, 2014 6:55 PM
> To: He, Shuang
> Cc: intel-gfx@lists.freedesktop.org
> Subject: Re: [Intel-gfx] [PATCH 4/4] drm/i915/skl: Read out crtl1 for
> eDP/DPLL0
>
> Hi Shuang,
>
> You wanted suggestions, so how about:
>
kmap never fails.
Spotted-by: Chris Wilson
Cc: Chris Wilson
Cc: Arun Siluvery
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/intel_lrc.c | 15 +++
1 file changed, 3 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lr
On Tue, Nov 18, 2014 at 07:44:40AM +, Chris Wilson wrote:
> On Mon, Nov 17, 2014 at 08:04:09PM +0100, Daniel Vetter wrote:
> > On Mon, Nov 17, 2014 at 03:48:27PM +, Arun Siluvery wrote:
> > > We are not freeing memory allocated for ringbuf and ctx if we fail
> > > to map status page so rele
On Mon, Nov 03, 2014 at 01:29:04PM +, Dave Gordon wrote:
> Fixes to both the LRC and the legacy ringbuffer code to correctly
> calculate and update the available space in a ring.
>
> The logical ring code was updating the software ring 'head' value
> by reading the hardware 'HEAD' register. In
83 matches
Mail list logo
