Re: [Intel-gfx] [PATCH] drm/i915: Silence a sparse warning
On Thu, Apr 02, 2015 at 06:28:07PM +0300, ville.syrj...@linux.intel.com wrote:
From: Ville Syrjälä ville.syrj...@linux.intel.com
../drivers/gpu/drm/i915/intel_pm.c:3185:45: warning: Initializer entry
defined twice
../drivers/gpu/drm/i915/intel_pm.c:3185:52: also defined here
Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
Queued for -next, thanks for the patch.
-Daniel
---
drivers/gpu/drm/i915/intel_pm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 8775509..b31b204 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -3182,7 +3182,7 @@ static void skl_flush_wm_values(struct drm_i915_private
*dev_priv,
{
struct drm_device *dev = dev_priv-dev;
struct skl_ddb_allocation *cur_ddb, *new_ddb;
- bool reallocated[I915_MAX_PIPES] = {false, false, false};
+ bool reallocated[I915_MAX_PIPES] = {};
struct intel_crtc *crtc;
enum pipe pipe;
--
2.0.5
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/2] drm/i915/bxt: Determine BXT slice/subslice/EU info
On Thu, Apr 02, 2015 at 02:50:09PM -0700, Jeff McGee wrote:
On Wed, Apr 01, 2015 at 08:20:44AM +0200, Daniel Vetter wrote:
On Tue, Mar 31, 2015 at 09:59:22AM -0700, jeff.mc...@intel.com wrote:
From: Jeff McGee jeff.mc...@intel.com
BXT uses a subset of the SKL fuse registers, because it has at
most 1 slice and at most 6 EU per subslice.
Signed-off-by: Jeff McGee jeff.mc...@intel.com
---
drivers/gpu/drm/i915/i915_dma.c | 47
+
1 file changed, 47 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_dma.c
b/drivers/gpu/drm/i915/i915_dma.c
index ec661fe..81afd31 100644
--- a/drivers/gpu/drm/i915/i915_dma.c
+++ b/drivers/gpu/drm/i915/i915_dma.c
@@ -733,6 +733,53 @@ static void intel_device_info_runtime_init(struct
drm_device *dev)
info-has_slice_pg = (info-slice_total 1) ? 1 : 0;
info-has_subslice_pg = 0;
info-has_eu_pg = (info-eu_per_subslice 2) ? 1 : 0;
+ } else if (IS_BROXTON(dev)) {
By all reasonable standards this function is getting a bit too long. Can
you please create a patch to extract the various platform-specific sseu
detection logic.
Also can't we just repurpose the skl version by limiting s_max
appropriately and applying
diff --git a/drivers/gpu/drm/i915/i915_dma.c
b/drivers/gpu/drm/i915/i915_dma.c
index 68e0c85a17cf..b164aeb09158 100644
--- a/drivers/gpu/drm/i915/i915_dma.c
+++ b/drivers/gpu/drm/i915/i915_dma.c
@@ -668,9 +668,8 @@ static void intel_device_info_runtime_init(struct
drm_device *dev)
ss_disable = (fuse2 GEN9_F2_SS_DIS_MASK)
GEN9_F2_SS_DIS_SHIFT;
- eu_disable[0] = I915_READ(GEN8_EU_DISABLE0);
- eu_disable[1] = I915_READ(GEN8_EU_DISABLE1);
- eu_disable[2] = I915_READ(GEN8_EU_DISABLE2);
+ for (s = 0; s s_max; s++)
+ eu_disable[s] = I915_READ(GEN8_EU_DISABLE(s));
info-slice_total = hweight32(s_enable);
with a suitable added #define ofc?
-Daniel
Agree with all of the above. Regarding the 2nd patch in this series which
performs related logic in i915_debugfs, would you like to see that broken
up similarly?
Yeah I think the same rework would benefit the debugfs code too, if only
for consistency.
Thanks, Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/2] drm/i915/skl: Allow universal planes to position
On 4/7/2015 1:46 PM, Daniel Vetter wrote: On Mon, Apr 06, 2015 at 10:50:51AM +0530, Jindal, Sonika wrote: On 4/2/2015 9:18 PM, Matt Roper wrote: On Thu, Apr 02, 2015 at 10:08:27AM +0530, Jindal, Sonika wrote: On 4/1/2015 11:51 PM, Matt Roper wrote: On Mon, Mar 30, 2015 at 02:04:56PM +0530, Sonika Jindal wrote: Signed-off-by: Sonika Jindal sonika.jin...@intel.com It looks like this is dependent on Ville's patch [PATCH v2 6/9] drm/i915: Pass the primary plane position to .update_primary_plane() to actually let us do something sensible with the destination rectangle at the hardware level. Looks like that patch has a r-b, but hasn't made it into di-nightly yet. Right now, can_position is used to check for the scenarios where the primary plane is not covering the complete crtc. This could be due to positioning or a smaller fb on primary plane. With Ville's patch, we would be able to allow positioning to happen. But I need it here, to create a smaller fb for 90/270 rotation. I agree that, until Ville's patch is there, we won't be entertaining any positioning requests on the primary plane and we will not be throwing any error also. Right...and I think failing to throw an error would be seen as a bug, which is why I think Ville's patch needs to go in first. Since it's already been reviewed, I'm not aware of anything holding that up from happening. Agree, will check with Daniel on this. But for the 90/270 testcase in kms_rotation_crc to go through, we would need this to create a smaller fb so that we can rotate it. So is your worry here that drm_plane_helper_check_update() doesn't understand rotation and winds up mixing up width/height? If so, I think the proper course of action is to write a patch for the helper function that makes it rotation-aware. No, the worry is that it rejects a smaller fb for primary plane for all the platforms. I mentioned 90/270 rotation, because I create a smaller fb (rather than the full screen fb), so that the rotated plane fits into the screen. If it is lets say 1920x1080, and the pipe is set at 1920x1080, after rotation the plane becomes 1080x1920 and the height of the plane surpasses that of crtc. For gen =9 , we can have smaller fb for primary plane which might not cover the entire crtc. That sounds like a bug in the helper though if it rejects such a framebuffer. -Daniel Till now we used to have primary plane covering the crtc, so its not a bug. For gen 9 we can have smaller primary planes (or with other platforms as well?) Anyways, we need to add this patch to get past that restriction. Regards, Sonika ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/2] drm/i915/skl: Allow universal planes to position
On Mon, Apr 06, 2015 at 10:50:51AM +0530, Jindal, Sonika wrote: On 4/2/2015 9:18 PM, Matt Roper wrote: On Thu, Apr 02, 2015 at 10:08:27AM +0530, Jindal, Sonika wrote: On 4/1/2015 11:51 PM, Matt Roper wrote: On Mon, Mar 30, 2015 at 02:04:56PM +0530, Sonika Jindal wrote: Signed-off-by: Sonika Jindal sonika.jin...@intel.com It looks like this is dependent on Ville's patch [PATCH v2 6/9] drm/i915: Pass the primary plane position to .update_primary_plane() to actually let us do something sensible with the destination rectangle at the hardware level. Looks like that patch has a r-b, but hasn't made it into di-nightly yet. Right now, can_position is used to check for the scenarios where the primary plane is not covering the complete crtc. This could be due to positioning or a smaller fb on primary plane. With Ville's patch, we would be able to allow positioning to happen. But I need it here, to create a smaller fb for 90/270 rotation. I agree that, until Ville's patch is there, we won't be entertaining any positioning requests on the primary plane and we will not be throwing any error also. Right...and I think failing to throw an error would be seen as a bug, which is why I think Ville's patch needs to go in first. Since it's already been reviewed, I'm not aware of anything holding that up from happening. Agree, will check with Daniel on this. But for the 90/270 testcase in kms_rotation_crc to go through, we would need this to create a smaller fb so that we can rotate it. So is your worry here that drm_plane_helper_check_update() doesn't understand rotation and winds up mixing up width/height? If so, I think the proper course of action is to write a patch for the helper function that makes it rotation-aware. No, the worry is that it rejects a smaller fb for primary plane for all the platforms. I mentioned 90/270 rotation, because I create a smaller fb (rather than the full screen fb), so that the rotated plane fits into the screen. If it is lets say 1920x1080, and the pipe is set at 1920x1080, after rotation the plane becomes 1080x1920 and the height of the plane surpasses that of crtc. For gen =9 , we can have smaller fb for primary plane which might not cover the entire crtc. That sounds like a bug in the helper though if it rejects such a framebuffer. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/bdw: WaProgramL3SqcReg1Default
On Wed, Apr 01, 2015 at 06:41:32PM +0300, Ville Syrjälä wrote: On Tue, Mar 31, 2015 at 04:03:21PM -0700, Rodrigo Vivi wrote: Program the default initial value of the L3SqcReg1 on BDW for performance v2: Default confirmed and using intel_ring_emit_wa as Mika pointed out. v3: Spec shows now a different value. It tells us to set to 0x784000 instead the 0x61 that is there already. Also rebased after a long time so using WA_WRITE now. Cc: Mika Kuoppala mika.kuopp...@intel.com Signed-off-by: Rodrigo Vivi rodrigo.v...@intel.com Reviewed-by: Ville Syrjälä ville.syrj...@linux.intel.com Queued for -next, thanks for the patch. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Clean-up idr table if context create fails.
On Thu, Apr 02, 2015 at 06:49:38PM +0530, Deepak S wrote: On Monday 30 March 2015 09:13 PM, Daniel Vetter wrote: On Mon, Mar 30, 2015 at 08:03:58PM +0530, deepa...@linux.intel.com wrote: From: Deepak S deepa...@linux.intel.com Cleanup idr table if any error happens after __create_hw_context() in i915_gem_create_context() Signed-off-by: Deepak S deepa...@linux.intel.com --- drivers/gpu/drm/i915/i915_gem_context.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/gpu/drm/i915/i915_gem_context.c b/drivers/gpu/drm/i915/i915_gem_context.c index f3e84c4..69bebe5 100644 --- a/drivers/gpu/drm/i915/i915_gem_context.c +++ b/drivers/gpu/drm/i915/i915_gem_context.c @@ -287,6 +287,8 @@ err_unpin: if (is_global_default_ctx ctx-legacy_hw_ctx.rcs_state) i915_gem_object_ggtt_unpin(ctx-legacy_hw_ctx.rcs_state); err_destroy: + if (ctx-file_priv) + idr_remove(ctx-file_priv-context_idr, ctx-user_handle); The common approach is to add a new err_idr: label at the op of the unwind code and make the call to idr_remove unconditional. Thanks, Daniel Thanks Daniel for review. I do not think we can have a unconditional idr remove since for global ctx i915_gem_create_context called with file_priv=NULL? Hm right, the entire control-flow in there is a bit funny. I think a much cleaner solution would be to drop the file_prive from create_context and add a new i915_gem_context_create_user which wraps create_context and the idr allocation. Doing the cleanup, conditionally, in a different function than where we do the allocation is a bit too brittle imo. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 15/19] drm/i915: HSW cdclk support
On Tue, Apr 07, 2015 at 12:33:40PM +0530, Sivakumar Thulasimani wrote: sorry if i am missing something, HSW and BDW requires display audio controller to be updated with new values once CD clock is modified. how is this accomplished here ? I'm hoping the audio driver will query the cdclk frequency after every modeset. -- Ville Syrjälä Intel OTC ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Dont enable CS_PARSER_ERROR interrupts at all
On Wed, Apr 01, 2015 at 01:43:46PM +0200, Daniel Vetter wrote:
We stopped handling them in
commit aaecdf611a05cac26a94713bad25297e60225c29
Author: Daniel Vetter daniel.vet...@ffwll.ch
Date: Tue Nov 4 15:52:22 2014 +0100
drm/i915: Stop gathering error states for CS error interrupts
but just clearing is apparently not enough: A sufficiently dead gpu
left behind by firmware (*cough* coreboot *cough*) can keep the gpu in
an endless loop of such interrupts, eventually leading to the nmi
firing. And definitely to what looks like a machine hang.
Since we don't even enable these interrupts on gen5+ let's do the same
on earlier platforms.
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=93171
Signed-off-by: Daniel Vetter daniel.vet...@intel.com
Tested-by: Mono mono-for-kernel-...@donderklumpen.de
Tested-by: i...@gluglug.org.uk
Cc: sta...@vger.kernel.org
---
drivers/gpu/drm/i915/i915_irq.c | 8 ++--
1 file changed, 2 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 14ecb4d13a1a..6d494432b19f 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -3598,14 +3598,12 @@ static int i8xx_irq_postinstall(struct drm_device
*dev)
~(I915_DISPLAY_PIPE_A_EVENT_INTERRUPT |
I915_DISPLAY_PIPE_B_EVENT_INTERRUPT |
I915_DISPLAY_PLANE_A_FLIP_PENDING_INTERRUPT |
- I915_DISPLAY_PLANE_B_FLIP_PENDING_INTERRUPT |
- I915_RENDER_COMMAND_PARSER_ERROR_INTERRUPT);
+ I915_DISPLAY_PLANE_B_FLIP_PENDING_INTERRUPT);
I915_WRITE16(IMR, dev_priv-irq_mask);
I915_WRITE16(IER,
I915_DISPLAY_PIPE_A_EVENT_INTERRUPT |
I915_DISPLAY_PIPE_B_EVENT_INTERRUPT |
- I915_RENDER_COMMAND_PARSER_ERROR_INTERRUPT |
I915_USER_INTERRUPT);
POSTING_READ16(IER);
@@ -3767,14 +3765,12 @@ static int i915_irq_postinstall(struct drm_device
*dev)
I915_DISPLAY_PIPE_A_EVENT_INTERRUPT |
I915_DISPLAY_PIPE_B_EVENT_INTERRUPT |
I915_DISPLAY_PLANE_A_FLIP_PENDING_INTERRUPT |
- I915_DISPLAY_PLANE_B_FLIP_PENDING_INTERRUPT |
- I915_RENDER_COMMAND_PARSER_ERROR_INTERRUPT);
+ I915_DISPLAY_PLANE_B_FLIP_PENDING_INTERRUPT);
enable_mask =
I915_ASLE_INTERRUPT |
I915_DISPLAY_PIPE_A_EVENT_INTERRUPT |
I915_DISPLAY_PIPE_B_EVENT_INTERRUPT |
- I915_RENDER_COMMAND_PARSER_ERROR_INTERRUPT |
I915_USER_INTERRUPT;
if (I915_HAS_HOTPLUG(dev)) {
--
2.1.4
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 06/20] drm/i915: Convert primary plane 16.16 values to regular ints
On Thu, Apr 02, 2015 at 04:03:22PM -0700, Matt Roper wrote: On Wed, Apr 01, 2015 at 07:59:35PM -0700, Chandra Konduru wrote: This patch converts intel_plane_state-src rect from 16.16 values into regular ints. This approach aligns with sprite_plane_state-src rects which are already in regular ints. Signed-off-by: Chandra Konduru chandra.kond...@intel.com You're not touching cursor state here, so I guess it stays in 16.16 form always? Does it need to be updated to behave the same way? Looking at our sprite code today, it treats intel_state-src as 16.16 for most of the check function, then re-writes it as integer pixels near the end, which I guess matches the type of change you're doing here. I still find this pretty confusing that our structure is sometimes interpreted in one way and other times interpreted a different way. Personally I think it would be less error-prone if we just treated src as 16.16 always, but if you to keep the current logic which changes the meaning at the end of the check() stage, can you add some comments to struct intel_plane_state clarifying that? Rewriting intel_plane_state won't work since on duplicate_state we'd need to undo that again. That's a bit too brittle imo. I'd go with Matt's suggestion to just use 16.16 everywhere. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Allow userptr backchannel for passing aroung GTT mappings
On Thu, Apr 02, 2015 at 04:04:14PM +0100, Chris Wilson wrote:
Once userptr becomes part of client API, it is almost a certainly that
eventually someone will try to create a new object from a mapping of
another client object, e.g.
new = vaImport(vaMap(old, size), size);
(using a hypothethical API, not meaning to pick on anyone!)
Since this is actually fairly safe to implement and to allow (since it
is within a single process space and the memory access passes the
standard permissions test) let us not limit the Client possibilities.
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
Cc: Gwenole Beauchesne gwenole.beauche...@intel.com
Cc: Michał Winiarski michal.winiar...@intel.com
Cc: Tvrtko Ursulin tvrtko.ursu...@intel.com
Thus far all the apis are very explicit in stating that you can only slurp
in anything that's allocated with malloc and friends. Also usually this
means we're dealing with tiled memory which looks linear, so I'm not sure
how this will work.
-Daniel
---
drivers/gpu/drm/i915/i915_gem_userptr.c | 46
++---
1 file changed, 43 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_userptr.c
b/drivers/gpu/drm/i915/i915_gem_userptr.c
index d96276caab49..8031ebe424fd 100644
--- a/drivers/gpu/drm/i915/i915_gem_userptr.c
+++ b/drivers/gpu/drm/i915/i915_gem_userptr.c
@@ -750,6 +750,35 @@ static const struct drm_i915_gem_object_ops
i915_gem_userptr_ops = {
.release = i915_gem_userptr_release,
};
+static struct drm_i915_gem_object *
+find_object_from_vma(struct drm_device *dev,
+ struct drm_i915_gem_userptr *args)
+{
+ struct drm_i915_gem_object *obj = NULL;
+ struct vm_area_struct *vma;
+
+ down_read(current-mm-mmap_sem);
+ vma = find_vma(current-mm, args-user_ptr);
+ if (vma == NULL)
+ goto out;
+
+ if (vma-vm_ops != dev-driver-gem_vm_ops)
+ goto out;
+
+ if (vma-vm_start != args-user_ptr ||
+ vma-vm_end != args-user_ptr + args-user_size) {
+ obj = ERR_PTR(-EINVAL);
+ goto out;
+ }
+
+ obj = to_intel_bo(vma-vm_private_data);
+ drm_gem_object_reference(obj);
+
+out:
+ up_read(current-mm-mmap_sem);
+ return obj;
+}
+
/**
* Creates a new mm object that wraps some normal memory from the process
* context - user memory.
@@ -757,8 +786,11 @@ static const struct drm_i915_gem_object_ops
i915_gem_userptr_ops = {
* We impose several restrictions upon the memory being mapped
* into the GPU.
* 1. It must be page aligned (both start/end addresses, i.e ptr and size).
- * 2. It must be normal system memory, not a pointer into another map of IO
- *space (e.g. it must not be a GTT mmapping of another object).
+ * 2. It must either be:
+ *a) normal system memory, not a pointer into another map of IO
+ * space (e.g. it must not be part of a GTT mmapping of another
object).
+ *b) a pointer to the complete GTT mmap of another object in your
+ * address space.
* 3. We only allow a bo as large as we could in theory map into the GTT,
*that is we limit the size to the total size of the GTT.
* 4. The bo is marked as being snoopable. The backing pages are left
@@ -812,6 +844,14 @@ i915_gem_userptr_ioctl(struct drm_device *dev, void
*data, struct drm_file *file
return -ENODEV;
}
+ obj = find_object_from_vma(dev, args);
+ if (obj) {
+ if (IS_ERR(obj))
+ return PTR_ERR(obj);
+ else
+ goto out;
+ }
+
obj = i915_gem_object_alloc(dev);
if (obj == NULL)
return -ENOMEM;
@@ -833,7 +873,7 @@ i915_gem_userptr_ioctl(struct drm_device *dev, void
*data, struct drm_file *file
if (ret == 0)
ret = i915_gem_userptr_init__mmu_notifier(obj, args-flags);
if (ret == 0)
- ret = drm_gem_handle_create(file, obj-base, handle);
+out: ret = drm_gem_handle_create(file, obj-base, handle);
/* drop reference from allocate - handle holds it now */
drm_gem_object_unreference_unlocked(obj-base);
--
2.1.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Pin tiled objects for L-shaped configs
On Fri, Apr 03, 2015 at 10:43:29AM +0100, Chris Wilson wrote:
On Thu, Nov 20, 2014 at 09:26:30AM +0100, Daniel Vetter wrote:
diff --git a/drivers/gpu/drm/i915/i915_gem_tiling.c
b/drivers/gpu/drm/i915/i915_gem_tiling.c
index 749ab485569e..03c675a4476e 100644
--- a/drivers/gpu/drm/i915/i915_gem_tiling.c
+++ b/drivers/gpu/drm/i915/i915_gem_tiling.c
@@ -178,6 +178,15 @@ i915_gem_detect_bit_6_swizzle(struct drm_device *dev)
}
break;
}
+
+ /* check for L-shaped memory aka modified enhanced addressing */
+ if (IS_GEN4(dev)) {
+ uint32_t ddc2 = I915_READ(DCC2);
+
+ if (!(ddc2 DCC2_MODIFIED_ENHANCED_DISABLE))
+ dev_priv-quirks |= QUIRK_PIN_SWIZZLED_PAGES;
+ }
+
if (dcc == 0x) {
DRM_ERROR(Couldn't read from MCHBAR.
Disabling tiling.\n);
I resurrected my dual-channel evenly loaded gm45 and to my surprise
found it reporting a L-shaped memory layout.
Well my gm45 is also dual-channel and evenly loaded and still mangles
tiled buffers when going through swap. Is gem_tiled_swapping happy on your
box?
Perhaps the if ((ddc2 DISABLE) == 0) is inverted or is not the truly
magic bit?
It was the best one I could find - given how old this all is now I think
some false positives are acceptable in the test. I did try a few other
things which did all fail.
-Daniel
ickle@x200s $ sudo cat /sys/kernel/debug/dri/0/i915_swizzle_info
bit6 swizzle for X-tiling = bit9/bit10/bit11
bit6 swizzle for Y-tiling = bit9/bit11
DDC = 0x000f0002
DDC2 = 0x0010
C0DRB3 = 0x
C1DRB3 = 0x
L-shaped memory detected
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/2] drm/i915/skl: Support for 90/270 rotation
On 4/7/2015 1:43 PM, Daniel Vetter wrote: On Thu, Apr 02, 2015 at 08:59:33AM -0700, Matt Roper wrote: On Thu, Apr 02, 2015 at 10:24:02AM +0530, Jindal, Sonika wrote: I am not sure how it will help. drm_plane_check_pixel_format should be used to check the pixel format of the fb which we should be doing in some -check functions (I don't think we do that right now?) against what is supported by the plane. But to check for the formats which are allowed for 90/270, we would need this kind of explicit check. Right, I guess there are two aspects here. First, we need to properly test for acceptable pixel formats for the plane in general; at the moment the DRM core setplane() tests this, but if we use the atomic ioctl it never gets checked (which is a bug). So as you say, we need a test in a _check() function to verify this. We probably also need to add an i-g-t test for it too. The core atomic ioctl does check for valid plane pixel formats for you. And there shouldn't be any other entrypoint (except internal ones, but that's ok). Is there a bug left? Oh, yes the check is there. Will abandon that check then and just move the 90/270 pixel format check to intel_plane_atomic_check. Regards, Sonika Definitely agree that testcases would be nice. -Daniel ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 15/19] drm/i915: HSW cdclk support
On Tue, Apr 07, 2015 at 11:57:23AM +0530, Sivakumar Thulasimani wrote:
On 3/31/2015 4:44 PM, Mika Kahola wrote:
Implement support for changing the cdclk frequency during runtime on
HSW. VLV/CHV already have support for this, so we can follow their
example for the most part. Only the actual hardware programming differs,
the rest is pretty much the same.
The pipe pixel rate stuff is handled a bit differently for now due to
the difference in pch vs. gmch pfit handling. Eventually we should unify
that part to eliminate what is essentially duplicated code.
v2: Grab rps.hw_lock around sandybridge_pcode_write()
v3: Rebase due to power well vs. .global_resources() reordering
v4: Rebase due to .global_resources() reordering for Haswell
Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
Signed-off-by: Mika Kahola mika.kah...@intel.com
---
drivers/gpu/drm/i915/i915_reg.h | 3 +
drivers/gpu/drm/i915/intel_display.c | 161
++-
2 files changed, 161 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_reg.h
b/drivers/gpu/drm/i915/i915_reg.h
index f26ebd2..b25f712 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -6244,6 +6244,7 @@ enum skl_disp_power_wells {
#define GEN6_PCODE_WRITE_D_COMP 0x11
#define GEN6_ENCODE_RC6_VID(mv) (((mv) - 245) / 5)
#define GEN6_DECODE_RC6_VID(vids) (((vids) * 5) + 245)
+#define HSW_PCODE_DE_WRITE_FREQ_REQ 0x17
#define DISPLAY_IPS_CONTROL 0x19
#define HSW_PCODE_DYNAMIC_DUTY_CYCLE_CONTROL 0x1A
#define GEN6_PCODE_DATA 0x138128
@@ -6698,10 +6699,12 @@ enum skl_disp_power_wells {
#define LCPLL_PLL_LOCK (130)
#define LCPLL_CLK_FREQ_MASK (326)
#define LCPLL_CLK_FREQ_450 (026)
+#define LCPLL_CLK_FREQ_ALT_HSW(126) /* 337.5 (ULX) or 540 */
#define LCPLL_CLK_FREQ_54O_BDW (126)
#define LCPLL_CLK_FREQ_337_5_BDW (226)
#define LCPLL_CLK_FREQ_675_BDW (326)
#define LCPLL_CD_CLOCK_DISABLE (125)
+#define LCPLL_ROOT_CD_CLOCK_DISABLE (124)
#define LCPLL_CD2X_CLOCK_DISABLE (123)
#define LCPLL_POWER_DOWN_ALLOW (122)
#define LCPLL_CD_SOURCE_FCLK (121)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 3752d5e..cce7103 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -5012,7 +5012,16 @@ static void intel_update_max_cdclk(struct drm_device
*dev)
{
struct drm_i915_private *dev_priv = dev-dev_private;
- if (IS_VALLEYVIEW(dev)) {
+ if (IS_HASWELL(dev)) {
+ if (I915_READ(FUSE_STRAP) HSW_CDCLK_LIMIT)
+ dev_priv-max_cdclk_freq = 45;
+ else if (IS_HSW_ULX(dev))
+ dev_priv-max_cdclk_freq = 337500;
+ else if (IS_HSW_ULT(dev))
+ dev_priv-max_cdclk_freq = 45;
+ else
+ dev_priv-max_cdclk_freq = 54;
+ } else if (IS_VALLEYVIEW(dev)) {
dev_priv-max_cdclk_freq = 40;
} else {
/* otherwise assume cdclk is fixed */
@@ -8773,6 +8782,144 @@ void hsw_enable_pc8(struct drm_i915_private
*dev_priv)
hsw_disable_lcpll(dev_priv, true, true);
}
+/* compute the max rate for new configuration */
+static int ilk_max_pixel_rate(struct drm_i915_private *dev_priv)
+{
+ struct drm_device *dev = dev_priv-dev;
+ struct intel_crtc *crtc;
+ int max_pixel_rate = 0;
+
+ for_each_intel_crtc(dev, crtc) {
+ if (crtc-new_enabled)
+ max_pixel_rate = max(max_pixel_rate,
+
ilk_pipe_pixel_rate(crtc-new_config));
+ }
+
+ return max_pixel_rate;
+}
+
+static int haswell_calc_cdclk(struct drm_i915_private *dev_priv,
+ int max_pixel_rate)
+{
+ int cdclk;
+
+ /*
+* FIXME should also account for plane ratio
+* once 64bpp pixel formats are supported.
+*/
+ if (max_pixel_rate 45)
+ cdclk = 54;
+ else if (max_pixel_rate 337500 || !IS_HSW_ULX(dev_priv))
+ cdclk = 45;
+ else
+ cdclk = 337500;
+
+ /*
+* FIXME move the cdclk caclulation to
+* compute_config() so we can fail gracegully.
+*/
+ if (cdclk dev_priv-max_cdclk_freq) {
+ DRM_ERROR(requested cdclk (%d kHz) exceeds max (%d kHz)\n,
+ cdclk, dev_priv-max_cdclk_freq);
+ cdclk = dev_priv-max_cdclk_freq;
+ }
+
+ return cdclk;
+}
won't this return 337MHz even for platforms that have HSW_CDCLK_LIMIT is
set ? this should return
Re: [Intel-gfx] [PATCH] drm/i915: Clean-up idr table if context create fails.
On Tue, Apr 07, 2015 at 10:20:15AM +0200, Daniel Vetter wrote: On Thu, Apr 02, 2015 at 06:49:38PM +0530, Deepak S wrote: On Monday 30 March 2015 09:13 PM, Daniel Vetter wrote: On Mon, Mar 30, 2015 at 08:03:58PM +0530, deepa...@linux.intel.com wrote: From: Deepak S deepa...@linux.intel.com Cleanup idr table if any error happens after __create_hw_context() in i915_gem_create_context() Signed-off-by: Deepak S deepa...@linux.intel.com --- drivers/gpu/drm/i915/i915_gem_context.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/gpu/drm/i915/i915_gem_context.c b/drivers/gpu/drm/i915/i915_gem_context.c index f3e84c4..69bebe5 100644 --- a/drivers/gpu/drm/i915/i915_gem_context.c +++ b/drivers/gpu/drm/i915/i915_gem_context.c @@ -287,6 +287,8 @@ err_unpin: if (is_global_default_ctx ctx-legacy_hw_ctx.rcs_state) i915_gem_object_ggtt_unpin(ctx-legacy_hw_ctx.rcs_state); err_destroy: + if (ctx-file_priv) + idr_remove(ctx-file_priv-context_idr, ctx-user_handle); The common approach is to add a new err_idr: label at the op of the unwind code and make the call to idr_remove unconditional. Thanks, Daniel Thanks Daniel for review. I do not think we can have a unconditional idr remove since for global ctx i915_gem_create_context called with file_priv=NULL? Hm right, the entire control-flow in there is a bit funny. I think a much cleaner solution would be to drop the file_prive from create_context and add a new i915_gem_context_create_user which wraps create_context and the idr allocation. Doing the cleanup, conditionally, in a different function than where we do the allocation is a bit too brittle imo. I suggested that it look like: http://cgit.freedesktop.org/~ickle/linux-2.6/tree/drivers/gpu/drm/i915/i915_gem_context.c#n179 -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 7/7] lib: add igt_draw
On Thu, Apr 02, 2015 at 12:15:13AM +0100, Chris Wilson wrote:
On Wed, Apr 01, 2015 at 07:40:59PM -0300, Paulo Zanoni wrote:
+static void draw_rect_mmap_wc(int fd, struct buf_data *buf, struct rect
*rect,
+ uint32_t color)
+{
+ uint32_t *ptr;
+ uint32_t tiling, swizzle;
+
+ gem_get_tiling(fd, buf-handle, tiling, swizzle);
+
+ /* We didn't implement suport for the older tiling methods yet. */
+ if (tiling != I915_TILING_NONE)
+ igt_require(intel_gen(intel_get_drm_devid(fd)) = 5);
But you now do! You need something like:
The problem is that the kernel hides bit17 swizzling. I chatted with Paulo
on irc about this and we decided just ignore them all is the simplest
approach.
-Daniel
static void get_tiling_and_swizzle(int fd,
struct buf_data *buf,
int *tiling, int *swizzle)
{
struct local_i915_gem_get_tiling_v2 {
uint32_t handle;
uint32_t tiling_mode;
uint32_t swizzle_mode;
uint32_t phys_swizzle_mode;
} tiling;
#define LOCAL_IOCTL_I915_GEM_GET_TILING DRM_IOWR (DRM_COMMAND_BASE +
DRM_I915_GEM_GET_TILING, struct local_i915_gem_get_tiling_v2)
memset(tiling, 0, sizeof(tiling));
tiling.handle = buf-handle;
do_ioctl(fd, LOCAL_IOCTL_I915_GEM_GET_TILING, tiling);
igt_require(tiling.phys_swizzle == tiling.swizzle_mode ||
intel_gen(intel_get_drm_devid(fd)) = 5); /* old kernel? */
*tiling = tiling.tilling_mode;
*swizzle = tiling.swizzle_mode;
}
--
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/2] lib/igt_kms: Let set_property return the result
Return the return value of the set_property ioctl and add check for
the failure.
Signed-off-by: Sonika Jindal sonika.jin...@intel.com
---
lib/igt_kms.c |7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/lib/igt_kms.c b/lib/igt_kms.c
index 6cb1f08..14abae8 100644
--- a/lib/igt_kms.c
+++ b/lib/igt_kms.c
@@ -927,13 +927,13 @@ get_plane_property(int drm_fd, uint32_t plane_id, const
char *name,
name, prop_id, value, prop);
}
-static void
+static int
igt_plane_set_property(igt_plane_t *plane, uint32_t prop_id, uint64_t value)
{
igt_pipe_t *pipe = plane-pipe;
igt_display_t *display = pipe-display;
- drmModeObjectSetProperty(display-drm_fd, plane-drm_plane-plane_id,
+ return drmModeObjectSetProperty(display-drm_fd,
plane-drm_plane-plane_id,
DRM_MODE_OBJECT_PLANE, prop_id, value);
}
@@ -1338,10 +1338,11 @@ static int igt_drm_plane_commit(igt_plane_t *plane,
plane-position_changed = false;
if (plane-rotation_changed) {
- igt_plane_set_property(plane, plane-rotation_property,
+ ret = igt_plane_set_property(plane, plane-rotation_property,
plane-rotation);
plane-rotation_changed = false;
+ CHECK_RETURN(ret, fail_on_error);
}
return 0;
--
1.7.10.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/2] kms_rotation_crc: Adding test for 90/270 rotation
Adding 90/270 rotation testcase for primary and sprite planes.
v2: Added position test for sprite. Checking for gen 9 for 90/270.
Some cleanup and rebase.
v3: Added test for unsupported tiling and unsupported pixel format for 90/270
Signed-off-by: Sonika Jindal sonika.jin...@intel.com
---
tests/kms_rotation_crc.c | 248 --
1 file changed, 215 insertions(+), 33 deletions(-)
diff --git a/tests/kms_rotation_crc.c b/tests/kms_rotation_crc.c
index e11d7a9..48afaa1 100644
--- a/tests/kms_rotation_crc.c
+++ b/tests/kms_rotation_crc.c
@@ -28,14 +28,21 @@
#include igt_debugfs.h
#include igt_kms.h
#include igt_core.h
+#include intel_chipset.h
typedef struct {
int gfx_fd;
igt_display_t display;
struct igt_fb fb;
struct igt_fb fb_cursor;
+ struct igt_fb fb_full;
+ struct igt_fb fb_565;
+ struct igt_fb fb_tiling;
igt_crc_t ref_crc;
igt_pipe_crc_t *pipe_crc;
+ igt_rotation_t rotation;
+ int pos_x;
+ int pos_y;
} data_t;
static void
@@ -63,18 +70,46 @@ paint_squares(data_t *data, struct igt_fb *fb,
drmModeModeInfo *mode,
w = mode-hdisplay;
h = mode-vdisplay;
- cr = igt_get_cairo_ctx(data-gfx_fd, data-fb);
+ cr = igt_get_cairo_ctx(data-gfx_fd, fb);
if (rotation == IGT_ROTATION_180) {
cairo_translate(cr, w, h);
cairo_rotate(cr, M_PI);
}
- /* Paint with 4 squares of Red, Green, White, Blue Clockwise */
- igt_paint_color(cr, 0, 0, w / 2, h / 2, 1.0, 0.0, 0.0);
- igt_paint_color(cr, w / 2, 0, w / 2, h / 2, 0.0, 1.0, 0.0);
- igt_paint_color(cr, 0, h / 2, w / 2, h / 2, 0.0, 0.0, 1.0);
- igt_paint_color(cr, w / 2, h / 2, w / 2, h / 2, 1.0, 1.0, 1.0);
+ /*
+* rotation is used for creating ref rotated fb and
+* data-rotation is used to determine the required size
+* while creating unrotated fb.
+*/
+ if (rotation == IGT_ROTATION_90) {
+ /* Paint 4 squares with width == height in Blue, Red,
+ Green, White Clockwise order to look like 90 degree
rotated*/
+ w = h = mode-vdisplay;
+ igt_paint_color(cr, 0, 0, w / 2, h / 2, 0.0, 0.0, 1.0);
+ igt_paint_color(cr, w / 2, 0, w / 2, h / 2, 1.0, 0.0,
0.0);
+ igt_paint_color(cr, 0, h / 2, w / 2, h / 2, 1.0, 1.0,
1.0);
+ igt_paint_color(cr, w / 2, h / 2, w / 2, h / 2, 0.0,
1.0, 0.0);
+
+ } else if (rotation == IGT_ROTATION_270) {
+ /* Paint 4 squares with width == height in Green, White,
+ Blue, Red Clockwise order to look like 270 degree
rotated*/
+ w = h = mode-vdisplay;
+ igt_paint_color(cr, 0, 0, w / 2, h / 2, 0.0, 1.0, 0.0);
+ igt_paint_color(cr, w / 2, 0, w / 2, h / 2, 1.0, 1.0,
1.0);
+ igt_paint_color(cr, 0, h / 2, w / 2, h / 2, 1.0, 0.0,
0.0);
+ igt_paint_color(cr, w / 2, h / 2, w / 2, h / 2, 0.0,
0.0, 1.0);
+
+ } else {
+ if (data-rotation == IGT_ROTATION_90 ||
+ data-rotation == IGT_ROTATION_270)
+ w = h = mode-vdisplay;
+ /* Paint with 4 squares of Red, Green, White, Blue
Clockwise */
+ igt_paint_color(cr, 0, 0, w / 2, h / 2, 1.0, 0.0, 0.0);
+ igt_paint_color(cr, w / 2, 0, w / 2, h / 2, 0.0, 1.0,
0.0);
+ igt_paint_color(cr, 0, h / 2, w / 2, h / 2, 0.0, 0.0,
1.0);
+ igt_paint_color(cr, w / 2, h / 2, w / 2, h / 2, 1.0,
1.0, 1.0);
+ }
}
cairo_destroy(cr);
}
@@ -84,7 +119,12 @@ static void prepare_crtc(data_t *data, igt_output_t
*output, enum pipe pipe,
{
drmModeModeInfo *mode;
igt_display_t *display = data-display;
- int fb_id, fb_cursor_id;
+ int fb_id, fb_cursor_id, fb_full_id;
+ int w, h;
+ uint64_t tiling = LOCAL_DRM_FORMAT_MOD_NONE;
+ enum igt_commit_style commit = COMMIT_LEGACY;
+ int old_rotation;
+ igt_plane_t *primary;
igt_output_set_pipe(output, pipe);
@@ -94,10 +134,45 @@ static void prepare_crtc(data_t *data, igt_output_t
*output, enum pipe pipe,
mode = igt_output_get_mode(output);
+ w = mode-hdisplay;
+ h = mode-vdisplay;
+
+ fb_full_id = igt_create_fb(data-gfx_fd,
+ w, h,
+ DRM_FORMAT_XRGB,
+ tiling,
+ data-fb_full);
+ igt_assert(fb_full_id);
+
+ /*
+* With
Re: [Intel-gfx] [PATCH 15/19] drm/i915: HSW cdclk support
where can i check this (audio driver) ? since there was no need for them to check CD clock value till now i don't think they will be doing it. also this needs to be changed in Display Audio controller, so not sure if audio driver has access to it in the first place. will be good to confirm this before merging as it will break display audio if it is not programmed. if any one has setup this can be confirmed by just switching CD clock after boot and playing an audio file. regards, Sivakumar On 4/7/2015 1:59 PM, Ville Syrjälä wrote: On Tue, Apr 07, 2015 at 12:33:40PM +0530, Sivakumar Thulasimani wrote: sorry if i am missing something, HSW and BDW requires display audio controller to be updated with new values once CD clock is modified. how is this accomplished here ? I'm hoping the audio driver will query the cdclk frequency after every modeset. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 7/7] lib: add igt_draw
On Tue, Apr 07, 2015 at 10:10:25AM +0200, Daniel Vetter wrote:
On Thu, Apr 02, 2015 at 12:15:13AM +0100, Chris Wilson wrote:
On Wed, Apr 01, 2015 at 07:40:59PM -0300, Paulo Zanoni wrote:
+static void draw_rect_mmap_wc(int fd, struct buf_data *buf, struct rect
*rect,
+ uint32_t color)
+{
+ uint32_t *ptr;
+ uint32_t tiling, swizzle;
+
+ gem_get_tiling(fd, buf-handle, tiling, swizzle);
+
+ /* We didn't implement suport for the older tiling methods yet. */
+ if (tiling != I915_TILING_NONE)
+ igt_require(intel_gen(intel_get_drm_devid(fd)) = 5);
But you now do! You need something like:
The problem is that the kernel hides bit17 swizzling. I chatted with Paulo
on irc about this and we decided just ignore them all is the simplest
approach.
Urm, that was the whole point of GET_TILING v2. That small function is
all you need to determine when bit17 is in effect and then you get to
reuse all the direct CPU methods (as they are also used by userspace)
for earlier gen.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH i-g-t] tests/pm_sseu: Require Gen8+ early in setup
On Fri, Apr 03, 2015 at 06:01:12PM -0700, jeff.mc...@intel.com wrote: From: Jeff McGee jeff.mc...@intel.com Pre-Gen8 devices should be skipped early instead of failing when test resources are not found. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=89822 Signed-off-by: Jeff McGee jeff.mc...@intel.com Applied, thanks. -Daniel --- tests/pm_sseu.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/tests/pm_sseu.c b/tests/pm_sseu.c index 34465db..320371f 100644 --- a/tests/pm_sseu.c +++ b/tests/pm_sseu.c @@ -262,6 +262,8 @@ gem_init(void) gem.devid = intel_get_drm_devid(gem.drm_fd); gem.gen = intel_gen(gem.devid); + igt_require_f(gem.gen = 8, + SSEU power gating only relevant for Gen8+); gem.has_ppgtt = gem_uses_aliasing_ppgtt(gem.drm_fd); gem.bufmgr = drm_intel_bufmgr_gem_init(gem.drm_fd, 4096); -- 2.3.3 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/skl: Enabling PSR2 SU with frame sync
On Thu, Apr 02, 2015 at 11:02:44AM +0530, Sonika Jindal wrote:
We make use of HW tracking for Selective update region and enable frame sync
on
sink. We use hardware's hardcoded data values for frame sync and GTC.
v2: Add 3200x2000 resolution restriction with PSR2, move psr2_support to
i915_psr
struct, add aux_frame_sync to independently control aux frame sync, rename the
TP2 TIME macro for 2500us (Rodrigo, Siva)
v3: Moving the resolution restriction to intel_psr_enable so that we check it
only once(Durga)
Cc: Durgadoss R durgados...@intel.com
Cc: Rodrigo Vivi rodrigo.v...@intel.com
Signed-off-by: Sonika Jindal sonika.jin...@intel.com
Reviewed-by: Durgadoss R durgados...@intel.com
---
Hi Daniel,
It applies cleanly for me. Still I created new patch.
Please try, if it works for you.
Yeah this one worked perfectly. Dunno what happened with the old one.
Thanks for resending, applied to dinq.
-Daniel
Regards,
Sonika
drivers/gpu/drm/i915/i915_drv.h |2 ++
drivers/gpu/drm/i915/i915_reg.h | 14 ++
drivers/gpu/drm/i915/intel_dp.c | 15 +++
drivers/gpu/drm/i915/intel_psr.c | 38
+-
4 files changed, 68 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index b13c552..f0e1f2e 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -881,6 +881,8 @@ struct i915_psr {
struct delayed_work work;
unsigned busy_frontbuffer_bits;
bool link_standby;
+ bool psr2_support;
+ bool aux_frame_sync;
};
enum intel_pch {
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index b134fa3..59e9b2d 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -2748,6 +2748,20 @@ enum skl_disp_power_wells {
#define EDP_PSR_DEBUG_MASK_MEMUP (126)
#define EDP_PSR_DEBUG_MASK_HPD (125)
+#define EDP_PSR2_CTL 0x6f900
+#define EDP_PSR2_ENABLE(131)
+#define EDP_SU_TRACK_ENABLE(130)
+#define EDP_MAX_SU_DISABLE_TIME(t) ((t)20)
+#define EDP_MAX_SU_DISABLE_TIME_MASK (0x1f20)
+#define EDP_PSR2_TP2_TIME_500 (08)
+#define EDP_PSR2_TP2_TIME_100 (18)
+#define EDP_PSR2_TP2_TIME_2500 (28)
+#define EDP_PSR2_TP2_TIME_50 (38)
+#define EDP_PSR2_TP2_TIME_MASK (38)
+#define EDP_PSR2_FRAME_BEFORE_SU_SHIFT 4
+#define EDP_PSR2_FRAME_BEFORE_SU_MASK (0xf4)
+#define EDP_PSR2_IDLE_MASK 0xf
+
/* VGA port control */
#define ADPA 0x61100
#define PCH_ADPA0xe1100
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 7936155..a651dba 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -3785,6 +3785,21 @@ intel_dp_get_dpcd(struct intel_dp *intel_dp)
dev_priv-psr.sink_support = true;
DRM_DEBUG_KMS(Detected EDP PSR Panel.\n);
}
+
+ if (INTEL_INFO(dev)-gen = 9
+ (intel_dp-psr_dpcd[0] DP_PSR2_IS_SUPPORTED)) {
+ uint8_t frame_sync_cap;
+
+ dev_priv-psr.sink_support = true;
+ intel_dp_dpcd_read_wake(intel_dp-aux,
+ DP_SINK_DEVICE_AUX_FRAME_SYNC_CAP,
+ frame_sync_cap, 1);
+ dev_priv-psr.aux_frame_sync = frame_sync_cap ? true :
false;
+ /* PSR2 needs frame sync as well */
+ dev_priv-psr.psr2_support =
dev_priv-psr.aux_frame_sync;
+ DRM_DEBUG_KMS(PSR2 %s on sink,
+ dev_priv-psr.psr2_support ? supported : not
supported);
+ }
}
/* Training Pattern 3 support, both source and sink */
diff --git a/drivers/gpu/drm/i915/intel_psr.c
b/drivers/gpu/drm/i915/intel_psr.c
index 9668735..27608ce 100644
--- a/drivers/gpu/drm/i915/intel_psr.c
+++ b/drivers/gpu/drm/i915/intel_psr.c
@@ -117,6 +117,19 @@ static void vlv_psr_setup_vsc(struct intel_dp *intel_dp)
I915_WRITE(VLV_VSCSDP(pipe), val);
}
+static void skl_psr_setup_su_vsc(struct intel_dp *intel_dp)
+{
+ struct edp_vsc_psr psr_vsc;
+
+ /* Prepare VSC Header for SU as per EDP 1.4 spec, Table 6.11 */
+ memset(psr_vsc, 0, sizeof(psr_vsc));
+ psr_vsc.sdp_header.HB0 = 0;
+ psr_vsc.sdp_header.HB1 = 0x7;
+ psr_vsc.sdp_header.HB2 = 0x3;
+ psr_vsc.sdp_header.HB3 = 0xb;
+ intel_psr_write_vsc(intel_dp, psr_vsc);
+}
+
static void hsw_psr_setup_vsc(struct intel_dp *intel_dp)
{
struct edp_vsc_psr psr_vsc;
@@ -165,6 +178,12 @@ static void hsw_psr_enable_sink(struct intel_dp
*intel_dp)
drm_dp_dpcd_writeb(intel_dp-aux,
Re: [Intel-gfx] [PATCH 2/2] drm/i915/skl: Support for 90/270 rotation
On Thu, Apr 02, 2015 at 08:59:33AM -0700, Matt Roper wrote: On Thu, Apr 02, 2015 at 10:24:02AM +0530, Jindal, Sonika wrote: I am not sure how it will help. drm_plane_check_pixel_format should be used to check the pixel format of the fb which we should be doing in some -check functions (I don't think we do that right now?) against what is supported by the plane. But to check for the formats which are allowed for 90/270, we would need this kind of explicit check. Right, I guess there are two aspects here. First, we need to properly test for acceptable pixel formats for the plane in general; at the moment the DRM core setplane() tests this, but if we use the atomic ioctl it never gets checked (which is a bug). So as you say, we need a test in a _check() function to verify this. We probably also need to add an i-g-t test for it too. The core atomic ioctl does check for valid plane pixel formats for you. And there shouldn't be any other entrypoint (except internal ones, but that's ok). Is there a bug left? Definitely agree that testcases would be nice. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC PATCH i-g-t 0/1] April Tools: complete intel reg tool overhaul
On Wed, Apr 01, 2015 at 09:37:22PM +0300, Jani Nikula wrote: Hi all - I think having several overlapping register read/write/dump/etc. tools is just silly. I've been working on unsillifying the situation a bit on the background, in the idle moments (while my kernel's compiling). Here's what I got: a replacement for intel_reg_dumper quick_dump.py intel_reg_read intel_reg_write intel_iosf_sb_read intel_iosf_sb_write intel_dpio_read intel_dpio_write intel_reg_snapshot intel_vga_read intel_vga_write I'm calling it intel_reg. It's a busybox-like tool that understands the subcommands dump read write decode snapshot The read, write and decode subcommands understand register references in the form [(PORTNAME|PORTNUM|MMIO-OFFSET):](REGNAME|REGADDR) letting you address all registers on all platforms. For example, $ intel_reg read DPIO:TX2_CH0_DW10 $ intel_reg write 0x7 0x The register spec, i.e. the registers known by name and their mapping to address, sideband port or mmio offset, is completely separated from the decoding. The spec can be provided through quick_dump.py compatible files (although it should not be difficult to add other formats). Quick addition of new registers to dump is just as easy as for quick_dump.py. As fallback, all the registers currently known by intel_reg_dumper are built-in. The decoding is done based on the resolved address, initially using the same functionality currently available in intel_reg_dumper. Now all the decoding and name-address mapping is available for *all* subcommands. All subcommands use the same output format (which, admittedly, I didn't polish yet, but that's a few lines of printfs). For dumping a bunch of registers with with --count, we also get the names for all: $ intel_reg read --count 2 BLC_PWM_CPU_CTL2 0x00048250 (BLC_PWM_CPU_CTL2): 0x8000 enable 1, pipe A 0x00048254 (BLC_PWM_CPU_CTL): 0x0206 cycle 518 intel_reg_decode.c is mostly a copy of intel_reg_dumper.c, otherwise this is fairly small amount of code for the functionality, compared to everything it's aiming to replace. It's mostly done, probably with plenty of bikeshedding potential, so I stopped short from the polishing stage. Let's hear it. TODO consists of eating a previously done dump and re-decoding the values with possibly updated decode code, bash completion for the commands and register names, and also replacing intel_audio_dump which has become a monster. Tbh I didn't read through the entire thing, but imo having a unified interface is very much required and this is awesome work. Imo better to push this and ignore any requests for color changes. One thing is missing thought: A bunch of patches on top which replace all the current tools with bash scripts which calls a suitable subcommand of intel_reg. Otherwise we'll keep adding divergent changes all over. But with that imo just go ahead an push it. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915/skl: Support for 90/270 rotation
v2: Moving creation of property in a function, checking for 90/270
rotation simultaneously (Chris)
Letting primary plane to be positioned
v3: Adding if/else for 90/270 and rest params programming, adding check for
pixel_format, some cleanup (review comments)
v4: Adding right pixel_formats, using src_* params instead of crtc_* for offset
and size programming (Ville)
v5: Rebased on -nightly and Tvrtko's series for gtt remapping.
v6: Rebased on -nightly (Tvrtko's series merged)
v7: Moving pixel_format check to intel_atomic_plane_check (Matt)
Signed-off-by: Sonika Jindal sonika.jin...@intel.com
---
drivers/gpu/drm/i915/i915_reg.h |2 +
drivers/gpu/drm/i915/intel_atomic_plane.c | 23
drivers/gpu/drm/i915/intel_display.c | 88 -
drivers/gpu/drm/i915/intel_drv.h |6 ++
drivers/gpu/drm/i915/intel_sprite.c | 52 -
5 files changed, 130 insertions(+), 41 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index b522eb6..564bbd5 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -4854,7 +4854,9 @@ enum skl_disp_power_wells {
#define PLANE_CTL_ALPHA_HW_PREMULTIPLY ( 3 4)
#define PLANE_CTL_ROTATE_MASK0x3
#define PLANE_CTL_ROTATE_0 0x0
+#define PLANE_CTL_ROTATE_90 0x1
#define PLANE_CTL_ROTATE_180 0x2
+#define PLANE_CTL_ROTATE_270 0x3
#define _PLANE_STRIDE_1_A 0x70188
#define _PLANE_STRIDE_2_A 0x70288
#define _PLANE_STRIDE_3_A 0x70388
diff --git a/drivers/gpu/drm/i915/intel_atomic_plane.c
b/drivers/gpu/drm/i915/intel_atomic_plane.c
index 976b891..ef8c291 100644
--- a/drivers/gpu/drm/i915/intel_atomic_plane.c
+++ b/drivers/gpu/drm/i915/intel_atomic_plane.c
@@ -162,6 +162,29 @@ static int intel_plane_atomic_check(struct drm_plane
*plane,
(1 drm_plane_index(plane));
}
+ if (state-fb intel_rotation_90_or_270(state-rotation)) {
+ if (!(state-fb-modifier[0] == I915_FORMAT_MOD_Y_TILED ||
+ state-fb-modifier[0] == I915_FORMAT_MOD_Yf_TILED)) {
+ DRM_DEBUG_KMS(Y/Yf tiling required for 90/270!\n);
+ return -EINVAL;
+ }
+
+ /*
+* 90/270 is not allowed with RGB64 16:16:16:16,
+* RGB 16-bit 5:6:5, and Indexed 8-bit.
+*/
+ switch (state-fb-pixel_format) {
+ case DRM_FORMAT_C8:
+ case DRM_FORMAT_RGB565:
+ DRM_DEBUG_KMS(Unsupported pixel format %s for
90/270!\n,
+
drm_get_format_name(state-fb-pixel_format));
+ return -EINVAL;
+
+ default:
+ break;
+ }
+ }
+
return intel_plane-check_plane(plane, intel_state);
}
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index f0bbc22..4de544c 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -2311,13 +2311,6 @@ intel_fill_fb_ggtt_view(struct i915_ggtt_view *view,
struct drm_framebuffer *fb,
info-pitch = fb-pitches[0];
info-fb_modifier = fb-modifier[0];
- if (!(info-fb_modifier == I915_FORMAT_MOD_Y_TILED ||
- info-fb_modifier == I915_FORMAT_MOD_Yf_TILED)) {
- DRM_DEBUG_KMS(
- Y or Yf tiling is needed for 90/270
rotation!\n);
- return -EINVAL;
- }
-
return 0;
}
@@ -2919,8 +2912,12 @@ static void skylake_update_primary_plane(struct drm_crtc
*crtc,
struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
struct drm_i915_gem_object *obj;
int pipe = intel_crtc-pipe;
- u32 plane_ctl, stride_div;
+ u32 plane_ctl, stride_div, stride;
+ u32 tile_height, plane_offset, plane_size;
+ unsigned int rotation;
+ int x_offset, y_offset;
unsigned long surf_addr;
+ struct drm_plane *plane;
if (!intel_crtc-primary_enabled) {
I915_WRITE(PLANE_CTL(pipe, 0), 0);
@@ -2981,21 +2978,51 @@ static void skylake_update_primary_plane(struct
drm_crtc *crtc,
}
plane_ctl |= PLANE_CTL_PLANE_GAMMA_DISABLE;
- if (crtc-primary-state-rotation == BIT(DRM_ROTATE_180))
+
+ plane = crtc-primary;
+ rotation = plane-state-rotation;
+ switch (rotation) {
+ case BIT(DRM_ROTATE_90):
+ plane_ctl |= PLANE_CTL_ROTATE_90;
+ break;
+
+ case BIT(DRM_ROTATE_180):
plane_ctl |= PLANE_CTL_ROTATE_180;
+ break;
+
+ case BIT(DRM_ROTATE_270):
+ plane_ctl |= PLANE_CTL_ROTATE_270;
+ break;
+ }
Re: [Intel-gfx] [PATCH] drm: Add integer overflow checking to transitional plane helpers
On Fri, Apr 03, 2015 at 02:27:46PM -0700, Matt Roper wrote:
Add tests for destination rectangle integer overflow before calling the
driver's check function. This will ensure that the transitional plane
helpers match the behavior of the full atomic helpers by always
returning -ERANGE for planes positioned beyond INT_MAX.
Note that the legacy SetPlane ioctl itself also includes similar tests
for integer overflow, so the only case where this check really matters
is when legacy cursor operations get routed through the universal plane
interface internally.
This issue was first noticed with i915 commit:
commit ff42e093e9c9c17a6e1d6aab24875a36795f926e
Author: Daniel Vetter daniel.vet...@ffwll.ch
Date: Mon Mar 2 16:35:20 2015 +0100
Revert drm/i915: Switch planes from transitional helpers to full
atomic helpers
The above revert switched us from full atomic helpers back to the
transitional helpers, and in doing so we lost the overflow checking here
for universal cursor updates. Even though such extreme cursor positions
are unlikely to actually happen in the wild, we still don't want there
to be a change of behavior when drivers switch from transitional helpers
to full helpers.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=84269
Signed-off-by: Matt Roper matthew.d.ro...@intel.com
Since this is just for the cursor ioctl ... shouldn't we instead move
these checks from drm_mode_setplane to __setplane_internal? That way other
drivers also can rely upon these guarantees when implementing universal
cursor support and we won't have a mismatch in what kind of plane
properties can sneak through to drivers.
-Daniel
---
drivers/gpu/drm/drm_plane_helper.c | 14 ++
1 file changed, 14 insertions(+)
diff --git a/drivers/gpu/drm/drm_plane_helper.c
b/drivers/gpu/drm/drm_plane_helper.c
index 33807e0..1e9e105 100644
--- a/drivers/gpu/drm/drm_plane_helper.c
+++ b/drivers/gpu/drm/drm_plane_helper.c
@@ -417,6 +417,20 @@ int drm_plane_helper_commit(struct drm_plane *plane,
for (i = 0; i 2; i++)
crtc_funcs[i] = crtc[i] ? crtc[i]-helper_private : NULL;
+ /*
+ * Give drivers some help against integer overflows (and match the
+ * behavior of the full atomic helpers).
+ */
+ if (plane_state-crtc_w INT_MAX ||
+ plane_state-crtc_x INT_MAX - (int32_t) plane_state-crtc_w ||
+ plane_state-crtc_h INT_MAX ||
+ plane_state-crtc_y INT_MAX - (int32_t) plane_state-crtc_h) {
+ DRM_DEBUG_ATOMIC(Invalid CRTC coordinates %ux%u+%d+%d\n,
+ plane_state-crtc_w, plane_state-crtc_h,
+ plane_state-crtc_x, plane_state-crtc_y);
+ return -ERANGE;
+ }
+
if (plane_funcs-atomic_check) {
ret = plane_funcs-atomic_check(plane, plane_state);
if (ret)
--
1.8.5.1
___
dri-devel mailing list
dri-de...@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 15/19] drm/i915: HSW cdclk support
On 3/31/2015 4:44 PM, Mika Kahola wrote:
Implement support for changing the cdclk frequency during runtime on
HSW. VLV/CHV already have support for this, so we can follow their
example for the most part. Only the actual hardware programming differs,
the rest is pretty much the same.
The pipe pixel rate stuff is handled a bit differently for now due to
the difference in pch vs. gmch pfit handling. Eventually we should unify
that part to eliminate what is essentially duplicated code.
v2: Grab rps.hw_lock around sandybridge_pcode_write()
v3: Rebase due to power well vs. .global_resources() reordering
v4: Rebase due to .global_resources() reordering for Haswell
Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
Signed-off-by: Mika Kahola mika.kah...@intel.com
---
drivers/gpu/drm/i915/i915_reg.h | 3 +
drivers/gpu/drm/i915/intel_display.c | 161 ++-
2 files changed, 161 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index f26ebd2..b25f712 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -6244,6 +6244,7 @@ enum skl_disp_power_wells {
#define GEN6_PCODE_WRITE_D_COMP 0x11
#define GEN6_ENCODE_RC6_VID(mv) (((mv) - 245) / 5)
#define GEN6_DECODE_RC6_VID(vids) (((vids) * 5) + 245)
+#define HSW_PCODE_DE_WRITE_FREQ_REQ 0x17
#define DISPLAY_IPS_CONTROL 0x19
#define HSW_PCODE_DYNAMIC_DUTY_CYCLE_CONTROL 0x1A
#define GEN6_PCODE_DATA 0x138128
@@ -6698,10 +6699,12 @@ enum skl_disp_power_wells {
#define LCPLL_PLL_LOCK (130)
#define LCPLL_CLK_FREQ_MASK (326)
#define LCPLL_CLK_FREQ_450 (026)
+#define LCPLL_CLK_FREQ_ALT_HSW(126) /* 337.5 (ULX) or 540 */
#define LCPLL_CLK_FREQ_54O_BDW (126)
#define LCPLL_CLK_FREQ_337_5_BDW (226)
#define LCPLL_CLK_FREQ_675_BDW (326)
#define LCPLL_CD_CLOCK_DISABLE (125)
+#define LCPLL_ROOT_CD_CLOCK_DISABLE (124)
#define LCPLL_CD2X_CLOCK_DISABLE (123)
#define LCPLL_POWER_DOWN_ALLOW (122)
#define LCPLL_CD_SOURCE_FCLK (121)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 3752d5e..cce7103 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -5012,7 +5012,16 @@ static void intel_update_max_cdclk(struct drm_device
*dev)
{
struct drm_i915_private *dev_priv = dev-dev_private;
- if (IS_VALLEYVIEW(dev)) {
+ if (IS_HASWELL(dev)) {
+ if (I915_READ(FUSE_STRAP) HSW_CDCLK_LIMIT)
+ dev_priv-max_cdclk_freq = 45;
+ else if (IS_HSW_ULX(dev))
+ dev_priv-max_cdclk_freq = 337500;
+ else if (IS_HSW_ULT(dev))
+ dev_priv-max_cdclk_freq = 45;
+ else
+ dev_priv-max_cdclk_freq = 54;
+ } else if (IS_VALLEYVIEW(dev)) {
dev_priv-max_cdclk_freq = 40;
} else {
/* otherwise assume cdclk is fixed */
@@ -8773,6 +8782,144 @@ void hsw_enable_pc8(struct drm_i915_private *dev_priv)
hsw_disable_lcpll(dev_priv, true, true);
}
+/* compute the max rate for new configuration */
+static int ilk_max_pixel_rate(struct drm_i915_private *dev_priv)
+{
+ struct drm_device *dev = dev_priv-dev;
+ struct intel_crtc *crtc;
+ int max_pixel_rate = 0;
+
+ for_each_intel_crtc(dev, crtc) {
+ if (crtc-new_enabled)
+ max_pixel_rate = max(max_pixel_rate,
+
ilk_pipe_pixel_rate(crtc-new_config));
+ }
+
+ return max_pixel_rate;
+}
+
+static int haswell_calc_cdclk(struct drm_i915_private *dev_priv,
+ int max_pixel_rate)
+{
+ int cdclk;
+
+ /*
+* FIXME should also account for plane ratio
+* once 64bpp pixel formats are supported.
+*/
+ if (max_pixel_rate 45)
+ cdclk = 54;
+ else if (max_pixel_rate 337500 || !IS_HSW_ULX(dev_priv))
+ cdclk = 45;
+ else
+ cdclk = 337500;
+
+ /*
+* FIXME move the cdclk caclulation to
+* compute_config() so we can fail gracegully.
+*/
+ if (cdclk dev_priv-max_cdclk_freq) {
+ DRM_ERROR(requested cdclk (%d kHz) exceeds max (%d kHz)\n,
+ cdclk, dev_priv-max_cdclk_freq);
+ cdclk = dev_priv-max_cdclk_freq;
+ }
+
+ return cdclk;
+}
won't this return 337MHz even for platforms that have HSW_CDCLK_LIMIT is
set ? this should return 450MHz if this fuse is set
+
+static void haswell_set_cdclk(struct drm_device *dev, int cdclk)
+{
+
Re: [Intel-gfx] [PATCH 15/19] drm/i915: HSW cdclk support
sorry if i am missing something, HSW and BDW requires display audio
controller to be updated with new values once CD clock is modified. how
is this accomplished here ?
regards,
Sivakumar
On 4/7/2015 11:57 AM, Sivakumar Thulasimani wrote:
On 3/31/2015 4:44 PM, Mika Kahola wrote:
Implement support for changing the cdclk frequency during runtime on
HSW. VLV/CHV already have support for this, so we can follow their
example for the most part. Only the actual hardware programming differs,
the rest is pretty much the same.
The pipe pixel rate stuff is handled a bit differently for now due to
the difference in pch vs. gmch pfit handling. Eventually we should unify
that part to eliminate what is essentially duplicated code.
v2: Grab rps.hw_lock around sandybridge_pcode_write()
v3: Rebase due to power well vs. .global_resources() reordering
v4: Rebase due to .global_resources() reordering for Haswell
Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
Signed-off-by: Mika Kahola mika.kah...@intel.com
---
drivers/gpu/drm/i915/i915_reg.h | 3 +
drivers/gpu/drm/i915/intel_display.c | 161
++-
2 files changed, 161 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_reg.h
b/drivers/gpu/drm/i915/i915_reg.h
index f26ebd2..b25f712 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -6244,6 +6244,7 @@ enum skl_disp_power_wells {
#define GEN6_PCODE_WRITE_D_COMP0x11
#define GEN6_ENCODE_RC6_VID(mv)(((mv) - 245) / 5)
#define GEN6_DECODE_RC6_VID(vids)(((vids) * 5) + 245)
+#define HSW_PCODE_DE_WRITE_FREQ_REQ0x17
#define DISPLAY_IPS_CONTROL0x19
#define HSW_PCODE_DYNAMIC_DUTY_CYCLE_CONTROL0x1A
#define GEN6_PCODE_DATA0x138128
@@ -6698,10 +6699,12 @@ enum skl_disp_power_wells {
#define LCPLL_PLL_LOCK(130)
#define LCPLL_CLK_FREQ_MASK(326)
#define LCPLL_CLK_FREQ_450(026)
+#define LCPLL_CLK_FREQ_ALT_HSW(126) /* 337.5 (ULX) or 540 */
#define LCPLL_CLK_FREQ_54O_BDW(126)
#define LCPLL_CLK_FREQ_337_5_BDW(226)
#define LCPLL_CLK_FREQ_675_BDW(326)
#define LCPLL_CD_CLOCK_DISABLE(125)
+#define LCPLL_ROOT_CD_CLOCK_DISABLE(124)
#define LCPLL_CD2X_CLOCK_DISABLE(123)
#define LCPLL_POWER_DOWN_ALLOW(122)
#define LCPLL_CD_SOURCE_FCLK(121)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 3752d5e..cce7103 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -5012,7 +5012,16 @@ static void intel_update_max_cdclk(struct
drm_device *dev)
{
struct drm_i915_private *dev_priv = dev-dev_private;
-if (IS_VALLEYVIEW(dev)) {
+if (IS_HASWELL(dev)) {
+if (I915_READ(FUSE_STRAP) HSW_CDCLK_LIMIT)
+dev_priv-max_cdclk_freq = 45;
+else if (IS_HSW_ULX(dev))
+dev_priv-max_cdclk_freq = 337500;
+else if (IS_HSW_ULT(dev))
+dev_priv-max_cdclk_freq = 45;
+else
+dev_priv-max_cdclk_freq = 54;
+} else if (IS_VALLEYVIEW(dev)) {
dev_priv-max_cdclk_freq = 40;
} else {
/* otherwise assume cdclk is fixed */
@@ -8773,6 +8782,144 @@ void hsw_enable_pc8(struct drm_i915_private
*dev_priv)
hsw_disable_lcpll(dev_priv, true, true);
}
+/* compute the max rate for new configuration */
+static int ilk_max_pixel_rate(struct drm_i915_private *dev_priv)
+{
+struct drm_device *dev = dev_priv-dev;
+struct intel_crtc *crtc;
+int max_pixel_rate = 0;
+
+for_each_intel_crtc(dev, crtc) {
+if (crtc-new_enabled)
+max_pixel_rate = max(max_pixel_rate,
+ ilk_pipe_pixel_rate(crtc-new_config));
+}
+
+return max_pixel_rate;
+}
+
+static int haswell_calc_cdclk(struct drm_i915_private *dev_priv,
+ int max_pixel_rate)
+{
+int cdclk;
+
+/*
+ * FIXME should also account for plane ratio
+ * once 64bpp pixel formats are supported.
+ */
+if (max_pixel_rate 45)
+cdclk = 54;
+else if (max_pixel_rate 337500 || !IS_HSW_ULX(dev_priv))
+cdclk = 45;
+else
+cdclk = 337500;
+
+/*
+ * FIXME move the cdclk caclulation to
+ * compute_config() so we can fail gracegully.
+ */
+if (cdclk dev_priv-max_cdclk_freq) {
+DRM_ERROR(requested cdclk (%d kHz) exceeds max (%d kHz)\n,
+ cdclk, dev_priv-max_cdclk_freq);
+cdclk = dev_priv-max_cdclk_freq;
+}
+
+return cdclk;
+}
won't this return 337MHz even for platforms that have HSW_CDCLK_LIMIT
is set ? this should return 450MHz if this fuse is set
+
+static void haswell_set_cdclk(struct drm_device *dev, int cdclk)
+{
+struct drm_i915_private *dev_priv = dev-dev_private;
+uint32_t val;
+
+if (WARN((I915_READ(LCPLL_CTL)
+
Re: [Intel-gfx] [PATCH 1/6] drm/i915: Don't use staged config for VLV cdclk calculations
On Thu, Apr 02, 2015 at 02:47:56PM +0300, Ander Conselvan de Oliveira wrote:
-static void valleyview_modeset_global_pipes(struct drm_device *dev,
+static int valleyview_modeset_global_pipes(struct drm_atomic_state *state,
unsigned *prepare_pipes)
{
- struct drm_i915_private *dev_priv = dev-dev_private;
+ struct drm_i915_private *dev_priv = to_i915(state-dev);
struct intel_crtc *intel_crtc;
- int max_pixclk = intel_mode_max_pixclk(dev_priv);
+ int max_pixclk = intel_mode_max_pixclk(state);
+
+ if (max_pixclk 0)
+ return max_pixclk;
if (valleyview_calc_cdclk(dev_priv, max_pixclk) ==
dev_priv-vlv_cdclk_freq)
We need to move the current cdclk_freq into the global state like the
shared pll state. But that's for another patch series, can you please make
a note about it to make sure we don't forget?
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/6] drm/i915: Don't use intel_crtc-new_config in pll calculation code
On Thu, Apr 02, 2015 at 02:47:57PM +0300, Ander Conselvan de Oliveira wrote:
Move towards atomic by using the atomic state instead.
Signed-off-by: Ander Conselvan de Oliveira
ander.conselvan.de.olive...@intel.com
---
drivers/gpu/drm/i915/intel_display.c | 15 +++
1 file changed, 11 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index a6cd8c7..0b7ddee 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -11581,10 +11581,11 @@ intel_modeset_compute_config(struct drm_crtc *crtc,
return intel_atomic_get_crtc_state(state, to_intel_crtc(crtc));;
}
-static int __intel_set_mode_setup_plls(struct drm_device *dev,
+static int __intel_set_mode_setup_plls(struct drm_atomic_state *state,
unsigned modeset_pipes,
unsigned disable_pipes)
Bikeshed: The name of this function is a bit confusion - it's part of the
compute_config phase of modesets still, but not really named like that.
Same with the call to valleyview_modeset_global_pipes right above it.
The problem is also that this is separated from the other compute_config
code. Hence I think we can only apply some polish here once that's all
unified again and merged into the overall atomic_check function.
-Daniel
{
+ struct drm_device *dev = state-dev;
struct drm_i915_private *dev_priv = to_i915(dev);
unsigned clear_pipes = modeset_pipes | disable_pipes;
struct intel_crtc *intel_crtc;
@@ -11598,9 +11599,15 @@ static int __intel_set_mode_setup_plls(struct
drm_device *dev,
goto done;
for_each_intel_crtc_masked(dev, modeset_pipes, intel_crtc) {
- struct intel_crtc_state *state = intel_crtc-new_config;
+ struct intel_crtc_state *crtc_state =
+ intel_atomic_get_crtc_state(state, intel_crtc);
+
+ /* Modeset pipes should have a new state by now */
+ if (WARN_ON(IS_ERR(crtc_state)))
+ continue;
+
ret = dev_priv-display.crtc_compute_clock(intel_crtc,
-state);
+crtc_state);
if (ret) {
intel_shared_dpll_abort_config(dev_priv);
goto done;
@@ -11658,7 +11665,7 @@ static int __intel_set_mode(struct drm_crtc *crtc,
prepare_pipes = ~disable_pipes;
}
- ret = __intel_set_mode_setup_plls(dev, modeset_pipes, disable_pipes);
+ ret = __intel_set_mode_setup_plls(state, modeset_pipes, disable_pipes);
if (ret)
goto done;
--
2.1.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 0/6] Remove more staged config usage
On Thu, Apr 02, 2015 at 02:47:55PM +0300, Ander Conselvan de Oliveira wrote: These patches remove usage of the staged config from the modeset path that I overlooked in my previous patch series. Ander Conselvan de Oliveira (6): drm/i915: Don't use staged config for VLV cdclk calculations drm/i915: Don't use intel_crtc-new_config in pll calculation code drm/i915: Remove intel_crtc-new_config drm/i915: Don't use staged config in check_digital_port_conflicts() drm/i915: Don't use staged config in check_encoder_cloning() drm/i915: Don't use staged config in intel_mst_pre_enable_dp() Entire series merged, thanks. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 15/19] drm/i915: HSW cdclk support
Definitely a good idea to check the audio part as well if there is a doubt that by changing CD clock the audio would fail. I can check this and I'll get back once I have the results. Cheers, Mika On Tue, Apr 07, 2015 at 02:06:50PM +0530, Sivakumar Thulasimani wrote: where can i check this (audio driver) ? since there was no need for them to check CD clock value till now i don't think they will be doing it. also this needs to be changed in Display Audio controller, so not sure if audio driver has access to it in the first place. will be good to confirm this before merging as it will break display audio if it is not programmed. if any one has setup this can be confirmed by just switching CD clock after boot and playing an audio file. regards, Sivakumar On 4/7/2015 1:59 PM, Ville Syrjälä wrote: On Tue, Apr 07, 2015 at 12:33:40PM +0530, Sivakumar Thulasimani wrote: sorry if i am missing something, HSW and BDW requires display audio controller to be updated with new values once CD clock is modified. how is this accomplished here ? I'm hoping the audio driver will query the cdclk frequency after every modeset. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: use kref_put_mutex in i915_gem_request_unreference__unlocked
Signed-off-by: Maarten Lankhorst maarten.lankho...@linux.intel.com
---
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index b13c5526a73b..7aaf8eddf19c 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2146,14 +2146,14 @@ i915_gem_request_unreference(struct
drm_i915_gem_request *req)
static inline void
i915_gem_request_unreference__unlocked(struct drm_i915_gem_request *req)
{
- if (req !atomic_add_unless(req-ref.refcount, -1, 1)) {
- struct drm_device *dev = req-ring-dev;
+ struct drm_device *dev;
+
+ if (!req)
+ return;
- mutex_lock(dev-struct_mutex);
- if (likely(atomic_dec_and_test(req-ref.refcount)))
- i915_gem_request_free(req-ref);
+ dev = req-ring-dev;
+ if (kref_put_mutex(req-ref, i915_gem_request_free,
dev-struct_mutex))
mutex_unlock(dev-struct_mutex);
- }
}
static inline void i915_gem_request_assign(struct drm_i915_gem_request **pdst,
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 19/19] drm/i915: Modeset global_pipes() update
Combined Valleyview, Haswell and Broadwell '*_modeset_global_pipes()'
into one function 'intel_modeset_global_pipes()'
v2:
- we don't modify 'disable_pipes', so passing this as a pointer
is removed (based on Ville's comment)
- introduced a new function 'intel_calc_cdclk()' that combines
routines from 'valleyview_calc_cdclk()' and 'haswell_calc_cdclk()'
v3:
- Let's take a step back and not remove the routines 'valleyview_calc_cdclk()'
and 'haswell_calc_cdclk()' from newly introduced routine
'intel_calc_cdclk()' (based on Ville's comment)
Signed-off-by: Mika Kahola mika.kah...@intel.com
---
drivers/gpu/drm/i915/intel_display.c | 63 ++--
1 file changed, 32 insertions(+), 31 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 7b97907..f05bd12 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -5225,22 +5225,6 @@ static int intel_mode_max_pixclk(struct drm_i915_private
*dev_priv)
return max_pixclk;
}
-static void valleyview_modeset_global_pipes(struct drm_device *dev,
- unsigned *prepare_pipes)
-{
- struct drm_i915_private *dev_priv = dev-dev_private;
- struct intel_crtc *intel_crtc;
- int max_pixclk = intel_mode_max_pixclk(dev_priv);
-
- if (valleyview_calc_cdclk(dev_priv, max_pixclk) == dev_priv-cdclk_freq)
- return;
-
- /* disable/enable all currently active pipes while we change cdclk */
- for_each_intel_crtc(dev, intel_crtc)
- if (intel_crtc-base.state-enable)
- *prepare_pipes |= (1 intel_crtc-pipe);
-}
-
static void vlv_program_pfi_credits(struct drm_i915_private *dev_priv)
{
unsigned int credits, default_credits;
@@ -8787,21 +8771,46 @@ static void broadwell_set_cdclk(struct drm_device *dev,
int cdclk)
cdclk, dev_priv-cdclk_freq);
}
-static void haswell_modeset_global_pipes(struct drm_device *dev,
-unsigned *prepare_pipes)
+static int intel_calc_cdclk(struct drm_device *dev, int max_pixclk)
+{
+ struct drm_i915_private *dev_priv = dev-dev_private;
+ int cdclk;
+
+ if (IS_VALLEYVIEW(dev))
+ cdclk = valleyview_calc_cdclk(dev_priv, max_pixclk);
+ else if (IS_HASWELL(dev) || IS_BROADWELL(dev))
+ cdclk = haswell_calc_cdclk(dev_priv, max_pixclk);
+
+ return cdclk;
+}
+
+static void intel_modeset_global_pipes(struct drm_device *dev,
+ unsigned *prepare_pipes,
+ unsigned disable_pipes)
{
struct drm_i915_private *dev_priv = dev-dev_private;
struct intel_crtc *crtc;
- int max_pixel_rate = ilk_max_pixel_rate(dev_priv);
+ int max_pixclk;
- if (haswell_calc_cdclk(dev_priv, max_pixel_rate) ==
- dev_priv-cdclk_freq)
+ /* this modeset is valid only for VLV, HSW, and BDW */
+ if (!IS_VALLEYVIEW(dev) !IS_HASWELL(dev) !IS_BROADWELL(dev))
+ return;
+
+ if (IS_VALLEYVIEW(dev))
+ max_pixclk = intel_mode_max_pixclk(dev_priv);
+ else if (IS_HASWELL(dev) || IS_BROADWELL(dev))
+ max_pixclk = ilk_max_pixel_rate(dev_priv);
+
+ if (intel_calc_cdclk(dev, max_pixclk) == dev_priv-cdclk_freq)
return;
/* disable/enable all currently active pipes while we change cdclk */
for_each_intel_crtc(dev, crtc)
- if (crtc-base.enabled)
+ if (crtc-base.state-enable)
*prepare_pipes |= 1 crtc-pipe;
+
+ /* may have added more to prepare_pipes than we should */
+ *prepare_pipes = ~disable_pipes;
}
static void haswell_modeset_global_resources(struct drm_atomic_state *state)
@@ -11933,15 +11942,7 @@ static int __intel_set_mode(struct drm_crtc *crtc,
* mode set on this crtc. For other crtcs we need to use the
* adjusted_mode bits in the crtc directly.
*/
- if (IS_VALLEYVIEW(dev) || IS_HASWELL(dev) || IS_BROADWELL(dev)) {
- if (IS_VALLEYVIEW(dev))
- valleyview_modeset_global_pipes(dev, prepare_pipes);
- else
- haswell_modeset_global_pipes(dev, prepare_pipes);
-
- /* may have added more to prepare_pipes than we should */
- prepare_pipes = ~disable_pipes;
- }
+ intel_modeset_global_pipes(dev, prepare_pipes, disable_pipes);
ret = __intel_set_mode_setup_plls(dev, modeset_pipes, disable_pipes);
if (ret)
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] 4.0.0-rc5 GFX warning
Please try v4.0-rc7. BR, Jani. On Mon, 06 Apr 2015, Winkler, Tomas tomas.wink...@intel.com wrote: Ubuntu 14.04.2 LTS 00:02.0 VGA compatible controller: Intel Corporation Xeon E3-1200 v3/4th Gen Core Processor Integrated Graphics Controller (rev 06) (prog-if 00 [VGA controller]) Subsystem: Gigabyte Technology Co., Ltd Device d000 Flags: bus master, fast devsel, latency 0, IRQ 29 Memory at f000 (64-bit, non-prefetchable) [size=4M] Memory at e000 (64-bit, prefetchable) [size=256M] I/O ports at f000 [size=64] Expansion ROM at unassigned [disabled] Capabilities: [90] MSI: Enable+ Count=1/1 Maskable- 64bit- Capabilities: [d0] Power Management version 2 Capabilities: [a4] PCI Advanced Features Kernel driver in use: i915 [ cut here ] [ 27.686672] WARNING: CPU: 5 PID: 97 at drivers/gpu/drm/drm_atomic.c:482 drm_atomic_check_only+0x36d/0x520 [drm]() [ 27.686684] Modules linked in: bnep i915 rfcomm bluetooth nfsd auth_rpcgss drm_kms_helper oid_registry hid_generic nfs_acl drm nfs usbhid hid x86_pkg_temp_thermal snd_hda_codec_realtek coretemp snd_hda_codec_generic kvm_intel snd_hda_intel snd_hda_controller snd_hda_codec kvm lockd snd_hwdep snd_pcm snd_seq_midi snd_seq_midi_event snd_rawmidi grace sunrpc snd_seq r8169 snd_seq_device snd_timer mei_me mii mei ghash_clmulni_intel aesni_intel snd shpchp i2c_algo_bit soundcore lpc_ich aes_x86_64 ablk_helper cryptd lrw gf128mul glue_helper psmouse microcode tpm_infineon tpm_tis mac_hid serio_raw fscache video binfmt_misc nls_iso8859_1 parport_pc ppdev lp parport [ 27.686685] CPU: 5 PID: 97 Comm: kworker/u16:6 Tainted: GW I 4.0.0-rc5-mei+ #1 [ 27.686686] Hardware name: Gigabyte Technology Co., Ltd. H87M-D3H/H87M-D3H, BIOS F6 08/03/2013 [ 27.686689] Workqueue: events_unbound async_run_entry_fn [ 27.686702] a03e5a1f 88003744f7b8 81771c54 117a [ 27.686703] 88003744f7f8 81054b8a 88003744f818 [ 27.686704] 88023267ad80 880232b3e960 880037633c00 [ 27.686704] Call Trace: [ 27.686707] [81771c54] dump_stack+0x4c/0x65 [ 27.686709] [81054b8a] warn_slowpath_common+0x8a/0xc0 [ 27.686711] [81054c7a] warn_slowpath_null+0x1a/0x20 [ 27.686718] [a03d202d] drm_atomic_check_only+0x36d/0x520 [drm] [ 27.686720] [811792d6] ? kmemdup+0x36/0x50 [ 27.686741] [a03d21f7] drm_atomic_commit+0x17/0x60 [drm] [ 27.686745] [a0278dad] drm_atomic_helper_plane_set_property+0x8d/0xd0 [drm_kms_helper] [ 27.686752] [a03c036d] drm_mode_plane_set_obj_prop+0x2d/0x90 [drm] [ 27.686756] [a027ab4b] restore_fbdev_mode+0x6b/0xf0 [drm_kms_helper] [ 27.686759] [a027caa9] drm_fb_helper_restore_fbdev_mode_unlocked+0x29/0x80 [drm_kms_helper] [ 27.686762] [a027cb22] drm_fb_helper_set_par+0x22/0x50 [drm_kms_helper] [ 27.686780] [a0803dca] intel_fbdev_set_par+0x1a/0x60 [i915] [ 27.686782] [81412014] fbcon_init+0x4f4/0x580 [ 27.686785] [814878dc] visual_init+0xbc/0x120 [ 27.686787] [8148a153] do_bind_con_driver+0x163/0x330 [ 27.686789] [8148a8a4] do_take_over_console+0x114/0x1c0 [ 27.686790] [8140d913] do_fbcon_takeover+0x63/0xd0 [ 27.686792] [81412bc5] fbcon_event_notify+0x795/0x8e0 [ 27.686793] [81415cbd] ? lock_fb_info+0x1d/0x50 [ 27.686795] [81075afe] notifier_call_chain+0x4e/0x80 [ 27.686797] [81075de3] __blocking_notifier_call_chain+0x53/0x70 [ 27.686798] [81075e16] blocking_notifier_call_chain+0x16/0x20 [ 27.686800] [814156cb] fb_notifier_call_chain+0x1b/0x20 [ 27.686801] [8141783c] register_framebuffer+0x1ec/0x330 [ 27.686805] [a027cdac] drm_fb_helper_initial_config+0x25c/0x3a0 [drm_kms_helper] [ 27.686820] [a080507b] intel_fbdev_initial_config+0x1b/0x20 [i915] [ 27.686822] [810777ea] async_run_entry_fn+0x4a/0x140 [ 27.686825] [8106f152] process_one_work+0x1c2/0x530 [ 27.686827] [8106f0db] ? process_one_work+0x14b/0x530 [ 27.686828] [8106f5db] worker_thread+0x11b/0x460 [ 27.686830] [8106f4c0] ? process_one_work+0x530/0x530 [ 27.686832] [81074a4f] kthread+0xef/0x110 [ 27.686833] [8107a34d] ? finish_task_switch+0x4d/0x130 [ 27.686835] [81074960] ? kthread_create_on_node+0x210/0x210 [ 27.686838] [8177b408] ret_from_fork+0x58/0x90 [ 27.686839] [81074960] ? kthread_create_on_node+0x210/0x210 Xorg.0.log [34.243] X Protocol Version 11, Revision 0 [34.243] Build Operating System: Linux 3.2.0-76-generic x86_64 Ubuntu [34.243] Current Operating System: Linux linux-tw 4.0.0-rc5-mei+ #1
Re: [Intel-gfx] [PATCH] drm/i915: reset drm state backpointer in crtc_state
On Mon, 06 Apr 2015, Chandra Konduru chandra.kond...@intel.com wrote:
At end of intel_crtc_set_config, reset crtc_state's
drm_state back pointer to null.
This does not tell me anything that reading the patch already
didn't. Please explain *why* this is needed in the commit message. What
breaks without it? If this fixes a regression, please indicate which
commit regressed.
BR,
Jani.
Signed-off-by: Chandra Konduru chandra.kond...@intel.com
---
drivers/gpu/drm/i915/intel_display.c |4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index c84926b..f9c2e4d 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -12451,8 +12451,10 @@ fail:
}
out_config:
- if (state)
+ if (state) {
drm_atomic_state_free(state);
+ to_intel_crtc(set-crtc)-config-base.state = NULL;
+ }
intel_set_config_free(config);
return ret;
--
1.7.9.5
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Jani Nikula, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 7/7] lib: add igt_draw
On Tue, Apr 07, 2015 at 09:36:37AM +0100, Chris Wilson wrote:
On Tue, Apr 07, 2015 at 10:10:25AM +0200, Daniel Vetter wrote:
On Thu, Apr 02, 2015 at 12:15:13AM +0100, Chris Wilson wrote:
On Wed, Apr 01, 2015 at 07:40:59PM -0300, Paulo Zanoni wrote:
+static void draw_rect_mmap_wc(int fd, struct buf_data *buf, struct
rect *rect,
+ uint32_t color)
+{
+ uint32_t *ptr;
+ uint32_t tiling, swizzle;
+
+ gem_get_tiling(fd, buf-handle, tiling, swizzle);
+
+ /* We didn't implement suport for the older tiling methods yet.
*/
+ if (tiling != I915_TILING_NONE)
+ igt_require(intel_gen(intel_get_drm_devid(fd)) = 5);
But you now do! You need something like:
The problem is that the kernel hides bit17 swizzling. I chatted with Paulo
on irc about this and we decided just ignore them all is the simplest
approach.
Urm, that was the whole point of GET_TILING v2. That small function is
all you need to determine when bit17 is in effect and then you get to
reuse all the direct CPU methods (as they are also used by userspace)
for earlier gen.
Oh right completely forgot that we've added this. But imo can be added on
top once we need it (it's not just gen2 but also some gen3 which need
different tile dimensions).
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC, 1/4] drm/i915: Convert requests to use struct fence
Hey,
Op 20-03-15 om 18:48 schreef john.c.harri...@intel.com:
From: John Harrison john.c.harri...@intel.com
There is a construct in the linux kernel called 'struct fence' that is
intended
to keep track of work that is executed on hardware. I.e. it solves the basic
problem that the drivers 'struct drm_i915_gem_request' is trying to address.
The
request structure does quite a lot more than simply track the execution
progress
so is very definitely still required. However, the basic completion status
side
could be updated to use the ready made fence implementation and gain all the
advantages that provides.
This patch makes the first step of integrating a struct fence into the
request.
It replaces the explicit reference count with that of the fence. It also
replaces the 'is completed' test with the fence's equivalent. Currently, that
simply chains on to the original request implementation. A future patch will
improve this.
For: VIZ-5190
Signed-off-by: John Harrison john.c.harri...@intel.com
---
drivers/gpu/drm/i915/i915_drv.h | 37 +
drivers/gpu/drm/i915/i915_gem.c | 55
---
drivers/gpu/drm/i915/intel_lrc.c|1 +
drivers/gpu/drm/i915/intel_ringbuffer.c |1 +
drivers/gpu/drm/i915/intel_ringbuffer.h |3 ++
5 files changed, 70 insertions(+), 27 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index ce3a536..7dcaf8c 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -50,6 +50,7 @@
#include linux/intel-iommu.h
#include linux/kref.h
#include linux/pm_qos.h
+#include linux/fence.h
/* General customization:
*/
@@ -2048,7 +2049,11 @@ void i915_gem_track_fb(struct drm_i915_gem_object *old,
* initial reference taken using kref_init
*/
struct drm_i915_gem_request {
- struct kref ref;
+ /** Underlying object for implementing the signal/wait stuff.
+ * NB: Never call fence_later()! Due to lazy allocation, scheduler
+ * re-ordering, pre-emption, etc., there is no guarantee at all
+ * about the validity or sequentialiaty of the fence's seqno! */
+ struct fence fence;
Set fence.context differently for each per context timeline. :-)
+static bool i915_gem_request_enable_signaling(struct fence *req_fence)
+{
+ WARN(true, Is this required?);
+ return true;
+}
Yes, try calling fence_wait() on the fence. :-) This function should call
irq_get and add itself to ring-irq_queue.
See for an example radeon_fence_enable_signaling.
@@ -2557,6 +2596,8 @@ int i915_gem_request_alloc(struct intel_engine_cs *ring,
return ret;
}
+ fence_init(request-fence, i915_gem_request_fops, ring-fence_lock,
ring-fence_context, request-seqno);
+
/*
* Reserve space in the ring buffer for all the commands required to
* eventually emit this request. This is to guarantee that the
Use ring-irq_queue.lock instead of making a new lock? This will make
implementing enable_signaling easier too.
~Maarten
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 4/6] drm/i915: Don't use staged config in check_digital_port_conflicts()
On Thu, Apr 02, 2015 at 02:47:59PM +0300, Ander Conselvan de Oliveira wrote:
Reduce dependency on the staged config by using the atomic state
instead.
Signed-off-by: Ander Conselvan de Oliveira
ander.conselvan.de.olive...@intel.com
---
drivers/gpu/drm/i915/intel_display.c | 22 ++
1 file changed, 14 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 207c713..b1fbe9d 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -10658,23 +10658,30 @@ static bool check_encoder_cloning(struct intel_crtc
*crtc)
return true;
}
-static bool check_digital_port_conflicts(struct drm_device *dev)
+static bool check_digital_port_conflicts(struct drm_atomic_state *state)
{
- struct intel_connector *connector;
+ struct drm_device *dev = state-dev;
+ struct intel_encoder *encoder;
+ struct drm_connector_state *connector_state;
unsigned int used_ports = 0;
+ int i;
/*
* Walk the connector list instead of the encoder
* list to detect the problem on ddi platforms
* where there's just one encoder per digital port.
*/
- for_each_intel_connector(dev, connector) {
- struct intel_encoder *encoder = connector-new_encoder;
+ for (i = 0; i state-num_connector; i++) {
+ if (!state-connectors[i])
+ continue;
More users for for_each_connector_in_state!
-Daniel
- if (!encoder)
+ connector_state = state-connector_states[i];
+ if (!connector_state-best_encoder)
continue;
- WARN_ON(!encoder-new_crtc);
+ encoder = to_intel_encoder(connector_state-best_encoder);
+
+ WARN_ON(!connector_state-crtc);
switch (encoder-type) {
unsigned int port_mask;
@@ -10716,7 +10723,6 @@ intel_modeset_pipe_config(struct drm_crtc *crtc,
struct drm_display_mode *mode,
struct drm_atomic_state *state)
{
- struct drm_device *dev = crtc-dev;
struct intel_encoder *encoder;
struct intel_connector *connector;
struct drm_connector_state *connector_state;
@@ -10730,7 +10736,7 @@ intel_modeset_pipe_config(struct drm_crtc *crtc,
return ERR_PTR(-EINVAL);
}
- if (!check_digital_port_conflicts(dev)) {
+ if (!check_digital_port_conflicts(state)) {
DRM_DEBUG_KMS(rejecting conflicting digital port
configuration\n);
return ERR_PTR(-EINVAL);
}
--
2.1.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 7/7] lib: add igt_draw
On Tue, Apr 07, 2015 at 11:07:07AM +0200, Daniel Vetter wrote:
On Tue, Apr 07, 2015 at 09:36:37AM +0100, Chris Wilson wrote:
On Tue, Apr 07, 2015 at 10:10:25AM +0200, Daniel Vetter wrote:
On Thu, Apr 02, 2015 at 12:15:13AM +0100, Chris Wilson wrote:
On Wed, Apr 01, 2015 at 07:40:59PM -0300, Paulo Zanoni wrote:
+static void draw_rect_mmap_wc(int fd, struct buf_data *buf, struct
rect *rect,
+ uint32_t color)
+{
+ uint32_t *ptr;
+ uint32_t tiling, swizzle;
+
+ gem_get_tiling(fd, buf-handle, tiling, swizzle);
+
+ /* We didn't implement suport for the older tiling methods yet.
*/
+ if (tiling != I915_TILING_NONE)
+ igt_require(intel_gen(intel_get_drm_devid(fd)) = 5);
But you now do! You need something like:
The problem is that the kernel hides bit17 swizzling. I chatted with Paulo
on irc about this and we decided just ignore them all is the simplest
approach.
Urm, that was the whole point of GET_TILING v2. That small function is
all you need to determine when bit17 is in effect and then you get to
reuse all the direct CPU methods (as they are also used by userspace)
for earlier gen.
Oh right completely forgot that we've added this. But imo can be added on
top once we need it (it's not just gen2 but also some gen3 which need
different tile dimensions).
Tile size is 2048 for gen2 only right. Tile width is the same for all
gen3 for tiling X (and gen2), but tiling Y width depends on subgen.
Right?
Just need to check because I have code that depends on this...
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915/bxt: Enable existing gen9 harware workarounds for Broxton
Signed-off-by: Nick Hoath nicholas.ho...@intel.com
---
drivers/gpu/drm/i915/i915_reg.h | 8 +
drivers/gpu/drm/i915/intel_pm.c | 2 ++
drivers/gpu/drm/i915/intel_ringbuffer.c | 53 +++--
3 files changed, 41 insertions(+), 22 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 7e1a0fd9..91eef06 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -5339,6 +5339,7 @@ enum skl_disp_power_wells {
#define GEN8_L3SQCREG4 0xb118
#define GEN8_LQSC_RO_PERF_DIS (127)
+#define GEN8_PIPELINE_FLUSH_COHERENT_LINES(121)
/* GEN8 chicken */
#define HDC_CHICKEN0 0x7300
@@ -7324,4 +7325,11 @@ enum skl_disp_power_wells {
#define _PALETTE_A (dev_priv-info.display_mmio_offset + 0xa000)
#define _PALETTE_B (dev_priv-info.display_mmio_offset + 0xa800)
+/*
+ * Chicken Registers for LLC/eLLC Hot Spotting Avoidance Mode for
+ * 3D/Media Compressed Resources
+ */
+#define GEN9_CHICKEN_MISC1_REG 0x42080
+#define GEN9_CHICKEN_MISC1_NEW_HASH_ENABLE (115)
+
#endif /* _I915_REG_H_ */
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index c3c473d..bbb5d64 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -96,6 +96,8 @@ static void skl_init_clock_gating(struct drm_device *dev)
static void bxt_init_clock_gating(struct drm_device *dev)
{
+ struct drm_i915_private *dev_priv = dev-dev_private;
+
gen9_init_clock_gating(dev);
/* WaVSRefCountFullforceMissDisable:bxt */
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c
b/drivers/gpu/drm/i915/intel_ringbuffer.c
index 44c7b99..741bdfa 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.c
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
@@ -916,7 +916,7 @@ static int gen9_init_workarounds(struct intel_engine_cs
*ring)
struct drm_device *dev = ring-dev;
struct drm_i915_private *dev_priv = dev-dev_private;
- /* WaDisablePartialInstShootdown:skl */
+ /* WaDisablePartialInstShootdown:skl,bxt */
WA_SET_BIT_MASKED(GEN8_ROW_CHICKEN,
PARTIAL_INSTRUCTION_SHOOTDOWN_DISABLE);
@@ -924,45 +924,43 @@ static int gen9_init_workarounds(struct intel_engine_cs
*ring)
WA_SET_BIT_MASKED(HALF_SLICE_CHICKEN3,
GEN9_DISABLE_OCL_OOB_SUPPRESS_LOGIC);
- if (INTEL_REVID(dev) == SKL_REVID_A0 ||
- INTEL_REVID(dev) == SKL_REVID_B0) {
- /* WaDisableDgMirrorFixInHalfSliceChicken5:skl */
+ if (
+ (IS_SKYLAKE(dev) (INTEL_REVID(dev) == SKL_REVID_A0 ||
+ INTEL_REVID(dev) == SKL_REVID_B0)) ||
+ (IS_BROXTON(dev) INTEL_REVID(dev) == BXT_REVID_A0)
+ ) {
+ /* WaDisableDgMirrorFixInHalfSliceChicken5:skl,bxt */
WA_CLR_BIT_MASKED(GEN9_HALF_SLICE_CHICKEN5,
GEN9_DG_MIRROR_FIX_ENABLE);
}
- if (IS_SKYLAKE(dev) INTEL_REVID(dev) = SKL_REVID_B0) {
- /* WaSetDisablePixMaskCammingAndRhwoInCommonSliceChicken:skl */
+ if (
+ (IS_SKYLAKE(dev) INTEL_REVID(dev) = SKL_REVID_B0) ||
+ (IS_BROXTON(dev) INTEL_REVID(dev) == BXT_REVID_A0)
+ ) {
+ /*
WaSetDisablePixMaskCammingAndRhwoInCommonSliceChicken:skl,bxt */
WA_SET_BIT_MASKED(GEN7_COMMON_SLICE_CHICKEN1,
GEN9_RHWO_OPTIMIZATION_DISABLE);
WA_SET_BIT_MASKED(GEN9_SLICE_COMMON_ECO_CHICKEN0,
DISABLE_PIXEL_MASK_CAMMING);
}
- if (INTEL_REVID(dev) = SKL_REVID_C0) {
- /* WaEnableYV12BugFixInHalfSliceChicken7:skl */
+ if (
+ (IS_SKYLAKE(dev) INTEL_REVID(dev) = SKL_REVID_C0) ||
+ (IS_BROXTON(dev))
+ ) {
+ /* WaEnableYV12BugFixInHalfSliceChicken7:skl,bxt */
WA_SET_BIT_MASKED(GEN9_HALF_SLICE_CHICKEN7,
GEN9_ENABLE_YV12_BUGFIX);
}
- if (INTEL_REVID(dev) = SKL_REVID_D0) {
- /*
-*Use Force Non-Coherent whenever executing a 3D context. This
-* is a workaround for a possible hang in the unlikely event
-* a TLB invalidation occurs during a PSD flush.
-*/
- /* WaForceEnableNonCoherent:skl */
- WA_SET_BIT_MASKED(HDC_CHICKEN0,
- HDC_FORCE_NON_COHERENT);
- }
-
- /* Wa4x4STCOptimizationDisable:skl */
+ /* Wa4x4STCOptimizationDisable:skl,bxt */
WA_SET_BIT_MASKED(CACHE_MODE_1, GEN8_4x4_STC_OPTIMIZATION_DISABLE);
- /* WaDisablePartialResolveInVc:skl */
+ /* WaDisablePartialResolveInVc:skl,bxt */
WA_SET_BIT_MASKED(CACHE_MODE_1,
Re: [Intel-gfx] [RFC, 1/4] drm/i915: Convert requests to use struct fence
Hey,
Op 07-04-15 om 12:59 schreef John Harrison:
On 07/04/2015 10:18, Maarten Lankhorst wrote:
Hey,
Op 20-03-15 om 18:48 schreef john.c.harri...@intel.com:
From: John Harrison john.c.harri...@intel.com
There is a construct in the linux kernel called 'struct fence' that is
intended
to keep track of work that is executed on hardware. I.e. it solves the basic
problem that the drivers 'struct drm_i915_gem_request' is trying to
address. The
request structure does quite a lot more than simply track the execution
progress
so is very definitely still required. However, the basic completion status
side
could be updated to use the ready made fence implementation and gain all the
advantages that provides.
This patch makes the first step of integrating a struct fence into the
request.
It replaces the explicit reference count with that of the fence. It also
replaces the 'is completed' test with the fence's equivalent. Currently,
that
simply chains on to the original request implementation. A future patch will
improve this.
For: VIZ-5190
Signed-off-by: John Harrison john.c.harri...@intel.com
---
drivers/gpu/drm/i915/i915_drv.h | 37 +
drivers/gpu/drm/i915/i915_gem.c | 55
---
drivers/gpu/drm/i915/intel_lrc.c|1 +
drivers/gpu/drm/i915/intel_ringbuffer.c |1 +
drivers/gpu/drm/i915/intel_ringbuffer.h |3 ++
5 files changed, 70 insertions(+), 27 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h
b/drivers/gpu/drm/i915/i915_drv.h
index ce3a536..7dcaf8c 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -50,6 +50,7 @@
#include linux/intel-iommu.h
#include linux/kref.h
#include linux/pm_qos.h
+#include linux/fence.h
/* General customization:
*/
@@ -2048,7 +2049,11 @@ void i915_gem_track_fb(struct drm_i915_gem_object
*old,
* initial reference taken using kref_init
*/
struct drm_i915_gem_request {
-struct kref ref;
+/** Underlying object for implementing the signal/wait stuff.
+ * NB: Never call fence_later()! Due to lazy allocation, scheduler
+ * re-ordering, pre-emption, etc., there is no guarantee at all
+ * about the validity or sequentialiaty of the fence's seqno! */
+struct fence fence;
Set fence.context differently for each per context timeline. :-)
Yeah, I didn't like the way the description for fence_later() says 'returns
NULL if both fences are signaled' and then also returns null on a context
mismatch. I was also not entirely sure what the fence context thing is meant
to be for. AFAICT, the expectation is that there is only supposed to be a
finite and small number of contexts as there is no management of them. They
are simply an incrementing number with no way to 'release' a previously
allocated context. Whereas, the i915 context is per application in an
execlist enabled system. Potentially, multiple contexts per application even.
So there is an unbounded and large number of them about. That sounds like a
bad idea for the fence context implementation!
No memory is allocated for them, they're just numbers. Worst thing that can
happen is an integer overflow, if that would ever happen we can bump it to
int64_t. :-)
If you allocate 1000 contexts/second for 50 days you'll hit the overflow,
realistically that will never happen.. I wouldn't worry about it.
+static bool i915_gem_request_enable_signaling(struct fence *req_fence)
+{
+WARN(true, Is this required?);
+return true;
+}
Yes, try calling fence_wait() on the fence. :-) This function should call
irq_get and add itself to ring-irq_queue.
See for an example radeon_fence_enable_signaling.
See patch three in the series :). The above warning should really say 'This
should not be required yet.' but I didn't get around to updating it.
Oke.
@@ -2557,6 +2596,8 @@ int i915_gem_request_alloc(struct intel_engine_cs
*ring,
return ret;
}
+fence_init(request-fence, i915_gem_request_fops, ring-fence_lock,
ring-fence_context, request-seqno);
+
/*
* Reserve space in the ring buffer for all the commands required to
* eventually emit this request. This is to guarantee that the
Use ring-irq_queue.lock instead of making a new lock? This will make
implementing enable_signaling easier too.
Is that definitely safe? It won't cause conflicts or unnecessary
complications? Indeed, is one supposed to play around with the implicit lock
inside a wait queue?
It's your own workqueue, it's the only way to add a waiter reliably. The
spinlock's not taken unless absolutely needed.
~Maarten
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Allow userptr backchannel for passing aroung GTT mappings
On Tue, Apr 07, 2015 at 10:53:20AM +0200, Daniel Vetter wrote: On Thu, Apr 02, 2015 at 04:04:14PM +0100, Chris Wilson wrote: Once userptr becomes part of client API, it is almost a certainly that eventually someone will try to create a new object from a mapping of another client object, e.g. new = vaImport(vaMap(old, size), size); (using a hypothethical API, not meaning to pick on anyone!) Since this is actually fairly safe to implement and to allow (since it is within a single process space and the memory access passes the standard permissions test) let us not limit the Client possibilities. Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk Cc: Gwenole Beauchesne gwenole.beauche...@intel.com Cc: Michał Winiarski michal.winiar...@intel.com Cc: Tvrtko Ursulin tvrtko.ursu...@intel.com Thus far all the apis are very explicit in stating that you can only slurp in anything that's allocated with malloc and friends. Also usually this means we're dealing with tiled memory which looks linear, so I'm not sure how this will work. The user doesn't know the object it tiled, all they have is a linear mapping. The kernel doesn't care either, all it sees is a bo. The idea is to simply enable a likely usecase that just works. -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Pin tiled objects for L-shaped configs
On Tue, Apr 07, 2015 at 10:05:39AM +0200, Daniel Vetter wrote: On Fri, Apr 03, 2015 at 10:43:29AM +0100, Chris Wilson wrote: I resurrected my dual-channel evenly loaded gm45 and to my surprise found it reporting a L-shaped memory layout. Well my gm45 is also dual-channel and evenly loaded and still mangles tiled buffers when going through swap. Is gem_tiled_swapping happy on your box? ickle@x200s ~/intel-gpu-tools/tests $ sudo ./gem_tiled_swapping IGT-Version: 1.10-ge809895 (x86_64) (Linux: 4.0.0-rc6+ x86_64) Using 640 1MiB objects (available RAM: 343/3847, swap: 3989) Subtest non-threaded: SUCCESS (23.344s) Subtest threaded: SUCCESS (110.801s) Perhaps the if ((ddc2 DISABLE) == 0) is inverted or is not the truly magic bit? It was the best one I could find - given how old this all is now I think some false positives are acceptable in the test. I did try a few other things which did all fail. It's the false-negative I worry about. I am just worried this is not the bit we are looking for. Time will tell if we get a new bug report with broken swizzling after swapping. -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC, 1/4] drm/i915: Convert requests to use struct fence
On 07/04/2015 10:18, Maarten Lankhorst wrote:
Hey,
Op 20-03-15 om 18:48 schreef john.c.harri...@intel.com:
From: John Harrison john.c.harri...@intel.com
There is a construct in the linux kernel called 'struct fence' that is intended
to keep track of work that is executed on hardware. I.e. it solves the basic
problem that the drivers 'struct drm_i915_gem_request' is trying to address. The
request structure does quite a lot more than simply track the execution progress
so is very definitely still required. However, the basic completion status side
could be updated to use the ready made fence implementation and gain all the
advantages that provides.
This patch makes the first step of integrating a struct fence into the request.
It replaces the explicit reference count with that of the fence. It also
replaces the 'is completed' test with the fence's equivalent. Currently, that
simply chains on to the original request implementation. A future patch will
improve this.
For: VIZ-5190
Signed-off-by: John Harrison john.c.harri...@intel.com
---
drivers/gpu/drm/i915/i915_drv.h | 37 +
drivers/gpu/drm/i915/i915_gem.c | 55 ---
drivers/gpu/drm/i915/intel_lrc.c|1 +
drivers/gpu/drm/i915/intel_ringbuffer.c |1 +
drivers/gpu/drm/i915/intel_ringbuffer.h |3 ++
5 files changed, 70 insertions(+), 27 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index ce3a536..7dcaf8c 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -50,6 +50,7 @@
#include linux/intel-iommu.h
#include linux/kref.h
#include linux/pm_qos.h
+#include linux/fence.h
/* General customization:
*/
@@ -2048,7 +2049,11 @@ void i915_gem_track_fb(struct drm_i915_gem_object *old,
* initial reference taken using kref_init
*/
struct drm_i915_gem_request {
- struct kref ref;
+ /** Underlying object for implementing the signal/wait stuff.
+ * NB: Never call fence_later()! Due to lazy allocation, scheduler
+ * re-ordering, pre-emption, etc., there is no guarantee at all
+ * about the validity or sequentialiaty of the fence's seqno! */
+ struct fence fence;
Set fence.context differently for each per context timeline. :-)
Yeah, I didn't like the way the description for fence_later() says
'returns NULL if both fences are signaled' and then also returns null on
a context mismatch. I was also not entirely sure what the fence context
thing is meant to be for. AFAICT, the expectation is that there is only
supposed to be a finite and small number of contexts as there is no
management of them. They are simply an incrementing number with no way
to 'release' a previously allocated context. Whereas, the i915 context
is per application in an execlist enabled system. Potentially, multiple
contexts per application even. So there is an unbounded and large number
of them about. That sounds like a bad idea for the fence context
implementation!
+static bool i915_gem_request_enable_signaling(struct fence *req_fence)
+{
+ WARN(true, Is this required?);
+ return true;
+}
Yes, try calling fence_wait() on the fence. :-) This function should call irq_get
and add itself to ring-irq_queue.
See for an example radeon_fence_enable_signaling.
See patch three in the series :). The above warning should really say
'This should not be required yet.' but I didn't get around to updating it.
@@ -2557,6 +2596,8 @@ int i915_gem_request_alloc(struct intel_engine_cs *ring,
return ret;
}
+ fence_init(request-fence, i915_gem_request_fops, ring-fence_lock,
ring-fence_context, request-seqno);
+
/*
* Reserve space in the ring buffer for all the commands required to
* eventually emit this request. This is to guarantee that the
Use ring-irq_queue.lock instead of making a new lock? This will make
implementing enable_signaling easier too.
Is that definitely safe? It won't cause conflicts or unnecessary
complications? Indeed, is one supposed to play around with the implicit
lock inside a wait queue?
~Maarten
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/skl: Support for 90/270 rotation
Tested-By: Intel Graphics QA PRTS (Patch Regression Test System Contact: shuang...@intel.com) Task id: 6135 -Summary- Platform Delta drm-intel-nightly Series Applied PNV -1 272/272 271/272 ILK 302/302 302/302 SNB 303/303 303/303 IVB -1 338/338 337/338 BYT -1 287/287 286/287 HSW 361/361 361/361 BDW 308/308 308/308 -Detailed- Platform Testdrm-intel-nightly Series Applied PNV igt@gen3_render_tiledx_blits FAIL(7)PASS(6) FAIL(2) *IVB igt@gem_storedw_batches_loop@secure-dispatch PASS(2) DMESG_WARN(1)PASS(1) (dmesg patch applied)drm:i915_hangcheck_elapsed[i915]]*ERROR*Hangcheck_timer_elapsed...blitter_ring_idle@Hangcheck timer elapsed... blitter ring idle *BYT igt@gem_exec_bad_domains@conflicting-write-domain PASS(20) FAIL(1)PASS(1) Note: You need to pay more attention to line start with '*' ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH i-g-t] tests/gem_mmap_gtt: add huge BO test
Add a straightforward test that allocates a BO that is bigger than
(by 1 page currently) the mappable aperture, tests mmap access to it
by CPU directly and through GTT in sequence.
Currently it is expected for the GTT access to gracefully fail as
all objects are attempted to get pinned to GTT completely for mmap
access. Once the partial view support is merged to kernel, the test
should pass for all parts.
Signed-off-by: Joonas Lahtinen joonas.lahti...@linux.intel.com
---
tests/gem_mmap_gtt.c | 68
1 file changed, 68 insertions(+)
diff --git a/tests/gem_mmap_gtt.c b/tests/gem_mmap_gtt.c
index 55c66a2..bf3627c 100644
--- a/tests/gem_mmap_gtt.c
+++ b/tests/gem_mmap_gtt.c
@@ -41,6 +41,10 @@
#include drmtest.h
#include igt_debugfs.h
+#ifndef PAGE_SIZE
+#define PAGE_SIZE 4096
+#endif
+
static int OBJECT_SIZE = 16*1024*1024;
static void set_domain(int fd, uint32_t handle)
@@ -258,6 +262,68 @@ test_write_gtt(int fd)
}
static void
+test_huge_bo(int fd)
+{
+ uint32_t bo;
+ char *ptr_cpu;
+ char *ptr_gtt;
+ char *cpu_pattern;
+ uint64_t mappable_aperture_pages = gem_mappable_aperture_size() /
+ PAGE_SIZE;
+ uint64_t huge_object_size = (mappable_aperture_pages + 1) * PAGE_SIZE;
+ uint64_t last_offset = huge_object_size - PAGE_SIZE;
+
+ cpu_pattern = malloc(PAGE_SIZE);
+ igt_assert(cpu_pattern);
+ memset(cpu_pattern, 0xaa, PAGE_SIZE);
+
+ bo = gem_create(fd, huge_object_size);
+
+ ptr_cpu = gem_mmap__cpu(fd, bo, 0, huge_object_size,
+ PROT_READ | PROT_WRITE);
+ if (!ptr_cpu) {
+ igt_warn(Not enough free memory for huge BO test!\n);
+ goto out;
+ }
+
+ /* Test read/write to first/last page with CPU. */
+ memcpy(ptr_cpu, cpu_pattern, PAGE_SIZE);
+ igt_assert(memcmp(ptr_cpu, cpu_pattern, PAGE_SIZE) == 0);
+
+ memcpy(ptr_cpu + last_offset, cpu_pattern, PAGE_SIZE);
+ igt_assert(memcmp(ptr_cpu + last_offset, cpu_pattern, PAGE_SIZE) == 0);
+
+ igt_assert(memcmp(ptr_cpu, ptr_cpu + last_offset, PAGE_SIZE) == 0);
+
+ munmap(ptr_cpu, huge_object_size);
+ ptr_cpu = NULL;
+
+ ptr_gtt = gem_mmap__gtt(fd, bo, huge_object_size,
+ PROT_READ | PROT_WRITE);
+ if (!ptr_gtt) {
+ igt_debug(Huge BO GTT mapping not supported!\n);
+ goto out;
+ }
+
+ /* Test read/write to first/last page through GTT. */
+ set_domain(fd, bo);
+
+ igt_assert(memcmp(ptr_gtt, cpu_pattern, PAGE_SIZE) == 0);
+ igt_assert(memcmp(ptr_gtt + last_offset, cpu_pattern, PAGE_SIZE) == 0);
+
+ memset(ptr_gtt, 0x55, PAGE_SIZE);
+ igt_assert(memcmp(ptr_gtt + last_offset, cpu_pattern, PAGE_SIZE) == 0);
+
+ memset(ptr_gtt + last_offset, 0x55, PAGE_SIZE);
+ igt_assert(memcmp(ptr_gtt, ptr_gtt + last_offset, PAGE_SIZE) == 0);
+
+ munmap(ptr_gtt, huge_object_size);
+out:
+ gem_close(fd, bo);
+ free(cpu_pattern);
+}
+
+static void
test_read(int fd)
{
void *dst;
@@ -395,6 +461,8 @@ igt_main
run_without_prefault(fd, test_write_gtt);
igt_subtest(write-cpu-read-gtt)
test_write_cpu_read_gtt(fd);
+ igt_subtest(huge-bo)
+ test_huge_bo(fd);
igt_fixture
close(fd);
--
1.9.3
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Do not set L3-LLC Coherency bit in ctx descriptor
According to Spec this is a reserved bit for Gen9+ and should not be set. Change-Id: I0215fb7057b94139b7a2f90ecc7a0201c0c93ad4 Signed-off-by: Arun Siluvery arun.siluv...@linux.intel.com --- drivers/gpu/drm/i915/intel_lrc.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c index 1c3834fc..cfc73ea 100644 --- a/drivers/gpu/drm/i915/intel_lrc.c +++ b/drivers/gpu/drm/i915/intel_lrc.c @@ -265,7 +265,8 @@ static uint64_t execlists_ctx_descriptor(struct intel_engine_cs *ring, desc = GEN8_CTX_VALID; desc |= LEGACY_CONTEXT GEN8_CTX_MODE_SHIFT; - desc |= GEN8_CTX_L3LLC_COHERENT; + if (IS_GEN8(ctx_obj-base.dev)) + desc |= GEN8_CTX_L3LLC_COHERENT; desc |= GEN8_CTX_PRIVILEGE; desc |= lrca; desc |= (u64)intel_execlists_ctx_id(ctx_obj) GEN8_CTX_ID_SHIFT; -- 2.3.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/2] drm/i915/vlv: remove wait for previous GFX clk disable request
On Thu, 02 Apr 2015, Darren Hart darren.h...@intel.com wrote: Jesse Barnes jbarnes at virtuousgeek.org writes: Looks like it was introduced in: commit 650ad970a39f8b6164fe8613edc150f585315289 Author: Imre Deak imre.deak at intel.com Date: Fri Apr 18 16:35:02 2014 +0300 drm/i915: vlv: factor out vlv_force_gfx_clock and check for pending force-of but I'm not sure why. It has caused problems for us in the past (see 85250ddff7a603dfe0ec0503a9e6395f79424f61 and 8d4eee9cd7a170342dc6fbc2ee19ae77031a8cd5) and doesn't seem to be required, so let's just drop it. References: https://bugs.freedesktop.org/show_bug.cgi?id=89611 Signed-off-by: Jesse Barnes jbarnes at virtuousgeek.org Thanks Jesse, With this and 1/2 applied I was able to suspend/resume twice in a row successfully on a MinnowBoard MAX dual-core (E3825) with the 0.78 firmware. Tested-by: Darren Hart dvh...@linux.intel.com Both patches pushed to drm-intel-fixes, along with a cherry-pick of 85250ddff7a6 (drm/i915/chv: Remove Wait for a previous gfx force-off) from drm-next to avoid conflicts, all cc: stable. Thanks for the patches, review, and testing. BR, Jani. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx -- Jani Nikula, Intel Open Source Technology Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: use kref_put_mutex in i915_gem_request_unreference__unlocked
On Tue, Apr 07, 2015 at 11:32:02AM +0200, Maarten Lankhorst wrote:
Signed-off-by: Maarten Lankhorst maarten.lankho...@linux.intel.com
---
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index b13c5526a73b..7aaf8eddf19c 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2146,14 +2146,14 @@ i915_gem_request_unreference(struct
drm_i915_gem_request *req)
static inline void
i915_gem_request_unreference__unlocked(struct drm_i915_gem_request *req)
{
- if (req !atomic_add_unless(req-ref.refcount, -1, 1)) {
- struct drm_device *dev = req-ring-dev;
+ struct drm_device *dev;
+
+ if (!req)
+ return;
- mutex_lock(dev-struct_mutex);
- if (likely(atomic_dec_and_test(req-ref.refcount)))
- i915_gem_request_free(req-ref);
+ dev = req-ring-dev;
+ if (kref_put_mutex(req-ref, i915_gem_request_free,
dev-struct_mutex))
mutex_unlock(dev-struct_mutex);
We don't need this conditional unlock here since that's only possible if
you have a weak reference somewhere (i.e. using kref_get_unless_zero). If
the object only has strong references and you're dropping the last one it
can't magically get resurrected somehow.
And drm_gem_object_unreference_unlocked wants the same patch I think.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: use kref_put_mutex in i915_gem_request_unreference__unlocked
On Tue, Apr 07, 2015 at 03:51:44PM +0200, Maarten Lankhorst wrote:
Op 07-04-15 om 15:37 schreef Daniel Vetter:
On Tue, Apr 07, 2015 at 11:32:02AM +0200, Maarten Lankhorst wrote:
Signed-off-by: Maarten Lankhorst maarten.lankho...@linux.intel.com
---
diff --git a/drivers/gpu/drm/i915/i915_drv.h
b/drivers/gpu/drm/i915/i915_drv.h
index b13c5526a73b..7aaf8eddf19c 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2146,14 +2146,14 @@ i915_gem_request_unreference(struct
drm_i915_gem_request *req)
static inline void
i915_gem_request_unreference__unlocked(struct drm_i915_gem_request *req)
{
- if (req !atomic_add_unless(req-ref.refcount, -1, 1)) {
- struct drm_device *dev = req-ring-dev;
+ struct drm_device *dev;
+
+ if (!req)
+ return;
- mutex_lock(dev-struct_mutex);
- if (likely(atomic_dec_and_test(req-ref.refcount)))
- i915_gem_request_free(req-ref);
+ dev = req-ring-dev;
+ if (kref_put_mutex(req-ref, i915_gem_request_free,
dev-struct_mutex))
mutex_unlock(dev-struct_mutex);
We don't need this conditional unlock here since that's only possible if
you have a weak reference somewhere (i.e. using kref_get_unless_zero). If
the object only has strong references and you're dropping the last one it
can't magically get resurrected somehow.
Because we use the same put call for kref_put and kref_put_mutex we do need
to unlock struct_mutex here,
kref_put_mutex doesn't release the mutex if true, so either the release call
needs to do it or the callee.
Indeed I didn't realize that all existing users of kref_put_mutex unlock
the mutex in the free callback. So looks all good, so applied it.
Thanks, Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 03/11] drm/i915: Add a delay in Displayport AUX transactions for compliance testing
2015-04-06 23:09 GMT-03:00 Todd Previte tprev...@gmail.com:
The Displayport Link Layer Compliance Testing Specification 1.2 rev 1.1
specifies that repeated AUX transactions after a failure (no response /
invalid response) must have a minimum delay of 400us before the resend can
occur. Tests 4.2.1.1 and 4.2.1.2 are two tests that require this specifically.
Also, the check for DP_AUX_CH_CTL_TIME_OUT_ERROR has been moved out into a
separate case. As of now, the only action taken is to log the error, since
the HW will have already waited the required amount of time for the
transaction to complete.
As of V6, this paragraph is no longer true. We could just remove it
while applying.
With that: Reviewed-by: Paulo Zanoni paulo.r.zan...@intel.com.
V2:
- Changed udelay() to usleep_range()
V3:
- Removed extraneous check for timeout
- Updated comment to reflect this change
V4:
- Reformatted a comment
V5:
- Added separate check for HW timeout on AUX transactions. A message
is logged upon detection of this case.
V6:
- Add continue statement to HW timeout detect case
- Remove the log message indicating a timeout has been
detected (review feedback)
Signed-off-by: Todd Previte tprev...@gmail.com
---
drivers/gpu/drm/i915/intel_dp.c | 13 +++--
1 file changed, 11 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index ed2f60c..8b59458 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -877,9 +877,18 @@ intel_dp_aux_ch(struct intel_dp *intel_dp,
DP_AUX_CH_CTL_TIME_OUT_ERROR |
DP_AUX_CH_CTL_RECEIVE_ERROR);
- if (status (DP_AUX_CH_CTL_TIME_OUT_ERROR |
- DP_AUX_CH_CTL_RECEIVE_ERROR))
+ if (status DP_AUX_CH_CTL_TIME_OUT_ERROR)
continue;
+
+ /* DP CTS 1.2 Core Rev 1.1, 4.2.1.1 4.2.1.2
+* 400us delay required for errors and timeouts
+* Timeout errors from the HW already meet this
+* requirement so skip to next iteration
+*/
+ if (status DP_AUX_CH_CTL_RECEIVE_ERROR) {
+ usleep_range(400, 500);
+ continue;
+ }
if (status DP_AUX_CH_CTL_DONE)
break;
}
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Paulo Zanoni
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Do not set L3-LLC Coherency bit in ctx descriptor
Arun Siluvery arun.siluv...@linux.intel.com writes: According to Spec this is a reserved bit for Gen9+ and should not be set. Change-Id: I0215fb7057b94139b7a2f90ecc7a0201c0c93ad4 Signed-off-by: Arun Siluvery arun.siluv...@linux.intel.com --- Reviewed-by: Mika Kuoppala mika.kuopp...@intel.com drivers/gpu/drm/i915/intel_lrc.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c index 1c3834fc..cfc73ea 100644 --- a/drivers/gpu/drm/i915/intel_lrc.c +++ b/drivers/gpu/drm/i915/intel_lrc.c @@ -265,7 +265,8 @@ static uint64_t execlists_ctx_descriptor(struct intel_engine_cs *ring, desc = GEN8_CTX_VALID; desc |= LEGACY_CONTEXT GEN8_CTX_MODE_SHIFT; - desc |= GEN8_CTX_L3LLC_COHERENT; + if (IS_GEN8(ctx_obj-base.dev)) + desc |= GEN8_CTX_L3LLC_COHERENT; desc |= GEN8_CTX_PRIVILEGE; desc |= lrca; desc |= (u64)intel_execlists_ctx_id(ctx_obj) GEN8_CTX_ID_SHIFT; -- 2.3.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 15/19] drm/i915: HSW cdclk support
On Tue, Apr 07, 2015 at 12:29:25PM +0300, Mika Kahola wrote: Definitely a good idea to check the audio part as well if there is a doubt that by changing CD clock the audio would fail. I can check this and I'll get back once I have the results. We force a full modeset, which should result in an interrupt on the audio side, which should result in the audio driver re-reading the current cdclk. If that's no the case it's buggy already. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 7/7] lib: add igt_draw
On Tue, Apr 07, 2015 at 11:12:09AM +0100, Chris Wilson wrote:
On Tue, Apr 07, 2015 at 11:07:07AM +0200, Daniel Vetter wrote:
On Tue, Apr 07, 2015 at 09:36:37AM +0100, Chris Wilson wrote:
On Tue, Apr 07, 2015 at 10:10:25AM +0200, Daniel Vetter wrote:
On Thu, Apr 02, 2015 at 12:15:13AM +0100, Chris Wilson wrote:
On Wed, Apr 01, 2015 at 07:40:59PM -0300, Paulo Zanoni wrote:
+static void draw_rect_mmap_wc(int fd, struct buf_data *buf, struct
rect *rect,
+ uint32_t color)
+{
+ uint32_t *ptr;
+ uint32_t tiling, swizzle;
+
+ gem_get_tiling(fd, buf-handle, tiling, swizzle);
+
+ /* We didn't implement suport for the older tiling methods yet.
*/
+ if (tiling != I915_TILING_NONE)
+ igt_require(intel_gen(intel_get_drm_devid(fd)) = 5);
But you now do! You need something like:
The problem is that the kernel hides bit17 swizzling. I chatted with
Paulo
on irc about this and we decided just ignore them all is the simplest
approach.
Urm, that was the whole point of GET_TILING v2. That small function is
all you need to determine when bit17 is in effect and then you get to
reuse all the direct CPU methods (as they are also used by userspace)
for earlier gen.
Oh right completely forgot that we've added this. But imo can be added on
top once we need it (it's not just gen2 but also some gen3 which need
different tile dimensions).
Tile size is 2048 for gen2 only right. Tile width is the same for all
gen3 for tiling X (and gen2), but tiling Y width depends on subgen.
Right?
Just need to check because I have code that depends on this...
Oh right thought about Y tiling which changes on gen3. X tiling matches
your description afaik - I consider gem_tiled_pread the authoritative
source for this stuff.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: use kref_put_mutex in i915_gem_request_unreference__unlocked
Op 07-04-15 om 15:37 schreef Daniel Vetter:
On Tue, Apr 07, 2015 at 11:32:02AM +0200, Maarten Lankhorst wrote:
Signed-off-by: Maarten Lankhorst maarten.lankho...@linux.intel.com
---
diff --git a/drivers/gpu/drm/i915/i915_drv.h
b/drivers/gpu/drm/i915/i915_drv.h
index b13c5526a73b..7aaf8eddf19c 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2146,14 +2146,14 @@ i915_gem_request_unreference(struct
drm_i915_gem_request *req)
static inline void
i915_gem_request_unreference__unlocked(struct drm_i915_gem_request *req)
{
-if (req !atomic_add_unless(req-ref.refcount, -1, 1)) {
-struct drm_device *dev = req-ring-dev;
+struct drm_device *dev;
+
+if (!req)
+return;
-mutex_lock(dev-struct_mutex);
-if (likely(atomic_dec_and_test(req-ref.refcount)))
-i915_gem_request_free(req-ref);
+dev = req-ring-dev;
+if (kref_put_mutex(req-ref, i915_gem_request_free,
dev-struct_mutex))
mutex_unlock(dev-struct_mutex);
We don't need this conditional unlock here since that's only possible if
you have a weak reference somewhere (i.e. using kref_get_unless_zero). If
the object only has strong references and you're dropping the last one it
can't magically get resurrected somehow.
Because we use the same put call for kref_put and kref_put_mutex we do need to
unlock struct_mutex here,
kref_put_mutex doesn't release the mutex if true, so either the release call
needs to do it or the callee.
And drm_gem_object_unreference_unlocked wants the same patch I think.
Indeed it does, but with slightly more lockdep annotation!
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 30/49] drm/i915/bxt: add display initialize/uninitialize sequence
On to, 2015-04-02 at 19:32 +0300, Ville Syrjälä wrote:
On Tue, Mar 17, 2015 at 11:39:56AM +0200, Imre Deak wrote:
From: Vandana Kannan vandana.kan...@intel.com
Add display clock/PHY initialization sequence as per BSpec.
Until GOP/VBIOS provides an upper limit value for CDCLK, comparing clock
value with 624 MHz and returning 0 in case it exceeds.
Note that the CD clock and PHY initialization/uninitialization are done
at their current place only for simplicity, in a future patch - when more
of the runtime PM features will be enabled - these will be moved to
power well#1 and modeset encoder enabling/disabling hooks respectively.
This also means that atm dynamic power gating power well #2 is
effectively disabled.
OK, I've gone through the PHY stuff a bit now, and skipped the cdclk
stuff this time.
v1: Added function definitions in header files
v2: Imre's review comments addressed
- Moved CDCLK related definitions to i915_reg.h
- Removed defintions for CDCLK frequency
- Split uninit_cdclk() by adding a phy_uninit function
- Calculate freq and decimal based on input frequency
- Program SSA precharge based on input frequency
- Use wait_for 1ms instead 200us udelay for DE PLL locking
- Removed initial value for divider, freq, decimal, ratio.
- Replaced polling loops with wait_for
- Parameterized latency optim setting
- Fix the parts where DE PLL has to be disabled.
- Call CDCLK selection from mode set
v3: (imre)
- add note about the plan to move the cdclk/phy init to a better place
- take rps.hw_lock around pcode access
- fix DDI PHY timeout value
- squash in Vandana's PORT_CL2CM_DW6_A BUN fix,
DDI PHY programming register defn, Do ddi_phy_init always,
Check CDCLK upper limit patches
- move PHY register macros next to the corresponding CHV/VLV macros
- move DE PLL register macros here from another patch since they are
used here first
- add BXT_ prefix to CDCLK flags
- s/COMMON_RESET/COMMON_RESET_DIS/ and clarify related code comments
- fix incorrect read value for the RMW of BXT_PHY_CTL_FAMILY_DDI
- fix using GT_DISPLAY_EDP_POWER_ON vs. GT_DISPLAY_DDI_POWER_ON
when powering on DDI ports
- fix incorrect port when setting BXT_PORT_TX_DW14_LN for DDI ports
- add missing masking when programming CDCLK_FREQ_DECIMAL
- add missing powering on for DDI-C port, rename OCL2_LDOFUSE_PWR_EN
to OCL2_LDOFUSE_PWR_DIS to reduce confusion
- add note about mismatch with bspec in the PORT_REF_DW6 fields
- factor out PHY init code to a new function, so we can call it for
PHY_A and PHY_BC, instead of open-coding the same
Signed-off-by: Vandana Kannan vandana.kan...@intel.com (v2)
Signed-off-by: Imre Deak imre.d...@intel.com
---
drivers/gpu/drm/i915/i915_reg.h | 126 +++
drivers/gpu/drm/i915/intel_ddi.c | 291
+++
drivers/gpu/drm/i915/intel_display.c | 75 +
drivers/gpu/drm/i915/intel_drv.h | 4 +
4 files changed, 496 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_reg.h
b/drivers/gpu/drm/i915/i915_reg.h
index b4474d3..a3579c0 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -1120,6 +1120,110 @@ enum skl_disp_power_wells {
#define DPIO_FRC_LATENCY_SHFIT 8
#define CHV_TX_DW14(ch, lane) _TXLANE(ch, lane, 0xb8)
#define DPIO_UPAR_SHIFT 30
+
+/* BXT PHY registers */
+enum bxt_phy {
+ BXT_PHY_A,
+ BXT_PHY_BC
+};
We have enum dpio_phy already. Although here we have defined 0 to be the
single channel PHY and 1 is the two channel PHY, whereas on CHV it's
the other way around. I'm going to suggest we flip BXT over to use the
CHV scheme to avoid any surpises later if we actualy try to unify the
code.
Yea, I haven't noticed it, will use that instead.
+
+#define BXT_PHY(phy, a, b) ((a) + (phy) * ((b) - (a)))
This seems to be just another _PIPE(), should at least have an
underscore so that people don't confuse it with something they are
supposed to use.
Ok, I can rewrite this to
#define _BXT_PHY(phy, a, b) _PIPE(phy, a, b)
+
+#define BXT_P_CR_GT_DISP_PWRON_0_2_0_GTTMMADR 0x138090
We can drop the _0_2_0_GTTMMADR suffix, we've never included it for any
other platforms either.
Ok.
+#define _EDP_POWER_ON(1 1)
+#define _DDI_POWER_ON(1 0)
+#define GT_DISPLAY_POWER_ON(phy) BXT_PHY(phy, _EDP_POWER_ON, \
+ _DDI_POWER_ON)
Using a _PIPE() type of macro for register bits seems a bit unusual.
I'd just open code it as (1 (phy)) or something. That also work
better if we the PHYs around so that PHY0 is the dual channel PHY.
Ok, will rewrite it.
+
+#define _PHY_CTL_FAMILY_EDP0x64C80
+#define _PHY_CTL_FAMILY_DDI0x64C90
+#define
Re: [Intel-gfx] [PATCH i-g-t] tests/gem_mmap_gtt: add huge BO test
On Tue, Apr 07, 2015 at 03:23:08PM +0300, Joonas Lahtinen wrote:
static void
+test_huge_bo(int fd)
+{
+ uint32_t bo;
+ char *ptr_cpu;
+ char *ptr_gtt;
+ char *cpu_pattern;
+ uint64_t mappable_aperture_pages = gem_mappable_aperture_size() /
+PAGE_SIZE;
+ uint64_t huge_object_size = (mappable_aperture_pages + 1) * PAGE_SIZE;
+ uint64_t last_offset = huge_object_size - PAGE_SIZE;
+
+ cpu_pattern = malloc(PAGE_SIZE);
+ igt_assert(cpu_pattern);
+ memset(cpu_pattern, 0xaa, PAGE_SIZE);
+
+ bo = gem_create(fd, huge_object_size);
+
+ ptr_cpu = gem_mmap__cpu(fd, bo, 0, huge_object_size,
+ PROT_READ | PROT_WRITE);
+ if (!ptr_cpu) {
+ igt_warn(Not enough free memory for huge BO test!\n);
+ goto out;
+ }
Should be a set-domain(CPU, CPU) here.
+ /* Test read/write to first/last page with CPU. */
+ memcpy(ptr_cpu, cpu_pattern, PAGE_SIZE);
+ igt_assert(memcmp(ptr_cpu, cpu_pattern, PAGE_SIZE) == 0);
+
+ memcpy(ptr_cpu + last_offset, cpu_pattern, PAGE_SIZE);
+ igt_assert(memcmp(ptr_cpu + last_offset, cpu_pattern, PAGE_SIZE) == 0);
+
+ igt_assert(memcmp(ptr_cpu, ptr_cpu + last_offset, PAGE_SIZE) == 0);
+
+ munmap(ptr_cpu, huge_object_size);
+ ptr_cpu = NULL;
+
+ ptr_gtt = gem_mmap__gtt(fd, bo, huge_object_size,
+ PROT_READ | PROT_WRITE);
+ if (!ptr_gtt) {
+ igt_debug(Huge BO GTT mapping not supported!\n);
+ goto out;
+ }
+
+ /* Test read/write to first/last page through GTT. */
+ set_domain(fd, bo);
+
+ igt_assert(memcmp(ptr_gtt, cpu_pattern, PAGE_SIZE) == 0);
+ igt_assert(memcmp(ptr_gtt + last_offset, cpu_pattern, PAGE_SIZE) == 0);
+
+ memset(ptr_gtt, 0x55, PAGE_SIZE);
+ igt_assert(memcmp(ptr_gtt + last_offset, cpu_pattern, PAGE_SIZE) == 0);
+
+ memset(ptr_gtt + last_offset, 0x55, PAGE_SIZE);
+ igt_assert(memcmp(ptr_gtt, ptr_gtt + last_offset, PAGE_SIZE) == 0);
+
+ munmap(ptr_gtt, huge_object_size);
And repeat the CPU sanity check (for 0x55). Perhaps using pread this time.
And tiling checks.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 43/49] drm/i915: Do not zero initialise page tables
On Tue, Apr 07, 2015 at 05:46:19PM +0300, Mika Kuoppala wrote: Chris Wilson ch...@chris-wilson.co.uk writes: After we successfully allocate them, we will fill them with their initial contents (either the chain of page tables, or a pointer to the scratch page). Regression from commit 06fda602dbca9c59d87db7da71192e4b54c9f5ff Author: Ben Widawsky benjamin.widaw...@intel.com Date: Tue Feb 24 16:22:36 2015 + drm/i915: Create page table allocators Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk Cc: Michel Thierry michel.thie...@intel.com (v3+) Cc: Mika Kuoppala mika.kuopp...@intel.com Cc: Daniel Vetter daniel.vet...@ffwll.ch --- The gen8 parts of dynamic page table series, which Michel will resend in near future, address this by not zero filling but pointing unused page directory entries to scratch page table. However, it is currently a regression. -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] intel gm45 chipset problem
On Tue, 31 Mar 2015, jinwb ji...@sonoscape.net wrote: My machine is intel gm45 chipset,i found a problem in ubuntu 10.04. When i use xrandr to change output on VGA and TV, sometime is not successd.I update ubuntu 10.04 to ubuntu 13.04,founding the bug has solved, but my compony need the machine use ubuntu10.04. So i need someone help, how can i do to solve the problem in ubuntu 10.04, thanks. All those Ubuntu versions are practically at end of life (10.04 server version has support until end of this month). The kernel on 10.04 is ancient. If it works on a later kernel, I don't think anyone's interested in figuring this out. You should try to convince your company to upgrade no matter what. That said, maybe you can try installing a later kernel on your old Ubuntu. Maybe reverse bisect to figure out when the issue was fixed. But basically you're on your own with this. BR, Jani. -- Jani Nikula, Intel Open Source Technology Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 07/11] drm/i915: Fix for DP CTS test 4.2.2.5 - I2C DEFER handling
2015-04-06 23:11 GMT-03:00 Todd Previte tprev...@gmail.com: For test 4.2.2.5 to pass per the Link CTS Core 1.2 rev1.1 spec, the source device must attempt at least 7 times to read the EDID when it receives an I2C defer. The normal DRM code makes only 7 retries, regardless of whether or not the response is a native defer or an I2C defer. Test 4.2.2.5 fails since there are native defers interspersed with the I2C defers which results in less than 7 EDID read attempts. The solution is to decrement the retry counter when an I2C DEFER is returned such that another read attempt will be made. This situation should normally only occur in compliance testing, however, as a worse case real-world scenario, it would result in 13 attempts ( 6 native defers, 7 I2C defers) for a single transaction to complete. The net result is a slightly slower response to an EDID read that shouldn't significantly impact overall performance. V2: - Added a check on the number of I2C Defers to limit the number of times that the retries variable will be decremented. This is to address review feedback regarding possible infinite loops from misbehaving sink devices. Signed-off-by: Todd Previte tprev...@gmail.com Cc: dri-de...@lists.freedesktop.org --- drivers/gpu/drm/drm_dp_helper.c | 6 ++ 1 file changed, 6 insertions(+) diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c index 79968e3..23025cf 100644 --- a/drivers/gpu/drm/drm_dp_helper.c +++ b/drivers/gpu/drm/drm_dp_helper.c @@ -469,6 +469,12 @@ static int drm_dp_i2c_do_msg(struct drm_dp_aux *aux, struct drm_dp_aux_msg *msg) case DP_AUX_I2C_REPLY_DEFER: DRM_DEBUG_KMS(I2C defer\n); aux-i2c_defer_count++; + /* DP Compliance Test 4.2.2.5 Requirement: +* Must have at least 7 retries for I2C defers on the +* transaction to pass this test +*/ + if (aux-i2c_defer_count 8) I don't think this is the way to go. During normal (non-compliance-testing) operation we never zero i2c_defer_count, so we can't expect this to work, since we may start drm_dp_i2c_do_msg with a i2c_defer_count value different than zero. Also, during i915.ko DP compliance we only zero i2c_defer_count at the very beginning of each test, not at every aux transaction, and I really think we need a solution that is not specific to compliance testing. + retry--; usleep_range(400, 500); continue; -- 1.9.1 ___ dri-devel mailing list dri-de...@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel -- Paulo Zanoni ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 07/11] drm/i915: Fix for DP CTS test 4.2.2.5 - I2C DEFER handling
On Tue, Apr 07, 2015 at 11:29:43AM -0300, Paulo Zanoni wrote:
2015-04-06 23:11 GMT-03:00 Todd Previte tprev...@gmail.com:
For test 4.2.2.5 to pass per the Link CTS Core 1.2 rev1.1 spec, the source
device must attempt at least 7 times to read the EDID when it receives an
I2C defer. The normal DRM code makes only 7 retries, regardless of whether
or not the response is a native defer or an I2C defer. Test 4.2.2.5 fails
since there are native defers interspersed with the I2C defers which
results in less than 7 EDID read attempts.
The solution is to decrement the retry counter when an I2C DEFER is returned
such that another read attempt will be made. This situation should normally
only occur in compliance testing, however, as a worse case real-world
scenario, it would result in 13 attempts ( 6 native defers, 7 I2C defers)
for a single transaction to complete. The net result is a slightly slower
response to an EDID read that shouldn't significantly impact overall
performance.
V2:
- Added a check on the number of I2C Defers to limit the number
of times that the retries variable will be decremented. This
is to address review feedback regarding possible infinite loops
from misbehaving sink devices.
Signed-off-by: Todd Previte tprev...@gmail.com
Cc: dri-de...@lists.freedesktop.org
---
drivers/gpu/drm/drm_dp_helper.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/gpu/drm/drm_dp_helper.c
b/drivers/gpu/drm/drm_dp_helper.c
index 79968e3..23025cf 100644
--- a/drivers/gpu/drm/drm_dp_helper.c
+++ b/drivers/gpu/drm/drm_dp_helper.c
@@ -469,6 +469,12 @@ static int drm_dp_i2c_do_msg(struct drm_dp_aux *aux,
struct drm_dp_aux_msg *msg)
case DP_AUX_I2C_REPLY_DEFER:
DRM_DEBUG_KMS(I2C defer\n);
aux-i2c_defer_count++;
+ /* DP Compliance Test 4.2.2.5 Requirement:
+* Must have at least 7 retries for I2C defers on
the
+* transaction to pass this test
+*/
+ if (aux-i2c_defer_count 8)
I don't think this is the way to go. During normal
(non-compliance-testing) operation we never zero i2c_defer_count, so
we can't expect this to work, since we may start drm_dp_i2c_do_msg
with a i2c_defer_count value different than zero. Also, during i915.ko
DP compliance we only zero i2c_defer_count at the very beginning of
each test, not at every aux transaction, and I really think we need a
solution that is not specific to compliance testing.
What I was suggesting earlier (or trying to at least) would be
simply something like this:
int defer_native = 0, defer_i2c = 0;
while (defer_native 7 defer_i2c 7) {
...
case DP_AUX_NATIVE_REPLY_NACK:
...
defer_native++;
continue;
}
...
case DP_AUX_I2C_REPLY_DEFER:
...
defer_i2c++;
continue;
}
...
}
+ retry--;
usleep_range(400, 500);
continue;
--
1.9.1
___
dri-devel mailing list
dri-de...@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Paulo Zanoni
___
dri-devel mailing list
dri-de...@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Ville Syrjälä
Intel OTC
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 43/49] drm/i915: Do not zero initialise page tables
Chris Wilson ch...@chris-wilson.co.uk writes:
After we successfully allocate them, we will fill them with their
initial contents (either the chain of page tables, or a pointer to the
scratch page).
Regression from
commit 06fda602dbca9c59d87db7da71192e4b54c9f5ff
Author: Ben Widawsky benjamin.widaw...@intel.com
Date: Tue Feb 24 16:22:36 2015 +
drm/i915: Create page table allocators
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
Cc: Michel Thierry michel.thie...@intel.com (v3+)
Cc: Mika Kuoppala mika.kuopp...@intel.com
Cc: Daniel Vetter daniel.vet...@ffwll.ch
---
The gen8 parts of dynamic page table series, which Michel will resend
in near future, address this by not zero filling but pointing
unused page directory entries to scratch page table.
-Mika
drivers/gpu/drm/i915/i915_gem_gtt.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index 543fff104401..4a50e1db63dc 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -426,7 +426,7 @@ static struct i915_page_directory_entry
*alloc_pd_single(void)
if (!pd)
return ERR_PTR(-ENOMEM);
- pd-page = alloc_page(GFP_KERNEL | __GFP_ZERO);
+ pd-page = alloc_page(GFP_KERNEL);
if (!pd-page) {
kfree(pd);
return ERR_PTR(-ENOMEM);
--
2.1.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 49/70] drm/i915: Do not zero initialise page tables
After we successfully allocate them, we will fill them with their
initial contents (either the chain of page tables, or a pointer to the
scratch page).
Regression from
commit 06fda602dbca9c59d87db7da71192e4b54c9f5ff
Author: Ben Widawsky benjamin.widaw...@intel.com
Date: Tue Feb 24 16:22:36 2015 +
drm/i915: Create page table allocators
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
Cc: Michel Thierry michel.thie...@intel.com (v3+)
Cc: Mika Kuoppala mika.kuopp...@intel.com
Cc: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/i915/i915_gem_gtt.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index 85077beb9338..a80573105a61 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -429,7 +429,7 @@ static struct i915_page_directory_entry
*alloc_pd_single(void)
if (!pd)
return ERR_PTR(-ENOMEM);
- pd-page = alloc_page(GFP_KERNEL | __GFP_ZERO);
+ pd-page = alloc_page(GFP_KERNEL);
if (!pd-page) {
kfree(pd);
return ERR_PTR(-ENOMEM);
--
2.1.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 31/70] drm/i915: Refactor duplicate object vmap functions
We now have two implementations for vmapping a whole object, one for
dma-buf and one for the ringbuffer. If we couple the vmapping into the
obj-pages lifetime, then we can reuse an obj-vmapping for both and at
the same time couple it into the shrinker.
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
---
drivers/gpu/drm/i915/i915_drv.h | 12 ---
drivers/gpu/drm/i915/i915_gem.c | 41
drivers/gpu/drm/i915/i915_gem_dmabuf.c | 55 +
drivers/gpu/drm/i915/intel_ringbuffer.c | 53 ++-
4 files changed, 72 insertions(+), 89 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index b36c97c8c486..600b6d4a0139 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2004,10 +2004,7 @@ struct drm_i915_gem_object {
struct scatterlist *sg;
int last;
} get_page;
-
- /* prime dma-buf support */
- void *dma_buf_vmapping;
- int vmapping_count;
+ void *vmapping;
/** Breadcrumb of last rendering to the buffer.
* There can only be one writer, but we allow for multiple readers.
@@ -2706,12 +2703,19 @@ static inline void i915_gem_object_pin_pages(struct
drm_i915_gem_object *obj)
BUG_ON(obj-pages == NULL);
obj-pages_pin_count++;
}
+
static inline void i915_gem_object_unpin_pages(struct drm_i915_gem_object *obj)
{
BUG_ON(obj-pages_pin_count == 0);
obj-pages_pin_count--;
}
+void *__must_check i915_gem_object_pin_vmap(struct drm_i915_gem_object *obj);
+static inline void i915_gem_object_unpin_vmap(struct drm_i915_gem_object *obj)
+{
+ i915_gem_object_unpin_pages(obj);
+}
+
int __must_check i915_mutex_lock_interruptible(struct drm_device *dev);
int i915_gem_object_sync(struct drm_i915_gem_object *obj,
struct intel_engine_cs *to);
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 5ab974a19779..1f07cd17be04 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -2150,6 +2150,11 @@ i915_gem_object_put_pages(struct drm_i915_gem_object
*obj)
ops-put_pages(obj);
obj-pages = NULL;
+ if (obj-vmapping) {
+ vunmap(obj-vmapping);
+ obj-vmapping = NULL;
+ }
+
i915_gem_object_invalidate(obj);
return 0;
@@ -2309,6 +2314,42 @@ i915_gem_object_get_pages(struct drm_i915_gem_object
*obj)
return 0;
}
+void *i915_gem_object_pin_vmap(struct drm_i915_gem_object *obj)
+{
+ int ret;
+
+ ret = i915_gem_object_get_pages(obj);
+ if (ret)
+ return ERR_PTR(ret);
+
+ i915_gem_object_pin_pages(obj);
+
+ if (obj-vmapping == NULL) {
+ struct sg_page_iter sg_iter;
+ struct page **pages;
+ int n;
+
+ n = obj-base.size PAGE_SHIFT;
+ pages = kmalloc(n*sizeof(*pages), GFP_TEMPORARY);
+ if (pages == NULL)
+ pages = drm_malloc_ab(n, sizeof(*pages));
+ if (pages != NULL) {
+ n = 0;
+ for_each_sg_page(obj-pages-sgl, sg_iter,
obj-pages-nents, 0)
+ pages[n++] = sg_page_iter_page(sg_iter);
+
+ obj-vmapping = vmap(pages, n, 0, PAGE_KERNEL);
+ drm_free_large(pages);
+ }
+ if (obj-vmapping == NULL) {
+ i915_gem_object_unpin_pages(obj);
+ return ERR_PTR(-ENOMEM);
+ }
+ }
+
+ return obj-vmapping;
+}
+
void i915_vma_move_to_active(struct i915_vma *vma,
struct intel_engine_cs *ring)
{
diff --git a/drivers/gpu/drm/i915/i915_gem_dmabuf.c
b/drivers/gpu/drm/i915/i915_gem_dmabuf.c
index 82a1f4b57778..18bdad6a54d2 100644
--- a/drivers/gpu/drm/i915/i915_gem_dmabuf.c
+++ b/drivers/gpu/drm/i915/i915_gem_dmabuf.c
@@ -95,14 +95,12 @@ static void i915_gem_unmap_dma_buf(struct
dma_buf_attachment *attachment,
{
struct drm_i915_gem_object *obj = dma_buf_to_obj(attachment-dmabuf);
- mutex_lock(obj-base.dev-struct_mutex);
-
dma_unmap_sg(attachment-dev, sg-sgl, sg-nents, dir);
sg_free_table(sg);
kfree(sg);
- i915_gem_object_unpin_pages(obj);
-
+ mutex_lock(obj-base.dev-struct_mutex);
+ i915_gem_object_unpin_vmap(obj);
mutex_unlock(obj-base.dev-struct_mutex);
}
@@ -110,51 +108,17 @@ static void *i915_gem_dmabuf_vmap(struct dma_buf *dma_buf)
{
struct drm_i915_gem_object *obj = dma_buf_to_obj(dma_buf);
struct drm_device *dev = obj-base.dev;
- struct sg_page_iter sg_iter;
- struct page **pages;
- int ret, i;
+ void *addr;
+ int ret;
ret = i915_mutex_lock_interruptible(dev);
if
[Intel-gfx] [PATCH 15/70] drm/i915: Include active flag when describing objects in debugfs
Since we use obj-active as a hint in many places throughout the code, knowing its state in debugfs is extremely useful. Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk Reviewed-by: Tvrtko Ursulin tvrtko.ursu...@intel.com --- drivers/gpu/drm/i915/i915_debugfs.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/i915_debugfs.c b/drivers/gpu/drm/i915/i915_debugfs.c index 11eebc28775a..e87f031abc99 100644 --- a/drivers/gpu/drm/i915/i915_debugfs.c +++ b/drivers/gpu/drm/i915/i915_debugfs.c @@ -123,8 +123,9 @@ describe_obj(struct seq_file *m, struct drm_i915_gem_object *obj) struct i915_vma *vma; int pin_count = 0; - seq_printf(m, %pK: %s%s%s %8zdKiB %02x %02x %x %x %x%s%s%s, + seq_printf(m, %pK: %s%s%s%s %8zdKiB %02x %02x %x %x %x%s%s%s, obj-base, + obj-active ? * : , get_pin_flag(obj), get_tiling_flag(obj), get_global_flag(obj), -- 2.1.4 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 52/70] drm/i915: Cache the execlist ctx descriptor
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
---
drivers/gpu/drm/i915/intel_lrc.c| 56 +
drivers/gpu/drm/i915/intel_ringbuffer.h | 3 +-
2 files changed, 31 insertions(+), 28 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 459a27a2b486..3fe63bf604b4 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -230,37 +230,13 @@ int intel_sanitize_enable_execlists(struct drm_device
*dev, int enable_execlists
return 0;
}
-static uint32_t execlists_ctx_descriptor(struct intel_engine_cs *engine,
-uint32_t ggtt_offset)
-{
- uint32_t desc;
-
- desc = GEN8_CTX_VALID;
- desc |= LEGACY_CONTEXT GEN8_CTX_MODE_SHIFT;
- desc |= GEN8_CTX_L3LLC_COHERENT;
- desc |= GEN8_CTX_PRIVILEGE;
- desc |= ggtt_offset;
-
- /* TODO: WaDisableLiteRestore when we start using semaphore
-* signalling between Command Streamers */
- /* desc |= GEN8_CTX_FORCE_RESTORE; */
-
- /* WaEnableForceRestoreInCtxtDescForVCS:skl */
- if (IS_GEN9(engine-dev) INTEL_REVID(engine-dev) = SKL_REVID_B0
- (engine-id == BCS || engine-id == VCS ||
-engine-id == VECS || engine-id == VCS2))
- desc |= GEN8_CTX_FORCE_RESTORE;
-
- return desc;
-}
-
static uint32_t execlists_request_write_tail(struct intel_engine_cs *engine,
struct drm_i915_gem_request *rq)
{
struct intel_ringbuffer *ring = rq-ctx-engine[engine-id].ringbuf;
ring-regs[CTX_RING_TAIL+1] = rq-tail;
- return execlists_ctx_descriptor(engine, ring-ggtt_offset);
+ return ring-descriptor;
}
static void execlists_submit_pair(struct intel_engine_cs *ring)
@@ -498,6 +474,7 @@ static int intel_lr_context_pin(struct intel_engine_cs
*ring,
{
struct drm_i915_gem_object *ctx_obj = ctx-engine[ring-id].state;
struct intel_ringbuffer *ringbuf = ctx-engine[ring-id].ringbuf;
+ u32 ggtt_offset;
int ret;
WARN_ON(!mutex_is_locked(ring-dev-struct_mutex));
@@ -508,11 +485,12 @@ static int intel_lr_context_pin(struct intel_engine_cs
*ring,
if (ret)
goto reset_pin_count;
- ringbuf-ggtt_offset = i915_gem_obj_ggtt_offset(ctx_obj);
- if (WARN_ON(ringbuf-ggtt_offset 0x0FFFULL)) {
+ ggtt_offset = i915_gem_obj_ggtt_offset(ctx_obj);
+ if (WARN_ON(ggtt_offset 0x0FFFULL)) {
ret = -ENODEV;
goto unpin_ctx_obj;
}
+ ringbuf-descriptor = ggtt_offset | ring-execlist_ctx_descriptor;
ret = intel_pin_and_map_ringbuffer_obj(ring-dev, ringbuf);
if (ret)
@@ -1222,6 +1200,28 @@ void intel_logical_ring_cleanup(struct intel_engine_cs
*ring)
}
}
+static uint32_t base_ctx_descriptor(struct intel_engine_cs *engine)
+{
+ uint32_t desc;
+
+ desc = GEN8_CTX_VALID;
+ desc |= LEGACY_CONTEXT GEN8_CTX_MODE_SHIFT;
+ desc |= GEN8_CTX_L3LLC_COHERENT;
+ desc |= GEN8_CTX_PRIVILEGE;
+
+ /* TODO: WaDisableLiteRestore when we start using semaphore
+* signalling between Command Streamers */
+ /* desc |= GEN8_CTX_FORCE_RESTORE; */
+
+ /* WaEnableForceRestoreInCtxtDescForVCS:skl */
+ if (IS_GEN9(engine-dev) INTEL_REVID(engine-dev) = SKL_REVID_B0
+ (engine-id == BCS || engine-id == VCS ||
+engine-id == VECS || engine-id == VCS2))
+ desc |= GEN8_CTX_FORCE_RESTORE;
+
+ return desc;
+}
+
static int logical_ring_init(struct drm_device *dev, struct intel_engine_cs
*ring)
{
int ret;
@@ -1243,6 +1243,8 @@ static int logical_ring_init(struct drm_device *dev,
struct intel_engine_cs *rin
if (ret)
return ret;
+ ring-execlist_ctx_descriptor = base_ctx_descriptor(ring);
+
ret = intel_lr_context_deferred_create(ring-default_context, ring);
return ret;
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.h
b/drivers/gpu/drm/i915/intel_ringbuffer.h
index 55c91014bfdf..97832b6369a6 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.h
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.h
@@ -98,7 +98,7 @@ struct intel_ringbuffer {
struct drm_i915_gem_object *obj;
void __iomem *virtual_start;
uint32_t *regs;
- uint32_t ggtt_offset;
+ uint32_t descriptor;
struct intel_engine_cs *ring;
@@ -243,6 +243,7 @@ struct intel_engine_cs {
struct drm_i915_gem_request *execlist_port[2];
struct list_head execlist_queue;
struct list_head execlist_completed;
+ u32 execlist_ctx_descriptor;
u8 next_context_status_buffer;
u32 irq_keep_mask; /* bitmask for interrupts that should
not be masked */
int (*emit_request)(struct intel_ringbuffer *ringbuf,
--
2.1.4
[Intel-gfx] [PATCH 04/70] drm/i915: Agressive downclocking on Baytrail
Reuse the same reclocking strategy for Baytail as on its bigger brethren,
Sandybridge and Ivybridge. In particular, this makes the device quicker
to reclock (both up and down) though the tendency now is to downclock
more aggressively to compensate for the RPS boosts.
v2: Rebase
v3: Exclude Cherrytrail as Deepak was concerned that the increased
number of register writes would wake the common powerwell too often.
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
Cc: Deepak S deepa...@linux.intel.com
Cc: Ville Syrjälä ville.syrj...@linux.intel.com
Cc: Rodrigo Vivi rodrigo.v...@intel.com
Cc: Daniel Vetter daniel.vet...@ffwll.ch
Reviewed-by: Deepak S deepa...@linux.intel.com
---
drivers/gpu/drm/i915/i915_drv.h | 3 +++
drivers/gpu/drm/i915/i915_irq.c | 4 ++--
drivers/gpu/drm/i915/i915_reg.h | 2 --
drivers/gpu/drm/i915/intel_pm.c | 8 +++-
4 files changed, 12 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 51b21483b95f..31011988d153 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1036,6 +1036,9 @@ struct intel_gen6_power_mgmt {
u8 rp0_freq;/* Non-overclocked max frequency. */
u32 cz_freq;
+ u8 up_threshold; /* Current %busy required to uplock */
+ u8 down_threshold; /* Current %busy required to downclock */
+
int last_adj;
enum { LOW_POWER, BETWEEN, HIGH_POWER } power;
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 14ecb4d13a1a..128a6f40b450 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -1049,7 +1049,7 @@ static u32 vlv_wa_c0_ei(struct drm_i915_private
*dev_priv, u32 pm_iir)
if (pm_iir GEN6_PM_RP_DOWN_EI_EXPIRED) {
if (!vlv_c0_above(dev_priv,
dev_priv-rps.down_ei, now,
- VLV_RP_DOWN_EI_THRESHOLD))
+ dev_priv-rps.down_threshold))
events |= GEN6_PM_RP_DOWN_THRESHOLD;
dev_priv-rps.down_ei = now;
}
@@ -1057,7 +1057,7 @@ static u32 vlv_wa_c0_ei(struct drm_i915_private
*dev_priv, u32 pm_iir)
if (pm_iir GEN6_PM_RP_UP_EI_EXPIRED) {
if (vlv_c0_above(dev_priv,
dev_priv-rps.up_ei, now,
-VLV_RP_UP_EI_THRESHOLD))
+dev_priv-rps.up_threshold))
events |= GEN6_PM_RP_UP_THRESHOLD;
dev_priv-rps.up_ei = now;
}
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 12e6fd1bc1f0..626db2b134c7 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -671,8 +671,6 @@ enum skl_disp_power_wells {
#define FB_FMAX_VMIN_FREQ_LO_MASK0xf800
#define VLV_CZ_CLOCK_TO_MILLI_SEC 10
-#define VLV_RP_UP_EI_THRESHOLD 90
-#define VLV_RP_DOWN_EI_THRESHOLD 70
/* vlv2 north clock has */
#define CCK_FUSE_REG 0x8
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 63e642bc9713..50c03472ea41 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -3934,6 +3934,8 @@ static void gen6_set_rps_thresholds(struct
drm_i915_private *dev_priv, u8 val)
GEN6_RP_DOWN_IDLE_AVG);
dev_priv-rps.power = new_power;
+ dev_priv-rps.up_threshold = threshold_up;
+ dev_priv-rps.down_threshold = threshold_down;
dev_priv-rps.last_adj = 0;
}
@@ -4005,8 +4007,11 @@ static void valleyview_set_rps(struct drm_device *dev,
u8 val)
Odd GPU freq value\n))
val = ~1;
- if (val != dev_priv-rps.cur_freq)
+ if (val != dev_priv-rps.cur_freq) {
vlv_punit_write(dev_priv, PUNIT_REG_GPU_FREQ_REQ, val);
+ if (!IS_CHERRYVIEW(dev_priv))
+ gen6_set_rps_thresholds(dev_priv, val);
+ }
I915_WRITE(GEN6_PMINTRMSK, gen6_rps_pm_mask(dev_priv, val));
@@ -4055,6 +4060,7 @@ static void vlv_set_rps_idle(struct drm_i915_private
*dev_priv)
GENFREQSTATUS) == 0, 100))
DRM_ERROR(timed out waiting for Punit\n);
+ gen6_set_rps_thresholds(dev_priv, val);
vlv_force_gfx_clock(dev_priv, false);
I915_WRITE(GEN6_PMINTRMSK, gen6_rps_pm_mask(dev_priv, val));
--
2.1.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 21/70] drm/i915: Limit mmio flip RPS boosts
Since we will often pageflip to an active surface, we will often have to
wait for the surface to be written before issuing the flip. Also we are
likely to wait on that surface in plenty of time before the vblank.
Since we have a mechanism for boosting when a flip misses the expected
vblank, curtain the number of times we RPS boost when simply waiting for
mmioflip.
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
---
drivers/gpu/drm/i915/i915_debugfs.c | 1 +
drivers/gpu/drm/i915/i915_drv.h | 1 +
drivers/gpu/drm/i915/intel_display.c | 4 +++-
drivers/gpu/drm/i915/intel_drv.h | 1 +
drivers/gpu/drm/i915/intel_pm.c | 1 +
5 files changed, 7 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index c8fe548af41d..dc5394032077 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -2297,6 +2297,7 @@ static int i915_rps_boost_info(struct seq_file *m, void
*data)
rcu_read_unlock();
}
seq_printf(m, Semaphore boosts: %d\n,
dev_priv-rps.semaphores.rps_boosts);
+ seq_printf(m, MMIO flip boosts: %d\n,
dev_priv-rps.mmioflips.rps_boosts);
seq_printf(m, Kernel boosts: %d\n, dev_priv-rps.boosts);
mutex_unlock(dev_priv-rps.hw_lock);
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 057a1346e81f..8bb7e66dd4cd 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1064,6 +1064,7 @@ struct intel_gen6_power_mgmt {
unsigned boosts;
struct drm_i915_file_private semaphores;
+ struct drm_i915_file_private mmioflips;
/* manual wa residency calculations */
struct intel_rps_ei up_ei, down_ei;
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 83785976aa85..0c2bb2ce04fc 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -10111,7 +10111,8 @@ static void intel_mmio_flip_work_func(struct
work_struct *work)
if (mmio_flip-rq)
WARN_ON(__i915_wait_request(mmio_flip-rq,
mmio_flip-crtc-reset_counter,
- false, NULL, NULL));
+ false, NULL,
+ mmio_flip-i915-rps.mmioflips));
intel_do_mmio_flip(mmio_flip-crtc);
@@ -10132,6 +10133,7 @@ static int intel_queue_mmio_flip(struct drm_device *dev,
if (mmio_flip == NULL)
return -ENOMEM;
+ mmio_flip-i915 = to_i915(dev);
mmio_flip-rq = i915_gem_request_reference(obj-last_write_req);
mmio_flip-crtc = to_intel_crtc(crtc);
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 6163be8be812..160f6a28e9a1 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -404,6 +404,7 @@ struct intel_pipe_wm {
struct intel_mmio_flip {
struct work_struct work;
+ struct drm_i915_private *i915;
struct drm_i915_gem_request *rq;
struct intel_crtc *crtc;
};
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 3e274cf3adaa..17092897c728 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -6828,6 +6828,7 @@ void intel_pm_setup(struct drm_device *dev)
intel_gen6_powersave_work);
INIT_LIST_HEAD(dev_priv-rps.clients);
INIT_LIST_HEAD(dev_priv-rps.semaphores.rps_boost);
+ INIT_LIST_HEAD(dev_priv-rps.mmioflips.rps_boost);
dev_priv-pm.suspended = false;
}
--
2.1.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 34/70] drm/i915: Use a separate slab for vmas
vma are more frequently allocated than objects and so should equally
benefit from having a dedicated slab.
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
---
drivers/gpu/drm/i915/i915_dma.c | 4
drivers/gpu/drm/i915/i915_drv.h | 1 +
drivers/gpu/drm/i915/i915_gem.c | 7 ++-
drivers/gpu/drm/i915/i915_gem_gtt.c | 3 ++-
4 files changed, 13 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
index 135fbcad367f..9cbc04df94fb 100644
--- a/drivers/gpu/drm/i915/i915_dma.c
+++ b/drivers/gpu/drm/i915/i915_dma.c
@@ -1012,6 +1012,8 @@ put_bridge:
free_priv:
if (dev_priv-requests)
kmem_cache_destroy(dev_priv-requests);
+ if (dev_priv-vmas)
+ kmem_cache_destroy(dev_priv-vmas);
if (dev_priv-objects)
kmem_cache_destroy(dev_priv-objects);
kfree(dev_priv);
@@ -1098,6 +1100,8 @@ int i915_driver_unload(struct drm_device *dev)
if (dev_priv-requests)
kmem_cache_destroy(dev_priv-requests);
+ if (dev_priv-vmas)
+ kmem_cache_destroy(dev_priv-vmas);
if (dev_priv-objects)
kmem_cache_destroy(dev_priv-objects);
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index ad08aa532456..2ca11208983e 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1579,6 +1579,7 @@ struct i915_virtual_gpu {
struct drm_i915_private {
struct drm_device *dev;
struct kmem_cache *objects;
+ struct kmem_cache *vmas;
struct kmem_cache *requests;
const struct intel_device_info info;
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index a4a62592f0f8..05d7431db4ab 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -4832,7 +4832,7 @@ void i915_gem_vma_destroy(struct i915_vma *vma)
list_del(vma-vma_link);
- kfree(vma);
+ kmem_cache_free(to_i915(vma-obj-base.dev)-vmas, vma);
}
static void
@@ -5211,6 +5211,11 @@ i915_gem_load(struct drm_device *dev)
sizeof(struct drm_i915_gem_object), 0,
SLAB_HWCACHE_ALIGN,
NULL);
+ dev_priv-vmas =
+ kmem_cache_create(i915_gem_vma,
+ sizeof(struct i915_vma), 0,
+ SLAB_HWCACHE_ALIGN,
+ NULL);
dev_priv-requests =
kmem_cache_create(i915_gem_request,
sizeof(struct drm_i915_gem_request), 0,
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index f48d8454f0ef..a9f24236efd9 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -2542,7 +2542,8 @@ __i915_gem_vma_create(struct drm_i915_gem_object *obj,
if (WARN_ON(i915_is_ggtt(vm) != !!ggtt_view))
return ERR_PTR(-EINVAL);
- vma = kzalloc(sizeof(*vma), GFP_KERNEL);
+
+ vma = kmem_cache_zalloc(to_i915(obj-base.dev)-vmas, GFP_KERNEL);
if (vma == NULL)
return ERR_PTR(-ENOMEM);
--
2.1.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 23/70] drm/i915: Record ring-start address in error state
This is mostly useful for execlists where the rings switch between
contexts (and so checking that the ring's start register matches the
context is important).
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
---
drivers/gpu/drm/i915/i915_drv.h | 1 +
drivers/gpu/drm/i915/i915_gpu_error.c | 10 ++
2 files changed, 7 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 8bb7e66dd4cd..d69ccd16cd60 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -471,6 +471,7 @@ struct drm_i915_error_state {
u32 semaphore_seqno[I915_NUM_RINGS - 1];
/* Register state */
+ u32 start;
u32 tail;
u32 head;
u32 ctl;
diff --git a/drivers/gpu/drm/i915/i915_gpu_error.c
b/drivers/gpu/drm/i915/i915_gpu_error.c
index 5f798961266f..17dc2fcaba10 100644
--- a/drivers/gpu/drm/i915/i915_gpu_error.c
+++ b/drivers/gpu/drm/i915/i915_gpu_error.c
@@ -256,10 +256,11 @@ static void i915_ring_error_state(struct
drm_i915_error_state_buf *m,
return;
err_printf(m, %s command stream:\n, ring_str(ring_idx));
- err_printf(m, HEAD: 0x%08x\n, ring-head);
- err_printf(m, TAIL: 0x%08x\n, ring-tail);
- err_printf(m, CTL: 0x%08x\n, ring-ctl);
- err_printf(m, HWS: 0x%08x\n, ring-hws);
+ err_printf(m, START: 0x%08x\n, ring-start);
+ err_printf(m, HEAD: 0x%08x\n, ring-head);
+ err_printf(m, TAIL: 0x%08x\n, ring-tail);
+ err_printf(m, CTL: 0x%08x\n, ring-ctl);
+ err_printf(m, HWS: 0x%08x\n, ring-hws);
err_printf(m, ACTHD: 0x%08x %08x\n, (u32)(ring-acthd32),
(u32)ring-acthd);
err_printf(m, IPEIR: 0x%08x\n, ring-ipeir);
err_printf(m, IPEHR: 0x%08x\n, ring-ipehr);
@@ -890,6 +891,7 @@ static void i915_record_ring_state(struct drm_device *dev,
ering-instpm = I915_READ(RING_INSTPM(ring-mmio_base));
ering-seqno = ring-get_seqno(ring, false);
ering-acthd = intel_ring_get_active_head(ring);
+ ering-start = I915_READ_START(ring);
ering-head = I915_READ_HEAD(ring);
ering-tail = I915_READ_TAIL(ring);
ering-ctl = I915_READ_CTL(ring);
--
2.1.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 35/70] drm/i915: Use the new rq-i915 field where appropriate
In a few cases, having a direct pointer to the drm_i915_private from the
request is useful.
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
---
drivers/gpu/drm/i915/i915_gem.c | 11 ---
drivers/gpu/drm/i915/intel_pm.c | 2 +-
2 files changed, 5 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 05d7431db4ab..796dc69a6c47 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -1227,8 +1227,7 @@ int __i915_wait_request(struct drm_i915_gem_request *req,
struct drm_i915_file_private *file_priv)
{
struct intel_engine_cs *ring = i915_gem_request_get_ring(req);
- struct drm_device *dev = ring-dev;
- struct drm_i915_private *dev_priv = dev-dev_private;
+ struct drm_i915_private *dev_priv = req-i915;
const bool irq_test_in_progress =
ACCESS_ONCE(dev_priv-gpu_error.test_irq_rings)
intel_ring_flag(ring);
DEFINE_WAIT(wait);
@@ -1247,7 +1246,7 @@ int __i915_wait_request(struct drm_i915_gem_request *req,
timeout_expire = timeout ?
jiffies + nsecs_to_jiffies_timeout((u64)*timeout) : 0;
- if (INTEL_INFO(dev)-gen = 6)
+ if (INTEL_INFO(dev_priv)-gen = 6)
gen6_rps_boost(dev_priv, file_priv);
/* Record current time in case interrupted by signal, or wedged */
@@ -1404,18 +1403,16 @@ __i915_gem_request_retire__upto(struct
drm_i915_gem_request *rq)
int
i915_wait_request(struct drm_i915_gem_request *req)
{
- struct drm_device *dev;
struct drm_i915_private *dev_priv;
bool interruptible;
int ret;
BUG_ON(req == NULL);
- dev = req-ring-dev;
- dev_priv = dev-dev_private;
+ dev_priv = req-i915;
interruptible = dev_priv-mm.interruptible;
- BUG_ON(!mutex_is_locked(dev-struct_mutex));
+ BUG_ON(!mutex_is_locked(dev_priv-dev-struct_mutex));
ret = i915_gem_check_wedge(dev_priv-gpu_error, interruptible);
if (ret)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 17092897c728..a48c65cffb97 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -6793,7 +6793,7 @@ static void __intel_rps_boost_work(struct work_struct
*work)
struct request_boost *boost = container_of(work, struct request_boost,
work);
if (!i915_gem_request_completed(boost-rq, true))
- gen6_rps_boost(to_i915(boost-rq-ring-dev), NULL);
+ gen6_rps_boost(boost-rq-i915, NULL);
i915_gem_request_unreference__unlocked(boost-rq);
kfree(boost);
--
2.1.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 32/70] drm/i915: Treat ringbuffer writes as write to normal memory
The hardware is documentated as treating the TAIL register update as
serialising, so we can relax the barriers when filling the rings.
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
---
drivers/gpu/drm/i915/intel_lrc.h| 6 +++---
drivers/gpu/drm/i915/intel_ringbuffer.h | 17 -
2 files changed, 15 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_lrc.h b/drivers/gpu/drm/i915/intel_lrc.h
index 0790e4b26b13..16c717672020 100644
--- a/drivers/gpu/drm/i915/intel_lrc.h
+++ b/drivers/gpu/drm/i915/intel_lrc.h
@@ -52,8 +52,9 @@ int logical_ring_flush_all_caches(struct intel_ringbuffer
*ringbuf,
*/
static inline void intel_logical_ring_advance(struct intel_ringbuffer *ringbuf)
{
- ringbuf-tail = ringbuf-size - 1;
+ intel_ringbuffer_advance(ringbuf);
}
+
/**
* intel_logical_ring_emit() - write a DWORD to the ringbuffer.
* @ringbuf: Ringbuffer to write to.
@@ -62,8 +63,7 @@ static inline void intel_logical_ring_advance(struct
intel_ringbuffer *ringbuf)
static inline void intel_logical_ring_emit(struct intel_ringbuffer *ringbuf,
u32 data)
{
- iowrite32(data, ringbuf-virtual_start + ringbuf-tail);
- ringbuf-tail += 4;
+ intel_ringbuffer_emit(ringbuf, data);
}
/* Logical Ring Contexts */
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.h
b/drivers/gpu/drm/i915/intel_ringbuffer.h
index 298b0ff46ecb..0899123c6bcc 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.h
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.h
@@ -404,17 +404,24 @@ int intel_ring_alloc_request_extras(struct
drm_i915_gem_request *request);
int __must_check intel_ring_begin(struct intel_engine_cs *ring, int n);
int __must_check intel_ring_cacheline_align(struct intel_engine_cs *ring);
+static inline void intel_ringbuffer_emit(struct intel_ringbuffer *rb,
+u32 data)
+{
+ *(uint32_t __force *)(rb-virtual_start + rb-tail) = data;
+ rb-tail += 4;
+}
+static inline void intel_ringbuffer_advance(struct intel_ringbuffer *rb)
+{
+ rb-tail = rb-size - 1;
+}
static inline void intel_ring_emit(struct intel_engine_cs *ring,
u32 data)
{
- struct intel_ringbuffer *ringbuf = ring-buffer;
- iowrite32(data, ringbuf-virtual_start + ringbuf-tail);
- ringbuf-tail += 4;
+ intel_ringbuffer_emit(ring-buffer, data);
}
static inline void intel_ring_advance(struct intel_engine_cs *ring)
{
- struct intel_ringbuffer *ringbuf = ring-buffer;
- ringbuf-tail = ringbuf-size - 1;
+ intel_ringbuffer_advance(ring-buffer);
}
int __intel_ring_space(int head, int tail, int size);
void intel_ring_update_space(struct intel_ringbuffer *ringbuf);
--
2.1.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 03/70] drm/i915: Ensure cache flushes prior to doing CS flips
Synchronising to an object active on the same ring is a no-op, for the
benefit of execbuffer scheduler. However, for CS flips this means that
we can forgo checking whether the last write request of the object is
actually queued and more importantly whether the cache flush for the
write was emitted.
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
---
drivers/gpu/drm/i915/intel_display.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 4af89c27504e..0415e40cef6e 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -10347,6 +10347,12 @@ static int intel_crtc_page_flip(struct drm_crtc *crtc,
i915_gem_request_assign(work-flip_queued_req,
obj-last_write_req);
} else {
+ if (obj-last_write_req) {
+ ret = i915_gem_check_olr(obj-last_write_req);
+ if (ret)
+ goto cleanup_unpin;
+ }
+
ret = dev_priv-display.queue_flip(dev, crtc, fb, obj, ring,
page_flip_flags);
if (ret)
--
2.1.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 57/70] drm/i915: intel_ring_initialized() must be simple and inline
Fixes regression from
commit 48d823878d64f93163f5a949623346748bbce1b4
Author: Oscar Mateo oscar.ma...@intel.com
Date: Thu Jul 24 17:04:23 2014 +0100
drm/i915/bdw: Generic logical ring init and cleanup
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
---
drivers/gpu/drm/i915/intel_lrc.c| 18 -
drivers/gpu/drm/i915/intel_ringbuffer.c | 35 +++--
drivers/gpu/drm/i915/intel_ringbuffer.h | 6 +-
3 files changed, 38 insertions(+), 21 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 3fe63bf604b4..db93eed9eacd 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -1241,12 +1241,28 @@ static int logical_ring_init(struct drm_device *dev,
struct intel_engine_cs *rin
ret = i915_cmd_parser_init_ring(ring);
if (ret)
- return ret;
+ goto error;
ring-execlist_ctx_descriptor = base_ctx_descriptor(ring);
ret = intel_lr_context_deferred_create(ring-default_context, ring);
+ if (ret)
+ goto error;
+
+ return 0;
+error:
+ if (ring-cleanup)
+ ring-cleanup(ring);
+
+ i915_cmd_parser_fini_ring(ring);
+ i915_gem_batch_pool_fini(ring-batch_pool);
+
+ if (ring-status_page.obj) {
+ kunmap(sg_page(ring-status_page.obj-pages-sgl));
+ ring-status_page.obj = NULL;
+ }
+ ring-dev = NULL;
return ret;
}
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c
b/drivers/gpu/drm/i915/intel_ringbuffer.c
index 0b68ac5a7298..913efe47054d 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.c
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
@@ -33,23 +33,6 @@
#include i915_trace.h
#include intel_drv.h
-bool
-intel_ring_initialized(struct intel_engine_cs *ring)
-{
- struct drm_device *dev = ring-dev;
-
- if (!dev)
- return false;
-
- if (i915.enable_execlists) {
- struct intel_context *dctx = ring-default_context;
- struct intel_ringbuffer *ringbuf =
dctx-engine[ring-id].ringbuf;
-
- return ringbuf-obj;
- } else
- return ring-buffer ring-buffer-obj;
-}
-
int __intel_ring_space(int head, int tail, int size)
{
int space = head - tail;
@@ -1992,8 +1975,10 @@ static int intel_init_ring_buffer(struct drm_device *dev,
WARN_ON(ring-buffer);
ringbuf = kzalloc(sizeof(*ringbuf), GFP_KERNEL);
- if (!ringbuf)
- return -ENOMEM;
+ if (!ringbuf) {
+ ret = -ENOMEM;
+ goto error;
+ }
ring-buffer = ringbuf;
ring-dev = dev;
@@ -2050,8 +2035,18 @@ static int intel_init_ring_buffer(struct drm_device *dev,
return 0;
error:
+ if (ring-cleanup)
+ ring-cleanup(ring);
+
+ cleanup_status_page(ring);
+
+ i915_cmd_parser_fini_ring(ring);
+ i915_gem_batch_pool_fini(ring-batch_pool);
+
kfree(ringbuf);
ring-buffer = NULL;
+
+ ring-dev = NULL;
return ret;
}
@@ -2083,6 +2078,8 @@ void intel_cleanup_ring_buffer(struct intel_engine_cs
*ring)
kfree(ringbuf);
ring-buffer = NULL;
+
+ ring-dev = NULL;
}
static int ring_wait_for_space(struct intel_engine_cs *ring, int n)
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.h
b/drivers/gpu/drm/i915/intel_ringbuffer.h
index 97832b6369a6..75268b7d2d41 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.h
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.h
@@ -327,7 +327,11 @@ struct intel_engine_cs {
u32 (*get_cmd_length_mask)(u32 cmd_header);
};
-bool intel_ring_initialized(struct intel_engine_cs *ring);
+static inline bool
+intel_ring_initialized(struct intel_engine_cs *ring)
+{
+ return ring-dev != NULL;
+}
static inline unsigned
intel_ring_flag(struct intel_engine_cs *ring)
--
2.1.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 24/70] drm/i915: Use simpler form of spin_lock_irq(execlist_lock)
We can use the simpler spinlock form to disable interrupts as we are
always outside of an irq/softirq handler.
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
---
drivers/gpu/drm/i915/intel_lrc.c | 10 --
1 file changed, 4 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 8ff8c5326b23..ce84aa9811ba 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -501,7 +501,6 @@ static int execlists_context_queue(struct intel_engine_cs
*ring,
{
struct drm_i915_gem_request *cursor;
struct drm_i915_private *dev_priv = ring-dev-dev_private;
- unsigned long flags;
int num_elements = 0;
if (to != ring-default_context)
@@ -528,7 +527,7 @@ static int execlists_context_queue(struct intel_engine_cs
*ring,
intel_runtime_pm_get(dev_priv);
- spin_lock_irqsave(ring-execlist_lock, flags);
+ spin_lock_irq(ring-execlist_lock);
list_for_each_entry(cursor, ring-execlist_queue, execlist_link)
if (++num_elements 2)
@@ -554,7 +553,7 @@ static int execlists_context_queue(struct intel_engine_cs
*ring,
if (num_elements == 0)
execlists_context_unqueue(ring);
- spin_unlock_irqrestore(ring-execlist_lock, flags);
+ spin_unlock_irq(ring-execlist_lock);
return 0;
}
@@ -936,7 +935,6 @@ void intel_execlists_retire_requests(struct intel_engine_cs
*ring)
{
struct drm_i915_gem_request *req, *tmp;
struct drm_i915_private *dev_priv = ring-dev-dev_private;
- unsigned long flags;
struct list_head retired_list;
WARN_ON(!mutex_is_locked(ring-dev-struct_mutex));
@@ -944,9 +942,9 @@ void intel_execlists_retire_requests(struct intel_engine_cs
*ring)
return;
INIT_LIST_HEAD(retired_list);
- spin_lock_irqsave(ring-execlist_lock, flags);
+ spin_lock_irq(ring-execlist_lock);
list_replace_init(ring-execlist_retired_req_list, retired_list);
- spin_unlock_irqrestore(ring-execlist_lock, flags);
+ spin_unlock_irq(ring-execlist_lock);
list_for_each_entry_safe(req, tmp, retired_list, execlist_link) {
struct intel_context *ctx = req-ctx;
--
2.1.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 46/70] drm/i915: Cache the reset_counter for the request
Instead of querying the reset counter before every access to the ring,
query it the first time we touch the ring, and do a final compare when
submitting the request. For correctness, we need to then sanitize how
the reset_counter is incremented to prevent broken submission and
waiting across resets, in the process fixing the persistent -EIO we
still see today on failed waits.
v2: Rebase
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
---
drivers/gpu/drm/i915/i915_drv.c | 32 +++-
drivers/gpu/drm/i915/i915_drv.h | 29 +++
drivers/gpu/drm/i915/i915_gem.c | 87 ++---
drivers/gpu/drm/i915/i915_irq.c | 28 ---
drivers/gpu/drm/i915/intel_display.c| 10 ++--
drivers/gpu/drm/i915/intel_lrc.c| 7 ---
drivers/gpu/drm/i915/intel_ringbuffer.c | 6 ---
7 files changed, 87 insertions(+), 112 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 1366e0ec4933..72b01323c549 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -827,6 +827,8 @@ int i915_resume_legacy(struct drm_device *dev)
int i915_reset(struct drm_device *dev)
{
struct drm_i915_private *dev_priv = dev-dev_private;
+ struct i915_gpu_error *error = dev_priv-gpu_error;
+ unsigned reset_counter;
bool simulated;
int ret;
@@ -836,17 +838,23 @@ int i915_reset(struct drm_device *dev)
intel_reset_gt_powersave(dev);
mutex_lock(dev-struct_mutex);
+ reset_counter = atomic_inc_return(error-reset_counter);
+ if (WARN_ON(__i915_reset_in_progress(reset_counter))) {
+ atomic_set_mask(I915_WEDGED, error-reset_counter);
+ mutex_unlock(dev-struct_mutex);
+ return -EIO;
+ }
i915_gem_reset(dev);
- simulated = dev_priv-gpu_error.stop_rings != 0;
+ simulated = error-stop_rings != 0;
ret = intel_gpu_reset(dev);
/* Also reset the gpu hangman. */
if (simulated) {
DRM_INFO(Simulated gpu hang, resetting stop_rings\n);
- dev_priv-gpu_error.stop_rings = 0;
+ error-stop_rings = 0;
if (ret == -ENODEV) {
DRM_INFO(Reset not implemented, but ignoring
error for simulated gpu hangs\n);
@@ -859,8 +867,7 @@ int i915_reset(struct drm_device *dev)
if (ret) {
DRM_ERROR(Failed to reset chip: %i\n, ret);
- mutex_unlock(dev-struct_mutex);
- return ret;
+ goto error;
}
intel_overlay_reset(dev_priv);
@@ -879,20 +886,14 @@ int i915_reset(struct drm_device *dev)
* was running at the time of the reset (i.e. we weren't VT
* switched away).
*/
-
- /* Used to prevent gem_check_wedged returning -EAGAIN during gpu reset
*/
- dev_priv-gpu_error.reload_in_reset = true;
-
ret = i915_gem_init_hw(dev);
-
- dev_priv-gpu_error.reload_in_reset = false;
-
- mutex_unlock(dev-struct_mutex);
if (ret) {
DRM_ERROR(Failed hw init on reset %d\n, ret);
- return ret;
+ goto error;
}
+ mutex_unlock(dev-struct_mutex);
+
/*
* rps/rc6 re-init is necessary to restore state lost after the
* reset and the re-install of gt irqs. Skip for ironlake per
@@ -903,6 +904,11 @@ int i915_reset(struct drm_device *dev)
intel_enable_gt_powersave(dev);
return 0;
+
+error:
+ atomic_set_mask(I915_WEDGED, error-reset_counter);
+ mutex_unlock(dev-struct_mutex);
+ return ret;
}
static int i915_pci_probe(struct pci_dev *pdev, const struct pci_device_id
*ent)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 89839751237c..97f5d266b17c 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1308,9 +1308,6 @@ struct i915_gpu_error {
/* For missed irq/seqno simulation. */
unsigned int test_irq_rings;
-
- /* Used to prevent gem_check_wedged returning -EAGAIN during gpu reset
*/
- bool reload_in_reset;
};
enum modeset_restore {
@@ -2072,6 +2069,7 @@ struct drm_i915_gem_request {
/** On Which ring this request was generated */
struct drm_i915_private *i915;
struct intel_engine_cs *ring;
+ unsigned reset_counter;
/** GEM sequence number associated with this request. */
uint32_t seqno;
@@ -2767,24 +2765,38 @@ struct drm_i915_gem_request *
i915_gem_find_active_request(struct intel_engine_cs *ring);
bool i915_gem_retire_requests(struct drm_device *dev);
-int __must_check i915_gem_check_wedge(struct i915_gpu_error *error,
+int __must_check i915_gem_check_wedge(unsigned reset_counter,
bool interruptible);
int __must_check
[Intel-gfx] [PATCH 56/70] drm/i915: Cache kmap between relocations
When doing relocations, we have to obtain a mapping to the page
containing the target address. This is either a kmap or iomap depending
on GPU and its cache coherency. Neighbouring relocation entries are
typically within the same page and so we can cache our kmapping between
them and avoid those pesky TLB flushes.
Note that there is some sleight-of-hand in how the slow relocate works
as the reloc_entry_cache implies pagefaults disabled (as we are inside a
kmap_atomic section). However, the slow relocate code is meant to be the
fallback from the atomic fast path failing. Fortunately it works as we
already have performed the copy_from_user for the relocation array (no
more pagefaults there) and the kmap_atomic cache is enabled after we
have waited upon an active buffer (so no more sleeping in atomic).
Magic!
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
---
drivers/gpu/drm/i915/i915_gem_execbuffer.c | 145 +++--
1 file changed, 96 insertions(+), 49 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
index 16fd922afb72..9afd2dcba43b 100644
--- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
@@ -248,9 +248,48 @@ static inline int use_cpu_reloc(struct drm_i915_gem_object
*obj)
obj-cache_level != I915_CACHE_NONE);
}
+struct reloc_entry_cache {
+ void *vaddr;
+ unsigned page;
+ enum { KMAP, IOMAP } type;
+};
+
+static void reloc_entry_cache_init(struct reloc_entry_cache *cache)
+{
+ cache-page = -1;
+ cache-vaddr = NULL;
+}
+
+static void reloc_entry_cache_fini(struct reloc_entry_cache *cache)
+{
+ if (cache-vaddr == NULL)
+ return;
+
+ switch (cache-type) {
+ case KMAP: kunmap_atomic(cache-vaddr); break;
+ case IOMAP: io_mapping_unmap_atomic(cache-vaddr); break;
+ }
+}
+
+static void *reloc_kmap(struct drm_i915_gem_object *obj,
+ struct reloc_entry_cache *cache,
+ int page)
+{
+ if (cache-page != page) {
+ if (cache-vaddr)
+ kunmap_atomic(cache-vaddr);
+ cache-page = page;
+ cache-vaddr = kmap_atomic(i915_gem_object_get_page(obj, page));
+ cache-type = KMAP;
+ }
+
+ return cache-vaddr;
+}
+
static int
relocate_entry_cpu(struct drm_i915_gem_object *obj,
struct drm_i915_gem_relocation_entry *reloc,
+ struct reloc_entry_cache *cache,
uint64_t target_offset)
{
struct drm_device *dev = obj-base.dev;
@@ -263,30 +302,41 @@ relocate_entry_cpu(struct drm_i915_gem_object *obj,
if (ret)
return ret;
- vaddr = kmap_atomic(i915_gem_object_get_page(obj,
- reloc-offset PAGE_SHIFT));
+ vaddr = reloc_kmap(obj, cache, reloc-offset PAGE_SHIFT);
*(uint32_t *)(vaddr + page_offset) = lower_32_bits(delta);
if (INTEL_INFO(dev)-gen = 8) {
- page_offset = offset_in_page(page_offset + sizeof(uint32_t));
-
- if (page_offset == 0) {
- kunmap_atomic(vaddr);
- vaddr = kmap_atomic(i915_gem_object_get_page(obj,
- (reloc-offset + sizeof(uint32_t)) PAGE_SHIFT));
+ page_offset += sizeof(uint32_t);
+ if (page_offset == PAGE_SIZE) {
+ vaddr = reloc_kmap(obj, cache, cache-page + 1);
+ page_offset = 0;
}
-
*(uint32_t *)(vaddr + page_offset) = upper_32_bits(delta);
}
- kunmap_atomic(vaddr);
-
return 0;
}
+static void *reloc_iomap(struct drm_i915_private *i915,
+struct reloc_entry_cache *cache,
+uint64_t offset)
+{
+ if (cache-page != offset PAGE_SHIFT) {
+ if (cache-vaddr)
+ io_mapping_unmap_atomic(cache-vaddr);
+ cache-page = offset PAGE_SHIFT;
+ cache-vaddr =
+ io_mapping_map_atomic_wc(i915-gtt.mappable,
+offset PAGE_MASK);
+ cache-type = IOMAP;
+ }
+
+ return cache-vaddr;
+}
static int
relocate_entry_gtt(struct drm_i915_gem_object *obj,
struct drm_i915_gem_relocation_entry *reloc,
+ struct reloc_entry_cache *cache,
uint64_t target_offset)
{
struct drm_device *dev = obj-base.dev;
@@ -307,26 +357,17 @@ relocate_entry_gtt(struct drm_i915_gem_object *obj,
/* Map the page containing the relocation we're going to perform. */
offset = i915_gem_obj_ggtt_offset(obj);
offset += reloc-offset;
- reloc_page = io_mapping_map_atomic_wc(dev_priv-gtt.mappable,
-
[Intel-gfx] [PATCH 36/70] drm/i915: Reduce the pointer dance of i915_is_ggtt()
The multiple levels of indirect do nothing but hinder the compiler and
the pointer chasing turns to be quite painful but painless to fix.
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
---
drivers/gpu/drm/i915/i915_drv.h | 4 +---
drivers/gpu/drm/i915/i915_gem_gtt.c | 1 +
drivers/gpu/drm/i915/i915_gem_gtt.h | 2 ++
3 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 2ca11208983e..2a5343a9ed24 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2898,9 +2898,7 @@ bool i915_gem_obj_is_pinned(struct drm_i915_gem_object
*obj);
(((struct drm_i915_private *)(obj)-base.dev-dev_private)-gtt.base)
static inline bool i915_is_ggtt(struct i915_address_space *vm)
{
- struct i915_address_space *ggtt =
- ((struct drm_i915_private *)(vm)-dev-dev_private)-gtt.base;
- return vm == ggtt;
+ return vm-is_ggtt;
}
static inline struct i915_hw_ppgtt *
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index a9f24236efd9..df1ee971138e 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -2511,6 +2511,7 @@ int i915_gem_gtt_init(struct drm_device *dev)
return ret;
gtt-base.dev = dev;
+ gtt-base.is_ggtt = true;
/* GMADR is the PCI mmio aperture into the global GTT. */
DRM_INFO(Memory usable by graphics device = %zdM\n,
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.h
b/drivers/gpu/drm/i915/i915_gem_gtt.h
index fc03c99317c9..db9ec04d312c 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.h
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.h
@@ -235,6 +235,8 @@ struct i915_address_space {
unsigned long start;/* Start offset always 0 for dri2 */
size_t total; /* size addr space maps (ex. 2GB for ggtt) */
+ bool is_ggtt;
+
struct {
dma_addr_t addr;
struct page *page;
--
2.1.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 05/70] drm/i915: Fix computation of last_adjustment for RPS autotuning
The issue is that by computing the last_adj value after applying the
clamping, we can end up with a bogus value for feeding into the next RPS
autotuning step.
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
Cc: Daniel Vetter daniel.vet...@ffwll.ch
Cc: Deepak S deepa...@linux.intel.com
Reviewed-by: Deepak S deepa...@linux.intel.com
---
drivers/gpu/drm/i915/i915_irq.c | 27 ---
1 file changed, 12 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 128a6f40b450..8b5e0358c592 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -1095,21 +1095,20 @@ static void gen6_pm_rps_work(struct work_struct *work)
pm_iir |= vlv_wa_c0_ei(dev_priv, pm_iir);
adj = dev_priv-rps.last_adj;
+ new_delay = dev_priv-rps.cur_freq;
if (pm_iir GEN6_PM_RP_UP_THRESHOLD) {
if (adj 0)
adj *= 2;
- else {
- /* CHV needs even encode values */
- adj = IS_CHERRYVIEW(dev_priv-dev) ? 2 : 1;
- }
- new_delay = dev_priv-rps.cur_freq + adj;
-
+ else /* CHV needs even encode values */
+ adj = IS_CHERRYVIEW(dev_priv) ? 2 : 1;
/*
* For better performance, jump directly
* to RPe if we're below it.
*/
- if (new_delay dev_priv-rps.efficient_freq)
+ if (new_delay dev_priv-rps.efficient_freq - adj) {
new_delay = dev_priv-rps.efficient_freq;
+ adj = 0;
+ }
} else if (pm_iir GEN6_PM_RP_DOWN_TIMEOUT) {
if (dev_priv-rps.cur_freq dev_priv-rps.efficient_freq)
new_delay = dev_priv-rps.efficient_freq;
@@ -1119,24 +1118,22 @@ static void gen6_pm_rps_work(struct work_struct *work)
} else if (pm_iir GEN6_PM_RP_DOWN_THRESHOLD) {
if (adj 0)
adj *= 2;
- else {
- /* CHV needs even encode values */
- adj = IS_CHERRYVIEW(dev_priv-dev) ? -2 : -1;
- }
- new_delay = dev_priv-rps.cur_freq + adj;
+ else /* CHV needs even encode values */
+ adj = IS_CHERRYVIEW(dev_priv) ? -2 : -1;
} else { /* unknown event */
- new_delay = dev_priv-rps.cur_freq;
+ adj = 0;
}
+ dev_priv-rps.last_adj = adj;
+
/* sysfs frequency interfaces may have snuck in while servicing the
* interrupt
*/
+ new_delay += adj;
new_delay = clamp_t(int, new_delay,
dev_priv-rps.min_freq_softlimit,
dev_priv-rps.max_freq_softlimit);
- dev_priv-rps.last_adj = new_delay - dev_priv-rps.cur_freq;
-
intel_set_rps(dev_priv-dev, new_delay);
mutex_unlock(dev_priv-rps.hw_lock);
--
2.1.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 37/70] drm/i915: Squash more pointer indirection for i915_is_gtt
12:58 jlahtine there're actually equally many i915_is_ggtt(vma-vm)
calls
12:58 jlahtine (one less)
12:59 jlahtine so while at it I'd make it vm-is_ggtt and
vma-is_ggtt
12:59 jlahtine then get rid of the whole helper, maybe
13:00 ickle you preempted my beautiful macro
13:03 ickle just don't complain about the increased churn
* to be squashed into the previous patch if desired
---
drivers/gpu/drm/i915/i915_debugfs.c| 4 ++--
drivers/gpu/drm/i915/i915_drv.h| 7 +--
drivers/gpu/drm/i915/i915_gem.c| 32 ++
drivers/gpu/drm/i915/i915_gem_execbuffer.c | 5 ++---
drivers/gpu/drm/i915/i915_gem_gtt.c| 21 ++--
drivers/gpu/drm/i915/i915_gem_gtt.h| 1 +
drivers/gpu/drm/i915/i915_gpu_error.c | 2 +-
drivers/gpu/drm/i915/i915_trace.h | 18 ++---
8 files changed, 39 insertions(+), 51 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index 6c147e1bff0c..2e851c6a310c 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -156,7 +156,7 @@ describe_obj(struct seq_file *m, struct drm_i915_gem_object
*obj)
if (obj-fence_reg != I915_FENCE_REG_NONE)
seq_printf(m, (fence: %d), obj-fence_reg);
list_for_each_entry(vma, obj-vma_list, vma_link) {
- if (!i915_is_ggtt(vma-vm))
+ if (!vma-is_ggtt)
seq_puts(m, (pp);
else
seq_puts(m, (g);
@@ -335,7 +335,7 @@ static int per_file_stats(int id, void *ptr, void *data)
if (!drm_mm_node_allocated(vma-node))
continue;
- if (i915_is_ggtt(vma-vm)) {
+ if (vma-is_ggtt) {
stats-global += obj-base.size;
continue;
}
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 2a5343a9ed24..0dbc7d69f148 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2896,16 +2896,11 @@ bool i915_gem_obj_is_pinned(struct drm_i915_gem_object
*obj);
/* Some GGTT VM helpers */
#define i915_obj_to_ggtt(obj) \
(((struct drm_i915_private *)(obj)-base.dev-dev_private)-gtt.base)
-static inline bool i915_is_ggtt(struct i915_address_space *vm)
-{
- return vm-is_ggtt;
-}
static inline struct i915_hw_ppgtt *
i915_vm_to_ppgtt(struct i915_address_space *vm)
{
- WARN_ON(i915_is_ggtt(vm));
-
+ WARN_ON(vm-is_ggtt);
return container_of(vm, struct i915_hw_ppgtt, base);
}
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 796dc69a6c47..36add864593a 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -3200,8 +3200,7 @@ int i915_vma_unbind(struct i915_vma *vma)
* cause memory corruption through use-after-free.
*/
- if (i915_is_ggtt(vma-vm)
- vma-ggtt_view.type == I915_GGTT_VIEW_NORMAL) {
+ if (vma-is_ggtt vma-ggtt_view.type == I915_GGTT_VIEW_NORMAL) {
i915_gem_object_finish_gtt(obj);
/* release the fence reg _after_ flushing */
@@ -3215,7 +3214,7 @@ int i915_vma_unbind(struct i915_vma *vma)
vma-unbind_vma(vma);
list_del_init(vma-mm_list);
- if (i915_is_ggtt(vma-vm)) {
+ if (vma-is_ggtt) {
if (vma-ggtt_view.type == I915_GGTT_VIEW_NORMAL) {
obj-map_and_fenceable = false;
} else if (vma-ggtt_view.pages) {
@@ -3658,7 +3657,7 @@ i915_gem_object_bind_to_vm(struct drm_i915_gem_object
*obj,
struct i915_vma *vma;
int ret;
- if(WARN_ON(i915_is_ggtt(vm) != !!ggtt_view))
+ if (WARN_ON(vm-is_ggtt != !!ggtt_view))
return ERR_PTR(-EINVAL);
fence_size = i915_gem_get_gtt_size(dev,
@@ -3756,8 +3755,7 @@ search_free:
/* allocate before insert / bind */
if (vma-vm-allocate_va_range) {
- trace_i915_va_alloc(vma-vm, vma-node.start, vma-node.size,
- VM_TO_TRACE_NAME(vma-vm));
+ trace_i915_va_alloc(vma-vm, vma-node.start, vma-node.size);
ret = vma-vm-allocate_va_range(vma-vm,
vma-node.start,
vma-node.size);
@@ -4360,13 +4358,13 @@ i915_gem_object_do_pin(struct drm_i915_gem_object *obj,
if (WARN_ON(vm == dev_priv-mm.aliasing_ppgtt-base))
return -ENODEV;
- if (WARN_ON(flags (PIN_GLOBAL | PIN_MAPPABLE) !i915_is_ggtt(vm)))
+ if (WARN_ON(flags (PIN_GLOBAL | PIN_MAPPABLE) !vm-is_ggtt))
return -EINVAL;
if (WARN_ON((flags (PIN_MAPPABLE | PIN_GLOBAL)) == PIN_MAPPABLE))
return
[Intel-gfx] [PATCH 45/70] drm/i915: Remove request-uniq
We already assign a unique identifier to every request: seqno. That
someone felt like adding a second one without even mentioning why and
tweaking ABI smells very fishy.
Fixes regression from
commit b3a38998f042b862f5ba4d7f2268f3a8dfb4883a
Author: Nick Hoath nicholas.ho...@intel.com
Date: Thu Feb 19 16:30:47 2015 +
drm/i915: Fix a use after free, and unbalanced refcounting
v2: Rebase
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
Cc: Nick Hoath nicholas.ho...@intel.com
Cc: Thomas Daniel thomas.dan...@intel.com
Cc: Daniel Vetter dan...@ffwll.ch
Cc: Jani Nikula jani.nik...@intel.com
---
drivers/gpu/drm/i915/i915_drv.h | 4
drivers/gpu/drm/i915/i915_gem.c | 1 -
drivers/gpu/drm/i915/i915_trace.h | 13 -
3 files changed, 4 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 262ebb620112..89839751237c 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1843,8 +1843,6 @@ struct drm_i915_private {
void (*stop_ring)(struct intel_engine_cs *ring);
} gt;
- uint32_t request_uniq;
-
/*
* NOTE: This is the dri1/ums dungeon, don't add stuff here. Your patch
* will be rejected. Instead look for a better place.
@@ -2120,8 +2118,6 @@ struct drm_i915_gem_request {
/** process identifier submitting this request */
struct pid *pid;
- uint32_t uniq;
-
/**
* The ELSP only accepts two elements at a time, so we queue
* context/tail pairs on a given queue (ring-execlist_queue) until the
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index c394c0d13eb7..e90894545fa4 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -2660,7 +2660,6 @@ int i915_gem_request_alloc(struct intel_engine_cs *ring,
}
rq-ring = ring;
- rq-uniq = dev_priv-request_uniq++;
if (i915.enable_execlists)
ret = intel_logical_ring_alloc_request_extras(rq, ctx);
diff --git a/drivers/gpu/drm/i915/i915_trace.h
b/drivers/gpu/drm/i915/i915_trace.h
index ce8ee9e8bced..6e2eee52aaa2 100644
--- a/drivers/gpu/drm/i915/i915_trace.h
+++ b/drivers/gpu/drm/i915/i915_trace.h
@@ -499,7 +499,6 @@ DECLARE_EVENT_CLASS(i915_gem_request,
TP_STRUCT__entry(
__field(u32, dev)
__field(u32, ring)
-__field(u32, uniq)
__field(u32, seqno)
),
@@ -508,13 +507,11 @@ DECLARE_EVENT_CLASS(i915_gem_request,
i915_gem_request_get_ring(req);
__entry-dev = ring-dev-primary-index;
__entry-ring = ring-id;
- __entry-uniq = req ? req-uniq : 0;
__entry-seqno = i915_gem_request_get_seqno(req);
),
- TP_printk(dev=%u, ring=%u, uniq=%u, seqno=%u,
- __entry-dev, __entry-ring, __entry-uniq,
- __entry-seqno)
+ TP_printk(dev=%u, ring=%u, seqno=%u,
+ __entry-dev, __entry-ring, __entry-seqno)
);
DEFINE_EVENT(i915_gem_request, i915_gem_request_add,
@@ -559,7 +556,6 @@ TRACE_EVENT(i915_gem_request_wait_begin,
TP_STRUCT__entry(
__field(u32, dev)
__field(u32, ring)
-__field(u32, uniq)
__field(u32, seqno)
__field(bool, blocking)
),
@@ -575,14 +571,13 @@ TRACE_EVENT(i915_gem_request_wait_begin,
i915_gem_request_get_ring(req);
__entry-dev = ring-dev-primary-index;
__entry-ring = ring-id;
- __entry-uniq = req ? req-uniq : 0;
__entry-seqno = i915_gem_request_get_seqno(req);
__entry-blocking =
mutex_is_locked(ring-dev-struct_mutex);
),
- TP_printk(dev=%u, ring=%u, uniq=%u, seqno=%u, blocking=%s,
- __entry-dev, __entry-ring, __entry-uniq,
+ TP_printk(dev=%u, ring=%u, seqno=%u, blocking=%s,
+ __entry-dev, __entry-ring,
__entry-seqno, __entry-blocking ? yes (NB) : no)
);
--
2.1.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 07/70] drm/i915: Boost GPU frequency if we detect outstanding pageflips
If we hit a vblank and see that have a pageflip queue but not yet
processed, ensure that the GPU is running at maximum in order to clear
the backlog. Pageflips are only queued for the following vblank, if we
miss it, there will be a visible stutter. Boosting the GPU frequency
doesn't prevent us from missing the target vblank, but it should help
the subsequent frames hitting theirs.
v2: Reorder vblank vs flip-complete so that we only check for a missed
flip after processing the completion events, and avoid spurious boosts.
v3: Rename missed_vblank
v4: Rebase
v5: Cancel the outstanding work in runtime suspend
v6: Rebase
v7: Rebase required fixing
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
Cc: Daniel Vetter daniel.vet...@ffwll.ch
Cc: Ville Syrjälä ville.syrj...@linux.intel.com
Cc: Deepak Sdeepa...@linux.intel.com
---
drivers/gpu/drm/i915/intel_display.c | 11 ---
drivers/gpu/drm/i915/intel_drv.h | 2 ++
drivers/gpu/drm/i915/intel_pm.c | 35 +++
3 files changed, 45 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 94c09bf0047d..1846fb510ebb 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -10195,6 +10195,7 @@ void intel_check_page_flip(struct drm_device *dev, int
pipe)
struct drm_i915_private *dev_priv = dev-dev_private;
struct drm_crtc *crtc = dev_priv-pipe_to_crtc_mapping[pipe];
struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
+ struct intel_unpin_work *work;
WARN_ON(!in_interrupt());
@@ -10202,12 +10203,16 @@ void intel_check_page_flip(struct drm_device *dev,
int pipe)
return;
spin_lock(dev-event_lock);
- if (intel_crtc-unpin_work __intel_pageflip_stall_check(dev, crtc)) {
+ work = intel_crtc-unpin_work;
+ if (work != NULL __intel_pageflip_stall_check(dev, crtc)) {
WARN_ONCE(1, Kicking stuck page flip: queued at %d, now %d\n,
-intel_crtc-unpin_work-flip_queued_vblank,
-drm_vblank_count(dev, pipe));
+work-flip_queued_vblank, drm_vblank_count(dev, pipe));
page_flip_completed(intel_crtc);
+ work = NULL;
}
+ if (work != NULL
+ drm_vblank_count(dev, pipe) - work-flip_queued_vblank 1)
+ intel_queue_rps_boost_for_request(dev, work-flip_queued_req);
spin_unlock(dev-event_lock);
}
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 0bcc5f36a810..4f1d02af1237 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -1263,6 +1263,8 @@ void gen6_rps_busy(struct drm_i915_private *dev_priv);
void gen6_rps_reset_ei(struct drm_i915_private *dev_priv);
void gen6_rps_idle(struct drm_i915_private *dev_priv);
void gen6_rps_boost(struct drm_i915_private *dev_priv);
+void intel_queue_rps_boost_for_request(struct drm_device *dev,
+ struct drm_i915_gem_request *rq);
void ilk_wm_get_hw_state(struct drm_device *dev);
void skl_wm_get_hw_state(struct drm_device *dev);
void skl_ddb_get_hw_state(struct drm_i915_private *dev_priv,
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 50c03472ea41..3e98f30517c6 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -6772,6 +6772,41 @@ int intel_freq_opcode(struct drm_i915_private *dev_priv,
int val)
return val / GT_FREQUENCY_MULTIPLIER;
}
+struct request_boost {
+ struct work_struct work;
+ struct drm_i915_gem_request *rq;
+};
+
+static void __intel_rps_boost_work(struct work_struct *work)
+{
+ struct request_boost *boost = container_of(work, struct request_boost,
work);
+
+ if (!i915_gem_request_completed(boost-rq, true))
+ gen6_rps_boost(to_i915(boost-rq-ring-dev));
+
+ i915_gem_request_unreference__unlocked(boost-rq);
+ kfree(boost);
+}
+
+void intel_queue_rps_boost_for_request(struct drm_device *dev,
+ struct drm_i915_gem_request *rq)
+{
+ struct request_boost *boost;
+
+ if (rq == NULL || INTEL_INFO(dev)-gen 6)
+ return;
+
+ boost = kmalloc(sizeof(*boost), GFP_ATOMIC);
+ if (boost == NULL)
+ return;
+
+ i915_gem_request_reference(rq);
+ boost-rq = rq;
+
+ INIT_WORK(boost-work, __intel_rps_boost_work);
+ queue_work(to_i915(dev)-wq, boost-work);
+}
+
void intel_pm_setup(struct drm_device *dev)
{
struct drm_i915_private *dev_priv = dev-dev_private;
--
2.1.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 08/70] drm/i915: Deminish contribution of wait-boosting from clients
With boosting for missed pageflips, we have a much stronger indication
of when we need to (temporarily) boost GPU frequency to ensure smooth
delivery of frames. So now only allow each client to perform one RPS boost
in each period of GPU activity due to stalling on results.
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
Cc: Deepak S deepa...@linux.intel.com
Reviewed-by: Deepak S deepa...@linux.intel.com
---
drivers/gpu/drm/i915/i915_debugfs.c | 39 +
drivers/gpu/drm/i915/i915_drv.h | 9 ++---
drivers/gpu/drm/i915/i915_gem.c | 35 -
drivers/gpu/drm/i915/intel_drv.h| 3 ++-
drivers/gpu/drm/i915/intel_pm.c | 18 ++---
5 files changed, 70 insertions(+), 34 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index 10ca5117fcee..9c23eec3277e 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -2239,6 +2239,44 @@ static int i915_ppgtt_info(struct seq_file *m, void
*data)
return 0;
}
+static int i915_rps_boost_info(struct seq_file *m, void *data)
+{
+ struct drm_info_node *node = m-private;
+ struct drm_device *dev = node-minor-dev;
+ struct drm_i915_private *dev_priv = dev-dev_private;
+ struct drm_file *file;
+ int ret;
+
+ ret = mutex_lock_interruptible(dev-struct_mutex);
+ if (ret)
+ return ret;
+
+ ret = mutex_lock_interruptible(dev_priv-rps.hw_lock);
+ if (ret)
+ goto unlock;
+
+ list_for_each_entry_reverse(file, dev-filelist, lhead) {
+ struct drm_i915_file_private *file_priv = file-driver_priv;
+ struct task_struct *task;
+
+ rcu_read_lock();
+ task = pid_task(file-pid, PIDTYPE_PID);
+ seq_printf(m, %s [%d]: %d boosts%s\n,
+ task ? task-comm : unknown,
+ task ? task-pid : -1,
+ file_priv-rps_boosts,
+ list_empty(file_priv-rps_boost) ? : , active);
+ rcu_read_unlock();
+ }
+ seq_printf(m, Kernel boosts: %d\n, dev_priv-rps.boosts);
+
+ mutex_unlock(dev_priv-rps.hw_lock);
+unlock:
+ mutex_unlock(dev-struct_mutex);
+
+ return ret;
+}
+
static int i915_llc(struct seq_file *m, void *data)
{
struct drm_info_node *node = m-private;
@@ -4704,6 +4742,7 @@ static const struct drm_info_list i915_debugfs_list[] = {
{i915_ddb_info, i915_ddb_info, 0},
{i915_sseu_status, i915_sseu_status, 0},
{i915_drrs_status, i915_drrs_status, 0},
+ {i915_rps_boost_info, i915_rps_boost_info, 0},
};
#define I915_DEBUGFS_ENTRIES ARRAY_SIZE(i915_debugfs_list)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 0bc913934d3f..357d781095a2 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1044,6 +1044,8 @@ struct intel_gen6_power_mgmt {
bool enabled;
struct delayed_work delayed_resume_work;
+ struct list_head clients;
+ unsigned boosts;
/* manual wa residency calculations */
struct intel_rps_ei up_ei, down_ei;
@@ -2193,12 +2195,13 @@ struct drm_i915_file_private {
struct {
spinlock_t lock;
struct list_head request_list;
- struct delayed_work idle_work;
} mm;
struct idr context_idr;
- atomic_t rps_wait_boost;
- struct intel_engine_cs *bsd_ring;
+ struct list_head rps_boost;
+ struct intel_engine_cs *bsd_ring;
+
+ unsigned rps_boosts;
};
/*
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 567affeafec4..102bef9a77c0 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -1181,14 +1181,6 @@ static bool missed_irq(struct drm_i915_private *dev_priv,
return test_bit(ring-id, dev_priv-gpu_error.missed_irq_rings);
}
-static bool can_wait_boost(struct drm_i915_file_private *file_priv)
-{
- if (file_priv == NULL)
- return true;
-
- return !atomic_xchg(file_priv-rps_wait_boost, true);
-}
-
/**
* __i915_wait_request - wait until execution of request has finished
* @req: duh!
@@ -1230,13 +1222,8 @@ int __i915_wait_request(struct drm_i915_gem_request *req,
timeout_expire = timeout ?
jiffies + nsecs_to_jiffies_timeout((u64)*timeout) : 0;
- if (INTEL_INFO(dev)-gen = 6 ring-id == RCS
can_wait_boost(file_priv)) {
- gen6_rps_boost(dev_priv);
- if (file_priv)
- mod_delayed_work(dev_priv-wq,
-file_priv-mm.idle_work,
-msecs_to_jiffies(100));
- }
+ if (ring-id == RCS INTEL_INFO(dev)-gen = 6)
+
[Intel-gfx] Low hanging fruit take 2
Lots of pickings here to improve both microbenchmarks and beyond across several generations. Have fun! -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 20/70] drm/i915: Limit ring synchronisation (sw sempahores) RPS boosts
Ring switches can occur many times per frame, and are often out of
control, causing frequent RPS boosting for no practical benefit. Treat
the sw semaphore synchronisation as a separate client and only allow it
to boost once per busy/idle cycle.
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
---
drivers/gpu/drm/i915/i915_debugfs.c | 1 +
drivers/gpu/drm/i915/i915_drv.h | 34 ++
drivers/gpu/drm/i915/i915_gem.c | 7 +--
drivers/gpu/drm/i915/intel_pm.c | 1 +
4 files changed, 25 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index 5da74b46e202..c8fe548af41d 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -2296,6 +2296,7 @@ static int i915_rps_boost_info(struct seq_file *m, void
*data)
list_empty(file_priv-rps_boost) ? : , active);
rcu_read_unlock();
}
+ seq_printf(m, Semaphore boosts: %d\n,
dev_priv-rps.semaphores.rps_boosts);
seq_printf(m, Kernel boosts: %d\n, dev_priv-rps.boosts);
mutex_unlock(dev_priv-rps.hw_lock);
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index d35778797ef0..057a1346e81f 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -268,6 +268,22 @@ struct drm_i915_private;
struct i915_mm_struct;
struct i915_mmu_object;
+struct drm_i915_file_private {
+ struct drm_i915_private *dev_priv;
+ struct drm_file *file;
+
+ struct {
+ spinlock_t lock;
+ struct list_head request_list;
+ } mm;
+ struct idr context_idr;
+
+ struct list_head rps_boost;
+ struct intel_engine_cs *bsd_ring;
+
+ unsigned rps_boosts;
+};
+
enum intel_dpll_id {
DPLL_ID_PRIVATE = -1, /* non-shared dpll in use */
/* real shared dpll ids must be = 0 */
@@ -1047,6 +1063,8 @@ struct intel_gen6_power_mgmt {
struct list_head clients;
unsigned boosts;
+ struct drm_i915_file_private semaphores;
+
/* manual wa residency calculations */
struct intel_rps_ei up_ei, down_ei;
@@ -2185,22 +2203,6 @@ static inline void i915_gem_request_assign(struct
drm_i915_gem_request **pdst,
* a later patch when the call to i915_seqno_passed() is obsoleted...
*/
-struct drm_i915_file_private {
- struct drm_i915_private *dev_priv;
- struct drm_file *file;
-
- struct {
- spinlock_t lock;
- struct list_head request_list;
- } mm;
- struct idr context_idr;
-
- struct list_head rps_boost;
- struct intel_engine_cs *bsd_ring;
-
- unsigned rps_boosts;
-};
-
/*
* A command that requires special handling by the command parser.
*/
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index a32a84598fac..3d31ff11fbef 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -3045,9 +3045,12 @@ __i915_gem_object_sync(struct drm_i915_gem_object *obj,
return ret;
if (!i915_semaphore_is_enabled(obj-base.dev)) {
+ struct drm_i915_private *i915 = to_i915(obj-base.dev);
ret = __i915_wait_request(rq,
-
atomic_read(to_i915(obj-base.dev)-gpu_error.reset_counter),
-
to_i915(obj-base.dev)-mm.interruptible, NULL, NULL);
+
atomic_read(i915-gpu_error.reset_counter),
+ i915-mm.interruptible,
+ NULL,
+ i915-rps.semaphores);
if (ret)
return ret;
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index d3f4e9593db1..3e274cf3adaa 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -6827,6 +6827,7 @@ void intel_pm_setup(struct drm_device *dev)
INIT_DELAYED_WORK(dev_priv-rps.delayed_resume_work,
intel_gen6_powersave_work);
INIT_LIST_HEAD(dev_priv-rps.clients);
+ INIT_LIST_HEAD(dev_priv-rps.semaphores.rps_boost);
dev_priv-pm.suspended = false;
}
--
2.1.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 14/70] drm/i915: Split batch pool into size buckets
Now with the trimmed memcpy before the command parser, we try to
allocate many different sizes of batches, predominantly one or two
pages. We can therefore speed up searching for a good sized batch by
keeping the objects of buckets of roughly the same size.
v2: Add a comment about bucket sizes
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
Reviewed-by: Tvrtko Ursulin tvrtko.ursu...@intel.com
---
drivers/gpu/drm/i915/i915_debugfs.c| 46 ++--
drivers/gpu/drm/i915/i915_drv.h| 2 +-
drivers/gpu/drm/i915/i915_gem.c| 2 +-
drivers/gpu/drm/i915/i915_gem_batch_pool.c | 49 +++---
drivers/gpu/drm/i915/i915_gem_batch_pool.h | 2 +-
5 files changed, 64 insertions(+), 37 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index f610a2cd2088..11eebc28775a 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -378,15 +378,17 @@ static void print_batch_pool_stats(struct seq_file *m,
struct drm_i915_gem_object *obj;
struct file_stats stats;
struct intel_engine_cs *ring;
- int i;
+ int i, j;
memset(stats, 0, sizeof(stats));
for_each_ring(ring, dev_priv, i) {
- list_for_each_entry(obj,
- ring-batch_pool.cache_list,
- batch_pool_list)
- per_file_stats(0, obj, stats);
+ for (j = 0; j ARRAY_SIZE(ring-batch_pool.cache_list); j++) {
+ list_for_each_entry(obj,
+ ring-batch_pool.cache_list[j],
+ batch_pool_link)
+ per_file_stats(0, obj, stats);
+ }
}
print_file_stats(m, batch pool, stats);
@@ -618,26 +620,38 @@ static int i915_gem_batch_pool_info(struct seq_file *m,
void *data)
struct drm_i915_private *dev_priv = dev-dev_private;
struct drm_i915_gem_object *obj;
struct intel_engine_cs *ring;
- int count = 0;
- int ret, i;
+ int total = 0;
+ int ret, i, j;
ret = mutex_lock_interruptible(dev-struct_mutex);
if (ret)
return ret;
for_each_ring(ring, dev_priv, i) {
- seq_printf(m, %s cache:\n, ring-name);
- list_for_each_entry(obj,
- ring-batch_pool.cache_list,
- batch_pool_list) {
- seq_puts(m,);
- describe_obj(m, obj);
- seq_putc(m, '\n');
- count++;
+ for (j = 0; j ARRAY_SIZE(ring-batch_pool.cache_list); j++) {
+ int count;
+
+ count = 0;
+ list_for_each_entry(obj,
+ ring-batch_pool.cache_list[j],
+ batch_pool_link)
+ count++;
+ seq_printf(m, %s cache[%d]: %d objects\n,
+ ring-name, j, count);
+
+ list_for_each_entry(obj,
+ ring-batch_pool.cache_list[j],
+ batch_pool_link) {
+ seq_puts(m,);
+ describe_obj(m, obj);
+ seq_putc(m, '\n');
+ }
+
+ total += count;
}
}
- seq_printf(m, total: %d\n, count);
+ seq_printf(m, total: %d\n, total);
mutex_unlock(dev-struct_mutex);
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 178da6eb4edb..cc7956c7f251 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1911,7 +1911,7 @@ struct drm_i915_gem_object {
/** Used in execbuf to temporarily hold a ref */
struct list_head obj_exec_link;
- struct list_head batch_pool_list;
+ struct list_head batch_pool_link;
/**
* This is set if the object is on the active lists (has pending
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 2282f579e101..c7d9ee2f708a 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -4450,7 +4450,7 @@ void i915_gem_object_init(struct drm_i915_gem_object *obj,
INIT_LIST_HEAD(obj-ring_list);
INIT_LIST_HEAD(obj-obj_exec_link);
INIT_LIST_HEAD(obj-vma_list);
- INIT_LIST_HEAD(obj-batch_pool_list);
+ INIT_LIST_HEAD(obj-batch_pool_link);
obj-ops = ops;
diff --git a/drivers/gpu/drm/i915/i915_gem_batch_pool.c
b/drivers/gpu/drm/i915/i915_gem_batch_pool.c
index 1287abf55b84..7bf2f3f2968e
[Intel-gfx] [PATCH 10/70] drm/i915: Split i915_gem_batch_pool into its own header
In the next patch, I want to use the structure elsewhere and so require
it defined earlier. Rather than move the definition to an earlier location
where it feels very odd, place it in its own header file.
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
Reviewed-by: Tvrtko Ursulin tvrtko.ursu...@intel.com
---
drivers/gpu/drm/i915/i915_drv.h| 13 +
drivers/gpu/drm/i915/i915_gem_batch_pool.c | 1 +
drivers/gpu/drm/i915/i915_gem_batch_pool.h | 42 ++
3 files changed, 44 insertions(+), 12 deletions(-)
create mode 100644 drivers/gpu/drm/i915/i915_gem_batch_pool.h
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 357d781095a2..e629939bd23c 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -37,6 +37,7 @@
#include intel_bios.h
#include intel_ringbuffer.h
#include intel_lrc.h
+#include i915_gem_batch_pool.h
#include i915_gem_gtt.h
#include i915_gem_render_state.h
#include linux/io-mapping.h
@@ -1143,11 +1144,6 @@ struct intel_l3_parity {
int which_slice;
};
-struct i915_gem_batch_pool {
- struct drm_device *dev;
- struct list_head cache_list;
-};
-
struct i915_gem_mm {
/** Memory allocator for GTT stolen memory */
struct drm_mm stolen;
@@ -3078,13 +3074,6 @@ void i915_destroy_error_state(struct drm_device *dev);
void i915_get_extra_instdone(struct drm_device *dev, uint32_t *instdone);
const char *i915_cache_level_str(struct drm_i915_private *i915, int type);
-/* i915_gem_batch_pool.c */
-void i915_gem_batch_pool_init(struct drm_device *dev,
- struct i915_gem_batch_pool *pool);
-void i915_gem_batch_pool_fini(struct i915_gem_batch_pool *pool);
-struct drm_i915_gem_object*
-i915_gem_batch_pool_get(struct i915_gem_batch_pool *pool, size_t size);
-
/* i915_cmd_parser.c */
int i915_cmd_parser_get_version(void);
int i915_cmd_parser_init_ring(struct intel_engine_cs *ring);
diff --git a/drivers/gpu/drm/i915/i915_gem_batch_pool.c
b/drivers/gpu/drm/i915/i915_gem_batch_pool.c
index c690170a1c4f..564be7c5ea7e 100644
--- a/drivers/gpu/drm/i915/i915_gem_batch_pool.c
+++ b/drivers/gpu/drm/i915/i915_gem_batch_pool.c
@@ -23,6 +23,7 @@
*/
#include i915_drv.h
+#include i915_gem_batch_pool.h
/**
* DOC: batch pool
diff --git a/drivers/gpu/drm/i915/i915_gem_batch_pool.h
b/drivers/gpu/drm/i915/i915_gem_batch_pool.h
new file mode 100644
index ..5ed70ef6a887
--- /dev/null
+++ b/drivers/gpu/drm/i915/i915_gem_batch_pool.h
@@ -0,0 +1,42 @@
+/*
+ * Copyright © 2014 Intel Corporation
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the Software),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
+ * IN THE SOFTWARE.
+ *
+ */
+
+#ifndef I915_GEM_BATCH_POOL_H
+#define I915_GEM_BATCH_POOL_H
+
+#include i915_drv.h
+
+struct i915_gem_batch_pool {
+ struct drm_device *dev;
+ struct list_head cache_list;
+};
+
+/* i915_gem_batch_pool.c */
+void i915_gem_batch_pool_init(struct drm_device *dev,
+ struct i915_gem_batch_pool *pool);
+void i915_gem_batch_pool_fini(struct i915_gem_batch_pool *pool);
+struct drm_i915_gem_object*
+i915_gem_batch_pool_get(struct i915_gem_batch_pool *pool, size_t size);
+
+#endif /* I915_GEM_BATCH_POOL_H */
--
2.1.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Do not set L3-LLC Coherency bit in ctx descriptor
Tested-By: Intel Graphics QA PRTS (Patch Regression Test System Contact: shuang...@intel.com) Task id: 6139 -Summary- Platform Delta drm-intel-nightly Series Applied PNV -5 272/272 267/272 ILK 302/302 302/302 SNB 303/303 303/303 IVB 338/338 338/338 BYT -1 287/287 286/287 HSW 361/361 361/361 BDW 308/308 308/308 -Detailed- Platform Testdrm-intel-nightly Series Applied *PNV igt@gem_fence_thrash@bo-write-verify-threaded-none PASS(5) FAIL(1)PASS(1) *PNV igt@gem_fence_thrash@bo-write-verify-x PASS(2) FAIL(1)PASS(1) *PNV igt@gem_fence_thrash@bo-write-verify-y PASS(3) FAIL(1)PASS(1) PNV igt@gem_tiled_pread_pwrite FAIL(3)PASS(12) FAIL(1)PASS(1) PNV igt@gem_userptr_blits@coherency-sync CRASH(5)PASS(9) CRASH(1)PASS(1) *BYT igt@gem_exec_bad_domains@conflicting-write-domain PASS(21) FAIL(1)PASS(1) Note: You need to pay more attention to line start with '*' ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/5] mutex: Export an interface to wrap a mutex lock
In i915, we have a big mutex around our device struct - every time before
we attempt to communicate with the GPU, we acquire the mutex. This makes
it a convenient juncture to place our GPU error handling - before we take
the mutex we first check whether the GPU is hung or whether we are in
the process of recovering from a GPU hang. So we wrap the call to
mutex_lock() alongside our additional error handling routines.
The downside of using a wrapper around mutex_lock() is that lockdep and
lockstat cannot discriminate the true callers of mutex_lock(). Unless we
provide a means for the wrapper to pass that information down.
It also appears that i915 is almost unique in this manner of wrapping
mutex_lock(), with only one or two other potential candidates for using
this interface.
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
Cc: Ben Widawsky benjamin.widaw...@intel.com
---
drivers/gpu/drm/i915/i915_gem.c | 4 +++-
include/linux/mutex.h | 9 +
kernel/locking/mutex.c | 36
3 files changed, 48 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 267fdf0f46ae..7ab8e0039790 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -135,7 +135,9 @@ int i915_mutex_lock_interruptible(struct drm_device *dev)
if (ret)
return ret;
- ret = mutex_lock_interruptible(dev-struct_mutex);
+ ret = mutex_lock_wrapper(dev-struct_mutex,
+TASK_INTERRUPTIBLE,
+_RET_IP_);
if (ret)
return ret;
diff --git a/include/linux/mutex.h b/include/linux/mutex.h
index 2cb7531e7d7a..3f6030b3f5aa 100644
--- a/include/linux/mutex.h
+++ b/include/linux/mutex.h
@@ -142,10 +142,15 @@ extern int __must_check
mutex_lock_interruptible_nested(struct mutex *lock,
unsigned int subclass);
extern int __must_check mutex_lock_killable_nested(struct mutex *lock,
unsigned int subclass);
+extern int __must_check mutex_lock_wrapper_nested(struct mutex *lock,
+ unsigned int subclass,
+ long state,
+ unsigned long ip);
#define mutex_lock(lock) mutex_lock_nested(lock, 0)
#define mutex_lock_interruptible(lock) mutex_lock_interruptible_nested(lock, 0)
#define mutex_lock_killable(lock) mutex_lock_killable_nested(lock, 0)
+#define mutex_lock_wrapper(lock, state, ip) mutex_lock_wrapper_nested(lock, 0,
state, ip)
#define mutex_lock_nest_lock(lock, nest_lock) \
do { \
@@ -157,10 +162,14 @@ do {
\
extern void mutex_lock(struct mutex *lock);
extern int __must_check mutex_lock_interruptible(struct mutex *lock);
extern int __must_check mutex_lock_killable(struct mutex *lock);
+extern int __must_check mutex_lock_wrapper(struct mutex *lock,
+ long state,
+ unsigned long ip);
# define mutex_lock_nested(lock, subclass) mutex_lock(lock)
# define mutex_lock_interruptible_nested(lock, subclass)
mutex_lock_interruptible(lock)
# define mutex_lock_killable_nested(lock, subclass) mutex_lock_killable(lock)
+# define mutex_lock_wrapper_nested(lock, subclass, state, ip)
mutex_lock_wrapper(lock, state, ip)
# define mutex_lock_nest_lock(lock, nest_lock) mutex_lock(lock)
#endif
diff --git a/kernel/locking/mutex.c b/kernel/locking/mutex.c
index 94674e5919cb..098b9e71ada1 100644
--- a/kernel/locking/mutex.c
+++ b/kernel/locking/mutex.c
@@ -658,6 +658,17 @@ mutex_lock_interruptible_nested(struct mutex *lock,
unsigned int subclass)
EXPORT_SYMBOL_GPL(mutex_lock_interruptible_nested);
+int __sched
+mutex_lock_wrapper_nested(struct mutex *lock, unsigned int subclass,
+ long state, unsigned long ip)
+{
+ might_sleep();
+ return __mutex_lock_common(lock, state,
+ subclass, NULL, ip, NULL, 0);
+}
+
+EXPORT_SYMBOL_GPL(mutex_lock_wrapper_nested);
+
static inline int
ww_mutex_deadlock_injection(struct ww_mutex *lock, struct ww_acquire_ctx *ctx)
{
@@ -780,6 +791,9 @@ __mutex_lock_killable_slowpath(struct mutex *lock);
static noinline int __sched
__mutex_lock_interruptible_slowpath(struct mutex *lock);
+static noinline int __sched
+__mutex_lock_wrapper_slowpath(struct mutex *lock, long state, unsigned long
ip);
+
/**
* mutex_lock_interruptible - acquire the mutex, interruptible
* @lock: the mutex to be acquired
@@ -806,6 +820,21 @@ int __sched mutex_lock_interruptible(struct mutex *lock)
EXPORT_SYMBOL(mutex_lock_interruptible);
+int __sched
[Intel-gfx] [PATCH] drm/i915: drm locks up when connecting laptop to docking station
Hello, since late 4.0-rc4 / early4.0-rc5 drm-intel branch I'm experiencing lockups every time I try to connect my lenovo t440p laptop to its docking station. [ 143.896172] [ cut here ] [ 143.896182] WARNING: CPU: 0 PID: 1102 at drivers/gpu/drm/drm_atomic_helper.c:2204 drm_atomic_helper_connector_duplicate_state+0x35/0x40 [drm_kms_helper]() [ 143.896184] Modules linked in: snd_hda_codec_hdmi i915 snd_hda_codec_realtek snd_hda_codec_generic iwlmvm snd_hda_intel snd_hda_controller i2c_algo_bit drm_kms_helper snd_hda_codec drm iwlwifi snd_hwdep snd_pcm intel_gtt snd_timer thinkpad_acpi agpgart snd_hda_core [ 143.896201] CPU: 0 PID: 1102 Comm: X Not tainted 4.0.0-rc7-01086-g91d1586 #1 [ 143.896202] Hardware name: LENOVO ENX407/ENX407, BIOS GLET77WW (2.31 ) 01/27/2015 [ 143.896203] a0171420 81590365 [ 143.896206] 81043617 fff4 8804098d7d80 8800c9cd3000 [ 143.896209] 0006 8800c9c7a800 a016bf05 [ 143.896212] Call Trace: [ 143.896219] [81590365] ? dump_stack+0x40/0x50 [ 143.896223] [81043617] ? warn_slowpath_common+0x77/0xb0 [ 143.896228] [a016bf05] ? drm_atomic_helper_connector_duplicate_state+0x35/0x40 [drm_kms_helper] [ 143.896235] [a00efea5] ? drm_atomic_get_connector_state+0x95/0x110 [drm] [ 143.896252] [a0352e8f] ? intel_crtc_set_config+0xc6f/0xfb0 [i915] [ 143.896258] [8112c21b] ? ep_poll_callback+0xeb/0x120 [ 143.896264] [a00eed99] ? drm_modeset_lock_all_crtcs+0xa9/0xc0 [drm] [ 143.896273] [a00d] ? drm_mode_set_config_internal+0x5f/0x100 [drm] [ 143.896281] [a00e47fa] ? drm_mode_setcrtc+0x22a/0x5f0 [drm] [ 143.896288] [a00d65ca] ? drm_ioctl+0x15a/0x580 [drm] [ 143.896292] [8106b8cf] ? pick_next_task_fair+0x43f/0x4b0 [ 143.896295] [81103488] ? do_vfs_ioctl+0x2e8/0x4f0 [ 143.896298] [8159288d] ? __schedule+0x24d/0x7c0 [ 143.896301] [811036c6] ? SyS_ioctl+0x36/0x80 [ 143.896303] [811055f2] ? SyS_poll+0x52/0xf0 [ 143.896307] [81595f36] ? system_call_fastpath+0x16/0x1b [ 143.896309] ---[ end trace 17ff49bc79a1a762 ]--- [ 143.896318] BUG: unable to handle kernel NULL pointer dereference at 0008 [ 143.896362] IP: [a00eff84] drm_atomic_add_affected_connectors+0x64/0xc0 [drm] [ 143.896403] PGD 406577067 PUD 408c42067 PMD 0 [ 143.896426] Oops: [#1] SMP [ 143.896439] Modules linked in: snd_hda_codec_hdmi i915 snd_hda_codec_realtek snd_hda_codec_generic iwlmvm snd_hda_intel snd_hda_controller i2c_algo_bit drm_kms_helper snd_hda_codec drm iwlwifi snd_hwdep snd_pcm intel_gtt snd_timer thinkpad_acpi agpgart snd_hda_core [ 143.896584] CPU: 0 PID: 1102 Comm: X Tainted: GW 4.0.0-rc7-01086-g91d1586 #1 [ 143.896619] Hardware name: LENOVO ENX407/ENX407, BIOS GLET77WW (2.31 ) 01/27/2015 [ 143.896654] task: 88040652b1e0 ti: 880409a9 task.ti: 880409a9 [ 143.896686] RIP: 0010:[a00eff84] [a00eff84] drm_atomic_add_affected_connectors+0x64/0xc0 [drm] [ 143.896738] RSP: 0018:880409a93b18 EFLAGS: 00010283 [ 143.896759] RAX: RBX: 8800c9cd3000 RCX: 88040af8ec00 [ 143.896789] RDX: 88040a603e20 RSI: 880408d916a8 RDI: 88040af8eea8 [ 143.896819] RBP: 8800c9c7ab28 R08: 00015700 R09: 880409a93c30 [ 143.896849] R10: 88040dc01500 R11: a00ef362 R12: 88040c38d000 [ 143.896878] R13: 8804098d7d80 R14: 880409a93c34 R15: 88040c38d000 [ 143.896909] FS: 7f13fb95f8c0() GS:88041e20() knlGS: [ 143.896943] CS: 0010 DS: ES: CR0: 80050033 [ 143.896966] CR2: 0008 CR3: 00040bbd7000 CR4: 001406f0 [ 143.896995] Stack: [ 143.897000] 0006 8800c9c7a800 880409a93c30 8804098d7d80 [ 143.897037] a034c0ac 880409a93c2c [ 143.897074] 000c a0171420 089c [ 143.897112] Call Trace: [ 143.897131] [a034c0ac] ? intel_modeset_compute_config+0x3c/0x1090 [i915] [ 143.897166] [8158f7b5] ? printk+0x48/0x4d [ 143.897196] [a0351b49] ? intel_set_mode+0x39/0xa0 [i915] [ 143.897225] [a016bf05] ? drm_atomic_helper_connector_duplicate_state+0x35/0x40 [drm_kms_helper] [ 143.897272] [a00ef362] ? drm_atomic_state_clear+0xb2/0x180 [drm] [ 143.897311] [a0352c3d] ? intel_crtc_set_config+0xa1d/0xfb0 [i915] [ 143.897343] [8112c21b] ? ep_poll_callback+0xeb/0x120 [ 143.897372] [a00eed99] ? drm_modeset_lock_all_crtcs+0xa9/0xc0 [drm] [ 143.897409] [a00d] ? drm_mode_set_config_internal+0x5f/0x100 [drm] [ 143.897447] [a00e47fa] ? drm_mode_setcrtc+0x22a/0x5f0
[Intel-gfx] [PATCH 2/5] mm: Refactor remap_pfn_range()
In preparation for exporting very similar functionality through another
interface, gut the current remap_pfn_range(). The motivating factor here
is to reuse the PGB/PUD/PMD/PTE walker, but allow back progation of
errors rather than BUG_ON.
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
Cc: Andrew Morton a...@linux-foundation.org
Cc: Kirill A. Shutemov kirill.shute...@linux.intel.com
Cc: Peter Zijlstra pet...@infradead.org
Cc: Rik van Riel r...@redhat.com
Cc: Mel Gorman mgor...@suse.de
Cc: Cyrill Gorcunov gorcu...@gmail.com
Cc: Johannes Weiner han...@cmpxchg.org
Cc: linux...@kvack.org
---
mm/memory.c | 102 +---
1 file changed, 57 insertions(+), 45 deletions(-)
diff --git a/mm/memory.c b/mm/memory.c
index 97839f5c8c30..acb06f40d614 100644
--- a/mm/memory.c
+++ b/mm/memory.c
@@ -1614,71 +1614,81 @@ int vm_insert_mixed(struct vm_area_struct *vma,
unsigned long addr,
}
EXPORT_SYMBOL(vm_insert_mixed);
+struct remap_pfn {
+ struct mm_struct *mm;
+ unsigned long addr;
+ unsigned long pfn;
+ pgprot_t prot;
+};
+
/*
* maps a range of physical memory into the requested pages. the old
* mappings are removed. any references to nonexistent pages results
* in null mappings (currently treated as copy-on-access)
*/
-static int remap_pte_range(struct mm_struct *mm, pmd_t *pmd,
- unsigned long addr, unsigned long end,
- unsigned long pfn, pgprot_t prot)
+static inline int remap_pfn(struct remap_pfn *r, pte_t *pte)
+{
+ if (!pte_none(*pte))
+ return -EBUSY;
+
+ set_pte_at(r-mm, r-addr, pte,
+ pte_mkspecial(pfn_pte(r-pfn, r-prot)));
+ r-pfn++;
+ r-addr += PAGE_SIZE;
+ return 0;
+}
+
+static int remap_pte_range(struct remap_pfn *r, pmd_t *pmd, unsigned long end)
{
pte_t *pte;
spinlock_t *ptl;
+ int err;
- pte = pte_alloc_map_lock(mm, pmd, addr, ptl);
+ pte = pte_alloc_map_lock(r-mm, pmd, r-addr, ptl);
if (!pte)
return -ENOMEM;
+
arch_enter_lazy_mmu_mode();
do {
- BUG_ON(!pte_none(*pte));
- set_pte_at(mm, addr, pte, pte_mkspecial(pfn_pte(pfn, prot)));
- pfn++;
- } while (pte++, addr += PAGE_SIZE, addr != end);
+ err = remap_pfn(r, pte++);
+ } while (err == 0 r-addr end);
arch_leave_lazy_mmu_mode();
+
pte_unmap_unlock(pte - 1, ptl);
- return 0;
+ return err;
}
-static inline int remap_pmd_range(struct mm_struct *mm, pud_t *pud,
- unsigned long addr, unsigned long end,
- unsigned long pfn, pgprot_t prot)
+static inline int remap_pmd_range(struct remap_pfn *r, pud_t *pud, unsigned
long end)
{
pmd_t *pmd;
- unsigned long next;
+ int err;
- pfn -= addr PAGE_SHIFT;
- pmd = pmd_alloc(mm, pud, addr);
+ pmd = pmd_alloc(r-mm, pud, r-addr);
if (!pmd)
return -ENOMEM;
VM_BUG_ON(pmd_trans_huge(*pmd));
+
do {
- next = pmd_addr_end(addr, end);
- if (remap_pte_range(mm, pmd, addr, next,
- pfn + (addr PAGE_SHIFT), prot))
- return -ENOMEM;
- } while (pmd++, addr = next, addr != end);
- return 0;
+ err = remap_pte_range(r, pmd++, pmd_addr_end(r-addr, end));
+ } while (err == 0 r-addr end);
+
+ return err;
}
-static inline int remap_pud_range(struct mm_struct *mm, pgd_t *pgd,
- unsigned long addr, unsigned long end,
- unsigned long pfn, pgprot_t prot)
+static inline int remap_pud_range(struct remap_pfn *r, pgd_t *pgd, unsigned
long end)
{
pud_t *pud;
- unsigned long next;
+ int err;
- pfn -= addr PAGE_SHIFT;
- pud = pud_alloc(mm, pgd, addr);
+ pud = pud_alloc(r-mm, pgd, r-addr);
if (!pud)
return -ENOMEM;
+
do {
- next = pud_addr_end(addr, end);
- if (remap_pmd_range(mm, pud, addr, next,
- pfn + (addr PAGE_SHIFT), prot))
- return -ENOMEM;
- } while (pud++, addr = next, addr != end);
- return 0;
+ err = remap_pmd_range(r, pud++, pud_addr_end(r-addr, end));
+ } while (err == 0 r-addr end);
+
+ return err;
}
/**
@@ -1694,10 +1704,9 @@ static inline int remap_pud_range(struct mm_struct *mm,
pgd_t *pgd,
int remap_pfn_range(struct vm_area_struct *vma, unsigned long addr,
unsigned long pfn, unsigned long size, pgprot_t prot)
{
- pgd_t *pgd;
- unsigned long next;
unsigned long end = addr + PAGE_ALIGN(size);
- struct mm_struct *mm = vma-vm_mm;
+ struct remap_pfn r;
+ pgd_t *pgd;
int err;
/*
@@ -1731,19 +1740,22 @@
Re: [Intel-gfx] [PATCH] drm/i915: Do not set L3-LLC Coherency bit in ctx descriptor
On Tue, Apr 07, 2015 at 05:03:32PM +0300, Mika Kuoppala wrote: Arun Siluvery arun.siluv...@linux.intel.com writes: According to Spec this is a reserved bit for Gen9+ and should not be set. Change-Id: I0215fb7057b94139b7a2f90ecc7a0201c0c93ad4 Signed-off-by: Arun Siluvery arun.siluv...@linux.intel.com --- Reviewed-by: Mika Kuoppala mika.kuopp...@intel.com Queued for -next, thanks for the patch. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 51/70] drm/i915: Record the position of the start of the request
Not only does it make for good documentation and debugging aide, but it
is also vital for when we want to unwind requests - such as when
throwing away an incomplete request.
v2: Rebase
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
---
drivers/gpu/drm/i915/i915_gem.c | 13
drivers/gpu/drm/i915/i915_gem_context.c | 9 +
drivers/gpu/drm/i915/intel_lrc.c| 35 -
drivers/gpu/drm/i915/intel_lrc.h| 2 --
4 files changed, 10 insertions(+), 49 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index d9b5bf4f1f21..e9f2d2b102de 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -2462,7 +2462,6 @@ int __i915_add_request(struct intel_engine_cs *ring,
struct drm_i915_private *dev_priv = ring-dev-dev_private;
struct drm_i915_gem_request *request;
struct intel_ringbuffer *ringbuf;
- u32 request_start;
int ret;
request = ring-outstanding_lazy_request;
@@ -2477,7 +2476,6 @@ int __i915_add_request(struct intel_engine_cs *ring,
} else
ringbuf = ring-buffer;
- request_start = intel_ring_get_tail(ringbuf);
/*
* Emit any outstanding flushes - execbuf can fail to emit the flush
* after having emitted the batchbuffer command. Hence we need to fix
@@ -2505,7 +2503,6 @@ int __i915_add_request(struct intel_engine_cs *ring,
return ret;
}
- request-head = request_start;
request-tail = intel_ring_get_tail(ringbuf);
/* Whilst this request exists, batch_obj will be on the
@@ -2652,6 +2649,7 @@ int i915_gem_request_alloc(struct intel_engine_cs *ring,
return ret;
}
+ rq-head = intel_ring_get_tail(rq-ringbuf);
ring-outstanding_lazy_request = rq;
return 0;
}
@@ -2736,7 +2734,14 @@ static void i915_gem_reset_ring_cleanup(struct
drm_i915_private *dev_priv,
}
/* This may not have been flushed before the reset, so clean it now */
- i915_gem_request_assign(ring-outstanding_lazy_request, NULL);
+ if (ring-outstanding_lazy_request) {
+ struct drm_i915_gem_request *request;
+
+ request = ring-outstanding_lazy_request;
+ request-ringbuf-tail = request-head;
+
+ i915_gem_request_assign(ring-outstanding_lazy_request, NULL);
+ }
}
void i915_gem_restore_fences(struct drm_device *dev)
diff --git a/drivers/gpu/drm/i915/i915_gem_context.c
b/drivers/gpu/drm/i915/i915_gem_context.c
index b9c6b0ad1d0f..43e58249235b 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/i915_gem_context.c
@@ -298,15 +298,8 @@ void i915_gem_context_reset(struct drm_device *dev)
struct drm_i915_private *dev_priv = dev-dev_private;
int i;
- if (i915.enable_execlists) {
- struct intel_context *ctx;
-
- list_for_each_entry(ctx, dev_priv-context_list, link) {
- intel_lr_context_reset(dev, ctx);
- }
-
+ if (i915.enable_execlists)
return;
- }
for (i = 0; i I915_NUM_RINGS; i++) {
struct intel_engine_cs *ring = dev_priv-ring[i];
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index b3ca88ff88eb..459a27a2b486 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -1804,38 +1804,3 @@ error_unpin_ctx:
drm_gem_object_unreference(ctx_obj-base);
return ret;
}
-
-void intel_lr_context_reset(struct drm_device *dev,
- struct intel_context *ctx)
-{
- struct drm_i915_private *dev_priv = dev-dev_private;
- struct intel_engine_cs *ring;
- int i;
-
- for_each_ring(ring, dev_priv, i) {
- struct drm_i915_gem_object *ctx_obj =
- ctx-engine[ring-id].state;
- struct intel_ringbuffer *ringbuf =
- ctx-engine[ring-id].ringbuf;
- uint32_t *reg_state;
- struct page *page;
-
- if (!ctx_obj)
- continue;
-
- if (i915_gem_object_get_pages(ctx_obj)) {
- WARN(1, Failed get_pages for context obj\n);
- continue;
- }
- page = i915_gem_object_get_page(ctx_obj, 1);
- reg_state = kmap_atomic(page);
-
- reg_state[CTX_RING_HEAD+1] = 0;
- reg_state[CTX_RING_TAIL+1] = 0;
-
- kunmap_atomic(reg_state);
-
- ringbuf-head = 0;
- ringbuf-tail = 0;
- }
-}
diff --git a/drivers/gpu/drm/i915/intel_lrc.h b/drivers/gpu/drm/i915/intel_lrc.h
index 16c717672020..1aafb99cfff4 100644
--- a/drivers/gpu/drm/i915/intel_lrc.h
+++ b/drivers/gpu/drm/i915/intel_lrc.h
[Intel-gfx] [PATCH 17/70] drm/i915: Optimistically spin for the request completion
This provides a nice boost to mesa in swap bound scenarios (as mesa
throttles itself to the previous frame and given the scenario that will
complete shortly). It will also provide a good boost to systems running
with semaphores disabled and so frequently waiting on the GPU as it
switches rings. In the most favourable of microbenchmarks, this can
increase performance by around 15% - though in practice improvements
will be marginal and rarely noticeable.
v2: Account for user timeouts
v3: Limit the spinning to a single jiffie (~1us) at most. On an
otherwise idle system, there is no scheduler contention and so without a
limit we would spin until the GPU is ready.
v4: Drop forcewake - the lazy coherent access doesn't require it, and we
have no reason to believe that the forcewake itself improves seqno
coherency - it only adds delay.
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
Cc: Daniel Vetter daniel.vet...@ffwll.ch
Cc: Tvrtko Ursulin tvrtko.ursu...@linux.intel.com
Cc: Eero Tamminen eero.t.tammi...@intel.com
Cc: Rantala, Valtteri valtteri.rant...@intel.com
---
drivers/gpu/drm/i915/i915_gem.c | 44 +++--
1 file changed, 38 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index c7d9ee2f708a..47650327204e 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -1181,6 +1181,29 @@ static bool missed_irq(struct drm_i915_private *dev_priv,
return test_bit(ring-id, dev_priv-gpu_error.missed_irq_rings);
}
+static int __i915_spin_request(struct drm_i915_gem_request *rq)
+{
+ unsigned long timeout;
+
+ if (i915_gem_request_get_ring(rq)-irq_refcount)
+ return -EBUSY;
+
+ timeout = jiffies + 1;
+ while (!need_resched()) {
+ if (i915_gem_request_completed(rq, true))
+ return 0;
+
+ if (time_after_eq(jiffies, timeout))
+ break;
+
+ cpu_relax_lowlatency();
+ }
+ if (i915_gem_request_completed(rq, false))
+ return 0;
+
+ return -EAGAIN;
+}
+
/**
* __i915_wait_request - wait until execution of request has finished
* @req: duh!
@@ -1225,12 +1248,20 @@ int __i915_wait_request(struct drm_i915_gem_request
*req,
if (INTEL_INFO(dev)-gen = 6)
gen6_rps_boost(dev_priv, file_priv);
- if (!irq_test_in_progress WARN_ON(!ring-irq_get(ring)))
- return -ENODEV;
-
/* Record current time in case interrupted by signal, or wedged */
trace_i915_gem_request_wait_begin(req);
before = ktime_get_raw_ns();
+
+ /* Optimistic spin for the next jiffie before touching IRQs */
+ ret = __i915_spin_request(req);
+ if (ret == 0)
+ goto out;
+
+ if (!irq_test_in_progress WARN_ON(!ring-irq_get(ring))) {
+ ret = -ENODEV;
+ goto out;
+ }
+
for (;;) {
struct timer_list timer;
@@ -1279,14 +1310,15 @@ int __i915_wait_request(struct drm_i915_gem_request
*req,
destroy_timer_on_stack(timer);
}
}
- now = ktime_get_raw_ns();
- trace_i915_gem_request_wait_end(req);
-
if (!irq_test_in_progress)
ring-irq_put(ring);
finish_wait(ring-irq_queue, wait);
+out:
+ now = ktime_get_raw_ns();
+ trace_i915_gem_request_wait_end(req);
+
if (timeout) {
s64 tres = *timeout - (now - before);
--
2.1.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 02/70] drm/i915: Fix the flip synchronisation to consider mmioflips
Currently we emit semaphore synchronisation as if we were going to flip
using the target CS engine, but we then change our minds and do the flip
using the CPU. Consequently we write instructions to the ring but never
use them - even to the point of filling that ring up entirely and never
submitting a request.
The wrinkle in the ointment is that we have to tell a white lie to
pin-to-display for it to skip the synchronisation for mmioflips as we
will create a task specifically for that slow synchronisation. An oddity
of note is the discrepancy in requests that we tell to pin-display to
serialise to and that we then eventually wait upon. This is due to a
limitation in the i915_gem_object_sync() routine that will be lifted
later.
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
---
drivers/gpu/drm/i915/intel_display.c | 13 +++--
1 file changed, 11 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 3af87e4b0f66..4af89c27504e 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -10224,6 +10224,7 @@ static int intel_crtc_page_flip(struct drm_crtc *crtc,
enum pipe pipe = intel_crtc-pipe;
struct intel_unpin_work *work;
struct intel_engine_cs *ring;
+ bool mmio_flip;
int ret;
/*
@@ -10321,15 +10322,23 @@ static int intel_crtc_page_flip(struct drm_crtc *crtc,
ring = dev_priv-ring[RCS];
}
+ mmio_flip = use_mmio_flip(ring, obj);
+
+ /* When using CS flips, we want to emit semaphores between rings.
+* However, when using mmio flips we will create a task to do the
+* synchronisation, so all we want here is to pin the framebuffer
+* into the display plane and skip any waits.
+*/
ret = intel_pin_and_fence_fb_obj(crtc-primary, fb,
-crtc-primary-state, ring);
+crtc-primary-state,
+mmio_flip ?
i915_gem_request_get_ring(obj-last_read_req) : ring);
if (ret)
goto cleanup_pending;
work-gtt_offset = intel_plane_obj_offset(to_intel_plane(primary), obj)
+ intel_crtc-dspaddr_offset;
- if (use_mmio_flip(ring, obj)) {
+ if (mmio_flip) {
ret = intel_queue_mmio_flip(dev, crtc, fb, obj, ring,
page_flip_flags);
if (ret)
--
2.1.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 19/70] drm/i915: Inline check required for object syncing prior to execbuf
This trims a little overhead from the common case of not needing to
synchronize between rings.
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
---
drivers/gpu/drm/i915/i915_gem_execbuffer.c | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
index bd7b7ec5c184..1eda0bdc5eab 100644
--- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
@@ -909,9 +909,12 @@ i915_gem_execbuffer_move_to_gpu(struct intel_engine_cs
*ring,
list_for_each_entry(vma, vmas, exec_list) {
struct drm_i915_gem_object *obj = vma-obj;
- ret = i915_gem_object_sync(obj, ring);
- if (ret)
- return ret;
+
+ if (obj-active ~intel_ring_flag(ring)) {
+ ret = i915_gem_object_sync(obj, ring);
+ if (ret)
+ return ret;
+ }
if (obj-base.write_domain I915_GEM_DOMAIN_CPU)
flush_chipset |= i915_gem_clflush_object(obj, false);
--
2.1.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 13/70] drm/i915: Free batch pool when idle
At runtime, this helps ensure that the batch pools are kept trim and
fast. Then at suspend, this releases memory that we do not need to
restore. It also ties into the oom-notifier to ensure that we recover as
much kernel memory as possible during OOM.
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
Reviewed-by: Tvrtko Ursulin tvrtko.ursu...@intel.com
---
drivers/gpu/drm/i915/i915_gem.c | 13 -
1 file changed, 12 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 9e1d872aa576..2282f579e101 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -2795,8 +2795,19 @@ i915_gem_idle_work_handler(struct work_struct *work)
{
struct drm_i915_private *dev_priv =
container_of(work, typeof(*dev_priv), mm.idle_work.work);
+ struct drm_device *dev = dev_priv-dev;
+
+ intel_mark_idle(dev);
- intel_mark_idle(dev_priv-dev);
+ if (mutex_trylock(dev-struct_mutex)) {
+ struct intel_engine_cs *ring;
+ int i;
+
+ for_each_ring(ring, dev_priv, i)
+ i915_gem_batch_pool_fini(ring-batch_pool);
+
+ mutex_unlock(dev-struct_mutex);
+ }
}
/**
--
2.1.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 30/70] drm/i915: Map the ringbuffer using WB on LLC machines
If we have llc coherency, we can write directly into the ringbuffer
using ordinary cached writes rather than forcing WC access.
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
---
drivers/gpu/drm/i915/intel_ringbuffer.c | 60 +++--
1 file changed, 49 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c
b/drivers/gpu/drm/i915/intel_ringbuffer.c
index 93788a36db62..5b837ed842f6 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.c
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
@@ -1907,11 +1907,35 @@ static int init_phys_status_page(struct intel_engine_cs
*ring)
void intel_unpin_ringbuffer_obj(struct intel_ringbuffer *ringbuf)
{
- iounmap(ringbuf-virtual_start);
+ if (HAS_LLC(ringbuf-obj-base.dev) !ringbuf-obj-stolen)
+ vunmap(ringbuf-virtual_start);
+ else
+ iounmap(ringbuf-virtual_start);
ringbuf-virtual_start = NULL;
i915_gem_object_ggtt_unpin(ringbuf-obj);
}
+static u32 *vmap_obj(struct drm_i915_gem_object *obj)
+{
+ struct sg_page_iter sg_iter;
+ struct page **pages;
+ void *addr;
+ int i;
+
+ pages = drm_malloc_ab(obj-base.size PAGE_SHIFT, sizeof(*pages));
+ if (pages == NULL)
+ return NULL;
+
+ i = 0;
+ for_each_sg_page(obj-pages-sgl, sg_iter, obj-pages-nents, 0)
+ pages[i++] = sg_page_iter_page(sg_iter);
+
+ addr = vmap(pages, i, 0, PAGE_KERNEL);
+ drm_free_large(pages);
+
+ return addr;
+}
+
int intel_pin_and_map_ringbuffer_obj(struct drm_device *dev,
struct intel_ringbuffer *ringbuf)
{
@@ -1923,17 +1947,31 @@ int intel_pin_and_map_ringbuffer_obj(struct drm_device
*dev,
if (ret)
return ret;
- ret = i915_gem_object_set_to_gtt_domain(obj, true);
- if (ret) {
- i915_gem_object_ggtt_unpin(obj);
- return ret;
- }
+ if (HAS_LLC(dev_priv) !obj-stolen) {
+ ret = i915_gem_object_set_to_cpu_domain(obj, true);
+ if (ret) {
+ i915_gem_object_ggtt_unpin(obj);
+ return ret;
+ }
- ringbuf-virtual_start = ioremap_wc(dev_priv-gtt.mappable_base +
- i915_gem_obj_ggtt_offset(obj), ringbuf-size);
- if (ringbuf-virtual_start == NULL) {
- i915_gem_object_ggtt_unpin(obj);
- return -EINVAL;
+ ringbuf-virtual_start = vmap_obj(obj);
+ if (ringbuf-virtual_start == NULL) {
+ i915_gem_object_ggtt_unpin(obj);
+ return -ENOMEM;
+ }
+ } else {
+ ret = i915_gem_object_set_to_gtt_domain(obj, true);
+ if (ret) {
+ i915_gem_object_ggtt_unpin(obj);
+ return ret;
+ }
+
+ ringbuf-virtual_start = ioremap_wc(dev_priv-gtt.mappable_base
+
+
i915_gem_obj_ggtt_offset(obj), ringbuf-size);
+ if (ringbuf-virtual_start == NULL) {
+ i915_gem_object_ggtt_unpin(obj);
+ return -EINVAL;
+ }
}
return 0;
--
2.1.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 27/70] drm/i915: Remove vestigal DRI1 ring quiescing code
After the removal of DRI1, all access to the rings are through requests
and so we can always be sure that there is a request to wait upon to
free up available space. The fallback code only existed so that we could
quiesce the GPU following unmediated access by DRI1.
v2: Rebase
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
---
drivers/gpu/drm/i915/i915_trace.h | 27
drivers/gpu/drm/i915/intel_lrc.c| 57 +++--
drivers/gpu/drm/i915/intel_ringbuffer.c | 56 ++--
3 files changed, 6 insertions(+), 134 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_trace.h
b/drivers/gpu/drm/i915/i915_trace.h
index b3070a4501ab..97483e21c9b4 100644
--- a/drivers/gpu/drm/i915/i915_trace.h
+++ b/drivers/gpu/drm/i915/i915_trace.h
@@ -597,33 +597,6 @@ DEFINE_EVENT(i915_gem_request, i915_gem_request_wait_end,
TP_ARGS(req)
);
-DECLARE_EVENT_CLASS(i915_ring,
- TP_PROTO(struct intel_engine_cs *ring),
- TP_ARGS(ring),
-
- TP_STRUCT__entry(
-__field(u32, dev)
-__field(u32, ring)
-),
-
- TP_fast_assign(
- __entry-dev = ring-dev-primary-index;
- __entry-ring = ring-id;
- ),
-
- TP_printk(dev=%u, ring=%u, __entry-dev, __entry-ring)
-);
-
-DEFINE_EVENT(i915_ring, i915_ring_wait_begin,
- TP_PROTO(struct intel_engine_cs *ring),
- TP_ARGS(ring)
-);
-
-DEFINE_EVENT(i915_ring, i915_ring_wait_end,
- TP_PROTO(struct intel_engine_cs *ring),
- TP_ARGS(ring)
-);
-
TRACE_EVENT(i915_flip_request,
TP_PROTO(int plane, struct drm_i915_gem_object *obj),
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 4c985e186e3a..d1a9701c7f7b 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -613,8 +613,9 @@ int intel_logical_ring_alloc_request_extras(struct
drm_i915_gem_request *request
return 0;
}
-static int logical_ring_wait_request(struct intel_ringbuffer *ringbuf,
-int bytes)
+static int logical_ring_wait_for_space(struct intel_ringbuffer *ringbuf,
+ struct intel_context *ctx,
+ int bytes)
{
struct intel_engine_cs *ring = ringbuf-ring;
struct drm_i915_gem_request *request;
@@ -640,7 +641,7 @@ static int logical_ring_wait_request(struct
intel_ringbuffer *ringbuf,
break;
}
- if (request-list == ring-request_list)
+ if (WARN_ON(request-list == ring-request_list))
return -ENOSPC;
ret = i915_wait_request(request);
@@ -675,56 +676,6 @@ intel_logical_ring_advance_and_submit(struct
intel_ringbuffer *ringbuf,
execlists_context_queue(ring, ctx, ringbuf-tail, request);
}
-static int logical_ring_wait_for_space(struct intel_ringbuffer *ringbuf,
- struct intel_context *ctx,
- int bytes)
-{
- struct intel_engine_cs *ring = ringbuf-ring;
- struct drm_device *dev = ring-dev;
- struct drm_i915_private *dev_priv = dev-dev_private;
- unsigned long end;
- int ret;
-
- ret = logical_ring_wait_request(ringbuf, bytes);
- if (ret != -ENOSPC)
- return ret;
-
- /* Force the context submission in case we have been skipping it */
- intel_logical_ring_advance_and_submit(ringbuf, ctx, NULL);
-
- /* With GEM the hangcheck timer should kick us out of the loop,
-* leaving it early runs the risk of corrupting GEM state (due
-* to running on almost untested codepaths). But on resume
-* timers don't work yet, so prevent a complete hang in that
-* case by choosing an insanely large timeout. */
- end = jiffies + 60 * HZ;
-
- ret = 0;
- do {
- if (intel_ring_space(ringbuf) = bytes)
- break;
-
- msleep(1);
-
- if (dev_priv-mm.interruptible signal_pending(current)) {
- ret = -ERESTARTSYS;
- break;
- }
-
- ret = i915_gem_check_wedge(dev_priv-gpu_error,
- dev_priv-mm.interruptible);
- if (ret)
- break;
-
- if (time_after(jiffies, end)) {
- ret = -EBUSY;
- break;
- }
- } while (1);
-
- return ret;
-}
-
static int logical_ring_wrap_buffer(struct intel_ringbuffer *ringbuf,
struct intel_context *ctx)
{
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c
b/drivers/gpu/drm/i915/intel_ringbuffer.c
index
[Intel-gfx] [PATCH 59/70] drm/i915: Simplify object is-pinned checking for shrinker
When looking for viable candidates to shrink, we only want objects that
are not pinned. However to do so we performed a double iteration over
the vma in the objects, first looking for the pin-count, then looking
for allocations. We can do both at once and be slightly more explicit in
our validity test.
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
---
drivers/gpu/drm/i915/i915_gem_shrinker.c | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_shrinker.c
b/drivers/gpu/drm/i915/i915_gem_shrinker.c
index 3b44ed54cf46..d64c54b329b2 100644
--- a/drivers/gpu/drm/i915/i915_gem_shrinker.c
+++ b/drivers/gpu/drm/i915/i915_gem_shrinker.c
@@ -190,9 +190,12 @@ static int num_vma_bound(struct drm_i915_gem_object *obj)
struct i915_vma *vma;
int count = 0;
- list_for_each_entry(vma, obj-vma_list, vma_link)
+ list_for_each_entry(vma, obj-vma_list, vma_link) {
if (drm_mm_node_allocated(vma-node))
count++;
+ if (vma-pin_count)
+ count++;
+ }
return count;
}
@@ -218,8 +221,7 @@ i915_gem_shrinker_count(struct shrinker *shrinker, struct
shrink_control *sc)
count += obj-base.size PAGE_SHIFT;
list_for_each_entry(obj, dev_priv-mm.bound_list, global_list) {
- if (!i915_gem_obj_is_pinned(obj)
- obj-pages_pin_count == num_vma_bound(obj))
+ if (obj-pages_pin_count == num_vma_bound(obj))
count += obj-base.size PAGE_SHIFT;
}
--
2.1.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
