On Fri, May 16, 2014 at 11:03 AM, akash goel akash.go...@gmail.com wrote:
Sorry not aware of this specific difference in the starting value of
scanline counter for HSW+ ( gen 2), but implementation wise, patch looks
fine.
Reviewed-by: Akash Goel akash.go...@gmail.com
Don't have enough
Get CRCs of a full red and a full blue surface as reference.
Create a big framebuffer that is twice width and twice height as the
current display mode.
Fill the top left quarter with red, bottom right quarter with blue
Check the scanned out image with the CRTC at position (0, 0) of the
On Fri, May 16, 2014 at 7:25 AM, Lee, Chon Ming chon.ming@intel.com wrote:
Cherryview display allow the primary plane to be position at any
location similiar to sprite plane for certain port. So, this shouldn't
need to
check here.
And the width/height doesn't need to cover the
Hi Dave -
Intel fixes for regressions, black screens and hangs, for 3.15.
BR,
Jani.
The following changes since commit 2a1235e53bed8fa111e1c1ee2e7d8d91efa71ebc:
Merge branch 'drm-nouveau-next' of
git://anongit.freedesktop.org/git/nouveau/linux-2.6 into drm-fixes (2014-05-07
09:06:21
On 04/30/2014 10:08 PM, Imre Deak wrote:
On Fri, 2014-04-25 at 10:45 +0200, Daniel Vetter wrote:
Ok, review assignements. Please complain if you don't have the
bandwidth so that I can find someone else.
On Thu, Apr 24, 2014 at 11:54 PM, Daniel Vetter daniel.vet...@ffwll.ch wrote:
Daniel
On Thu, May 15, 2014 at 10:46:50PM -0600, Alex Williamson wrote:
On Fri, 2014-05-16 at 00:50 +0200, Daniel Vetter wrote:
On Thu, May 15, 2014 at 11:43 PM, Alex Williamson
alex.william...@redhat.com wrote:
I don't know what to do with this. It seems like a lot of wishful
thinking that
On Fri, May 16, 2014 at 01:38:18AM +, O'Rourke, Tom wrote:
+static void gen8_disable_rps_interrupts(struct drm_device *dev) {
+struct drm_i915_private *dev_priv = dev-dev_private;
+
+I915_WRITE(GEN6_PMINTRMSK, 0x);
[TOR:] Please note that for Broadwell, bit 31 in
On Thu, May 15, 2014 at 08:13:57PM -0400, Rodrigo Vivi wrote:
v2: rebase after a long time.
Signed-off-by: Rodrigo Vivi rodrigo.v...@gmail.com
Oh dear, the basic test was completely lost when we've merged the sink_crc
debugfs support :( Applied now, thanks for the patch.
One comment below.
On Thu, May 15, 2014 at 06:17:25PM -0700, Matt Roper wrote:
Cursor planes are a bit trickier to support via the universal plane interface
than primary planes were. Legacy cursor ioctls take handles to driver buffers
directly whereas the universal plane API takes drm_framebuffer's that
Thanks Damien for your review
On Thursday 15 May 2014 10:18 PM, Damien Lespiau wrote:
On Mon, Apr 14, 2014 at 11:18:27AM +0530, Shobhit Kumar wrote:
This driver makes use of the generic panel information from the VBT.
Panel information is classified into two - panel configuration and panel
On Fri, May 16, 2014 at 11:09:35AM +0200, Daniel Vetter wrote:
On Fri, May 16, 2014 at 01:38:18AM +, O'Rourke, Tom wrote:
+static void gen8_disable_rps_interrupts(struct drm_device *dev) {
+ struct drm_i915_private *dev_priv = dev-dev_private;
+
+ I915_WRITE(GEN6_PMINTRMSK,
On Thu, Apr 24, 2014 at 11:55:00PM +0200, Daniel Vetter wrote:
All the callbacks are gone now.
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
Merged up to this patch here, thanks everyone for the reviews.
-Daniel
---
drivers/gpu/drm/i915/intel_display.c | 33
On Thu, Apr 17, 2014 at 03:18:48PM -0700, Volkin, Bradley D wrote:
+ union {
+ struct i915_gem_userptr {
Out of curiosity, what's the point of using both a union and a
struct here, given that everything is within the struct?
Because I stuff other things into this union in
On Fri, May 16, 2014 at 12:46:00PM +0300, Ville Syrjälä wrote:
On Fri, May 16, 2014 at 11:09:35AM +0200, Daniel Vetter wrote:
On Fri, May 16, 2014 at 01:38:18AM +, O'Rourke, Tom wrote:
+static void gen8_disable_rps_interrupts(struct drm_device *dev) {
+struct drm_i915_private
On Thu, May 15, 2014 at 08:13:04PM -0400, Rodrigo Vivi wrote:
Also do not cache aux info. That info could be related to another panel.
You should kill the bool sink_support then. There are other places that
it used that could be invalid.
I'm not sure though that we can cope with eDP panels
On Thu, May 15, 2014 at 08:13:05PM -0400, Rodrigo Vivi wrote:
The perfect solution for psr_exit is the hardware tracking the changes and
doing the psr exit by itself. This scenario works for HSW and BDW with some
environments like Gnome and Wayland.
However there are many other scenarios
On Thu, May 15, 2014 at 08:13:05PM -0400, Rodrigo Vivi wrote:
The perfect solution for psr_exit is the hardware tracking the changes and
doing the psr exit by itself. This scenario works for HSW and BDW with some
environments like Gnome and Wayland.
However there are many other scenarios
On Thu, May 15, 2014 at 06:17:29PM -0700, Matt Roper wrote:
The DRM core will translate calls to legacy cursor ioctls into universal
cursor calls automatically, so there's no need to maintain the legacy
cursor support. This greatly simplifies the transition since we don't
have to handle
Bit 31 in GEN6_PMINTRMSK is not an interrupt disable bit with gen8.
Reviewed-by: Ville Syrjälä ville.syrj...@linux.intel.com
Signed-off-by: Mika Kuoppala mika.kuopp...@intel.com
---
drivers/gpu/drm/i915/intel_pm.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
-Original Message-
From: Ville Syrjälä [mailto:ville.syrj...@linux.intel.com]
Sent: Thursday, May 15, 2014 2:34 PM
To: Mateo Lozano, Oscar
Cc: Daniel Vetter; intel-gfx@lists.freedesktop.org
Subject: Re: [Intel-gfx] [PATCH] drm/i915: Gracefully handle obj not bound to
GGTT in
On Thu, May 15, 2014 at 08:23:47PM +0530, akash goel wrote:
Reviewed the patch it looks good.
Just to confirm, this patch tries to address the case of a tiny window of
transition, i.e. from the 1st field (last half line) to 2nd field (first
half line).
The hardware counts things so that one
On Fri, May 09, 2014 at 01:08:39PM +0100, oscar.ma...@intel.com wrote:
From: Oscar Mateo oscar.ma...@intel.com
The context are going to become very important pretty soon, and
we need to be able to access them in a number of places inside
the command submission path. The idea is that, when we
-Original Message-
From: Chris Wilson [mailto:ch...@chris-wilson.co.uk]
Sent: Friday, May 16, 2014 12:05 PM
To: Mateo Lozano, Oscar
Cc: intel-gfx@lists.freedesktop.org
Subject: Re: [Intel-gfx] [PATCH 09/50] drm/i915: Plumb the context everywhere
in the execbuffer path
On Fri, May
From: Oscar Mateo oscar.ma...@intel.com
Otherwise, we do a NULL pointer dereference.
I've seen this happen while handling an error in
i915_gem_object_pin_to_display_plane():
If i915_gem_object_set_cache_level() fails, we call is_pin_display()
to handle the error. At this point, the object is
From: Oscar Mateo oscar.ma...@intel.com
This is a review by igt test for a bug located in
i915_gem_object_pin_to_display_plane and fixed by:
commit 392013bdd4b6128795e33c84bd6d6d3fd66ff0a3
Author: Oscar Mateo oscar.ma...@intel.com
Date: Fri May 16 11:23:12 2014 +0100
drm/i915: Gracefully
On Thu, May 15, 2014 at 05:48:57PM +0100, Damien Lespiau wrote:
+static struct gpio_table gtable[] = {
const
Please, disregard this comment. It's being written to to track GPIO
initialization.
--
Damien
___
Intel-gfx mailing list
On Fri, May 16, 2014 at 12:08:22PM +0100, oscar.ma...@intel.com wrote:
From: Oscar Mateo oscar.ma...@intel.com
Otherwise, we do a NULL pointer dereference.
I've seen this happen while handling an error in
i915_gem_object_pin_to_display_plane():
If i915_gem_object_set_cache_level()
On Fri, May 16, 2014 at 11:11:38AM +, Mateo Lozano, Oscar wrote:
-Original Message-
From: Chris Wilson [mailto:ch...@chris-wilson.co.uk]
Sent: Friday, May 16, 2014 12:05 PM
To: Mateo Lozano, Oscar
Cc: intel-gfx@lists.freedesktop.org
Subject: Re: [Intel-gfx] [PATCH 09/50]
On Mon, May 12, 2014 at 06:40:43PM +0200, Daniel Vetter wrote:
I think as soon as we have the golden context stuff from Mika we could
drop our usage of restore_inhibit. We only need that to avoid the hw
getting angry if the context state is illegal afaik.
Apart from the contexts being over
On Tue, May 13, 2014 at 06:38:32PM +0200, Daniel Vetter wrote:
On Tue, May 13, 2014 at 05:21:49PM +0200, Jörg Otte wrote:
2014-05-13 15:22 GMT+02:00 Daniel Vetter dan...@ffwll.ch:
On Tue, May 13, 2014 at 12:38:41PM +0200, Daniel Vetter wrote:
On Tue, May 13, 2014 at 12:29 PM, Jörg Otte
On Fri, May 16, 2014 at 12:08:51PM +0100, oscar.ma...@intel.com wrote:
From: Oscar Mateo oscar.ma...@intel.com
This is a review by igt test for a bug located in
i915_gem_object_pin_to_display_plane and fixed by:
commit 392013bdd4b6128795e33c84bd6d6d3fd66ff0a3
Author: Oscar Mateo
On Fri, May 16, 2014 at 03:04:21PM +0300, Ville Syrjälä wrote:
On Fri, May 16, 2014 at 12:08:51PM +0100, oscar.ma...@intel.com wrote:
From: Oscar Mateo oscar.ma...@intel.com
This is a review by igt test for a bug located in
i915_gem_object_pin_to_display_plane and fixed by:
commit
On Thu, 2014-05-15 at 12:27 +, Ville Syrjälä wrote:
On Thu, May 15, 2014 at 11:47:37AM +0530, sourab.gu...@intel.com wrote:
From: Sourab Gupta sourab.gu...@intel.com
Using MMIO based flips on Gen5+ for Media power well residency optimization.
The blitter ring is currently being used
On Fri, May 16, 2014 at 12:34:08PM +, Gupta, Sourab wrote:
On Thu, 2014-05-15 at 12:27 +, Ville Syrjälä wrote:
On Thu, May 15, 2014 at 11:47:37AM +0530, sourab.gu...@intel.com wrote:
From: Sourab Gupta sourab.gu...@intel.com
Using MMIO based flips on Gen5+ for Media power well
-Original Message-
From: Ville Syrjälä [mailto:ville.syrj...@linux.intel.com]
Sent: Friday, May 16, 2014 1:14 PM
To: Mateo Lozano, Oscar
Cc: intel-gfx@lists.freedesktop.org
Subject: Re: [Intel-gfx] [PATCH] tests/kms_flip: test a fb backed by a bo too
big
for its own good
On
From: Oscar Mateo oscar.ma...@intel.com
Useful for testing bigger/smaller fb-wrapped buffer objects.
Cc: Ville Syrjälä ville.syrj...@linux.intel.com
Signed-off-by: Oscar Mateo oscar.ma...@intel.com
---
lib/igt_fb.c | 45 ++---
lib/igt_fb.h | 3 +++
2
From: Oscar Mateo oscar.ma...@intel.com
This is a review by igt test for a bug located in
i915_gem_object_pin_to_display_plane and fixed by:
commit 392013bdd4b6128795e33c84bd6d6d3fd66ff0a3
Author: Oscar Mateo oscar.ma...@intel.com
Date: Fri May 16 11:23:12 2014 +0100
drm/i915: Gracefully
By exporting the ability to map user address and inserting PTEs
representing their backing pages into the GTT, we can exploit UMA in order
to utilize normal application data as a texture source or even as a
render target (depending upon the capabilities of the chipset). This has
a number of uses,
From: Oscar Mateo oscar.ma...@intel.com
Otherwise, we do a NULL pointer dereference.
I've seen this happen while handling an error in
i915_gem_object_pin_to_display_plane():
If i915_gem_object_set_cache_level() fails, we call is_pin_display()
to handle the error. At this point, the object is
Hi Daniel, dear list,
just tried the latest nightly build of 3.15.0+, and I'm sorry to say
that the watermark configuration of the 830GM is still off.
This is what I get from the kernel: (not to be taken too serious, but
humor is the only thing that keeps me from getting seriously anoyed
On Fri, May 16, 2014 at 02:20:43PM +0100, oscar.ma...@intel.com wrote:
From: Oscar Mateo oscar.ma...@intel.com
Otherwise, we do a NULL pointer dereference.
I've seen this happen while handling an error in
i915_gem_object_pin_to_display_plane():
If i915_gem_object_set_cache_level()
On Fri, May 16, 2014 at 12:36:09PM +0100, Chris Wilson wrote:
On Mon, May 12, 2014 at 06:40:43PM +0200, Daniel Vetter wrote:
I think as soon as we have the golden context stuff from Mika we could
drop our usage of restore_inhibit. We only need that to avoid the hw
getting angry if the
On Fri, May 16, 2014 at 01:44:12PM +0300, Mika Kuoppala wrote:
Bit 31 in GEN6_PMINTRMSK is not an interrupt disable bit with gen8.
Reviewed-by: Ville Syrjälä ville.syrj...@linux.intel.com
Signed-off-by: Mika Kuoppala mika.kuopp...@intel.com
Queued for -next, thanks for the patch.
-Daniel
--
On Fri, 2014-05-16 at 11:06 +0200, Daniel Vetter wrote:
On Thu, May 15, 2014 at 10:46:50PM -0600, Alex Williamson wrote:
On Fri, 2014-05-16 at 00:50 +0200, Daniel Vetter wrote:
On Thu, May 15, 2014 at 11:43 PM, Alex Williamson
alex.william...@redhat.com wrote:
I don't know what to do
On Fri, May 16, 2014 at 04:02:48PM +0200, Thomas Richter wrote:
It's not that I haven't had a patch for it. Really trivial. I wonder
what keeps you from adding this to the kernel and just make things
working?
You mean this patch?
diff --git a/drivers/gpu/drm/i915/intel_pm.c
On Fri, May 16, 2014 at 04:27:34PM +0200, Daniel Vetter wrote:
On Fri, May 16, 2014 at 12:36:09PM +0100, Chris Wilson wrote:
On Mon, May 12, 2014 at 06:40:43PM +0200, Daniel Vetter wrote:
I think as soon as we have the golden context stuff from Mika we could
drop our usage of
deepa...@linux.intel.com writes:
From: Deepak S deepa...@linux.intel.com
Support to individually control Media/Render well based on the register
access.
Add CHV specific write function to habdle difference between registers
that are sadowed vs those that need forcewake even for writes.
On Fri, May 16, 2014 at 02:07:12PM +0100, oscar.ma...@intel.com wrote:
From: Oscar Mateo oscar.ma...@intel.com
This is a review by igt test for a bug located in
i915_gem_object_pin_to_display_plane and fixed by:
Thanks. Both patches pushed.
--
Ville Syrjälä
Intel OTC
On Fri, May 16, 2014 at 03:45:24PM +0100, Chris Wilson wrote:
On Fri, May 16, 2014 at 04:27:34PM +0200, Daniel Vetter wrote:
On Fri, May 16, 2014 at 12:36:09PM +0100, Chris Wilson wrote:
On Mon, May 12, 2014 at 06:40:43PM +0200, Daniel Vetter wrote:
I think as soon as we have the golden
On Fri, May 16, 2014 at 03:41:05PM +0100, Chris Wilson wrote:
On Fri, May 16, 2014 at 04:02:48PM +0200, Thomas Richter wrote:
It's not that I haven't had a patch for it. Really trivial. I wonder
what keeps you from adding this to the kernel and just make things
working?
You mean this
Reviewed-by: Brad Volkin bradley.d.vol...@intel.com
On Fri, May 16, 2014 at 02:22:37PM +0100, Chris Wilson wrote:
By exporting the ability to map user address and inserting PTEs
representing their backing pages into the GTT, we can exploit UMA in order
to utilize normal application data as a
On Fri, May 16, 2014 at 10:51:44AM +0800, Lee, Chon Ming wrote:
...
+int drm_primary_helper_check_update(struct drm_plane *plane,
+ struct drm_crtc *crtc,
+ struct drm_framebuffer *fb,
+ struct
On Thu, May 15, 2014 at 06:17:26PM -0700, Matt Roper wrote:
If drivers support universal planes and have registered a cursor plane
with the DRM core, we should use that universal plane support when
handling legacy cursor ioctls. Drivers that transition to universal
planes won't have to
On Thu, May 15, 2014 at 06:17:28PM -0700, Matt Roper wrote:
Refactor cursor buffer setting such that the code to actually update the
cursor lives in a new function, intel_crtc_cursor_set_obj(), and takes
a GEM object as a parameter. The existing legacy cursor ioctl handler,
On Thu, May 15, 2014 at 06:17:27PM -0700, Matt Roper wrote:
Universal plane support had placeholders for cursor planes, but didn't
actually do anything with them. Save the cursor plane reference inside
the crtc and update the cursor plane parameter from void* to drm_plane.
Signed-off-by:
On Fri, May 16, 2014 at 05:09:53PM +0200, Daniel Vetter wrote:
On Fri, May 16, 2014 at 03:41:05PM +0100, Chris Wilson wrote:
On Fri, May 16, 2014 at 04:02:48PM +0200, Thomas Richter wrote:
It's not that I haven't had a patch for it. Really trivial. I wonder
what keeps you from adding this
On Thu, May 15, 2014 at 06:17:29PM -0700, Matt Roper wrote:
The DRM core will translate calls to legacy cursor ioctls into universal
cursor calls automatically, so there's no need to maintain the legacy
cursor support. This greatly simplifies the transition since we don't
have to handle
Extremely unlikely to ever be required, but BIOSes do like to attack in
unexpected ways.
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
---
drivers/gpu/drm/i915/intel_display.c |2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_display.c
On Fri, May 16, 2014 at 08:34:52AM -0700, Volkin, Bradley D wrote:
Reviewed-by: Brad Volkin bradley.d.vol...@intel.com
On Fri, May 16, 2014 at 02:22:37PM +0100, Chris Wilson wrote:
By exporting the ability to map user address and inserting PTEs
representing their backing pages into the
On Fri, May 16, 2014 at 3:21 AM, Chris Wilson ch...@chris-wilson.co.ukwrote:
On Thu, May 15, 2014 at 08:13:04PM -0400, Rodrigo Vivi wrote:
Also do not cache aux info. That info could be related to another panel.
You should kill the bool sink_support then. There are other places that
it used
From: Ville Syrjälä ville.syrj...@linux.intel.com
I was looking at FIFO underruns a bit and came up with a few improvements to
the FIFO underrun reporting code. Mainly this should lead to detecting FIFO
a bit more more reliably on gmch platforms.
I also promoted the IVB/CPT uncleared FIFO
From: Ville Syrjälä ville.syrj...@linux.intel.com
FIFO underruns don't generate an interrupt on gmch platforms, so we
should check whether there were any that we failed to notice when
we're disabling FIFO underrun reporting.
Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
---
From: Ville Syrjälä ville.syrj...@linux.intel.com
Checking whether the error interrupt was enabled or not isn't really
necessary when we check for uncleared FIFO underruns. If it was enabled
we'll race with the interrupt handler a bit, but that seems OK as we
still claim the interrupt.
From: Ville Syrjälä ville.syrj...@linux.intel.com
Gen2 reports FIFO underruns whenever no planes are enabled on the pipe.
So in order to avoid false positives we must enable the FIFO underrun
reporting only when at least one plane is enabled on the pipe. For
now just move the underrun reporting
From: Ville Syrjälä ville.syrj...@linux.intel.com
FIFO underruns don't generate interrupts on gmch platforms, so
if we want to know whether a modeset triggered FIFO underruns we
need to explicitly check for them.
As a modeset on one pipe could cause underruns on other pipes,
check for underruns
From: Ville Syrjälä ville.syrj...@linux.intel.com
Some platforms have a shared error interrupt, so if FIFO underrun
reporting gets disabled for one pipe/transcoder it gets disabled
for all pipes/transcoders.
When we disable FIFO underrun reporting we check whether the
interrupt was enabled or
On Fri, May 16, 2014 at 3:23 AM, Chris Wilson ch...@chris-wilson.co.ukwrote:
On Thu, May 15, 2014 at 08:13:05PM -0400, Rodrigo Vivi wrote:
The perfect solution for psr_exit is the hardware tracking the changes
and
doing the psr exit by itself. This scenario works for HSW and BDW with
some
Hi Dave,
drm-intel-next-2014-05-06:
- ring init improvements (Chris)
- vebox2 support (Zhao Yakui)
- more prep work for runtime pm on Baytrail (Imre)
- eDram support for BDW (Ben)
- prep work for userptr support (Chris)
- first parts of the encoder-mode_set callback removal (Daniel)
- 64b reloc
On Fri, May 16, 2014 at 07:04:54PM +0300, Ville Syrjälä wrote:
On Fri, May 16, 2014 at 05:09:53PM +0200, Daniel Vetter wrote:
On Fri, May 16, 2014 at 03:41:05PM +0100, Chris Wilson wrote:
On Fri, May 16, 2014 at 04:02:48PM +0200, Thomas Richter wrote:
It's not that I haven't had a patch
On Fri, May 16, 2014 at 05:36:59PM +0100, Chris Wilson wrote:
Extremely unlikely to ever be required, but BIOSes do like to attack in
unexpected ways.
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
---
drivers/gpu/drm/i915/intel_display.c |2 ++
1 file changed, 2 insertions(+)
On Fri, May 16, 2014 at 07:40:23PM +0300, ville.syrj...@linux.intel.com wrote:
From: Ville Syrjälä ville.syrj...@linux.intel.com
Some platforms have a shared error interrupt, so if FIFO underrun
reporting gets disabled for one pipe/transcoder it gets disabled
for all pipes/transcoders.
On Fri, May 16, 2014 at 06:53:52PM +0200, Daniel Vetter wrote:
On Fri, May 16, 2014 at 05:36:59PM +0100, Chris Wilson wrote:
Extremely unlikely to ever be required, but BIOSes do like to attack in
unexpected ways.
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
---
On Fri, May 16, 2014 at 06:02:29PM +0100, Chris Wilson wrote:
On Fri, May 16, 2014 at 06:53:52PM +0200, Daniel Vetter wrote:
On Fri, May 16, 2014 at 05:36:59PM +0100, Chris Wilson wrote:
Extremely unlikely to ever be required, but BIOSes do like to attack in
unexpected ways.
2014-05-16 13:53 GMT+02:00 Ville Syrjälä ville.syrj...@linux.intel.com:
On Tue, May 13, 2014 at 06:38:32PM +0200, Daniel Vetter wrote:
On Tue, May 13, 2014 at 05:21:49PM +0200, Jörg Otte wrote:
2014-05-13 15:22 GMT+02:00 Daniel Vetter dan...@ffwll.ch:
On Tue, May 13, 2014 at 12:38:41PM
Since commit 691e6415c891b8b2b082a120b896b443531c4d45
Author: Chris Wilson ch...@chris-wilson.co.uk
Date: Wed Apr 9 09:07:36 2014 +0100
drm/i915: Always use kref tracking for all contexts.
we have contexts everywhere, and so we must be careful to distinguish
fake contexts, which do not
On Thu, 27 Mar 2014 16:22:44 -0700
Kenneth Graunke kenn...@whitecape.org wrote:
On 03/27/2014 03:44 PM, Daniel Vetter wrote:
On Thu, Mar 27, 2014 at 10:34 PM, Kenneth Graunke kenn...@whitecape.org
wrote:
Why are we parsing batches with I915_EXEC_SECURE at all? Secure batches
are only
On Fri, May 16, 2014 at 12:05:45PM -0700, Jesse Barnes wrote:
On Thu, 27 Mar 2014 16:22:44 -0700
Kenneth Graunke kenn...@whitecape.org wrote:
On 03/27/2014 03:44 PM, Daniel Vetter wrote:
On Thu, Mar 27, 2014 at 10:34 PM, Kenneth Graunke kenn...@whitecape.org
wrote:
Why are we
On Fri, 16 May 2014 20:20:50 +0100
Chris Wilson ch...@chris-wilson.co.uk wrote:
On Fri, May 16, 2014 at 12:05:45PM -0700, Jesse Barnes wrote:
On Thu, 27 Mar 2014 16:22:44 -0700
Kenneth Graunke kenn...@whitecape.org wrote:
On 03/27/2014 03:44 PM, Daniel Vetter wrote:
On Thu, Mar 27,
On Fri, May 16, 2014 at 06:59:00PM +0100, Chris Wilson wrote:
Since commit 691e6415c891b8b2b082a120b896b443531c4d45
Author: Chris Wilson ch...@chris-wilson.co.uk
Date: Wed Apr 9 09:07:36 2014 +0100
drm/i915: Always use kref tracking for all contexts.
we have contexts everywhere, and
On Fri, 16 May 2014 12:34:08 -0700
Jesse Barnes jbar...@virtuousgeek.org wrote:
On Fri, 16 May 2014 20:20:50 +0100
Chris Wilson ch...@chris-wilson.co.uk wrote:
Yes, X only sets the secure bit when it pokes the display registers, and
those registers should be privileged even with a cmd
On Fri, May 16, 2014 at 12:53:30PM -0700, Jesse Barnes wrote:
On Fri, 16 May 2014 12:34:08 -0700
Jesse Barnes jbar...@virtuousgeek.org wrote:
On Fri, 16 May 2014 20:20:50 +0100
Chris Wilson ch...@chris-wilson.co.uk wrote:
Yes, X only sets the secure bit when it pokes the display
On Fri, 16 May 2014 20:49:30 +0100
Chris Wilson ch...@chris-wilson.co.uk wrote:
On Fri, May 16, 2014 at 12:34:08PM -0700, Jesse Barnes wrote:
On Fri, 16 May 2014 20:20:50 +0100
Chris Wilson ch...@chris-wilson.co.uk wrote:
We haven't even fixed the major regression from enabling FBC.
On Fri, 16 May 2014 13:12:27 -0700
Volkin, Bradley D bradley.d.vol...@intel.com wrote:
On Fri, May 16, 2014 at 12:53:30PM -0700, Jesse Barnes wrote:
On Fri, 16 May 2014 12:34:08 -0700
Jesse Barnes jbar...@virtuousgeek.org wrote:
On Fri, 16 May 2014 20:20:50 +0100
Chris Wilson
On Thu, May 15, 2014 at 10:41:42AM +0100, Chris Wilson wrote:
More fallout from
commit c8725f3dc0911d4354315a65150aecd8b7d0d74a
Author: Chris Wilson ch...@chris-wilson.co.uk
Date: Mon Mar 17 12:21:55 2014 +
drm/i915: Do not call retire_requests from wait_for_rendering
is that
From: Clint Taylor clinton.a.tay...@intel.com
The panel power sequencer on vlv doesn't appear to accept changes to its T12
power down duration during warm reboots. This change forces a delay for warm
reboots to the T12 panel timing as defined in the VBT table for the connected
panel.
Ver2:
If it's a simple test, it needs to be in the simple lists. Tests with
subtests go into the _M tests.
Without that test enumeration is all screwed up.
Cc: Rodrigo Vivi rodrigo.v...@gmail.com
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
tests/Makefile.sources | 2 +-
1 file changed, 1
On Thu, 24 Apr 2014 23:55:42 +0200
Daniel Vetter daniel.vet...@ffwll.ch wrote:
+ if (enable) {
+ if (!intel_crtc-active) {
+ domains = get_crtc_power_domains(crtc);
+ for_each_power_domain(domain, domains)
+
On Fri, May 16, 2014 at 02:48:27PM -0700, Jesse Barnes wrote:
On Thu, 24 Apr 2014 23:55:42 +0200
Daniel Vetter daniel.vet...@ffwll.ch wrote:
+ if (enable) {
+ if (!intel_crtc-active) {
+ domains = get_crtc_power_domains(crtc);
+
On Mon, 21 Apr 2014 18:37:31 +0200
Knut Petersen knut_peter...@t-online.de wrote:
+ /* This driver doesn't need a VT switch to restore the mode on resume */
+ info-skip_vt_switch = true;
+
drm_fb_helper_fill_fix(info, fb-pitches[0], fb-depth);
drm_fb_helper_fill_var(info,
On Sat, 17 May 2014 00:19:09 +0200
Daniel Vetter dan...@ffwll.ch wrote:
On Fri, May 16, 2014 at 02:48:27PM -0700, Jesse Barnes wrote:
On Thu, 24 Apr 2014 23:55:42 +0200
Daniel Vetter daniel.vet...@ffwll.ch wrote:
+ if (enable) {
+ if (!intel_crtc-active) {
+
On Sat, May 17, 2014 at 12:20 AM, Jesse Barnes jbar...@virtuousgeek.org wrote:
On Mon, 21 Apr 2014 18:37:31 +0200
Knut Petersen knut_peter...@t-online.de wrote:
+ /* This driver doesn't need a VT switch to restore the mode on resume
*/
+ info-skip_vt_switch = true;
+
Refactor DRM setplane code into a new setplane_internal() function that
takes DRM objects directly as parameters rather than looking them up by
ID. We'll use this in a future patch when we implement legacy cursor
ioctls on top of the universal plane interface.
Signed-off-by: Matt Roper
Refactor DRM framebuffer creation into a new function that returns a
struct drm_framebuffer directly. The upcoming universal cursor support
will want to create framebuffers internally to wrap cursor buffers, so
we want to be able to share that framebuffer creation with the
drm_mode_addfb2 ioctl
If drivers support universal planes and have registered a cursor plane
with the DRM core, we should use that universal plane support when
handling legacy cursor ioctls. Drivers that transition to universal
planes won't have to maintain separate legacy ioctl handling; drivers
that don't transition
On Fri, May 16, 2014 at 03:20:47PM -0700, Jesse Barnes wrote:
On Mon, 21 Apr 2014 18:37:31 +0200
Knut Petersen knut_peter...@t-online.de wrote:
+ /* This driver doesn't need a VT switch to restore the mode on resume */
+ info-skip_vt_switch = true;
+
On Fri, May 16, 2014 at 11:38:07PM +0100, Chris Wilson wrote:
On Fri, May 16, 2014 at 03:20:47PM -0700, Jesse Barnes wrote:
On Mon, 21 Apr 2014 18:37:31 +0200
Knut Petersen knut_peter...@t-online.de wrote:
+ /* This driver doesn't need a VT switch to restore the mode on
resume
On Sat, May 17, 2014 at 12:38 AM, Matt Roper matthew.d.ro...@intel.com wrote:
+ if (ret) {
+ if (req-flags DRM_MODE_CURSOR_BO)
+ drm_mode_rmfb(dev, fb-base.id, file_priv);
+ return ret;
+ }
With the new refcount logic an
Refactor cursor buffer setting such that the code to actually update the
cursor lives in a new function, intel_crtc_cursor_set_obj(), and takes
a GEM object as a parameter. The existing legacy cursor ioctl handler,
intel_crtc_cursor_set() will now perform the userspace handle lookup and
then call
Hi,
I am trying to step through i-g-t libdrm source w/ GDB but single
stepping seems erratic so I am guessing the build is optimized. Is
changing CFLAGS = -g -O2 to CFLAGS = -g -O0 the right thing to do?
If so, how can I do that globally one time versus touching every
Makefile inside the
On 05/16/2014 04:29 PM, Michael H Nguyen wrote:
Hi,
I am trying to step through i-g-t libdrm source w/ GDB but single
stepping seems erratic so I am guessing the build is optimized. Is
changing CFLAGS = -g -O2 to CFLAGS = -g -O0 the right thing to do?
If so, how can I do that globally one
1 - 100 of 101 matches
Mail list logo
