On Sun, May 18, 2014 at 11:27:00AM +0530, Akash Goel wrote:
On Wed, 2014-05-14 at 10:14 +0200, Daniel Vetter wrote:
On Tue, May 13, 2014 at 03:43:12PM -0700, Jesse Barnes wrote:
On Wed, 14 May 2014 00:30:34 +0200
Daniel Vetter dan...@ffwll.ch wrote:
On Tue, May 13, 2014 at
This also appears to be true (but not documented as so) for gen4 and
gen5. To generalise we force it into the low mappable region for all
non-LLC platforms. If we locate the HWS at the top of the GTT the
machine will hard hang during boot (fails on pnv, gm45, ilk and byt,
but works on snb, ivb,
On Sun, May 18, 2014 at 08:13:38PM +0100, Chris Wilson wrote:
On Sun, May 18, 2014 at 09:08:40PM +0200, Thomas Meyer wrote:
Am Montag, den 12.05.2014, 07:33 +0100 schrieb Chris Wilson:
On Sun, May 11, 2014 at 07:40:57PM +0200, Daniel Vetter wrote:
On Sun, May 11, 2014 at 11:02 AM, Dave
On Fri, May 16, 2014 at 03:36:47PM -0700, Matt Roper wrote:
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
On Fri, May 16, 2014 at 03:36:48PM -0700, Matt Roper wrote:
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
On Sun, May 18, 2014 at 02:24:50AM +0200, Robin Schroer wrote:
Fixed several switch statements, curly braces, dereference operators
and keywords.
Signed-off-by: Robin Schroer sulamiificat...@gmail.com
Queued for -next, thanks for the patch.
-Daniel
---
drivers/gpu/drm/i915/intel_display.c
I didn't spot anything else, so with the below issue addressed this patch
is Reviewed-by: Daniel Vetter daniel.vet...@ffwll.ch
On Sat, May 17, 2014 at 12:43:04AM +0200, Daniel Vetter wrote:
On Sat, May 17, 2014 at 12:38 AM, Matt Roper matthew.d.ro...@intel.com
wrote:
+ if (ret) {
+
On Mon, 2014-05-19 at 08:56 +0200, Daniel Vetter wrote:
On Sun, May 18, 2014 at 11:27:00AM +0530, Akash Goel wrote:
On Wed, 2014-05-14 at 10:14 +0200, Daniel Vetter wrote:
On Tue, May 13, 2014 at 03:43:12PM -0700, Jesse Barnes wrote:
On Wed, 14 May 2014 00:30:34 +0200
Daniel Vetter
So far we used the wrong opcodes to access the DSI registers, so the
register writes during DSI programming didn't actually succeed and left
the registers unchanged. This wasn't a problem for the initial modeset,
where the BIOS-programmed values happened to work, but after resuming
from s0ix these
These opcodes are not specific for an endpoint, but are the same for all
endpoints. So rename them accordingly, using the name the VLV2 sideband
HAS uses. Also move the macros to the .c file, since they aren't used
anywhere else.
Signed-off-by: Imre Deak imre.d...@intel.com
---
On Fri, 2014-05-16 at 12:51 +, Ville Syrjälä wrote:
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
Hi Daniel,
-Original Message-
From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of Daniel Vetter
Sent: Thursday, May 15, 2014 9:52 PM
To: Mateo Lozano, Oscar
Cc: Lespiau, Damien; Daniel Vetter; intel-gfx@lists.freedesktop.org
Subject: Re: [Intel-gfx] [PATCH 06/50]
-Original Message-
From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of
ville.syrj...@linux.intel.com
Sent: Tuesday, April 29, 2014 4:06 PM
To: intel-gfx@lists.freedesktop.org
Subject: [Intel-gfx] [PATCH v2 4/9] drm/i915: Perform primary enable/disable
On Mon, May 19, 2014 at 07:56:11AM +0100, Chris Wilson wrote:
This also appears to be true (but not documented as so) for gen4 and
gen5. To generalise we force it into the low mappable region for all
non-LLC platforms. If we locate the HWS at the top of the GTT the
machine will hard hang
On Mon, May 19, 2014 at 02:49:59PM +0530, Arun Murthy wrote:
Add a mechanism by which we can evade the leading edge of vblank. This
guarantees that no two sprite register writes will straddle on either
side of the vblank start, and that means all the writes will be latched
together in one
as some tests, like drv_hangman, sets the flags with script
and then expects them to stick.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=78322
Signed-off-by: Mika Kuoppala mika.kuopp...@intel.com
---
lib/drmtest.c | 17 +
lib/igt_core.h |2 +-
2 files changed, 10
On Mon, May 19, 2014 at 04:08:09PM +0530, Arun Murthy wrote:
Add a mechanism by which we can evade the leading edge of vblank. This
guarantees that no two sprite register writes will straddle on either
side of the vblank start, and that means all the writes will be latched
together in one
Add a mechanism by which we can evade the leading edge of vblank. This
guarantees that no two sprite register writes will straddle on either
side of the vblank start, and that means all the writes will be latched
together in one atomic operation.
Here only one sprite update followed by the
-Original Message-
From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of
ville.syrj...@linux.intel.com
Sent: Tuesday, April 29, 2014 4:06 PM
To: intel-gfx@lists.freedesktop.org
Subject: [Intel-gfx] [PATCH v8 3/9] drm/i915: Make sprite updates atomic
From: Ville
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 just for command streamer based
flip calls. For pure 3D workloads, with MMIO flips, there will be no use
of blitter ring and this will
On May-15-2014 2:48 PM, Vandana Kannan wrote:
On May-13-2014 3:10 PM, Vandana Kannan wrote:
On May-13-2014 2:28 PM, Daniel Vetter wrote:
On Tue, May 13, 2014 at 01:56:04PM +0530, Vandana Kannan wrote:
On May-12-2014 3:57 PM, Ville Syrjälä wrote:
On Mon, May 05, 2014 at 01:49:31PM +0530,
On Mon, May 19, 2014 at 05:00:14PM +0530, Vandana Kannan wrote:
Please let me know your inputs on this..
Given that making changes to avoid DRRS related checks in
pipe_config_compare affects the overall design and future
implementations related to RR switching, I think that using a quirk for
On Mon, May 19, 2014 at 4:19 PM, Ville Syrjälä
ville.syrj...@linux.intel.com wrote:
On Mon, May 19, 2014 at 04:08:09PM +0530, Arun Murthy wrote:
Add a mechanism by which we can evade the leading edge of vblank. This
guarantees that no two sprite register writes will straddle on either
side
Add a mechanism by which we can evade the leading edge of vblank. This
guarantees that no two sprite register writes will straddle on either
side of the vblank start, and that means all the writes will be latched
together in one atomic operation.
Here only one sprite update followed by the
Add a mechanism by which we can evade the leading edge of vblank. This
guarantees that no two sprite register writes will straddle on either
side of the vblank start, and that means all the writes will be latched
together in one atomic operation.
Here only one sprite update followed by the
Hello!
I'm developing some openCL application with Beignet in Ubuntu 14.04 x64
Desktop upon Bay Trail E3825.
And I found that reading data from GPU memory through whatever drm_intel
gem_bo_map or drm_intel_gem_bo_get subdata cost about 0.002 ~ 0.003 second to
fetch a 7MiB array,
On Mon, May 19, 2014 at 04:28:58PM +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 just for command streamer based
flip calls. For pure 3D
Fixed several switch statements, curly braces, dereference operators
and keywords.
Signed-off-by: Robin Schroer sulamiificat...@gmail.com
---
drivers/gpu/drm/i915/intel_display.c | 18 --
1 file changed, 8 insertions(+), 10 deletions(-)
diff --git
On Mon, May 19, 2014 at 10:02:07AM +, Mateo Lozano, Oscar wrote:
Hi Daniel,
-Original Message-
From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of Daniel
Vetter
Sent: Thursday, May 15, 2014 9:52 PM
To: Mateo Lozano, Oscar
Cc: Lespiau, Damien; Daniel Vetter;
On Mon, May 19, 2014 at 01:45:37PM +0200, Daniel Vetter wrote:
On Mon, May 19, 2014 at 05:00:14PM +0530, Vandana Kannan wrote:
Please let me know your inputs on this..
Given that making changes to avoid DRRS related checks in
pipe_config_compare affects the overall design and future
On Mon, May 19, 2014 at 02:29:09PM +0200, Daniel Vetter wrote:
On Mon, May 19, 2014 at 02:47:20PM +0300, Ville Syrjälä wrote:
On Mon, May 19, 2014 at 04:28:58PM +0530, sourab.gu...@intel.com wrote:
From: Sourab Gupta sourab.gu...@intel.com
Using MMIO based flips on Gen5+ for Media
On Mon, May 19, 2014 at 3:06 PM, Ville Syrjälä
ville.syrj...@linux.intel.com wrote:
So why can't we just latch a work item which uses all the established
seqno waiting stuff and so avoids all these issues
I hate blocking and waiting for stuff. It usually means all kinds of lock
dropping
-Original Message-
From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of Daniel Vetter
Sent: Monday, May 19, 2014 1:21 PM
To: Mateo Lozano, Oscar
Cc: Daniel Vetter; Lespiau, Damien; intel-gfx@lists.freedesktop.org
Subject: Re: [Intel-gfx] [PATCH 06/50] drm/i915:
Signed-off-by: Thomas Wood thomas.w...@intel.com
---
tests/kms_flip.c | 7 +++
tests/kms_pipe_crc_basic.c | 5 +
2 files changed, 12 insertions(+)
diff --git a/tests/kms_flip.c b/tests/kms_flip.c
index f2ec9ef..7d6e102 100644
--- a/tests/kms_flip.c
+++ b/tests/kms_flip.c
@@
Add a function to force a particular state on a connector and a
convenience function to find and set the state on the VGA connector.
Signed-off-by: Thomas Wood thomas.w...@intel.com
---
lib/igt_kms.c | 78
lib/igt_kms.h | 12
These opcodes are not specific for an endpoint, but are the same for all
endpoints. So rename them accordingly, using the name the VLV2 sideband
HAS uses. Also move the macros to the .c file, since they aren't used
anywhere else.
Signed-off-by: Imre Deak imre.d...@intel.com
---
lib/intel_iosf.c
Signed-off-by: Imre Deak imre.d...@intel.com
---
lib/intel_io.h | 2 ++
lib/intel_iosf.c | 14 ++
tools/quick_dump/chipset.i | 2 ++
tools/quick_dump/quick_dump.py | 2 ++
tools/quick_dump/reg_access.py | 6 ++
On Mon, May 19, 2014 at 3:41 PM, Mateo Lozano, Oscar
oscar.ma...@intel.com wrote:
diff --git a/drivers/gpu/drm/i915/i915_drv.h
b/drivers/gpu/drm/i915/i915_drv.h index 108e1ec2fa4b..e34db43dead3
100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1825,7
We can apperently miss them, but breaking the entire driver hampers
testing. So bail out after one minute, our customerary this is a lost
cause timeout.
References: https://bugs.freedesktop.org/show_bug.cgi?id=78383
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
Hi
On Mon, May 19, 2014 at 3:37 PM, Thomas Wood thomas.w...@intel.com wrote:
Signed-off-by: Thomas Wood thomas.w...@intel.com
The commit-msg lacks any discussion why this change is done. What is
the reason to do that? Isn't the kernel-command-line enough? Why is
this a regular feature instead
From: Ville Syrjälä ville.syrj...@linux.intel.com
On pre-HSW we have two encoders per digital port: one HDMI, one DP.
However they are the same physical port in hardware and we can't enable
both at the same time. Reject the modeset if the user attempts this.
So far we've been saved by the fact
On Mon, Apr 14, 2014 at 11:18:27AM +0530, Shobhit Kumar wrote:
+#define NS_MHZ_RATIO 100
[...]
+static bool generic_init(struct intel_dsi_device *dsi)
+{
[...]
+ /*
+ * ui(s) = 1/f [f in hz]
+ * ui(ns) = 10^9/f*10^6 [f in Mhz] - 10^3/f(Mhz)
ui(ns) = 10^9/(f*10^6)
+
On Mon, May 19, 2014 at 05:19:09PM +0300, ville.syrj...@linux.intel.com wrote:
From: Ville Syrjälä ville.syrj...@linux.intel.com
On pre-HSW we have two encoders per digital port: one HDMI, one DP.
However they are the same physical port in hardware and we can't enable
both at the same time.
On Mon, May 19, 2014 at 02:42:07PM +0100, Thomas Wood wrote:
Add a function to force a particular state on a connector and a
convenience function to find and set the state on the VGA connector.
Signed-off-by: Thomas Wood thomas.w...@intel.com
---
lib/igt_kms.c | 78
On 19 May 2014 15:13, David Herrmann dh.herrm...@gmail.com wrote:
Hi
On Mon, May 19, 2014 at 3:37 PM, Thomas Wood thomas.w...@intel.com wrote:
Signed-off-by: Thomas Wood thomas.w...@intel.com
The commit-msg lacks any discussion why this change is done. What is
the reason to do that? Isn't
-Original Message-
From: daniel.vet...@ffwll.ch [mailto:daniel.vet...@ffwll.ch] On Behalf Of
Daniel Vetter
Sent: Monday, May 19, 2014 2:53 PM
To: Mateo Lozano, Oscar
Cc: Lespiau, Damien; intel-gfx@lists.freedesktop.org
Subject: Re: [Intel-gfx] [PATCH 06/50] drm/i915:
Hi
On Mon, May 19, 2014 at 4:41 PM, Thomas Wood thomas.w...@intel.com wrote:
On 19 May 2014 15:13, David Herrmann dh.herrm...@gmail.com wrote:
Hi
On Mon, May 19, 2014 at 3:37 PM, Thomas Wood thomas.w...@intel.com wrote:
Signed-off-by: Thomas Wood thomas.w...@intel.com
The commit-msg lacks
On Mon, May 19, 2014 at 04:29:57PM +0200, Daniel Vetter wrote:
On Mon, May 19, 2014 at 05:19:09PM +0300, ville.syrj...@linux.intel.com wrote:
From: Ville Syrjälä ville.syrj...@linux.intel.com
On pre-HSW we have two encoders per digital port: one HDMI, one DP.
However they are the same
On Mon, May 19, 2014 at 04:44:15PM +0200, David Herrmann wrote:
Hi
On Mon, May 19, 2014 at 4:41 PM, Thomas Wood thomas.w...@intel.com wrote:
On 19 May 2014 15:13, David Herrmann dh.herrm...@gmail.com wrote:
Hi
On Mon, May 19, 2014 at 3:37 PM, Thomas Wood thomas.w...@intel.com wrote:
On 19 May 2014 15:28, Daniel Vetter dan...@ffwll.ch wrote:
On Mon, May 19, 2014 at 02:42:07PM +0100, Thomas Wood wrote:
Add a function to force a particular state on a connector and a
convenience function to find and set the state on the VGA connector.
Signed-off-by: Thomas Wood
On Mon, 19 May 2014 11:41:17 +0300
Imre Deak imre.d...@intel.com wrote:
These opcodes are not specific for an endpoint, but are the same for all
endpoints. So rename them accordingly, using the name the VLV2 sideband
HAS uses. Also move the macros to the .c file, since they aren't used
On Mon, 19 May 2014 11:41:18 +0300
Imre Deak imre.d...@intel.com wrote:
So far we used the wrong opcodes to access the DSI registers, so the
register writes during DSI programming didn't actually succeed and left
the registers unchanged. This wasn't a problem for the initial modeset,
where
On Mon, 19 May 2014 16:48:31 +0300
Imre Deak imre.d...@intel.com wrote:
These opcodes are not specific for an endpoint, but are the same for all
endpoints. So rename them accordingly, using the name the VLV2 sideband
HAS uses. Also move the macros to the .c file, since they aren't used
On Mon, 19 May 2014 16:09:35 +0200
Daniel Vetter daniel.vet...@ffwll.ch wrote:
We can apperently miss them, but breaking the entire driver hampers
testing. So bail out after one minute, our customerary this is a lost
cause timeout.
References:
On Mon, 2014-05-19 at 08:03 -0700, Jesse Barnes wrote:
On Mon, 19 May 2014 16:48:31 +0300
Imre Deak imre.d...@intel.com wrote:
These opcodes are not specific for an endpoint, but are the same for all
endpoints. So rename them accordingly, using the name the VLV2 sideband
HAS uses. Also
On Mon, May 19, 2014 at 02:43:05PM +, Mateo Lozano, Oscar wrote:
-Original Message-
From: daniel.vet...@ffwll.ch [mailto:daniel.vet...@ffwll.ch] On Behalf Of
Daniel Vetter
Sent: Monday, May 19, 2014 2:53 PM
To: Mateo Lozano, Oscar
Cc: Lespiau, Damien;
On Tue, 13 May 2014 10:41:58 +0300
Jani Nikula jani.nik...@linux.intel.com wrote:
On Thu, 08 May 2014, Ben Widawsky benjamin.widaw...@intel.com wrote:
Daniel requested in the bug that I use a 3GB fallback size. Since this
is not in the spec as a valid size, I decided against it. We could
On Mon, 2014-05-19 at 08:01 -0700, Jesse Barnes wrote:
On Mon, 19 May 2014 11:41:18 +0300
Imre Deak imre.d...@intel.com wrote:
So far we used the wrong opcodes to access the DSI registers, so the
register writes during DSI programming didn't actually succeed and left
the registers
On Mon, May 19, 2014 at 03:57:36PM +0100, Thomas Wood wrote:
On 19 May 2014 15:28, Daniel Vetter dan...@ffwll.ch wrote:
On Mon, May 19, 2014 at 02:42:07PM +0100, Thomas Wood wrote:
Add a function to force a particular state on a connector and a
convenience function to find and set the state
On Mon, May 19, 2014 at 08:06:06AM -0700, Jesse Barnes wrote:
On Mon, 19 May 2014 16:09:35 +0200
Daniel Vetter daniel.vet...@ffwll.ch wrote:
We can apperently miss them, but breaking the entire driver hampers
testing. So bail out after one minute, our customerary this is a lost
cause
This patchset contains 2 patches, which slightly change the DSI register
definitions in such a way, that the same definition can be used for future
platforms also.
1. drm/i915: Add MIPI mmio reg base
This patch adds a variable mipi_mmio_base in dev_private, and initializes
it for VLV. The
This patch adds a mmio base address variable for DSI display,
to make the DSI code generic, so that, if required, the same code
can be re-used for future platforms with different mmio base.
Signed-off-by: Shashank Sharma shashank.sha...@intel.com
---
drivers/gpu/drm/i915/i915_drv.h |3 +++
Re-define MIPI register definitions in such a way that most of
the existing DSI code can be re-used for future platforms. Register
definitions are re-written using MMIO offset variable, so that without
changing the existing sequence, same code can be generically applied.
Signed-off-by: Shashank
-Original Message-
From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of Daniel Vetter
Sent: Monday, May 19, 2014 4:12 PM
To: Mateo Lozano, Oscar
Cc: Daniel Vetter; Lespiau, Damien; intel-gfx@lists.freedesktop.org
Subject: Re: [Intel-gfx] [PATCH 06/50] drm/i915:
On Mon, 19 May 2014 18:10:18 +0300
Imre Deak imre.d...@intel.com wrote:
On Mon, 2014-05-19 at 08:01 -0700, Jesse Barnes wrote:
On Mon, 19 May 2014 11:41:18 +0300
Imre Deak imre.d...@intel.com wrote:
So far we used the wrong opcodes to access the DSI registers, so the
register writes
On Mon, 19 May 2014 17:18:40 +0200
Daniel Vetter dan...@ffwll.ch wrote:
On Mon, May 19, 2014 at 08:06:06AM -0700, Jesse Barnes wrote:
On Mon, 19 May 2014 16:09:35 +0200
Daniel Vetter daniel.vet...@ffwll.ch wrote:
We can apperently miss them, but breaking the entire driver hampers
On Mon, May 19, 2014 at 08:35:27AM -0700, Jesse Barnes wrote:
On Mon, 19 May 2014 17:18:40 +0200
Daniel Vetter dan...@ffwll.ch wrote:
On Mon, May 19, 2014 at 08:06:06AM -0700, Jesse Barnes wrote:
On Mon, 19 May 2014 16:09:35 +0200
Daniel Vetter daniel.vet...@ffwll.ch wrote:
We
On Mon, May 19, 2014 at 08:54:03PM +0530, Shashank Sharma wrote:
This patch adds a mmio base address variable for DSI display,
to make the DSI code generic, so that, if required, the same code
can be re-used for future platforms with different mmio base.
Signed-off-by: Shashank Sharma
On Mon, May 19, 2014 at 03:26:09PM +, Mateo Lozano, Oscar wrote:
I think special-casing the i915_gem_context_get function for the default
context and using private_default_ctx a bit more sounds good. We need to
adjust the idr allocator a bit though to reserve 0, and a bit of frobbing
On Mon, May 19, 2014 at 08:33:16AM -0700, Jesse Barnes wrote:
On Mon, 19 May 2014 18:10:18 +0300
Imre Deak imre.d...@intel.com wrote:
On Mon, 2014-05-19 at 08:01 -0700, Jesse Barnes wrote:
On Mon, 19 May 2014 11:41:18 +0300
Imre Deak imre.d...@intel.com wrote:
So far we used
On Mon, May 19, 2014 at 04:41:31PM +0100, Chris Wilson wrote:
On Mon, May 19, 2014 at 08:35:27AM -0700, Jesse Barnes wrote:
On Mon, 19 May 2014 17:18:40 +0200
Daniel Vetter dan...@ffwll.ch wrote:
On Mon, May 19, 2014 at 08:06:06AM -0700, Jesse Barnes wrote:
On Mon, 19 May 2014
On Mon, May 19, 2014 at 04:45:26PM +0100, Damien Lespiau wrote:
On Mon, May 19, 2014 at 08:54:03PM +0530, Shashank Sharma wrote:
This patch adds a mmio base address variable for DSI display,
to make the DSI code generic, so that, if required, the same code
can be re-used for future
On Mon, May 19, 2014 at 04:45:26PM +0100, Damien Lespiau wrote:
On Mon, May 19, 2014 at 08:54:03PM +0530, Shashank Sharma wrote:
This patch adds a mmio base address variable for DSI display,
to make the DSI code generic, so that, if required, the same code
can be re-used for future
-Original Message-
From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf
Of Chris Wilson
Sent: Tuesday, March 25, 2014 1:23 PM
To: intel-gfx@lists.freedesktop.org
Cc: Hugh Dickins
Subject: [Intel-gfx] [PATCH 1/4] drm/i915: Translate ENOSPC from
shmem_get_page()
-Original Message-
From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf
Of Chris Wilson
Sent: Tuesday, March 25, 2014 1:23 PM
To: intel-gfx@lists.freedesktop.org
Cc: Hugh Dickins
Subject: [Intel-gfx] [PATCH 2/4] drm/i915: Include bound and active pages in
the
-Original Message-
From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf
Of Chris Wilson
Sent: Tuesday, March 25, 2014 1:23 PM
To: intel-gfx@lists.freedesktop.org
Cc: Hugh Dickins
Subject: [Intel-gfx] [PATCH 4/4] drm/i915: Invalidate our pages under
memory
-Original Message-
From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf
Of Chris Wilson
Sent: Tuesday, March 25, 2014 1:23 PM
To: intel-gfx@lists.freedesktop.org
Cc: Hugh Dickins
Subject: [Intel-gfx] [PATCH 3/4] drm/i915: Refactor common lock handling
between
On Mon, May 19, 2014 at 08:54:04PM +0530, Shashank Sharma wrote:
Re-define MIPI register definitions in such a way that most of
the existing DSI code can be re-used for future platforms. Register
definitions are re-written using MMIO offset variable, so that without
changing the existing
-
Intel Corporation (UK) Limited
Registered No. 1134945 (England)
Registered Office: Pipers Way, Swindon SN3 1RJ
VAT No: 860 2173 47
-Original Message-
From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of
This reverts commit f00efff326610fdba92dbc91d951790a3320052e.
This is a temporary revert since I want QA to first test with the
original testcase whether it got faster again. This is to test the
effects of
commit 227f782e4667fc622810bce8be8ccdeee45f89c2
Author: Chris Wilson
Hi
On Mon, May 19, 2014 at 4:53 PM, Daniel Vetter dan...@ffwll.ch wrote:
On Mon, May 19, 2014 at 04:44:15PM +0200, David Herrmann wrote:
On Mon, May 19, 2014 at 4:41 PM, Thomas Wood thomas.w...@intel.com wrote:
It was intended as a debug/testing feature to allow tests in
intel-gpu-tools to
From: Ville Syrjälä ville.syrj...@linux.intel.com
We're using the reset domains bits for g4x on ilk. But on ilk those bits
actually shifted by one bit. Fix it up so that we use the correct bits.
We were actually always writing 0x2 to the reset domain bits, which
is a reserved value. In practice
On Mon, May 19, 2014 at 09:12:26AM -0700, Mateo Lozano, Oscar wrote:
BTW: do you want me to kill private_default_ctx as well? It doesn´t look very
useful...
Isn't private_default_ctx the one that's actually used when userspace
specifies DEFAULT_CONTEXT_ID?
Brad
From: Ville Syrjälä ville.syrj...@linux.intel.com
Clear the reset domain after a succesful GPU reset on ilk. We already
do that on gen4, so let's try to be a bit more consistent. And if
ether render or media reset fails, we might use the leftover value
in the register to pinpoint the culprit.
From: Ville Syrjälä ville.syrj...@linux.intel.com
Apparently we need to disable VCP unit clock gating around media reset
on g4x.
Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
---
drivers/gpu/drm/i915/i915_reg.h | 4
drivers/gpu/drm/i915/intel_uncore.c | 36
From: Ville Syrjälä ville.syrj...@linux.intel.com
All the other bits in the GDSR register are read-only, so we don't have
to preserve them when we perform a GPU reset.
Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
---
drivers/gpu/drm/i915/intel_uncore.c | 9 ++---
1 file
From: Ville Syrjälä ville.syrj...@linux.intel.com
I was looking through the docs and spotted all kinds of nonsense in our
reset code. The ilk code was totally bonkers. g4x just missed one
workaround. The rest of gen4 looks rather wrong too, but I didn't want
to touch that yet.
Quickly tested on
From: Ville Syrjälä ville.syrj...@linux.intel.com
There are comments in the gen4-5 reset functions stating that we can't
reset render and media without also doing a display reset. But that's
exactly what the code does, ie. we don't perform a display reset. Drop
the bogus comments.
Signed-off-by:
From: Ville Syrjälä ville.syrj...@linux.intel.com
We should be waiting for the reset bit to clear, not remain set.
Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
---
drivers/gpu/drm/i915/intel_uncore.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git
On Mon, 19 May 2014 19:23:22 +0300
ville.syrj...@linux.intel.com wrote:
From: Ville Syrjälä ville.syrj...@linux.intel.com
There are comments in the gen4-5 reset functions stating that we can't
reset render and media without also doing a display reset. But that's
exactly what the code does,
On Mon, 19 May 2014 19:23:23 +0300
ville.syrj...@linux.intel.com wrote:
From: Ville Syrjälä ville.syrj...@linux.intel.com
We should be waiting for the reset bit to clear, not remain set.
Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
---
drivers/gpu/drm/i915/intel_uncore.c |
On Fri, May 09, 2014 at 05:08:32AM -0700, oscar.ma...@intel.com wrote:
From: Ben Widawsky benjamin.widaw...@intel.com
for_each_ring() iterates over all rings supported by the hardware, not
just those which have been initialized as in for_each_active_ring()
I think we should give this a new
On Mon, 19 May 2014 19:23:24 +0300
ville.syrj...@linux.intel.com wrote:
From: Ville Syrjälä ville.syrj...@linux.intel.com
We're using the reset domains bits for g4x on ilk. But on ilk those bits
actually shifted by one bit. Fix it up so that we use the correct bits.
We were actually
On Mon, 19 May 2014 18:13:22 +0200
Daniel Vetter daniel.vet...@ffwll.ch wrote:
This reverts commit f00efff326610fdba92dbc91d951790a3320052e.
This is a temporary revert since I want QA to first test with the
original testcase whether it got faster again. This is to test the
effects of
Yeah
-Original Message-
From: Volkin, Bradley D
Sent: Monday, May 19, 2014 5:24 PM
To: Mateo Lozano, Oscar
Cc: Daniel Vetter; intel-gfx@lists.freedesktop.org
Subject: Re: [Intel-gfx] [PATCH 06/50] drm/i915:
s/intel_ring_buffer/intel_engine
On Mon, May 19, 2014 at 09:12:26AM -0700,
-Original Message-
From: Volkin, Bradley D
Sent: Monday, May 19, 2014 5:34 PM
To: Mateo Lozano, Oscar
Cc: intel-gfx@lists.freedesktop.org; Ben Widawsky; Widawsky, Benjamin
Subject: Re: [Intel-gfx] [PATCH 02/50] drm/i915: for_each_ring
On Fri, May 09, 2014 at 05:08:32AM -0700,
On Mon, May 19, 2014 at 09:33:37AM -0700, Mateo Lozano, Oscar wrote:
-Original Message-
From: Volkin, Bradley D
Sent: Monday, May 19, 2014 5:24 PM
To: Mateo Lozano, Oscar
Cc: Daniel Vetter; intel-gfx@lists.freedesktop.org
Subject: Re: [Intel-gfx] [PATCH 06/50] drm/i915:
-Original Message-
From: Volkin, Bradley D
Sent: Monday, May 19, 2014 5:41 PM
To: Mateo Lozano, Oscar
Cc: Daniel Vetter; intel-gfx@lists.freedesktop.org
Subject: Re: [Intel-gfx] [PATCH 06/50] drm/i915:
s/intel_ring_buffer/intel_engine
On Mon, May 19, 2014 at 09:33:37AM -0700,
On Mon, May 19, 2014 at 09:49:31AM -0700, Mateo Lozano, Oscar wrote:
-Original Message-
From: Volkin, Bradley D
Sent: Monday, May 19, 2014 5:41 PM
To: Mateo Lozano, Oscar
Cc: Daniel Vetter; intel-gfx@lists.freedesktop.org
Subject: Re: [Intel-gfx] [PATCH 06/50] drm/i915:
On 15.05.2014 10:19, Chris Wilson wrote:
On Thu, May 15, 2014 at 11:13:01AM +0300, Jani Nikula wrote:
On Wed, 14 May 2014, Knut Petersen knut_peter...@t-online.de wrote:
On 13.05.2014 22:24, Jesse Barnes wrote:
On Tue, 13 May 2014 16:50:12 +0100
Chris Wilson ch...@chris-wilson.co.uk wrote:
1 - 100 of 118 matches
Mail list logo
