Re: [Intel-gfx] [PATCH 2/2] drm/i915: allow sync points within batches
On Tue, Sep 02, 2014 at 02:32:41PM -0700, Jesse Barnes wrote:
Use a new reloc type to allow userspace to insert sync points within
batches before they're submitted. The corresponding fence fds are
returned in the offset field of the returned reloc tree, and can be
operated on with the sync fence APIs.
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
---
drivers/gpu/drm/i915/i915_drv.h| 4 +
drivers/gpu/drm/i915/i915_gem_execbuffer.c | 125
-
drivers/gpu/drm/i915/i915_sync.c | 58 ++---
include/uapi/drm/i915_drm.h| 11 ++-
4 files changed, 167 insertions(+), 31 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 6eb119e..410eedf 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2284,6 +2284,10 @@ int i915_sync_init(struct drm_i915_private *dev_priv);
void i915_sync_fini(struct drm_i915_private *dev_priv);
int i915_sync_create_fence_ioctl(struct drm_device *dev, void *data,
struct drm_file *file);
+int i915_sync_fence_create(struct intel_engine_cs *ring,
+struct intel_context *ctx,
+u32 seqno);
+
#define PIN_MAPPABLE 0x1
#define PIN_NONBLOCK 0x2
diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
index 60998fc..32ec599 100644
--- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
@@ -32,6 +32,7 @@
#include i915_trace.h
#include intel_drv.h
#include linux/dma_remapping.h
+#include ../../../staging/android/sync.h
#define __EXEC_OBJECT_HAS_PIN (131)
#define __EXEC_OBJECT_HAS_FENCE (130)
@@ -262,6 +263,67 @@ static inline int use_cpu_reloc(struct
drm_i915_gem_object *obj)
!obj-map_and_fenceable ||
obj-cache_level != I915_CACHE_NONE);
}
+static int
+emit_sync_obj_cpu(struct drm_i915_gem_object *obj,
+ struct drm_i915_gem_relocation_entry *reloc)
+{
+ uint32_t page_offset = offset_in_page(reloc-offset);
+ char *vaddr;
+ int ret;
+
+ ret = i915_gem_object_set_to_cpu_domain(obj, true);
+ if (ret)
+ return ret;
+
+ vaddr = kmap_atomic(i915_gem_object_get_page(obj,
+ reloc-offset PAGE_SHIFT));
+ *(uint32_t *)(vaddr + page_offset) = MI_STORE_DWORD_INDEX;
+ *(uint32_t *)(vaddr + page_offset + 4) =
+ I915_GEM_HWS_INDEX MI_STORE_DWORD_INDEX_SHIFT;
+ *(uint32_t *)(vaddr + page_offset + 8) =
+ obj-ring-outstanding_lazy_seqno;
+ *(uint32_t *)(vaddr + page_offset + 12) = MI_USER_INTERRUPT;
+
+ kunmap_atomic(vaddr);
+
+ return 0;
+}
+
+static int
+emit_sync_obj_gtt(struct drm_i915_gem_object *obj,
+ struct drm_i915_gem_relocation_entry *reloc)
+{
+ struct drm_device *dev = obj-base.dev;
+ struct drm_i915_private *dev_priv = dev-dev_private;
+ uint32_t __iomem *reloc_entry;
+ void __iomem *reloc_page;
+ int ret;
+
+ ret = i915_gem_object_set_to_gtt_domain(obj, true);
+ if (ret)
+ return ret;
+
+ ret = i915_gem_object_put_fence(obj);
+ if (ret)
+ return ret;
+
+ /* Map the page containing the relocation we're going to perform. */
+ reloc-offset += i915_gem_obj_ggtt_offset(obj);
+ reloc_page = io_mapping_map_atomic_wc(dev_priv-gtt.mappable,
+ reloc-offset PAGE_MASK);
+
+ reloc_entry = (uint32_t __iomem *)
+ (reloc_page + offset_in_page(reloc-offset));
+ iowrite32(MI_STORE_DWORD_INDEX, reloc_entry);
+ iowrite32(I915_GEM_HWS_INDEX MI_STORE_DWORD_INDEX_SHIFT,
+ reloc_entry);
+ iowrite32(obj-ring-outstanding_lazy_seqno, reloc_entry);
+ iowrite32(MI_USER_INTERRUPT, reloc_entry);
+
+ io_mapping_unmap_atomic(reloc_page);
These commands are illegal/invalid inside the object, only valid inside
the ring.
+ return 0;
+}
static int
relocate_entry_cpu(struct drm_i915_gem_object *obj,
@@ -349,7 +411,8 @@ relocate_entry_gtt(struct drm_i915_gem_object *obj,
static int
i915_gem_execbuffer_relocate_entry(struct drm_i915_gem_object *obj,
struct eb_vmas *eb,
-struct drm_i915_gem_relocation_entry *reloc)
+struct drm_i915_gem_relocation_entry *reloc,
+struct intel_context *ctx)
Hmm. That's a nuisance. But no, you only use it to automatically create
a fence not to patch the batch, so you can just use an object-flag.
This fits neatly into requests.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
Re: [Intel-gfx] [PATCH 1/2] drm/i915: Android sync points for i915 v2
On Tue, Sep 02, 2014 at 02:32:40PM -0700, Jesse Barnes wrote:
+static int i915_fence_check(wait_queue_t *wait, unsigned mode, int flags,
+ void *key)
+{
+ struct i915_fence *intel_fence = wait-private;
+ struct intel_engine_cs *ring = intel_fence-ring;
+
+ if (!i915_seqno_passed(ring-get_seqno(ring, false),
+intel_fence-seqno))
+ return 0;
+
+ fence_signal_locked(intel_fence-base);
+
+ __remove_wait_queue(ring-irq_queue, wait);
+ fence_put(intel_fence-base);
+ ring-irq_put(ring);
+
+ return 0;
+}
+
+static bool i915_fence_enable_signaling(struct fence *fence)
+{
+ struct i915_fence *intel_fence = to_intel_fence(fence);
+ struct intel_engine_cs *ring = intel_fence-ring;
+ struct drm_i915_private *dev_priv = ring-dev-dev_private;
+ wait_queue_t *wait = intel_fence-wait;
+
+ /* queue fence wait queue on irq queue and get fence */
+ if (i915_seqno_passed(ring-get_seqno(ring, false),
+ intel_fence-seqno) ||
+ i915_terminally_wedged(dev_priv-gpu_error))
+ return false;
+
+ if (!ring-irq_get(ring))
+ return false;
+
+ wait-flags = 0;
+ wait-private = intel_fence;
+ wait-func = i915_fence_check;
+
+ __add_wait_queue(ring-irq_queue, wait);
+ fence_get(fence);
+
+ return true;
+}
This looks like it implements poll().
You should recheck i915_request_complete() after setting up the irq
waiter. Or does struct fence_ops handle that?
-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 2/2] intel/uxa: add MST support.
On Wed, Sep 03, 2014 at 10:43:21AM +1000, Dave Airlie wrote:
@@ -808,6 +815,11 @@ intel_output_attach_edid(xf86OutputPtr output)
xf86MonPtr mon = NULL;
int i;
+ if (!koutput) {
+ xf86OutputSetEDID(output, mon);
+ return;
+ }
+
/* look for an EDID property */
for (i = 0; i koutput-count_props; i++) {
drmModePropertyPtr props;
@@ -897,6 +909,9 @@ intel_output_get_modes(xf86OutputPtr output)
intel_output_attach_edid(output);
+ if (!koutput)
+ return Modes;
+
/* modes should already be available */
for (i = 0; i koutput-count_modes; i++) {
DisplayModePtr Mode;
You don't hook into intel_output_detect() and report disconnected? Oh,
the code will already fail at drmModeGetConector().
So given that the output is disconnected, these two should never be
called?
-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] [drm/i915/3.17] panic in i915_digport_work_func
On Mon, 1 Sep 2014, Daniel Vetter wrote: From d407c946fbf5c48f30160591f5bd71fbe158aeb4 Mon Sep 17 00:00:00 2001 From: Dave Airlie airl...@redhat.com Date: Mon, 1 Sep 2014 16:58:12 +1000 Subject: [PATCH] drm/i915: handle G45/GM45 pulse detection connected state. In the HPD pulse handler we check for long pulses if the port is actually connected, however we do that for IBX, but we use the pulse handling code on GM45 systems as well, so we need to use a diffent check. This patch refactors the digital port connected check out of the g4x detection path and reuses it in the hpd pulse path. Should fix: Message-ID: 1409382202.5141.36.ca...@marge.simpson.net Reported-by: Mike Galbraith umgwanakikb...@gmail.com Signed-off-by: Dave Airlie airl...@redhat.com Reviewed-by: Daniel Vetter daniel.vet...@ffwll.ch I was just about to start bisecting, as my thinkpad x200s with Gen4 chip wouldn't ocassionally boot with -rc3, but this patch seems to be the cure for me as well. FWIW Tested-by: Jiri Kosina jkos...@suse.cz -- Jiri Kosina SUSE Labs ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH -v2 1/4] drm/i915: init sprites with univeral plane init function
On Tue, Sep 02, 2014 at 04:23:44PM -0300, Gustavo Padovan wrote:
From: Derek Foreman derek.fore...@collabora.co.uk
Really just for completeness - old init function ends up making the plane
exactly the same way due to the way the enums are set up.
Signed-off-by: Derek Foreman derek.fore...@collabora.co.uk
Reviewed-by: Ville Syrjälä ville.syrj...@linux.intel.com
---
drivers/gpu/drm/i915/intel_sprite.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_sprite.c
b/drivers/gpu/drm/i915/intel_sprite.c
index 0bdb00b..4cbe286 100644
--- a/drivers/gpu/drm/i915/intel_sprite.c
+++ b/drivers/gpu/drm/i915/intel_sprite.c
@@ -1375,10 +1375,10 @@ intel_plane_init(struct drm_device *dev, enum pipe
pipe, int plane)
intel_plane-plane = plane;
intel_plane-rotation = BIT(DRM_ROTATE_0);
possible_crtcs = (1 pipe);
- ret = drm_plane_init(dev, intel_plane-base, possible_crtcs,
- intel_plane_funcs,
- plane_formats, num_plane_formats,
- false);
+ ret = drm_universal_plane_init(dev, intel_plane-base, possible_crtcs,
+intel_plane_funcs,
+plane_formats, num_plane_formats,
+DRM_PLANE_TYPE_OVERLAY);
if (ret) {
kfree(intel_plane);
goto out;
--
1.9.3
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
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 -v2 3/4] drm/i915: create struct intel_plane_state
On Tue, Sep 02, 2014 at 04:23:46PM -0300, Gustavo Padovan wrote:
From: Gustavo Padovan gustavo.pado...@collabora.co.uk
This new struct will be the storage of src and dst coordinates
between the check and commit stages of a plane update.
Signed-off-by: Gustavo Padovan gustavo.pado...@collabora.co.uk
---
drivers/gpu/drm/i915/intel_drv.h | 20
1 file changed, 20 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_drv.h
b/drivers/gpu/drm/i915/intel_drv.h
index 4ab0d92..59c1675 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -33,6 +33,7 @@
#include drm/drm_crtc_helper.h
#include drm/drm_fb_helper.h
#include drm/drm_dp_mst_helper.h
+#include drm/drm_rect.h
/**
* _wait_for - magic (register) wait macro
@@ -227,6 +228,25 @@ typedef struct dpll {
int p;
} intel_clock_t;
+struct intel_plane_state {
+ struct drm_crtc *crtc;
+ struct drm_framebuffer *fb;
+ int crtc_x;
+ int crtc_y;
+ unsigned int crtc_w;
+ unsigned int crtc_h;
+ uint32_t src_x;
+ uint32_t src_y;
+ uint32_t src_w;
+ uint32_t src_h;
Seems to me we shouldn't need these non-drm_rect coordinates in
this struct. I'll comment a bit more on the next patch since that's
where this is used.
+ struct drm_rect src;
+ struct drm_rect dst;
+ struct drm_rect clip;
+ struct drm_rect orig_src;
+ struct drm_rect orig_dst;
+ bool visible;
+};
+
struct intel_plane_config {
bool tiled;
int size;
--
1.9.3
___
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 2/5] drm/i915/dp: Cache EDID for a detection cycle
On Tue, 02 Sep 2014, Chris Wilson ch...@chris-wilson.co.uk wrote: @@ -3819,27 +3819,55 @@ intel_dp_get_edid(struct drm_connector *connector, struct i2c_adapter *adapter) return NULL; return drm_edid_duplicate(intel_connector-edid); - } + } else + return drm_get_edid(intel_connector-base, + intel_dp-aux.ddc); Nitpick, I'd like to see braces on all branches if one branch requires them. Also CodingStyle. 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] DVFS in Intel graphic chips
Adding relevant mailing lists, please don't send me i915 related mails in private. On Tue, Sep 2, 2014 at 11:52 PM, Hadi am.h...@gmail.com wrote: Dear Daniel, I am PhD student in UW-Madison. I have a question about Intel i915 and I was wondering if you could possibly answer it. I have worked with Intel CPU DVFS (dynamic voltage and frequency scaling), and also cpuidle driver (for changing c-states). I was wondering if the same thing could be done on Intel graphic chips (changing frequency and sleep states for gpu). As far as I understood from the datasheet, turning off different parts of Intel gpu can only be done internally (sleep states), so is there any way to change the frequency? At least on all recent intel gpus supported by the i915 driver it's possible and we do it. In sysfs there's files to set the min/max frequencies the driver is allowed to select. By default we scale (depending upon the load) over the full frequency range the gpu supports. If you want to read up on the driver code for this grep for rps - that should dig up all the relevant stuff. Unfortunately this isn't documented in the public prm. Cheers, Daniel Thank you Hadi Asgharimoghaddam Research Assistant at UW-Madison -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - 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 -v2 1/4] drm/i915: init sprites with univeral plane init function
On Wed, Sep 03, 2014 at 11:18:27AM +0300, Ville Syrjälä wrote:
On Tue, Sep 02, 2014 at 04:23:44PM -0300, Gustavo Padovan wrote:
From: Derek Foreman derek.fore...@collabora.co.uk
Really just for completeness - old init function ends up making the plane
exactly the same way due to the way the enums are set up.
Signed-off-by: Derek Foreman derek.fore...@collabora.co.uk
Reviewed-by: Ville Syrjälä ville.syrj...@linux.intel.com
Queued for -next, thanks for the patch.
-Daniel
---
drivers/gpu/drm/i915/intel_sprite.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_sprite.c
b/drivers/gpu/drm/i915/intel_sprite.c
index 0bdb00b..4cbe286 100644
--- a/drivers/gpu/drm/i915/intel_sprite.c
+++ b/drivers/gpu/drm/i915/intel_sprite.c
@@ -1375,10 +1375,10 @@ intel_plane_init(struct drm_device *dev, enum pipe
pipe, int plane)
intel_plane-plane = plane;
intel_plane-rotation = BIT(DRM_ROTATE_0);
possible_crtcs = (1 pipe);
- ret = drm_plane_init(dev, intel_plane-base, possible_crtcs,
-intel_plane_funcs,
-plane_formats, num_plane_formats,
-false);
+ ret = drm_universal_plane_init(dev, intel_plane-base, possible_crtcs,
+ intel_plane_funcs,
+ plane_formats, num_plane_formats,
+ DRM_PLANE_TYPE_OVERLAY);
if (ret) {
kfree(intel_plane);
goto out;
--
1.9.3
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Ville Syrjälä
Intel OTC
___
dri-devel mailing list
dri-de...@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - 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 -v2 1/4] drm/i915: init sprites with univeral plane init function
On Wed, Sep 03, 2014 at 11:18:27AM +0300, Ville Syrjälä wrote: On Tue, Sep 02, 2014 at 04:23:44PM -0300, Gustavo Padovan wrote: From: Derek Foreman derek.fore...@collabora.co.uk Really just for completeness - old init function ends up making the plane exactly the same way due to the way the enums are set up. Signed-off-by: Derek Foreman derek.fore...@collabora.co.uk Reviewed-by: Ville Syrjälä ville.syrj...@linux.intel.com Queued for -next, thanks for the patch. And patch 2 is already merged from the previous round. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - 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/edid: Reduce horizontal timings for pixel replicated modes
On Tue, Sep 02, 2014 at 05:03:35PM -0700, clinton.a.tay...@intel.com wrote:
From: Clint Taylor clinton.a.tay...@intel.com
Pixel replicated modes should be non-2x horizontal timings and pixel
replicated by the HW across the HDMI cable at 2X pixel clock. Current
horizontal resolution of 1440 does not allow pixel duplication to
occur and scaling artifacts occur on the TV. HDMI certification
7-26 currently fails for all pixel replicated modes. This change will
allow HDMI certification with 480i/576i modes once pixel replication
is turned on.
Signed-off-by: Clint Taylor clinton.a.tay...@intel.com
Cc: Daniel Vetter daniel.vet...@ffwll.ch
Cc: Ville Syrjälä ville.syrj...@linux.intel.com
Reviewed-by: Ville Syrjälä ville.syrj...@linux.intel.com
Patch is missing the per-patch revision log and the cover letter also
doesn't have anything. Please remember to add that the next time around.
Anyway, patches merged to topic/core-stuff to make sure they don't get
lost.
Thanks, Daniel
---
drivers/gpu/drm/drm_edid.c | 96
++--
1 file changed, 48 insertions(+), 48 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index daf3cd8..1bdbfd0 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -632,27 +632,27 @@ static const struct drm_display_mode edid_cea_modes[] =
{
DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC |
DRM_MODE_FLAG_INTERLACE),
.vrefresh = 60, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_16_9, },
- /* 6 - 1440x480i@60Hz */
- { DRM_MODE(1440x480i, DRM_MODE_TYPE_DRIVER, 27000, 1440, 1478,
-1602, 1716, 0, 480, 488, 494, 525, 0,
+ /* 6 - 720(1440)x480i@60Hz */
+ { DRM_MODE(720x480i, DRM_MODE_TYPE_DRIVER, 13500, 720, 739,
+801, 858, 0, 480, 488, 494, 525, 0,
DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_NVSYNC |
DRM_MODE_FLAG_INTERLACE | DRM_MODE_FLAG_DBLCLK),
.vrefresh = 60, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_4_3, },
- /* 7 - 1440x480i@60Hz */
- { DRM_MODE(1440x480i, DRM_MODE_TYPE_DRIVER, 27000, 1440, 1478,
-1602, 1716, 0, 480, 488, 494, 525, 0,
+ /* 7 - 720(1440)x480i@60Hz */
+ { DRM_MODE(720x480i, DRM_MODE_TYPE_DRIVER, 13500, 720, 739,
+801, 858, 0, 480, 488, 494, 525, 0,
DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_NVSYNC |
DRM_MODE_FLAG_INTERLACE | DRM_MODE_FLAG_DBLCLK),
.vrefresh = 60, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_16_9, },
- /* 8 - 1440x240@60Hz */
- { DRM_MODE(1440x240, DRM_MODE_TYPE_DRIVER, 27000, 1440, 1478,
-1602, 1716, 0, 240, 244, 247, 262, 0,
+ /* 8 - 720(1440)x240@60Hz */
+ { DRM_MODE(720x240, DRM_MODE_TYPE_DRIVER, 13500, 720, 739,
+801, 858, 0, 240, 244, 247, 262, 0,
DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_NVSYNC |
DRM_MODE_FLAG_DBLCLK),
.vrefresh = 60, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_4_3, },
- /* 9 - 1440x240@60Hz */
- { DRM_MODE(1440x240, DRM_MODE_TYPE_DRIVER, 27000, 1440, 1478,
-1602, 1716, 0, 240, 244, 247, 262, 0,
+ /* 9 - 720(1440)x240@60Hz */
+ { DRM_MODE(720x240, DRM_MODE_TYPE_DRIVER, 13500, 720, 739,
+801, 858, 0, 240, 244, 247, 262, 0,
DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_NVSYNC |
DRM_MODE_FLAG_DBLCLK),
.vrefresh = 60, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_16_9, },
@@ -714,27 +714,27 @@ static const struct drm_display_mode edid_cea_modes[] =
{
DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC |
DRM_MODE_FLAG_INTERLACE),
.vrefresh = 50, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_16_9, },
- /* 21 - 1440x576i@50Hz */
- { DRM_MODE(1440x576i, DRM_MODE_TYPE_DRIVER, 27000, 1440, 1464,
-1590, 1728, 0, 576, 580, 586, 625, 0,
+ /* 21 - 720(1440)x576i@50Hz */
+ { DRM_MODE(720x576i, DRM_MODE_TYPE_DRIVER, 13500, 720, 732,
+795, 864, 0, 576, 580, 586, 625, 0,
DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_NVSYNC |
DRM_MODE_FLAG_INTERLACE | DRM_MODE_FLAG_DBLCLK),
.vrefresh = 50, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_4_3, },
- /* 22 - 1440x576i@50Hz */
- { DRM_MODE(1440x576i, DRM_MODE_TYPE_DRIVER, 27000, 1440, 1464,
-1590, 1728, 0, 576, 580, 586, 625, 0,
+ /* 22 - 720(1440)x576i@50Hz */
+ { DRM_MODE(720x576i, DRM_MODE_TYPE_DRIVER, 13500, 720, 732,
+795, 864, 0, 576, 580, 586, 625, 0,
DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_NVSYNC |
DRM_MODE_FLAG_INTERLACE | DRM_MODE_FLAG_DBLCLK),
.vrefresh = 50, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_16_9, },
- /* 23 -
Re: [Intel-gfx] [PATCH -v2 4/4] drm/i915: split intel_update_plane into check() and commit()
On Tue, Sep 02, 2014 at 04:23:47PM -0300, Gustavo Padovan wrote:
From: Gustavo Padovan gustavo.pado...@collabora.co.uk
Due to the upcoming atomic modesetting feature we need to separate
some update functions into a check step that can fail and a commit
step that should, ideally, never fail.
This commit splits intel_update_plane() and its commit part can still
fail due to the fb pinning procedure.
v2: use the new struct intel_plane_state to store information
between check and commit stages.
Signed-off-by: Gustavo Padovan gustavo.pado...@collabora.co.uk
---
drivers/gpu/drm/i915/intel_sprite.c | 236
++--
1 file changed, 146 insertions(+), 90 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_sprite.c
b/drivers/gpu/drm/i915/intel_sprite.c
index 4cbe286..062eca2 100644
--- a/drivers/gpu/drm/i915/intel_sprite.c
+++ b/drivers/gpu/drm/i915/intel_sprite.c
@@ -845,57 +845,28 @@ static bool colorkey_enabled(struct intel_plane
*intel_plane)
}
static int
-intel_update_plane(struct drm_plane *plane, struct drm_crtc *crtc,
-struct drm_framebuffer *fb, int crtc_x, int crtc_y,
-unsigned int crtc_w, unsigned int crtc_h,
-uint32_t src_x, uint32_t src_y,
-uint32_t src_w, uint32_t src_h)
+intel_check_sprite_plane(struct drm_plane *plane,
+ struct intel_plane_state *pstate)
pstate looks a bit funny. Makes me think on cpu pstates. Maybe just call
it 'state' everywhere?
{
- struct drm_device *dev = plane-dev;
- struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
+ struct intel_crtc *intel_crtc = to_intel_crtc(pstate-crtc);
struct intel_plane *intel_plane = to_intel_plane(plane);
- enum pipe pipe = intel_crtc-pipe;
+ struct drm_framebuffer *fb = pstate-fb;
struct intel_framebuffer *intel_fb = to_intel_framebuffer(fb);
struct drm_i915_gem_object *obj = intel_fb-obj;
- struct drm_i915_gem_object *old_obj = intel_plane-obj;
- int ret;
- bool primary_enabled;
- bool visible;
+ int crtc_x = pstate-crtc_x;
+ int crtc_y = pstate-crtc_y;
+ int crtc_w = pstate-crtc_w;
+ int crtc_h = pstate-crtc_h;
+ int src_x = pstate-src_x;
+ int src_y = pstate-src_y;
+ int src_w = pstate-src_w;
+ int src_h = pstate-src_h;
AFAICS we don't need to initialize this stuff here. We already populate
it all before we need it further down. So I think the only thing we need
is add a bit of code to write the src_? coordinates back into
pstate-src (at the end of check() like you already do for the dst
coordinates). To avoid warning about unitialized variables that
probably needs to be wrapped in an 'if (visible)' check.
+ struct drm_rect *src = pstate-src;
+ struct drm_rect *dst = pstate-dst;
+ struct drm_rect *clip = pstate-clip;
Please keep 'clip' const here to prevent silly accidents.
int hscale, vscale;
int max_scale, min_scale;
int pixel_size = drm_format_plane_cpp(fb-pixel_format, 0);
- struct drm_rect src = {
- /* sample coordinates in 16.16 fixed point */
- .x1 = src_x,
- .x2 = src_x + src_w,
- .y1 = src_y,
- .y2 = src_y + src_h,
- };
- struct drm_rect dst = {
- /* integer pixels */
- .x1 = crtc_x,
- .x2 = crtc_x + crtc_w,
- .y1 = crtc_y,
- .y2 = crtc_y + crtc_h,
- };
- const struct drm_rect clip = {
- .x2 = intel_crtc-active ? intel_crtc-config.pipe_src_w : 0,
- .y2 = intel_crtc-active ? intel_crtc-config.pipe_src_h : 0,
- };
- const struct {
- int crtc_x, crtc_y;
- unsigned int crtc_w, crtc_h;
- uint32_t src_x, src_y, src_w, src_h;
- } orig = {
- .crtc_x = crtc_x,
- .crtc_y = crtc_y,
- .crtc_w = crtc_w,
- .crtc_h = crtc_h,
- .src_x = src_x,
- .src_y = src_y,
- .src_w = src_w,
- .src_h = src_h,
- };
/* Don't modify another pipe's plane */
if (intel_plane-pipe != intel_crtc-pipe) {
@@ -927,55 +898,55 @@ intel_update_plane(struct drm_plane *plane, struct
drm_crtc *crtc,
max_scale = intel_plane-max_downscale 16;
min_scale = intel_plane-can_scale ? 1 : (1 16);
- drm_rect_rotate(src, fb-width 16, fb-height 16,
+ drm_rect_rotate(src, fb-width 16, fb-height 16,
intel_plane-rotation);
- hscale = drm_rect_calc_hscale_relaxed(src, dst, min_scale, max_scale);
+ hscale = drm_rect_calc_hscale_relaxed(src, dst, min_scale, max_scale);
BUG_ON(hscale 0);
- vscale = drm_rect_calc_vscale_relaxed(src, dst, min_scale, max_scale);
+ vscale = drm_rect_calc_vscale_relaxed(src, dst, min_scale, max_scale);
Re: [Intel-gfx] [PATCH 2/5] drm/i915/dp: Cache EDID for a detection cycle
On Wed, Sep 03, 2014 at 11:23:09AM +0300, Jani Nikula wrote: On Tue, 02 Sep 2014, Chris Wilson ch...@chris-wilson.co.uk wrote: @@ -3819,27 +3819,55 @@ intel_dp_get_edid(struct drm_connector *connector, struct i2c_adapter *adapter) return NULL; return drm_edid_duplicate(intel_connector-edid); - } + } else + return drm_get_edid(intel_connector-base, + intel_dp-aux.ddc); Nitpick, I'd like to see braces on all branches if one branch requires them. Also CodingStyle. This is actually one of the case where I tend to routinely ignore checkpatch and CodingStyle. We're already super-inconsistent about it at least, so I'm not terribly fond of enforcing it. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - 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 4/5] drm/i915/hdmi: Refactor force_audio - has_audio coupling
On Tue, Sep 02, 2014 at 08:08:20PM +0100, Chris Wilson wrote:
On Tue, Sep 02, 2014 at 08:04:02PM +0100, Chris Wilson wrote:
The routines for deciding whether we have audio (depending upon
force_audio and the associated EDID) are common between detection and
set-property. Refactor the code to remove the duplication.
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
---
drivers/gpu/drm/i915/intel_hdmi.c | 60
++-
1 file changed, 27 insertions(+), 33 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_hdmi.c
b/drivers/gpu/drm/i915/intel_hdmi.c
index 3b21a769ef54..ad7b523d39a8 100644
--- a/drivers/gpu/drm/i915/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/intel_hdmi.c
@@ -976,6 +976,30 @@ intel_hdmi_unset_edid(struct drm_connector *connector)
}
static bool
+intel_hdmi_update_audio(struct drm_connector *connector)
+{
+ struct intel_hdmi *intel_hdmi = intel_attached_hdmi(connector);
+ struct edid *edid = to_intel_connector(connector)-detect_edid;
+ bool has_audio, has_sink;
+ bool changed = false;
+
+ if (intel_hdmi-force_audio == HDMI_AUDIO_AUTO)
+ has_audio = drm_detect_monitor_audio(edid);
+ else
+ has_audio = intel_hdmi-force_audio == HDMI_AUDIO_ON;
+ changed |= intel_hdmi-has_audio |= has_audio;
Oh dear, it is obviously time to give up.
Aside of that I like the general direction, since we need to refactor this
stuff a bit anyway to make Thomas' EDID injection work for audio. And
hopefully we'll have atomic modeset this century so that we can finally
ditch all that fragile has this set_prop resulted in an actual change
logic ...
Pulled in the first 3 patches from this series, thanks.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - 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: change CHV write_eld/global_resources function pointers
On Tue, Sep 02, 2014 at 04:53:57PM -0300, Paulo Zanoni wrote:
From: Paulo Zanoni paulo.r.zan...@intel.com
Currently, CHV is using the same functions as HSW/BDW instead of the
same functions as VLV. This looks wrong, especially since, for
example, valleyview_modeset_global_resouces even has an IS_CHERRYVIEW
check.
This patch has the potential to fix display audio and the CHV CDCLK.
Cc: Ville Syrjälä ville.syrj...@linux.intel.com
Signed-off-by: Paulo Zanoni paulo.r.zan...@intel.com
Whoops. These things seem to slip through a lot. I can imediately
spot another IS_GEN8 fumble with intel_frontbuffer_flush().
Anyway this patch is:
Reviewed-by: Ville Syrjälä ville.syrj...@linux.intel.com
---
drivers/gpu/drm/i915/intel_display.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
This is completely untested! But maybe it should go to fixes/stable.
Yes. -fixes at least so we get it into 3.17. I'll spin it up on my bsw
and make sure it doesn't explode in some unforseen way.
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index c092ff4..e6cae59 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -12550,7 +12550,7 @@ static void intel_init_display(struct drm_device *dev)
dev_priv-display.write_eld = ironlake_write_eld;
dev_priv-display.modeset_global_resources =
ivb_modeset_global_resources;
- } else if (IS_HASWELL(dev) || IS_GEN8(dev)) {
+ } else if (IS_HASWELL(dev) || IS_BROADWELL(dev)) {
dev_priv-display.fdi_link_train = hsw_fdi_link_train;
dev_priv-display.write_eld = haswell_write_eld;
dev_priv-display.modeset_global_resources =
--
2.1.0
--
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 2/5] drm/i915/dp: Cache EDID for a detection cycle
On Wed, Sep 03, 2014 at 11:23:09AM +0300, Jani Nikula wrote: On Tue, 02 Sep 2014, Chris Wilson ch...@chris-wilson.co.uk wrote: @@ -3819,27 +3819,55 @@ intel_dp_get_edid(struct drm_connector *connector, struct i2c_adapter *adapter) return NULL; return drm_edid_duplicate(intel_connector-edid); - } + } else + return drm_get_edid(intel_connector-base, + intel_dp-aux.ddc); Nitpick, I'd like to see braces on all branches if one branch requires them. Also CodingStyle. It's one instance where CodingStyle doesn't match a dominant pattern in the kernel. After all it's a fairly recent addition in 2007 and they haven't won the flame war yet. -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: change CHV write_eld/global_resources function pointers
On Wed, Sep 03, 2014 at 11:52:43AM +0300, Ville Syrjälä wrote:
On Tue, Sep 02, 2014 at 04:53:57PM -0300, Paulo Zanoni wrote:
From: Paulo Zanoni paulo.r.zan...@intel.com
Currently, CHV is using the same functions as HSW/BDW instead of the
same functions as VLV. This looks wrong, especially since, for
example, valleyview_modeset_global_resouces even has an IS_CHERRYVIEW
check.
This patch has the potential to fix display audio and the CHV CDCLK.
Cc: Ville Syrjälä ville.syrj...@linux.intel.com
Signed-off-by: Paulo Zanoni paulo.r.zan...@intel.com
Whoops. These things seem to slip through a lot. I can imediately
spot another IS_GEN8 fumble with intel_frontbuffer_flush().
Anyway this patch is:
Reviewed-by: Ville Syrjälä ville.syrj...@linux.intel.com
---
drivers/gpu/drm/i915/intel_display.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
This is completely untested! But maybe it should go to fixes/stable.
Yes. -fixes at least so we get it into 3.17. I'll spin it up on my bsw
and make sure it doesn't explode in some unforseen way.
chv is still hidden behind the preliminary_hw flag, so no need for -fixes.
But we need the patch to remove this flag asap since the 3.18 merge window
will close roughly this week (if Dave really puts through his stance on
closing drm-next when -rc5 hits the streets).
Queued for -next, thanks for the patch.
-Daniel
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index c092ff4..e6cae59 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -12550,7 +12550,7 @@ static void intel_init_display(struct drm_device
*dev)
dev_priv-display.write_eld = ironlake_write_eld;
dev_priv-display.modeset_global_resources =
ivb_modeset_global_resources;
- } else if (IS_HASWELL(dev) || IS_GEN8(dev)) {
+ } else if (IS_HASWELL(dev) || IS_BROADWELL(dev)) {
dev_priv-display.fdi_link_train = hsw_fdi_link_train;
dev_priv-display.write_eld = haswell_write_eld;
dev_priv-display.modeset_global_resources =
--
2.1.0
--
Ville Syrjälä
Intel OTC
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - 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 igt] gem_workarounds: intel_wa_registers is now prefixed with i915
On 30/08/2014 22:46, Damien Lespiau wrote: Signed-off-by: Damien Lespiau damien.lesp...@intel.com --- tests/gem_workarounds.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tests/gem_workarounds.c b/tests/gem_workarounds.c index 6826562..32156d2 100644 --- a/tests/gem_workarounds.c +++ b/tests/gem_workarounds.c @@ -184,7 +184,7 @@ igt_main devid = intel_get_drm_devid(drm_fd); batch = intel_batchbuffer_alloc(bufmgr, devid); - fd = igt_debugfs_open(intel_wa_registers, O_RDONLY); + fd = igt_debugfs_open(i915_wa_registers, O_RDONLY); igt_assert(fd = 0); file = fdopen(fd, r); Reviewed-by: Arun Siluvery arun.siluv...@linux.intel.com regards Arun ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 0/5] A few fixes on top of the wa_regs patches
On 30/08/2014 16:50, Damien Lespiau wrote: Hi Arun, I've compiled a few patches that I think solve some small-ish issues around your wa_regs series. Could you please have a look at them and comment/give your r-b tag if you judge appropriate? On top of those patches, I'd love some comments on the issues I raised in the other mail and possible follow up patches to address them. http://lists.freedesktop.org/archives/intel-gfx/2014-August/051514.html At some point, we'll also need a bit of coherence with what Mika has been doing: http://lists.freedesktop.org/archives/intel-gfx/2014-August/05.html Hi Daniel, Since the new workaround design/implementation takes time could you please pull the patches in this series to fix the issues and also the patch to change filename in igt. for the series, Reviewed-by: Arun Siluvery arun.siluv...@linux.intel.com regards Arun ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2] drm/i915: Sysfs interface to get GFX shmem usage stats per process
From: Sourab Gupta sourab.gu...@intel.com
Currently the Graphics Driver provides an interface through which
one can get a snapshot of the overall Graphics memory consumption.
Also there is an interface available, which provides information
about the several memory related attributes of every single Graphics
buffer created by the various clients.
There is a requirement of a new interface for achieving below
functionalities:
1) Need to provide Client based detailed information about the
distribution of Graphics memory
2) Need to provide an interface which can provide info about the
sharing of Graphics buffers between the clients.
The client based interface would also aid in debugging of
memory usage/consumption by each client debug memleak related issues.
With this new interface,
1) In case of memleak scenarios, we can easily zero in on the culprit
client which is unexpectedly holding on the Graphics buffers for an
inordinate amount of time.
2) We can get an estimate of the instantaneous memory footprint of
every Graphics client.
3) We can now trace all the processes sharing a particular Graphics buffer.
By means of this patch we try to provide a sysfs interface to achieve
the mentioned functionalities.
There are two files created in sysfs:
'i915_gem_meminfo' will provide summary of the graphics resources used by
each graphics client.
'i915_gem_objinfo' will provide detailed view of each object created by
individual clients.
v2: Changes made for
- adding support to report user virtual addresses of mapped buffers
- replacing pid based reporting with tgid based one
- checkpatch and other misc cleanup
Signed-off-by: Sourab Gupta sourab.gu...@intel.com
Signed-off-by: Akash Goel akash.g...@intel.com
---
drivers/gpu/drm/i915/i915_dma.c | 1 +
drivers/gpu/drm/i915/i915_drv.c | 2 +
drivers/gpu/drm/i915/i915_drv.h | 26 ++
drivers/gpu/drm/i915/i915_gem.c | 169 ++-
drivers/gpu/drm/i915/i915_gem_debug.c | 542 ++
drivers/gpu/drm/i915/i915_gpu_error.c | 2 +-
drivers/gpu/drm/i915/i915_sysfs.c | 83 ++
7 files changed, 822 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
index a58fed9..7ea3250 100644
--- a/drivers/gpu/drm/i915/i915_dma.c
+++ b/drivers/gpu/drm/i915/i915_dma.c
@@ -1985,6 +1985,7 @@ void i915_driver_postclose(struct drm_device *dev, struct
drm_file *file)
{
struct drm_i915_file_private *file_priv = file-driver_priv;
+ kfree(file_priv-process_name);
if (file_priv file_priv-bsd_ring)
file_priv-bsd_ring = NULL;
kfree(file_priv);
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 1d6d9ac..9bee20e 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -1628,6 +1628,8 @@ static struct drm_driver driver = {
.debugfs_init = i915_debugfs_init,
.debugfs_cleanup = i915_debugfs_cleanup,
#endif
+ .gem_open_object = i915_gem_open_object,
+ .gem_close_object = i915_gem_close_object,
.gem_free_object = i915_gem_free_object,
.gem_vm_ops = i915_gem_vm_ops,
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 36f3da6..43ba7c4 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1765,6 +1765,11 @@ struct drm_i915_gem_object_ops {
#define INTEL_FRONTBUFFER_ALL_MASK(pipe) \
(0xf (INTEL_FRONTBUFFER_BITS_PER_PIPE * (pipe)))
+struct drm_i915_obj_virt_addr {
+ struct list_head head;
+ unsigned long user_virt_addr;
+};
+
struct drm_i915_gem_object {
struct drm_gem_object base;
@@ -1890,6 +1895,13 @@ struct drm_i915_gem_object {
struct work_struct *work;
} userptr;
};
+
+#define MAX_OPEN_HANDLE 20
+ struct {
+ struct list_head virt_addr_head;
+ pid_t pid;
+ int open_handle_count;
+ } pid_array[MAX_OPEN_HANDLE];
};
#define to_intel_bo(x) container_of(x, struct drm_i915_gem_object, base)
@@ -1940,6 +1952,8 @@ struct drm_i915_gem_request {
struct drm_i915_file_private {
struct drm_i915_private *dev_priv;
struct drm_file *file;
+ char *process_name;
+ struct pid *tgid;
struct {
spinlock_t lock;
@@ -2370,6 +2384,10 @@ void i915_init_vm(struct drm_i915_private *dev_priv,
struct i915_address_space *vm);
void i915_gem_free_object(struct drm_gem_object *obj);
void i915_gem_vma_destroy(struct i915_vma *vma);
+int i915_gem_open_object(struct drm_gem_object *gem_obj,
+ struct drm_file *file_priv);
+int i915_gem_close_object(struct drm_gem_object *gem_obj,
+ struct drm_file *file_priv);
#define PIN_MAPPABLE 0x1
#define PIN_NONBLOCK 0x2
@@ -2420,6 +2438,8 @@ int i915_gem_dumb_create(struct drm_file
Re: [Intel-gfx] [PATCH -v2 1/4] drm/i915: init sprites with univeral plane init function
On Wed, Sep 03, 2014 at 10:38:17AM +0200, Daniel Vetter wrote: On Wed, Sep 03, 2014 at 11:18:27AM +0300, Ville Syrjälä wrote: On Tue, Sep 02, 2014 at 04:23:44PM -0300, Gustavo Padovan wrote: From: Derek Foreman derek.fore...@collabora.co.uk Really just for completeness - old init function ends up making the plane exactly the same way due to the way the enums are set up. Signed-off-by: Derek Foreman derek.fore...@collabora.co.uk Reviewed-by: Ville Syrjälä ville.syrj...@linux.intel.com Queued for -next, thanks for the patch. And patch 2 is already merged from the previous round. Actually I can't merge this patch since it's not authered by you, but is missing your signed-off-by line. Please resend with that fixed, thanks. If you handle a patch for the linux kernel, you _always_ have to add your sob in accordance with the Developer's Certificate of Origin. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - 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/5] A few fixes on top of the wa_regs patches
On Wed, Sep 03, 2014 at 10:18:47AM +0100, Siluvery, Arun wrote: On 30/08/2014 16:50, Damien Lespiau wrote: Hi Arun, I've compiled a few patches that I think solve some small-ish issues around your wa_regs series. Could you please have a look at them and comment/give your r-b tag if you judge appropriate? On top of those patches, I'd love some comments on the issues I raised in the other mail and possible follow up patches to address them. http://lists.freedesktop.org/archives/intel-gfx/2014-August/051514.html At some point, we'll also need a bit of coherence with what Mika has been doing: http://lists.freedesktop.org/archives/intel-gfx/2014-August/05.html Hi Daniel, Since the new workaround design/implementation takes time could you please pull the patches in this series to fix the issues and also the patch to change filename in igt. Yes this is the best approach since clarifying what exactly the full blown w/a infrastructure should do will take a bit of time. for the series, Reviewed-by: Arun Siluvery arun.siluv...@linux.intel.com Thanks, Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - 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/5] drm/i915/dp: Cache EDID for a detection cycle
On Wed, 03 Sep 2014, Chris Wilson ch...@chris-wilson.co.uk wrote: On Wed, Sep 03, 2014 at 11:23:09AM +0300, Jani Nikula wrote: On Tue, 02 Sep 2014, Chris Wilson ch...@chris-wilson.co.uk wrote: @@ -3819,27 +3819,55 @@ intel_dp_get_edid(struct drm_connector *connector, struct i2c_adapter *adapter) return NULL; return drm_edid_duplicate(intel_connector-edid); - } + } else + return drm_get_edid(intel_connector-base, + intel_dp-aux.ddc); Nitpick, I'd like to see braces on all branches if one branch requires them. Also CodingStyle. It's one instance where CodingStyle doesn't match a dominant pattern in the kernel. After all it's a fairly recent addition in 2007 and they haven't won the flame war yet. As I tried to express, it is secondary to me what CodingStyle and checkpatch.pl say; my personal preference would be to have braces on all branches if one branch requires them. No use arguing further on it. Carry on. BR, Jani. -Chris -- Chris Wilson, Intel Open Source Technology Centre -- Jani Nikula, Intel Open Source Technology Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] NEWS: Updates in anticipation of the next release
Signed-off-by: Daniel Vetter daniel.vet...@intel.com --- NEWS | 21 + 1 file changed, 21 insertions(+) diff --git a/NEWS b/NEWS index de1f89ec97e2..e0ab2cc0e9e4 100644 --- a/NEWS +++ b/NEWS @@ -19,6 +19,27 @@ Release 1.8 (-xx-xx) - New commit functions for igt_kms to support the new universal planes interfaces (Matt Roper). +- Polish the debug output when test requirements aren't met a bit and inject the + program name/subtest in dmesg for easier backtrace/oom debugging (Chris). + +- A bit of polish for the framebuffer helper functions (Damien). + +- Robuster option parsing helpers, they now check for conflicts when merging + different option lists (Thomas). + +- MIPI DSI vbt support in intel_bios_read (Gaurav K Singh). + +- Clarify the split between low-level helpers and the high-level library in + igt_kms a bit by renaming some functions and improving and extending the api + documentation. + +- Helper to restore the vt mode, useful to test lastclose/fbdev emulation + behaviour (Thomas). + +- Refactor the support for 64bit relocs. By specifying the number of relocations + explicit a lot of the gen8 checks can be removed from simple testcases which + only use the blitter (Chris). + Release 1.7 (2014-06-09) -- 2.0.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Rename global latency_ns variable
We use the variable name latency_ns in both the local lowlevel wm
calculation routines and at the global level. Rename the global value to
reduce shadow warnings and future confusion.
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
---
drivers/gpu/drm/i915/intel_pm.c | 36 ++--
1 file changed, 18 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index a2340e87dd20..425d5e4052ae 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -872,7 +872,7 @@ void intel_set_memory_cxsr(struct drm_i915_private
*dev_priv, bool enable)
* A value of 5us seems to be a good balance; safe for very low end
* platforms but not overly aggressive on lower latency configs.
*/
-static const int latency_ns = 5000;
+static const int pessimal_latency_ns = 5000;
static int i9xx_get_fifo_size(struct drm_device *dev, int plane)
{
@@ -1387,14 +1387,14 @@ static void valleyview_update_wm(struct drm_crtc *crtc)
vlv_update_drain_latency(crtc);
if (g4x_compute_wm0(dev, PIPE_A,
- valleyview_wm_info, latency_ns,
- valleyview_cursor_wm_info, latency_ns,
+ valleyview_wm_info, pessimal_latency_ns,
+ valleyview_cursor_wm_info, pessimal_latency_ns,
planea_wm, cursora_wm))
enabled |= 1 PIPE_A;
if (g4x_compute_wm0(dev, PIPE_B,
- valleyview_wm_info, latency_ns,
- valleyview_cursor_wm_info, latency_ns,
+ valleyview_wm_info, pessimal_latency_ns,
+ valleyview_cursor_wm_info, pessimal_latency_ns,
planeb_wm, cursorb_wm))
enabled |= 1 PIPE_B;
@@ -1453,20 +1453,20 @@ static void cherryview_update_wm(struct drm_crtc *crtc)
vlv_update_drain_latency(crtc);
if (g4x_compute_wm0(dev, PIPE_A,
- valleyview_wm_info, latency_ns,
- valleyview_cursor_wm_info, latency_ns,
+ valleyview_wm_info, pessimal_latency_ns,
+ valleyview_cursor_wm_info, pessimal_latency_ns,
planea_wm, cursora_wm))
enabled |= 1 PIPE_A;
if (g4x_compute_wm0(dev, PIPE_B,
- valleyview_wm_info, latency_ns,
- valleyview_cursor_wm_info, latency_ns,
+ valleyview_wm_info, pessimal_latency_ns,
+ valleyview_cursor_wm_info, pessimal_latency_ns,
planeb_wm, cursorb_wm))
enabled |= 1 PIPE_B;
if (g4x_compute_wm0(dev, PIPE_C,
- valleyview_wm_info, latency_ns,
- valleyview_cursor_wm_info, latency_ns,
+ valleyview_wm_info, pessimal_latency_ns,
+ valleyview_cursor_wm_info, pessimal_latency_ns,
planec_wm, cursorc_wm))
enabled |= 1 PIPE_C;
@@ -1559,14 +1559,14 @@ static void g4x_update_wm(struct drm_crtc *crtc)
bool cxsr_enabled;
if (g4x_compute_wm0(dev, PIPE_A,
- g4x_wm_info, latency_ns,
- g4x_cursor_wm_info, latency_ns,
+ g4x_wm_info, pessimal_latency_ns,
+ g4x_cursor_wm_info, pessimal_latency_ns,
planea_wm, cursora_wm))
enabled |= 1 PIPE_A;
if (g4x_compute_wm0(dev, PIPE_B,
- g4x_wm_info, latency_ns,
- g4x_cursor_wm_info, latency_ns,
+ g4x_wm_info, pessimal_latency_ns,
+ g4x_cursor_wm_info, pessimal_latency_ns,
planeb_wm, cursorb_wm))
enabled |= 1 PIPE_B;
@@ -1709,7 +1709,7 @@ static void i9xx_update_wm(struct drm_crtc *unused_crtc)
adjusted_mode = to_intel_crtc(crtc)-config.adjusted_mode;
planea_wm = intel_calculate_wm(adjusted_mode-crtc_clock,
wm_info, fifo_size, cpp,
- latency_ns);
+ pessimal_latency_ns);
enabled = crtc;
} else {
planea_wm = fifo_size - wm_info-guard_size;
@@ -1731,7 +1731,7 @@ static void i9xx_update_wm(struct drm_crtc *unused_crtc)
adjusted_mode = to_intel_crtc(crtc)-config.adjusted_mode;
planeb_wm = intel_calculate_wm(adjusted_mode-crtc_clock,
wm_info, fifo_size, cpp,
- latency_ns);
+
Re: [Intel-gfx] [PATCH v2] drm/i915: Sysfs interface to get GFX shmem usage stats per process
On Wed, Sep 03, 2014 at 03:39:55PM +0530, sourab.gu...@intel.com wrote:
From: Sourab Gupta sourab.gu...@intel.com
Currently the Graphics Driver provides an interface through which
one can get a snapshot of the overall Graphics memory consumption.
Also there is an interface available, which provides information
about the several memory related attributes of every single Graphics
buffer created by the various clients.
There is a requirement of a new interface for achieving below
functionalities:
1) Need to provide Client based detailed information about the
distribution of Graphics memory
2) Need to provide an interface which can provide info about the
sharing of Graphics buffers between the clients.
The client based interface would also aid in debugging of
memory usage/consumption by each client debug memleak related issues.
With this new interface,
1) In case of memleak scenarios, we can easily zero in on the culprit
client which is unexpectedly holding on the Graphics buffers for an
inordinate amount of time.
2) We can get an estimate of the instantaneous memory footprint of
every Graphics client.
3) We can now trace all the processes sharing a particular Graphics buffer.
By means of this patch we try to provide a sysfs interface to achieve
the mentioned functionalities.
There are two files created in sysfs:
'i915_gem_meminfo' will provide summary of the graphics resources used by
each graphics client.
'i915_gem_objinfo' will provide detailed view of each object created by
individual clients.
v2: Changes made for
- adding support to report user virtual addresses of mapped buffers
- replacing pid based reporting with tgid based one
- checkpatch and other misc cleanup
Signed-off-by: Sourab Gupta sourab.gu...@intel.com
Signed-off-by: Akash Goel akash.g...@intel.com
Sorry I didn't spot this the first time around, but I think sysfs is the
wrong place for this.
Generally sysfs is for setting/reading per-object values, and it has the
big rule that there should be only _one_ value per file. The error state
is a bit an exception, but otoh it's also just the full dump as a binary
file (which for historical reasons is printed as ascii).
The other issue is that imo this should be a generic interface, so that we
can write a gpu_top tool for dumping memory consumers which works on all
linux platforms.
To avoid delaying for a long time can we just move ahead by putting this
into debugfs?
Also in debugfs there's already a lot of this stuff around - why is that
not sufficient and could we extend it somehow with the missing bits?
Thanks, Daniel
---
drivers/gpu/drm/i915/i915_dma.c | 1 +
drivers/gpu/drm/i915/i915_drv.c | 2 +
drivers/gpu/drm/i915/i915_drv.h | 26 ++
drivers/gpu/drm/i915/i915_gem.c | 169 ++-
drivers/gpu/drm/i915/i915_gem_debug.c | 542
++
drivers/gpu/drm/i915/i915_gpu_error.c | 2 +-
drivers/gpu/drm/i915/i915_sysfs.c | 83 ++
7 files changed, 822 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
index a58fed9..7ea3250 100644
--- a/drivers/gpu/drm/i915/i915_dma.c
+++ b/drivers/gpu/drm/i915/i915_dma.c
@@ -1985,6 +1985,7 @@ void i915_driver_postclose(struct drm_device *dev,
struct drm_file *file)
{
struct drm_i915_file_private *file_priv = file-driver_priv;
+ kfree(file_priv-process_name);
if (file_priv file_priv-bsd_ring)
file_priv-bsd_ring = NULL;
kfree(file_priv);
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 1d6d9ac..9bee20e 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -1628,6 +1628,8 @@ static struct drm_driver driver = {
.debugfs_init = i915_debugfs_init,
.debugfs_cleanup = i915_debugfs_cleanup,
#endif
+ .gem_open_object = i915_gem_open_object,
+ .gem_close_object = i915_gem_close_object,
.gem_free_object = i915_gem_free_object,
.gem_vm_ops = i915_gem_vm_ops,
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 36f3da6..43ba7c4 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1765,6 +1765,11 @@ struct drm_i915_gem_object_ops {
#define INTEL_FRONTBUFFER_ALL_MASK(pipe) \
(0xf (INTEL_FRONTBUFFER_BITS_PER_PIPE * (pipe)))
+struct drm_i915_obj_virt_addr {
+ struct list_head head;
+ unsigned long user_virt_addr;
+};
+
struct drm_i915_gem_object {
struct drm_gem_object base;
@@ -1890,6 +1895,13 @@ struct drm_i915_gem_object {
struct work_struct *work;
} userptr;
};
+
+#define MAX_OPEN_HANDLE 20
+ struct {
+ struct list_head virt_addr_head;
+ pid_t pid;
+ int open_handle_count;
+ } pid_array[MAX_OPEN_HANDLE];
[Intel-gfx] [PATCH] drm/i915: Remove shadowed local variable 'i' from i915_interrupt_info
Just a stray local variable, begone.
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
---
drivers/gpu/drm/i915/i915_debugfs.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index 86554dcd520f..f3e40fd9c8a9 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -739,7 +739,6 @@ static int i915_interrupt_info(struct seq_file *m, void
*data)
intel_runtime_pm_get(dev_priv);
if (IS_CHERRYVIEW(dev)) {
- int i;
seq_printf(m, Master Interrupt Control:\t%08x\n,
I915_READ(GEN8_MASTER_IRQ));
--
2.1.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 13/14] drm/i915: Enable DP port earlier
On Mon, 2014-08-18 at 22:16 +0300, ville.syrj...@linux.intel.com wrote:
From: Ville Syrjälä ville.syrj...@linux.intel.com
Bspec says we should enable the DP port before enabling panel power,
and that the port must be enabled with training pattern 1. Do so.
Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
Reviewed-by: Imre Deak imre.d...@intel.com
---
drivers/gpu/drm/i915/intel_dp.c | 172
+++-
1 file changed, 100 insertions(+), 72 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 28bc652..12925be 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -2264,6 +2264,104 @@ static void chv_post_disable_dp(struct intel_encoder
*encoder)
mutex_unlock(dev_priv-dpio_lock);
}
+static void
+_intel_dp_set_link_train(struct intel_dp *intel_dp,
+ uint32_t *DP,
+ uint8_t dp_train_pat)
+{
+ struct intel_digital_port *intel_dig_port = dp_to_dig_port(intel_dp);
+ struct drm_device *dev = intel_dig_port-base.base.dev;
+ struct drm_i915_private *dev_priv = dev-dev_private;
+ enum port port = intel_dig_port-port;
+
+ if (HAS_DDI(dev)) {
+ uint32_t temp = I915_READ(DP_TP_CTL(port));
+
+ if (dp_train_pat DP_LINK_SCRAMBLING_DISABLE)
+ temp |= DP_TP_CTL_SCRAMBLE_DISABLE;
+ else
+ temp = ~DP_TP_CTL_SCRAMBLE_DISABLE;
+
+ temp = ~DP_TP_CTL_LINK_TRAIN_MASK;
+ switch (dp_train_pat DP_TRAINING_PATTERN_MASK) {
+ case DP_TRAINING_PATTERN_DISABLE:
+ temp |= DP_TP_CTL_LINK_TRAIN_NORMAL;
+
+ break;
+ case DP_TRAINING_PATTERN_1:
+ temp |= DP_TP_CTL_LINK_TRAIN_PAT1;
+ break;
+ case DP_TRAINING_PATTERN_2:
+ temp |= DP_TP_CTL_LINK_TRAIN_PAT2;
+ break;
+ case DP_TRAINING_PATTERN_3:
+ temp |= DP_TP_CTL_LINK_TRAIN_PAT3;
+ break;
+ }
+ I915_WRITE(DP_TP_CTL(port), temp);
+
+ } else if (HAS_PCH_CPT(dev) (IS_GEN7(dev) || port != PORT_A)) {
+ *DP = ~DP_LINK_TRAIN_MASK_CPT;
+
+ switch (dp_train_pat DP_TRAINING_PATTERN_MASK) {
+ case DP_TRAINING_PATTERN_DISABLE:
+ *DP |= DP_LINK_TRAIN_OFF_CPT;
+ break;
+ case DP_TRAINING_PATTERN_1:
+ *DP |= DP_LINK_TRAIN_PAT_1_CPT;
+ break;
+ case DP_TRAINING_PATTERN_2:
+ *DP |= DP_LINK_TRAIN_PAT_2_CPT;
+ break;
+ case DP_TRAINING_PATTERN_3:
+ DRM_ERROR(DP training pattern 3 not supported\n);
+ *DP |= DP_LINK_TRAIN_PAT_2_CPT;
+ break;
+ }
+
+ } else {
+ if (IS_CHERRYVIEW(dev))
+ *DP = ~DP_LINK_TRAIN_MASK_CHV;
+ else
+ *DP = ~DP_LINK_TRAIN_MASK;
+
+ switch (dp_train_pat DP_TRAINING_PATTERN_MASK) {
+ case DP_TRAINING_PATTERN_DISABLE:
+ *DP |= DP_LINK_TRAIN_OFF;
+ break;
+ case DP_TRAINING_PATTERN_1:
+ *DP |= DP_LINK_TRAIN_PAT_1;
+ break;
+ case DP_TRAINING_PATTERN_2:
+ *DP |= DP_LINK_TRAIN_PAT_2;
+ break;
+ case DP_TRAINING_PATTERN_3:
+ if (IS_CHERRYVIEW(dev)) {
+ *DP |= DP_LINK_TRAIN_PAT_3_CHV;
+ } else {
+ DRM_ERROR(DP training pattern 3 not
supported\n);
+ *DP |= DP_LINK_TRAIN_PAT_2;
+ }
+ break;
+ }
+ }
+}
+
+static void intel_dp_enable_port(struct intel_dp *intel_dp)
+{
+ struct drm_device *dev = intel_dp_to_dev(intel_dp);
+ struct drm_i915_private *dev_priv = dev-dev_private;
+
+ intel_dp-DP |= DP_PORT_EN;
+
+ /* enable with pattern 1 (as per spec) */
+ _intel_dp_set_link_train(intel_dp, intel_dp-DP,
+ DP_TRAINING_PATTERN_1);
+
+ I915_WRITE(intel_dp-output_reg, intel_dp-DP);
+ POSTING_READ(intel_dp-output_reg);
+}
+
static void intel_enable_dp(struct intel_encoder *encoder)
{
struct intel_dp *intel_dp = enc_to_intel_dp(encoder-base);
@@ -2274,6 +2372,7 @@ static void intel_enable_dp(struct intel_encoder
*encoder)
if (WARN_ON(dp_reg DP_PORT_EN))
return;
+ intel_dp_enable_port(intel_dp);
intel_edp_panel_vdd_on(intel_dp);
intel_edp_panel_on(intel_dp);
[Intel-gfx] [PATCH 1/4] drm/i915: Don't call gen8_fbc_sw_flush() on chv
From: Ville Syrjälä ville.syrj...@linux.intel.com CHV doesn't have FBC, so don't go calling gen8_fbc_sw_flush() on it. Cc: Rodrigo Vivi rodrigo.v...@intel.com Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com --- drivers/gpu/drm/i915/intel_display.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c index e6cae59..83ea273 100644 --- a/drivers/gpu/drm/i915/intel_display.c +++ b/drivers/gpu/drm/i915/intel_display.c @@ -9132,7 +9132,7 @@ void intel_frontbuffer_flush(struct drm_device *dev, intel_edp_psr_flush(dev, frontbuffer_bits); - if (IS_GEN8(dev)) + if (IS_BROADWELL(dev)) gen8_fbc_sw_flush(dev, FBC_REND_CACHE_CLEAN); } -- 1.8.5.5 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/4] drm/i915: Use IS_BROADWELL() instead of IS_GEN8() in forcewake code
From: Ville Syrjälä ville.syrj...@linux.intel.com
IS_GEN8() is a bad check in the forcewake code due to bdw vs. chv
differences. Use IS_BROADWELL() instead.
The only actual bug here is that we currently call
__gen7_gt_force_wake_mt_reset() on chv. On the other places we
have checked for chv before using IS_GEN8(), but change them
to use IS_BROADWELL() anyway to reduce the chance of accidents in the
future.
Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
---
drivers/gpu/drm/i915/intel_uncore.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_uncore.c
b/drivers/gpu/drm/i915/intel_uncore.c
index e81bc3b..918b761 100644
--- a/drivers/gpu/drm/i915/intel_uncore.c
+++ b/drivers/gpu/drm/i915/intel_uncore.c
@@ -101,7 +101,7 @@ static void __gen7_gt_force_wake_mt_get(struct
drm_i915_private *dev_priv,
{
u32 forcewake_ack;
- if (IS_HASWELL(dev_priv-dev) || IS_GEN8(dev_priv-dev))
+ if (IS_HASWELL(dev_priv-dev) || IS_BROADWELL(dev_priv-dev))
forcewake_ack = FORCEWAKE_ACK_HSW;
else
forcewake_ack = FORCEWAKE_MT_ACK;
@@ -334,7 +334,7 @@ void intel_uncore_forcewake_reset(struct drm_device *dev,
bool restore)
else if (IS_GEN6(dev) || IS_GEN7(dev))
__gen6_gt_force_wake_reset(dev_priv);
- if (IS_IVYBRIDGE(dev) || IS_HASWELL(dev) || IS_GEN8(dev))
+ if (IS_IVYBRIDGE(dev) || IS_HASWELL(dev) || IS_BROADWELL(dev))
__gen7_gt_force_wake_mt_reset(dev_priv);
if (restore) { /* If reset with a user forcewake, try to restore */
@@ -838,7 +838,7 @@ void intel_uncore_init(struct drm_device *dev)
if (IS_VALLEYVIEW(dev)) {
dev_priv-uncore.funcs.force_wake_get = __vlv_force_wake_get;
dev_priv-uncore.funcs.force_wake_put = __vlv_force_wake_put;
- } else if (IS_HASWELL(dev) || IS_GEN8(dev)) {
+ } else if (IS_HASWELL(dev) || IS_BROADWELL(dev)) {
dev_priv-uncore.funcs.force_wake_get =
__gen7_gt_force_wake_mt_get;
dev_priv-uncore.funcs.force_wake_put =
__gen7_gt_force_wake_mt_put;
} else if (IS_IVYBRIDGE(dev)) {
--
1.8.5.5
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 3/4] drm/i915: Use HAS_GMCH_DISPLAY un underrun reporting code
From: Ville Syrjälä ville.syrj...@linux.intel.com
A few open coded HAS_GMCH_DISPLAY() remain in the underrun reporting
code. Convert them over.
Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
---
drivers/gpu/drm/i915/i915_irq.c | 2 +-
drivers/gpu/drm/i915/intel_display.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 6d5ae82..b964824 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -497,7 +497,7 @@ static bool __intel_set_cpu_fifo_underrun_reporting(struct
drm_device *dev,
old = !intel_crtc-cpu_fifo_underrun_disabled;
intel_crtc-cpu_fifo_underrun_disabled = !enable;
- if (INTEL_INFO(dev)-gen 5 || IS_VALLEYVIEW(dev))
+ if (HAS_GMCH_DISPLAY(dev))
i9xx_set_fifo_underrun_reporting(dev, pipe, enable, old);
else if (IS_GEN5(dev) || IS_GEN6(dev))
ironlake_set_fifo_underrun_reporting(dev, pipe, enable);
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 83ea273..0b9c9e0 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -13036,7 +13036,7 @@ static void intel_sanitize_crtc(struct intel_crtc *crtc)
}
}
- if (crtc-active || IS_VALLEYVIEW(dev) || INTEL_INFO(dev)-gen 5) {
+ if (crtc-active || HAS_GMCH_DISPLAY(dev)) {
/*
* We start out with underrun reporting disabled to avoid races.
* For correct bookkeeping mark this on active crtcs.
--
1.8.5.5
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 4/4] drm/i915: Check of !HAS_PCH_SPLIT() in PCH transcoder funcs
From: Ville Syrjälä ville.syrj...@linux.intel.com Check for !HAS_PCH_SPLIT() instead of 'gen 5' in the PCH transcoder enable functions. Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com --- drivers/gpu/drm/i915/intel_display.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c index 0b9c9e0..a53954c 100644 --- a/drivers/gpu/drm/i915/intel_display.c +++ b/drivers/gpu/drm/i915/intel_display.c @@ -1864,7 +1864,7 @@ static void ironlake_enable_pch_transcoder(struct drm_i915_private *dev_priv, uint32_t reg, val, pipeconf_val; /* PCH only available on ILK+ */ - BUG_ON(INTEL_INFO(dev)-gen 5); + BUG_ON(!HAS_PCH_SPLIT(dev)); /* Make sure PCH DPLL is enabled */ assert_shared_dpll_enabled(dev_priv, @@ -1917,7 +1917,7 @@ static void lpt_enable_pch_transcoder(struct drm_i915_private *dev_priv, u32 val, pipeconf_val; /* PCH only available on ILK+ */ - BUG_ON(INTEL_INFO(dev_priv-dev)-gen 5); + BUG_ON(!HAS_PCH_SPLIT(dev_priv-dev)); /* FDI must be feeding us bits for PCH ports */ assert_fdi_tx_enabled(dev_priv, (enum pipe) cpu_transcoder); -- 1.8.5.5 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Rename global latency_ns variable
On Wed, Sep 03, 2014 at 11:56:07AM +0100, Chris Wilson wrote:
We use the variable name latency_ns in both the local lowlevel wm
calculation routines and at the global level. Rename the global value to
reduce shadow warnings and future confusion.
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
This has confused me occasioanlly in the past. Though I'm not sure if
it would be better to move it into local scope instead since we already
have the sr_lantency_ns in there for some platforms. Also I'm not sure
5us is really a good value.
But anyway we can massage it further if anyone cares enough. In the
meantime this makes things clearer at least, so:
Reviewed-by: Ville Syrjälä ville.syrj...@linux.intel.com
---
drivers/gpu/drm/i915/intel_pm.c | 36 ++--
1 file changed, 18 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index a2340e87dd20..425d5e4052ae 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -872,7 +872,7 @@ void intel_set_memory_cxsr(struct drm_i915_private
*dev_priv, bool enable)
* A value of 5us seems to be a good balance; safe for very low end
* platforms but not overly aggressive on lower latency configs.
*/
-static const int latency_ns = 5000;
+static const int pessimal_latency_ns = 5000;
static int i9xx_get_fifo_size(struct drm_device *dev, int plane)
{
@@ -1387,14 +1387,14 @@ static void valleyview_update_wm(struct drm_crtc
*crtc)
vlv_update_drain_latency(crtc);
if (g4x_compute_wm0(dev, PIPE_A,
- valleyview_wm_info, latency_ns,
- valleyview_cursor_wm_info, latency_ns,
+ valleyview_wm_info, pessimal_latency_ns,
+ valleyview_cursor_wm_info, pessimal_latency_ns,
planea_wm, cursora_wm))
enabled |= 1 PIPE_A;
if (g4x_compute_wm0(dev, PIPE_B,
- valleyview_wm_info, latency_ns,
- valleyview_cursor_wm_info, latency_ns,
+ valleyview_wm_info, pessimal_latency_ns,
+ valleyview_cursor_wm_info, pessimal_latency_ns,
planeb_wm, cursorb_wm))
enabled |= 1 PIPE_B;
@@ -1453,20 +1453,20 @@ static void cherryview_update_wm(struct drm_crtc
*crtc)
vlv_update_drain_latency(crtc);
if (g4x_compute_wm0(dev, PIPE_A,
- valleyview_wm_info, latency_ns,
- valleyview_cursor_wm_info, latency_ns,
+ valleyview_wm_info, pessimal_latency_ns,
+ valleyview_cursor_wm_info, pessimal_latency_ns,
planea_wm, cursora_wm))
enabled |= 1 PIPE_A;
if (g4x_compute_wm0(dev, PIPE_B,
- valleyview_wm_info, latency_ns,
- valleyview_cursor_wm_info, latency_ns,
+ valleyview_wm_info, pessimal_latency_ns,
+ valleyview_cursor_wm_info, pessimal_latency_ns,
planeb_wm, cursorb_wm))
enabled |= 1 PIPE_B;
if (g4x_compute_wm0(dev, PIPE_C,
- valleyview_wm_info, latency_ns,
- valleyview_cursor_wm_info, latency_ns,
+ valleyview_wm_info, pessimal_latency_ns,
+ valleyview_cursor_wm_info, pessimal_latency_ns,
planec_wm, cursorc_wm))
enabled |= 1 PIPE_C;
@@ -1559,14 +1559,14 @@ static void g4x_update_wm(struct drm_crtc *crtc)
bool cxsr_enabled;
if (g4x_compute_wm0(dev, PIPE_A,
- g4x_wm_info, latency_ns,
- g4x_cursor_wm_info, latency_ns,
+ g4x_wm_info, pessimal_latency_ns,
+ g4x_cursor_wm_info, pessimal_latency_ns,
planea_wm, cursora_wm))
enabled |= 1 PIPE_A;
if (g4x_compute_wm0(dev, PIPE_B,
- g4x_wm_info, latency_ns,
- g4x_cursor_wm_info, latency_ns,
+ g4x_wm_info, pessimal_latency_ns,
+ g4x_cursor_wm_info, pessimal_latency_ns,
planeb_wm, cursorb_wm))
enabled |= 1 PIPE_B;
@@ -1709,7 +1709,7 @@ static void i9xx_update_wm(struct drm_crtc *unused_crtc)
adjusted_mode = to_intel_crtc(crtc)-config.adjusted_mode;
planea_wm = intel_calculate_wm(adjusted_mode-crtc_clock,
wm_info, fifo_size, cpp,
-latency_ns);
+pessimal_latency_ns);
enabled =
Re: [Intel-gfx] [PATCH 14/14] drm/i915: Move DP port disable to post_disable for pch platforms
On Mon, 2014-08-18 at 22:16 +0300, ville.syrj...@linux.intel.com wrote:
From: Ville Syrjälä ville.syrj...@linux.intel.com
We need to turn the DP port off after the pipe, otherwise the pipe won't
turn off properly on certain pch platforms at least (happens on my ILK for
example). This also matches the BSpec modeset sequence better. We still
don't match the spec exactly though (eg. audio disable should happen
much earlier), but at last this eliminates the nasty
wait_for_pipe_off() timeouts.
We already did the port disable after the pipe for VLV/CHV and for CPU
eDP.
For g4x leave the port disable where it is since that matches the
modeset sequence in the documentation and I don't have a suitable
machine to test if the other order would work.
Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
Reviewed-by: Imre Deak imre.d...@intel.com
---
drivers/gpu/drm/i915/intel_dp.c | 16 +++-
1 file changed, 7 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 12925be..915d4ec 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -2194,7 +2194,6 @@ void intel_edp_psr_init(struct drm_device *dev)
static void intel_disable_dp(struct intel_encoder *encoder)
{
struct intel_dp *intel_dp = enc_to_intel_dp(encoder-base);
- enum port port = dp_to_dig_port(intel_dp)-port;
struct drm_device *dev = encoder-base.dev;
/* Make sure the panel is off before trying to change the mode. But also
@@ -2204,21 +2203,19 @@ static void intel_disable_dp(struct intel_encoder
*encoder)
intel_dp_sink_dpms(intel_dp, DRM_MODE_DPMS_OFF);
intel_edp_panel_off(intel_dp);
- /* cpu edp my only be disable _after_ the cpu pipe/plane is disabled. */
- if (!(port == PORT_A || IS_VALLEYVIEW(dev)))
+ /* disable the port before the pipe on g4x */
+ if (INTEL_INFO(dev)-gen 5)
intel_dp_link_down(intel_dp);
}
-static void g4x_post_disable_dp(struct intel_encoder *encoder)
+static void ilk_post_disable_dp(struct intel_encoder *encoder)
{
struct intel_dp *intel_dp = enc_to_intel_dp(encoder-base);
enum port port = dp_to_dig_port(intel_dp)-port;
- if (port != PORT_A)
- return;
-
intel_dp_link_down(intel_dp);
- ironlake_edp_pll_off(intel_dp);
+ if (port == PORT_A)
+ ironlake_edp_pll_off(intel_dp);
}
static void vlv_post_disable_dp(struct intel_encoder *encoder)
@@ -5044,7 +5041,8 @@ intel_dp_init(struct drm_device *dev, int output_reg,
enum port port)
} else {
intel_encoder-pre_enable = g4x_pre_enable_dp;
intel_encoder-enable = g4x_enable_dp;
- intel_encoder-post_disable = g4x_post_disable_dp;
+ if (INTEL_INFO(dev)-gen = 5)
+ intel_encoder-post_disable = ilk_post_disable_dp;
}
intel_dig_port-port = port;
signature.asc
Description: This is a digitally signed message part
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2] drm/i915: Sysfs interface to get GFX shmem usage stats per process
On Wed, 2014-09-03 at 10:58 +, Daniel Vetter wrote:
On Wed, Sep 03, 2014 at 03:39:55PM +0530, sourab.gu...@intel.com wrote:
From: Sourab Gupta sourab.gu...@intel.com
Currently the Graphics Driver provides an interface through which
one can get a snapshot of the overall Graphics memory consumption.
Also there is an interface available, which provides information
about the several memory related attributes of every single Graphics
buffer created by the various clients.
There is a requirement of a new interface for achieving below
functionalities:
1) Need to provide Client based detailed information about the
distribution of Graphics memory
2) Need to provide an interface which can provide info about the
sharing of Graphics buffers between the clients.
The client based interface would also aid in debugging of
memory usage/consumption by each client debug memleak related issues.
With this new interface,
1) In case of memleak scenarios, we can easily zero in on the culprit
client which is unexpectedly holding on the Graphics buffers for an
inordinate amount of time.
2) We can get an estimate of the instantaneous memory footprint of
every Graphics client.
3) We can now trace all the processes sharing a particular Graphics buffer.
By means of this patch we try to provide a sysfs interface to achieve
the mentioned functionalities.
There are two files created in sysfs:
'i915_gem_meminfo' will provide summary of the graphics resources used by
each graphics client.
'i915_gem_objinfo' will provide detailed view of each object created by
individual clients.
v2: Changes made for
- adding support to report user virtual addresses of mapped buffers
- replacing pid based reporting with tgid based one
- checkpatch and other misc cleanup
Signed-off-by: Sourab Gupta sourab.gu...@intel.com
Signed-off-by: Akash Goel akash.g...@intel.com
Sorry I didn't spot this the first time around, but I think sysfs is the
wrong place for this.
Generally sysfs is for setting/reading per-object values, and it has the
big rule that there should be only _one_ value per file. The error state
is a bit an exception, but otoh it's also just the full dump as a binary
file (which for historical reasons is printed as ascii).
The other issue is that imo this should be a generic interface, so that we
can write a gpu_top tool for dumping memory consumers which works on all
linux platforms.
To avoid delaying for a long time can we just move ahead by putting this
into debugfs?
Also in debugfs there's already a lot of this stuff around - why is that
not sufficient and could we extend it somehow with the missing bits?
Thanks, Daniel
Hi Daniel,
Thanks for your inputs.
We had originally put the patch in sysfs, as there was a requirement for
this feature to be available in production kernels also.
We can move it to debugfs to move ahead with this. I'll submit the
debugfs version of this patch next time.
Also,
we developed this new interface to overcome the deficiencies of existing
interface. With this new interface, we can provide client based detailed
information about the distribution of Graphics memory. This gives
information about the various states of the graphics objects opened per
process (summarized as well as detailed info)
It also gives information about Graphics buffers shared between the
clients, and gives user mapped virtual address of all the mapped
graphics buffers.
It was not feasible to fit all this info in the existing interface. So
we decided to go ahead with new interface for these functionality.
Thanks,
Sourab
---
drivers/gpu/drm/i915/i915_dma.c | 1 +
drivers/gpu/drm/i915/i915_drv.c | 2 +
drivers/gpu/drm/i915/i915_drv.h | 26 ++
drivers/gpu/drm/i915/i915_gem.c | 169 ++-
drivers/gpu/drm/i915/i915_gem_debug.c | 542
++
drivers/gpu/drm/i915/i915_gpu_error.c | 2 +-
drivers/gpu/drm/i915/i915_sysfs.c | 83 ++
7 files changed, 822 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_dma.c
b/drivers/gpu/drm/i915/i915_dma.c
index a58fed9..7ea3250 100644
--- a/drivers/gpu/drm/i915/i915_dma.c
+++ b/drivers/gpu/drm/i915/i915_dma.c
@@ -1985,6 +1985,7 @@ void i915_driver_postclose(struct drm_device *dev,
struct drm_file *file)
{
struct drm_i915_file_private *file_priv = file-driver_priv;
+ kfree(file_priv-process_name);
if (file_priv file_priv-bsd_ring)
file_priv-bsd_ring = NULL;
kfree(file_priv);
diff --git a/drivers/gpu/drm/i915/i915_drv.c
b/drivers/gpu/drm/i915/i915_drv.c
index 1d6d9ac..9bee20e 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -1628,6 +1628,8 @@ static struct drm_driver driver = {
.debugfs_init = i915_debugfs_init,
.debugfs_cleanup =
Re: [Intel-gfx] [PATCH 15/14] drm/i915: Add comments explaining the vdd on/off functions
On Tue, 2014-08-19 at 20:47 +0300, ville.syrj...@linux.intel.com wrote:
From: Ville Syrjälä ville.syrj...@linux.intel.com
Jani wanted some comments to explain why we call certain vdd on/off
functions in certain places.
Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
---
drivers/gpu/drm/i915/intel_dp.c | 16
1 file changed, 16 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 1067082..1233a10 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -1315,6 +1315,7 @@ static u32 ironlake_get_pp_control(struct intel_dp
*intel_dp)
return control;
}
+/* should be paired with edp_panel_vdd_off() */
It would be useful to clarify here the purpose of the edp_ vs.
intel_edp_* versions. Iiuc you need to hold pps_lock around the whole
edp_panel_vdd_on/off() sequence and these can be nested within an
intel_edp_panel_vdd_on/off() sequence. Otoh, you can't nest
intel_edp_panel_vdd_on() calls.
static bool edp_panel_vdd_on(struct intel_dp *intel_dp)
{
struct drm_device *dev = intel_dp_to_dev(intel_dp);
@@ -1365,6 +1366,7 @@ static bool edp_panel_vdd_on(struct intel_dp *intel_dp)
return need_to_disable;
}
+/* should be paired with intel_edp_panel_vdd_off() */
void intel_edp_panel_vdd_on(struct intel_dp *intel_dp)
{
struct drm_i915_private *dev_priv =
@@ -1447,6 +1449,7 @@ static void edp_panel_vdd_schedule_off(struct intel_dp
*intel_dp)
schedule_delayed_work(intel_dp-panel_vdd_work, delay);
}
+/* should be paired with edp_panel_vdd_on() */
static void edp_panel_vdd_off(struct intel_dp *intel_dp, bool sync)
{
struct drm_i915_private *dev_priv =
@@ -1467,6 +1470,7 @@ static void edp_panel_vdd_off(struct intel_dp
*intel_dp, bool sync)
edp_panel_vdd_schedule_off(intel_dp);
}
+/* should be paired with intel_edp_panel_vdd_on() */
static void intel_edp_panel_vdd_off(struct intel_dp *intel_dp, bool sync)
{
struct drm_i915_private *dev_priv =
@@ -4307,6 +4311,10 @@ void intel_dp_encoder_destroy(struct drm_encoder
*encoder)
drm_encoder_cleanup(encoder);
if (is_edp(intel_dp)) {
cancel_delayed_work_sync(intel_dp-panel_vdd_work);
+ /*
+ * vdd might still be enabled do to the delayed vdd off.
s/do/due/
+ * Make sure vdd is actually turned off here.
+ */
mutex_lock(dev_priv-pps_mutex);
edp_panel_vdd_off_sync(intel_dp);
mutex_unlock(dev_priv-pps_mutex);
@@ -4327,6 +4335,10 @@ static void intel_dp_encoder_suspend(struct
intel_encoder *intel_encoder)
if (!is_edp(intel_dp))
return;
+ /*
+ * vdd might still be enabled do to the delayed vdd off.
+ * Make sure vdd is actually turned off here.
+ */
mutex_lock(dev_priv-pps_mutex);
edp_panel_vdd_off_sync(intel_dp);
mutex_unlock(dev_priv-pps_mutex);
@@ -5025,6 +5037,10 @@ intel_dp_init_connector(struct intel_digital_port
*intel_dig_port,
drm_dp_aux_unregister(intel_dp-aux);
if (is_edp(intel_dp)) {
cancel_delayed_work_sync(intel_dp-panel_vdd_work);
+ /*
+ * vdd might still be enabled do to the delayed vdd off.
+ * Make sure vdd is actually turned off here.
+ */
mutex_lock(dev_priv-pps_mutex);
edp_panel_vdd_off_sync(intel_dp);
mutex_unlock(dev_priv-pps_mutex);
edp_panel_vdd_off_sync() could also use a clarification similar to the
the rest of the API.
With or without the above changes:
Reviewed-by: Imre Deak imre.d...@intel.com
signature.asc
Description: This is a digitally signed message part
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/4] drm/i915: Use IS_BROADWELL() instead of IS_GEN8() in forcewake code
On Wednesday 03 September 2014 04:39 PM, ville.syrj...@linux.intel.com
wrote:
From: Ville Syrjälä ville.syrj...@linux.intel.com
IS_GEN8() is a bad check in the forcewake code due to bdw vs. chv
differences. Use IS_BROADWELL() instead.
The only actual bug here is that we currently call
__gen7_gt_force_wake_mt_reset() on chv. On the other places we
have checked for chv before using IS_GEN8(), but change them
to use IS_BROADWELL() anyway to reduce the chance of accidents in the
future.
Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
---
drivers/gpu/drm/i915/intel_uncore.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_uncore.c
b/drivers/gpu/drm/i915/intel_uncore.c
index e81bc3b..918b761 100644
--- a/drivers/gpu/drm/i915/intel_uncore.c
+++ b/drivers/gpu/drm/i915/intel_uncore.c
@@ -101,7 +101,7 @@ static void __gen7_gt_force_wake_mt_get(struct
drm_i915_private *dev_priv,
{
u32 forcewake_ack;
- if (IS_HASWELL(dev_priv-dev) || IS_GEN8(dev_priv-dev))
+ if (IS_HASWELL(dev_priv-dev) || IS_BROADWELL(dev_priv-dev))
forcewake_ack = FORCEWAKE_ACK_HSW;
else
forcewake_ack = FORCEWAKE_MT_ACK;
@@ -334,7 +334,7 @@ void intel_uncore_forcewake_reset(struct drm_device *dev,
bool restore)
else if (IS_GEN6(dev) || IS_GEN7(dev))
__gen6_gt_force_wake_reset(dev_priv);
- if (IS_IVYBRIDGE(dev) || IS_HASWELL(dev) || IS_GEN8(dev))
+ if (IS_IVYBRIDGE(dev) || IS_HASWELL(dev) || IS_BROADWELL(dev))
__gen7_gt_force_wake_mt_reset(dev_priv);
if (restore) { /* If reset with a user forcewake, try to restore */
@@ -838,7 +838,7 @@ void intel_uncore_init(struct drm_device *dev)
if (IS_VALLEYVIEW(dev)) {
dev_priv-uncore.funcs.force_wake_get = __vlv_force_wake_get;
dev_priv-uncore.funcs.force_wake_put = __vlv_force_wake_put;
- } else if (IS_HASWELL(dev) || IS_GEN8(dev)) {
+ } else if (IS_HASWELL(dev) || IS_BROADWELL(dev)) {
dev_priv-uncore.funcs.force_wake_get =
__gen7_gt_force_wake_mt_get;
dev_priv-uncore.funcs.force_wake_put =
__gen7_gt_force_wake_mt_put;
} else if (IS_IVYBRIDGE(dev)) {
Yup I Agree :)
Reviewed-by: Deepak S deepa...@linux.intel.com
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PULL] drm-intel-fixes
Hi Dave, here's a couple of display regression fixes for 3.17. BR, Jani. The following changes since commit bbe1c2740d3a25aa1dbe5d842d2ff09cddcdde0a: drm/i915: Remove bogus __init annotation from DMI callbacks (2014-08-28 09:54:27 +0300) are available in the git repository at: git://anongit.freedesktop.org/drm-intel tags/drm-intel-fixes-2014-09-03 for you to fetch changes up to bbfb44e8b688e778964275ab0862f67463ba4f84: drm/i915: Fix lock dropping in intel_tv_detect() (2014-09-02 12:58:51 +0300) Dave Airlie (1): drm/i915: handle G45/GM45 pulse detection connected state. Ville Syrjälä (1): drm/i915: Fix lock dropping in intel_tv_detect() drivers/gpu/drm/i915/intel_dp.c | 55 +++-- drivers/gpu/drm/i915/intel_tv.c | 10 +--- 2 files changed, 44 insertions(+), 21 deletions(-) -- 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: Prevent recursive deadlock on releasing a busy userptr
On Tue, 02 Sep 2014, Daniel Vetter dan...@ffwll.ch wrote: Queued for -next, thanks for the patch. Aside: Is there other userptr stuff outstanding? I've definitely lost track of them :( Picked up for drm-intel-fixes instead. Thanks. 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 v2] drm/i915: Sysfs interface to get GFX shmem usage stats per process
On Wed, Sep 03, 2014 at 11:49:52AM +, Gupta, Sourab wrote: On Wed, 2014-09-03 at 10:58 +, Daniel Vetter wrote: On Wed, Sep 03, 2014 at 03:39:55PM +0530, sourab.gu...@intel.com wrote: From: Sourab Gupta sourab.gu...@intel.com Currently the Graphics Driver provides an interface through which one can get a snapshot of the overall Graphics memory consumption. Also there is an interface available, which provides information about the several memory related attributes of every single Graphics buffer created by the various clients. There is a requirement of a new interface for achieving below functionalities: 1) Need to provide Client based detailed information about the distribution of Graphics memory 2) Need to provide an interface which can provide info about the sharing of Graphics buffers between the clients. The client based interface would also aid in debugging of memory usage/consumption by each client debug memleak related issues. With this new interface, 1) In case of memleak scenarios, we can easily zero in on the culprit client which is unexpectedly holding on the Graphics buffers for an inordinate amount of time. 2) We can get an estimate of the instantaneous memory footprint of every Graphics client. 3) We can now trace all the processes sharing a particular Graphics buffer. By means of this patch we try to provide a sysfs interface to achieve the mentioned functionalities. There are two files created in sysfs: 'i915_gem_meminfo' will provide summary of the graphics resources used by each graphics client. 'i915_gem_objinfo' will provide detailed view of each object created by individual clients. v2: Changes made for - adding support to report user virtual addresses of mapped buffers - replacing pid based reporting with tgid based one - checkpatch and other misc cleanup Signed-off-by: Sourab Gupta sourab.gu...@intel.com Signed-off-by: Akash Goel akash.g...@intel.com Sorry I didn't spot this the first time around, but I think sysfs is the wrong place for this. Generally sysfs is for setting/reading per-object values, and it has the big rule that there should be only _one_ value per file. The error state is a bit an exception, but otoh it's also just the full dump as a binary file (which for historical reasons is printed as ascii). The other issue is that imo this should be a generic interface, so that we can write a gpu_top tool for dumping memory consumers which works on all linux platforms. To avoid delaying for a long time can we just move ahead by putting this into debugfs? Also in debugfs there's already a lot of this stuff around - why is that not sufficient and could we extend it somehow with the missing bits? Thanks, Daniel Hi Daniel, Thanks for your inputs. We had originally put the patch in sysfs, as there was a requirement for this feature to be available in production kernels also. We can move it to debugfs to move ahead with this. I'll submit the debugfs version of this patch next time. Yeah sysfs is the only place where we have a stable api, but that also implies that requirements are a _lot_ more stringent. At least we need testcases to make sure the interface actually do what we want them to do, and to make sure we don't break the interface by accident. Also, we developed this new interface to overcome the deficiencies of existing interface. With this new interface, we can provide client based detailed information about the distribution of Graphics memory. This gives information about the various states of the graphics objects opened per process (summarized as well as detailed info) It also gives information about Graphics buffers shared between the clients, and gives user mapped virtual address of all the mapped graphics buffers. It was not feasible to fit all this info in the existing interface. So we decided to go ahead with new interface for these functionality. Well the problem is that adding more files like that increases the maintenance burden. So if there's some way to compute the information you want from information already provided in debugfs, then I prefer we do that at first. -Daniel Thanks, Sourab --- drivers/gpu/drm/i915/i915_dma.c | 1 + drivers/gpu/drm/i915/i915_drv.c | 2 + drivers/gpu/drm/i915/i915_drv.h | 26 ++ drivers/gpu/drm/i915/i915_gem.c | 169 ++- drivers/gpu/drm/i915/i915_gem_debug.c | 542 ++ drivers/gpu/drm/i915/i915_gpu_error.c | 2 +- drivers/gpu/drm/i915/i915_sysfs.c | 83 ++ 7 files changed, 822 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c index a58fed9..7ea3250 100644 --- a/drivers/gpu/drm/i915/i915_dma.c +++
Re: [Intel-gfx] [PATCH] drm/i915: Rename global latency_ns variable
On Wed, Sep 03, 2014 at 02:17:52PM +0300, Ville Syrjälä wrote:
On Wed, Sep 03, 2014 at 11:56:07AM +0100, Chris Wilson wrote:
We use the variable name latency_ns in both the local lowlevel wm
calculation routines and at the global level. Rename the global value to
reduce shadow warnings and future confusion.
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
This has confused me occasioanlly in the past. Though I'm not sure if
it would be better to move it into local scope instead since we already
have the sr_lantency_ns in there for some platforms. Also I'm not sure
5us is really a good value.
I've had some patches to clean up the gmch wm calculation code since
there's a few other really confusing things in there. But it's also a lot
of tricky/fragile code :(
But anyway we can massage it further if anyone cares enough. In the
meantime this makes things clearer at least, so:
Reviewed-by: Ville Syrjälä ville.syrj...@linux.intel.com
Queued for -next, thanks for the patch.
-Daniel
---
drivers/gpu/drm/i915/intel_pm.c | 36 ++--
1 file changed, 18 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_pm.c
b/drivers/gpu/drm/i915/intel_pm.c
index a2340e87dd20..425d5e4052ae 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -872,7 +872,7 @@ void intel_set_memory_cxsr(struct drm_i915_private
*dev_priv, bool enable)
* A value of 5us seems to be a good balance; safe for very low end
* platforms but not overly aggressive on lower latency configs.
*/
-static const int latency_ns = 5000;
+static const int pessimal_latency_ns = 5000;
static int i9xx_get_fifo_size(struct drm_device *dev, int plane)
{
@@ -1387,14 +1387,14 @@ static void valleyview_update_wm(struct drm_crtc
*crtc)
vlv_update_drain_latency(crtc);
if (g4x_compute_wm0(dev, PIPE_A,
- valleyview_wm_info, latency_ns,
- valleyview_cursor_wm_info, latency_ns,
+ valleyview_wm_info, pessimal_latency_ns,
+ valleyview_cursor_wm_info, pessimal_latency_ns,
planea_wm, cursora_wm))
enabled |= 1 PIPE_A;
if (g4x_compute_wm0(dev, PIPE_B,
- valleyview_wm_info, latency_ns,
- valleyview_cursor_wm_info, latency_ns,
+ valleyview_wm_info, pessimal_latency_ns,
+ valleyview_cursor_wm_info, pessimal_latency_ns,
planeb_wm, cursorb_wm))
enabled |= 1 PIPE_B;
@@ -1453,20 +1453,20 @@ static void cherryview_update_wm(struct drm_crtc
*crtc)
vlv_update_drain_latency(crtc);
if (g4x_compute_wm0(dev, PIPE_A,
- valleyview_wm_info, latency_ns,
- valleyview_cursor_wm_info, latency_ns,
+ valleyview_wm_info, pessimal_latency_ns,
+ valleyview_cursor_wm_info, pessimal_latency_ns,
planea_wm, cursora_wm))
enabled |= 1 PIPE_A;
if (g4x_compute_wm0(dev, PIPE_B,
- valleyview_wm_info, latency_ns,
- valleyview_cursor_wm_info, latency_ns,
+ valleyview_wm_info, pessimal_latency_ns,
+ valleyview_cursor_wm_info, pessimal_latency_ns,
planeb_wm, cursorb_wm))
enabled |= 1 PIPE_B;
if (g4x_compute_wm0(dev, PIPE_C,
- valleyview_wm_info, latency_ns,
- valleyview_cursor_wm_info, latency_ns,
+ valleyview_wm_info, pessimal_latency_ns,
+ valleyview_cursor_wm_info, pessimal_latency_ns,
planec_wm, cursorc_wm))
enabled |= 1 PIPE_C;
@@ -1559,14 +1559,14 @@ static void g4x_update_wm(struct drm_crtc *crtc)
bool cxsr_enabled;
if (g4x_compute_wm0(dev, PIPE_A,
- g4x_wm_info, latency_ns,
- g4x_cursor_wm_info, latency_ns,
+ g4x_wm_info, pessimal_latency_ns,
+ g4x_cursor_wm_info, pessimal_latency_ns,
planea_wm, cursora_wm))
enabled |= 1 PIPE_A;
if (g4x_compute_wm0(dev, PIPE_B,
- g4x_wm_info, latency_ns,
- g4x_cursor_wm_info, latency_ns,
+ g4x_wm_info, pessimal_latency_ns,
+ g4x_cursor_wm_info, pessimal_latency_ns,
planeb_wm, cursorb_wm))
enabled |= 1 PIPE_B;
@@ -1709,7 +1709,7 @@ static void i9xx_update_wm(struct drm_crtc
*unused_crtc)
adjusted_mode = to_intel_crtc(crtc)-config.adjusted_mode;
Re: [Intel-gfx] [PATCH] drm/i915: Remove shadowed local variable 'i' from i915_interrupt_info
On Wed, Sep 03, 2014 at 11:59:36AM +0100, Chris Wilson wrote:
Just a stray local variable, begone.
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
Queued for -next, thanks for the patch.
-Daniel
---
drivers/gpu/drm/i915/i915_debugfs.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index 86554dcd520f..f3e40fd9c8a9 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -739,7 +739,6 @@ static int i915_interrupt_info(struct seq_file *m, void
*data)
intel_runtime_pm_get(dev_priv);
if (IS_CHERRYVIEW(dev)) {
- int i;
seq_printf(m, Master Interrupt Control:\t%08x\n,
I915_READ(GEN8_MASTER_IRQ));
--
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
+41 (0) 79 365 57 48 - 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 4/4] drm/i915: Check of !HAS_PCH_SPLIT() in PCH transcoder funcs
On Wed, Sep 03, 2014 at 02:09:53PM +0300, ville.syrj...@linux.intel.com wrote: From: Ville Syrjälä ville.syrj...@linux.intel.com Check for !HAS_PCH_SPLIT() instead of 'gen 5' in the PCH transcoder enable functions. Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com All four patches from this series merged, thanks. -Daniel --- drivers/gpu/drm/i915/intel_display.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c index 0b9c9e0..a53954c 100644 --- a/drivers/gpu/drm/i915/intel_display.c +++ b/drivers/gpu/drm/i915/intel_display.c @@ -1864,7 +1864,7 @@ static void ironlake_enable_pch_transcoder(struct drm_i915_private *dev_priv, uint32_t reg, val, pipeconf_val; /* PCH only available on ILK+ */ - BUG_ON(INTEL_INFO(dev)-gen 5); + BUG_ON(!HAS_PCH_SPLIT(dev)); /* Make sure PCH DPLL is enabled */ assert_shared_dpll_enabled(dev_priv, @@ -1917,7 +1917,7 @@ static void lpt_enable_pch_transcoder(struct drm_i915_private *dev_priv, u32 val, pipeconf_val; /* PCH only available on ILK+ */ - BUG_ON(INTEL_INFO(dev_priv-dev)-gen 5); + BUG_ON(!HAS_PCH_SPLIT(dev_priv-dev)); /* FDI must be feeding us bits for PCH ports */ assert_fdi_tx_enabled(dev_priv, (enum pipe) cpu_transcoder); -- 1.8.5.5 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - 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: init sprites with univeral plane init function
From: Derek Foreman derek.fore...@collabora.co.uk
Really just for completeness - old init function ends up making the plane
exactly the same way due to the way the enums are set up.
Signed-off-by: Derek Foreman derek.fore...@collabora.co.uk
Signed-off-by: Gustavo Padovan gustavo.pado...@collabora.co.uk
---
drivers/gpu/drm/i915/intel_sprite.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_sprite.c
b/drivers/gpu/drm/i915/intel_sprite.c
index 0bdb00b..4cbe286 100644
--- a/drivers/gpu/drm/i915/intel_sprite.c
+++ b/drivers/gpu/drm/i915/intel_sprite.c
@@ -1375,10 +1375,10 @@ intel_plane_init(struct drm_device *dev, enum pipe
pipe, int plane)
intel_plane-plane = plane;
intel_plane-rotation = BIT(DRM_ROTATE_0);
possible_crtcs = (1 pipe);
- ret = drm_plane_init(dev, intel_plane-base, possible_crtcs,
-intel_plane_funcs,
-plane_formats, num_plane_formats,
-false);
+ ret = drm_universal_plane_init(dev, intel_plane-base, possible_crtcs,
+ intel_plane_funcs,
+ plane_formats, num_plane_formats,
+ DRM_PLANE_TYPE_OVERLAY);
if (ret) {
kfree(intel_plane);
goto out;
--
1.9.3
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: init sprites with univeral plane init function
On Wed, Sep 03, 2014 at 10:38:20AM -0300, Gustavo Padovan wrote:
From: Derek Foreman derek.fore...@collabora.co.uk
Really just for completeness - old init function ends up making the plane
exactly the same way due to the way the enums are set up.
Signed-off-by: Derek Foreman derek.fore...@collabora.co.uk
Signed-off-by: Gustavo Padovan gustavo.pado...@collabora.co.uk
Queued for -next, thanks for the patch.
-Daniel
---
drivers/gpu/drm/i915/intel_sprite.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_sprite.c
b/drivers/gpu/drm/i915/intel_sprite.c
index 0bdb00b..4cbe286 100644
--- a/drivers/gpu/drm/i915/intel_sprite.c
+++ b/drivers/gpu/drm/i915/intel_sprite.c
@@ -1375,10 +1375,10 @@ intel_plane_init(struct drm_device *dev, enum pipe
pipe, int plane)
intel_plane-plane = plane;
intel_plane-rotation = BIT(DRM_ROTATE_0);
possible_crtcs = (1 pipe);
- ret = drm_plane_init(dev, intel_plane-base, possible_crtcs,
- intel_plane_funcs,
- plane_formats, num_plane_formats,
- false);
+ ret = drm_universal_plane_init(dev, intel_plane-base, possible_crtcs,
+intel_plane_funcs,
+plane_formats, num_plane_formats,
+DRM_PLANE_TYPE_OVERLAY);
if (ret) {
kfree(intel_plane);
goto out;
--
1.9.3
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] linux-next: manual merge of the drm-intel tree with the tree
On Wed, Sep 03, 2014 at 02:31:46PM +0100, Mark Brown wrote: @@ -3923,7 +3942,9 @@ static void valleyview_irq_uninstall(struct drm_device *dev) I915_WRITE(VLV_MASTER_IER, 0); - for_each_pipe(pipe) + intel_hpd_irq_uninstall(dev_priv); + + for_each_pipe(dev_priv, pipe) I915_WRITE(PIPESTAT(pipe), 0x); I915_WRITE(HWSTAM, 0x); ...or actually this since the above doesn't build, I was too hasty: @@ -3923,7 +3942,9 @@ static void valleyview_irq_uninstall(struct drm_device *dev) I915_WRITE(VLV_MASTER_IER, 0); - for_each_pipe(pipe) + + for_each_pipe(dev_priv, pipe) I915_WRITE(PIPESTAT(pipe), 0x); I915_WRITE(HWSTAM, 0x); signature.asc Description: Digital signature ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] linux-next: manual merge of the drm-intel tree with the tree
Hi all, Today's linux-next merge of the drm-intel tree got a conflict which I'm not really sure of and commit b47d1189da119e (drm/i915: Use dev_priv as first argument of for_each_pipe()) from the drm-intel tree. I fixed it up (see below) and can carry the fix as necessary (no action is required). @@ -3923,7 +3942,9 @@ static void valleyview_irq_uninstall(struct drm_device *dev) I915_WRITE(VLV_MASTER_IER, 0); - for_each_pipe(pipe) + intel_hpd_irq_uninstall(dev_priv); + + for_each_pipe(dev_priv, pipe) I915_WRITE(PIPESTAT(pipe), 0x); I915_WRITE(HWSTAM, 0x); pgpEv85qYDOuN.pgp Description: PGP signature ___ 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: allow sync points within batches
On Wed, 3 Sep 2014 08:01:55 +0100
Chris Wilson ch...@chris-wilson.co.uk wrote:
On Tue, Sep 02, 2014 at 02:32:41PM -0700, Jesse Barnes wrote:
Use a new reloc type to allow userspace to insert sync points within
batches before they're submitted. The corresponding fence fds are
returned in the offset field of the returned reloc tree, and can be
operated on with the sync fence APIs.
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
---
drivers/gpu/drm/i915/i915_drv.h| 4 +
drivers/gpu/drm/i915/i915_gem_execbuffer.c | 125
-
drivers/gpu/drm/i915/i915_sync.c | 58 ++---
include/uapi/drm/i915_drm.h| 11 ++-
4 files changed, 167 insertions(+), 31 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h
b/drivers/gpu/drm/i915/i915_drv.h
index 6eb119e..410eedf 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2284,6 +2284,10 @@ int i915_sync_init(struct drm_i915_private
*dev_priv);
void i915_sync_fini(struct drm_i915_private *dev_priv);
int i915_sync_create_fence_ioctl(struct drm_device *dev, void *data,
struct drm_file *file);
+int i915_sync_fence_create(struct intel_engine_cs *ring,
+ struct intel_context *ctx,
+ u32 seqno);
+
#define PIN_MAPPABLE 0x1
#define PIN_NONBLOCK 0x2
diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
index 60998fc..32ec599 100644
--- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
@@ -32,6 +32,7 @@
#include i915_trace.h
#include intel_drv.h
#include linux/dma_remapping.h
+#include ../../../staging/android/sync.h
#define __EXEC_OBJECT_HAS_PIN (131)
#define __EXEC_OBJECT_HAS_FENCE (130)
@@ -262,6 +263,67 @@ static inline int use_cpu_reloc(struct
drm_i915_gem_object *obj)
!obj-map_and_fenceable ||
obj-cache_level != I915_CACHE_NONE);
}
+static int
+emit_sync_obj_cpu(struct drm_i915_gem_object *obj,
+ struct drm_i915_gem_relocation_entry *reloc)
+{
+ uint32_t page_offset = offset_in_page(reloc-offset);
+ char *vaddr;
+ int ret;
+
+ ret = i915_gem_object_set_to_cpu_domain(obj, true);
+ if (ret)
+ return ret;
+
+ vaddr = kmap_atomic(i915_gem_object_get_page(obj,
+ reloc-offset PAGE_SHIFT));
+ *(uint32_t *)(vaddr + page_offset) = MI_STORE_DWORD_INDEX;
+ *(uint32_t *)(vaddr + page_offset + 4) =
+ I915_GEM_HWS_INDEX MI_STORE_DWORD_INDEX_SHIFT;
+ *(uint32_t *)(vaddr + page_offset + 8) =
+ obj-ring-outstanding_lazy_seqno;
+ *(uint32_t *)(vaddr + page_offset + 12) = MI_USER_INTERRUPT;
+
+ kunmap_atomic(vaddr);
+
+ return 0;
+}
+
+static int
+emit_sync_obj_gtt(struct drm_i915_gem_object *obj,
+ struct drm_i915_gem_relocation_entry *reloc)
+{
+ struct drm_device *dev = obj-base.dev;
+ struct drm_i915_private *dev_priv = dev-dev_private;
+ uint32_t __iomem *reloc_entry;
+ void __iomem *reloc_page;
+ int ret;
+
+ ret = i915_gem_object_set_to_gtt_domain(obj, true);
+ if (ret)
+ return ret;
+
+ ret = i915_gem_object_put_fence(obj);
+ if (ret)
+ return ret;
+
+ /* Map the page containing the relocation we're going to perform. */
+ reloc-offset += i915_gem_obj_ggtt_offset(obj);
+ reloc_page = io_mapping_map_atomic_wc(dev_priv-gtt.mappable,
+ reloc-offset PAGE_MASK);
+
+ reloc_entry = (uint32_t __iomem *)
+ (reloc_page + offset_in_page(reloc-offset));
+ iowrite32(MI_STORE_DWORD_INDEX, reloc_entry);
+ iowrite32(I915_GEM_HWS_INDEX MI_STORE_DWORD_INDEX_SHIFT,
+ reloc_entry);
+ iowrite32(obj-ring-outstanding_lazy_seqno, reloc_entry);
+ iowrite32(MI_USER_INTERRUPT, reloc_entry);
+
+ io_mapping_unmap_atomic(reloc_page);
These commands are illegal/invalid inside the object, only valid inside
the ring.
Hm, we ought to be able to write to no privileged space with
STORE_DWORD, but that does mean moving to context specific pages in
process space, or at least adding them to our existing scheme.
I haven't tried MI_USER_INTERRUPT from a batch, if we can't do it from
a non-privileged batch that nixes one of the other neat features we
could have (fine grained intra-batch userspace synchronization).
+ return 0;
+}
static int
relocate_entry_cpu(struct drm_i915_gem_object *obj,
@@ -349,7 +411,8 @@ relocate_entry_gtt(struct drm_i915_gem_object *obj,
static int
i915_gem_execbuffer_relocate_entry(struct drm_i915_gem_object *obj,
struct eb_vmas *eb,
- struct drm_i915_gem_relocation_entry *reloc)
Re: [Intel-gfx] [PATCH 2/2] drm/i915: allow sync points within batches
On Wed, Sep 03, 2014 at 08:41:06AM -0700, Jesse Barnes wrote: On Wed, 3 Sep 2014 08:01:55 +0100 Chris Wilson ch...@chris-wilson.co.uk wrote: These commands are illegal/invalid inside the object, only valid inside the ring. Hm, we ought to be able to write to no privileged space with STORE_DWORD, but that does mean moving to context specific pages in process space, or at least adding them to our existing scheme. The per-process context page also doesn't exist generically. I certainly hope that userspace can't overwrite the hws! Imagine if we were using that for interrupt status reads, or seqno tracking... I haven't tried MI_USER_INTERRUPT from a batch, if we can't do it from a non-privileged batch that nixes one of the other neat features we could have (fine grained intra-batch userspace synchronization). I don't understand how writing the operation into the batch is beneficial vs writing into the ring, unless you instended to use something more fine grained than the batch seqno. You want to get interrupts from inside batches? Rather than continue the existing scheme of splitting up batches between fences? I definitely think we should think twice before allowing userspace to arbitrarily generate interrupts. + return 0; +} static int relocate_entry_cpu(struct drm_i915_gem_object *obj, @@ -349,7 +411,8 @@ relocate_entry_gtt(struct drm_i915_gem_object *obj, static int i915_gem_execbuffer_relocate_entry(struct drm_i915_gem_object *obj, struct eb_vmas *eb, -struct drm_i915_gem_relocation_entry *reloc) +struct drm_i915_gem_relocation_entry *reloc, +struct intel_context *ctx) Hmm. That's a nuisance. But no, you only use it to automatically create a fence not to patch the batch, so you can just use an object-flag. This fits neatly into requests. Most definitely. What do you think of the potential upside in the DDX for this, assuming we get dword writes from batches working? Negative. You now have relocation overhead, you still need to split batches to keep the gpu busy and do ring switches, and context switching between clients, so I don't feel a need for fences from inside a batch. Getting seqno and a hws in the client would be nice, but if it continues to require kernel polling, no thanks, I'll just still to approximately tracking the active state of surfaces with the heavier accurate queries sparingly. About the only thing I could see as being useful is that it would allow you to reuse a batch buffer multiple times, rather than overallocate a whole page and keep a pool of such pages. I am missing something? -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 1/2] drm/i915: Android sync points for i915 v2
On Wed, Sep 03, 2014 at 08:09:01AM +0100, Chris Wilson wrote:
On Tue, Sep 02, 2014 at 02:32:40PM -0700, Jesse Barnes wrote:
+static int i915_fence_check(wait_queue_t *wait, unsigned mode, int flags,
+ void *key)
+{
+ struct i915_fence *intel_fence = wait-private;
+ struct intel_engine_cs *ring = intel_fence-ring;
+
+ if (!i915_seqno_passed(ring-get_seqno(ring, false),
+ intel_fence-seqno))
+ return 0;
+
+ fence_signal_locked(intel_fence-base);
+
+ __remove_wait_queue(ring-irq_queue, wait);
+ fence_put(intel_fence-base);
+ ring-irq_put(ring);
+
+ return 0;
+}
+
+static bool i915_fence_enable_signaling(struct fence *fence)
+{
+ struct i915_fence *intel_fence = to_intel_fence(fence);
+ struct intel_engine_cs *ring = intel_fence-ring;
+ struct drm_i915_private *dev_priv = ring-dev-dev_private;
+ wait_queue_t *wait = intel_fence-wait;
+
+ /* queue fence wait queue on irq queue and get fence */
+ if (i915_seqno_passed(ring-get_seqno(ring, false),
+ intel_fence-seqno) ||
+ i915_terminally_wedged(dev_priv-gpu_error))
+ return false;
+
+ if (!ring-irq_get(ring))
+ return false;
+
+ wait-flags = 0;
+ wait-private = intel_fence;
+ wait-func = i915_fence_check;
+
+ __add_wait_queue(ring-irq_queue, wait);
+ fence_get(fence);
+
+ return true;
+}
This looks like it implements poll().
You should recheck i915_request_complete() after setting up the irq
waiter. Or does struct fence_ops handle that?
Also looks quite a bit like my ring notify doohicky from:
http://lists.freedesktop.org/archives/intel-gfx/2014-June/047623.html
Except I kept the list in the driver so you would need to do only one
get_seqno() per irq. Also if the list would be sorted (which it wasn't
in my patch) it would prevent signalling the fences out of order. But
maybe that's not really a problem for anyone.
Hmm, so if the out of order thing isn't a problem maybe use the wait
queue still but replace the wake_up() with __wake_up() so that the seqno
can be passed in as the key. That's assuming people care about
optimizing the seqno reads.
--
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 1/2] drm/i915: Android sync points for i915 v2
On Wed, Sep 03, 2014 at 06:05:42PM +0100, Chris Wilson wrote: On Wed, Sep 03, 2014 at 07:41:34PM +0300, Ville Syrjälä wrote: Also looks quite a bit like my ring notify doohicky from: http://lists.freedesktop.org/archives/intel-gfx/2014-June/047623.html Indeed, fences look similar :) Except I kept the list in the driver so you would need to do only one get_seqno() per irq. Also if the list would be sorted (which it wasn't in my patch) it would prevent signalling the fences out of order. But maybe that's not really a problem for anyone. Hmm, so if the out of order thing isn't a problem maybe use the wait queue still but replace the wake_up() with __wake_up() so that the seqno can be passed in as the key. That's assuming people care about optimizing the seqno reads. No, we don't care about plain seqno reads - they're a cached read. I guess I should clarify - after a single irq coherency barrier, they're cheap. -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 1/2] drm/i915: Android sync points for i915 v2
On Wed, Sep 03, 2014 at 07:41:34PM +0300, Ville Syrjälä wrote: Also looks quite a bit like my ring notify doohicky from: http://lists.freedesktop.org/archives/intel-gfx/2014-June/047623.html Indeed, fences look similar :) Except I kept the list in the driver so you would need to do only one get_seqno() per irq. Also if the list would be sorted (which it wasn't in my patch) it would prevent signalling the fences out of order. But maybe that's not really a problem for anyone. Hmm, so if the out of order thing isn't a problem maybe use the wait queue still but replace the wake_up() with __wake_up() so that the seqno can be passed in as the key. That's assuming people care about optimizing the seqno reads. No, we don't care about plain seqno reads - they're a cached read. But having a kthread dedicated to internal fence signalling makes sense if we have more than just mmioflips waiting. At the moment, I am quite happy with using one of the system kthread pool for just mmioflips. -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] igt_core: zero exit_handler_count before forking
From: Paulo Zanoni paulo.r.zan...@intel.com
If we don't reset exit_handler_count before forking, we may have a
case where the forked process is killed before it even does
exit_handler_count = 0: in that case, it is still finishing forking.
When that happens, we may end up calling our exit handlers. On the
specific bug I'm investigating, we call igt_reset_connnectors(), which
ends up in a deadlock inside malloc_atfork. If we attach gdb to the
forked process and get a backtrace, we have:
(gdb) bt
0 __lll_lock_wait_private () at
../nptl/sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:95
1 0x7f15634d36bf in _L_lock_10524 () from /lib/x86_64-linux-gnu/libc.so.6
2 0x7f15634d12ef in malloc_atfork (sz=139729840351352, caller=optimized
out) at arena.c:181
3 0x7f15640466a1 in drmMalloc () from /usr/lib/x86_64-linux-gnu/libdrm.so.2
4 0x7f1564049ad7 in drmModeGetResources () from
/usr/lib/x86_64-linux-gnu/libdrm.so.2
5 0x00408f84 in igt_reset_connectors () at igt_kms.c:1656
6 0x004092dc in call_exit_handlers (sig=15) at igt_core.c:1130
7 fatal_sig_handler (sig=15) at igt_core.c:1154
8 signal handler called
9 0x7f15634cce60 in ptmalloc_unlock_all2 () at arena.c:298
10 0x7f156350ca3f in __libc_fork () at
../nptl/sysdeps/unix/sysv/linux/x86_64/../fork.c:188
11 0x0040a029 in __igt_fork_helper (proc=proc@entry=0x610fc4
signal_helper) at igt_core.c:910
12 0x0040459d in igt_fork_signal_helper () at igt_aux.c:110
13 0x00402ab7 in __real_main63 () at bug.c:76
14 0x0040296e in main (argc=optimized out, argv=optimized out) at
bug.c:63
After doing some searches for stuck at malloc_atfork, it seems to me
we probably shouldn't be doing any malloc calls at this point of the
code, so the best way to do that is to make sure we can't really run
the exit handlers.
So on this patch, instead of resetting the exit handlers after
forking, we reset them before forking, and then restore the original
value on the parent process.
I can reproduce this problem by running ./kms_flip --run-subtest
2x-flip-vs-modeset under an infinite loop. Usually after a few
hundred calls, we end up stuck on the deadlock mentioned above. QA
says this problem happens every time, but I'm not sure what is the
difference between our environments that makes the race condition so
much easier for them.
The kms_flip.c problem can be considered a regression introduced by:
commit eef768f283466b6d7cb3f08381f72ccf3951dc99
Author: Thomas Wood thomas.w...@intel.com
Date: Wed Jun 18 14:28:43 2014 +0100
tests: enable extra connectors in kms_flip and kms_pipe_crc_basic
even though this commit is not the one that introduced the real
problem.
It is also possible to reproduce this problem with a few modifications
to template.c:
- Add a call to igt_enable_connectors() inside the first fixture.
- Add igt_fork_signal_helper() and igt_stop_signal_helper() calls
around subtest B.
Cc: Thomas Wood thomas.w...@intel.com
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=81367
Signed-off-by: Paulo Zanoni paulo.r.zan...@intel.com
---
lib/igt_core.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/lib/igt_core.c b/lib/igt_core.c
index 7f14b17..e9a27e3 100644
--- a/lib/igt_core.c
+++ b/lib/igt_core.c
@@ -895,6 +895,7 @@ bool __igt_fork_helper(struct igt_helper_process *proc)
{
pid_t pid;
int id;
+ int tmp_count;
assert(!proc-running);
assert(helper_process_count ARRAY_SIZE(helper_process_pids));
@@ -904,16 +905,19 @@ bool __igt_fork_helper(struct igt_helper_process *proc)
igt_install_exit_handler(fork_helper_exit_handler);
+ tmp_count = exit_handler_count;
+ exit_handler_count = 0;
switch (pid = fork()) {
case -1:
+ exit_handler_count = tmp_count;
igt_assert(0);
case 0:
- exit_handler_count = 0;
reset_helper_process_list();
oom_adjust_for_doom();
return true;
default:
+ exit_handler_count = tmp_count;
proc-running = true;
proc-pid = pid;
proc-id = id;
--
2.1.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Fix unsafe vma iteration in i915_drop_caches
When unbinding, there is a possibility that we drop the active reference
on the object, thereby freeing it. If that happens, we may destroy the
vm link as well as the object and vma. So iterate carefully.
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
---
drivers/gpu/drm/i915/i915_debugfs.c | 17 +++--
1 file changed, 11 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index 4bac550fe829..fba36ea263f0 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -3894,8 +3894,6 @@ i915_drop_caches_set(void *data, u64 val)
struct drm_device *dev = data;
struct drm_i915_private *dev_priv = dev-dev_private;
struct drm_i915_gem_object *obj, *next;
- struct i915_address_space *vm;
- struct i915_vma *vma, *x;
int ret;
DRM_DEBUG(Dropping caches: 0x%08llx\n, val);
@@ -3916,16 +3914,23 @@ i915_drop_caches_set(void *data, u64 val)
i915_gem_retire_requests(dev);
if (val DROP_BOUND) {
- list_for_each_entry(vm, dev_priv-vm_list, global_link) {
- list_for_each_entry_safe(vma, x, vm-inactive_list,
-mm_list) {
+ list_for_each_entry_safe(obj, next, dev_priv-mm.bound_list,
+global_list) {
+ struct i915_vma *vma, *v;
+
+ ret = 0;
+ drm_gem_object_reference(obj-base);
+ list_for_each_entry_safe(vma, v, obj-vma_list,
vma_link) {
if (vma-pin_count)
continue;
ret = i915_vma_unbind(vma);
if (ret)
- goto unlock;
+ break;
}
+ drm_gem_object_unreference(obj-base);
+ if (ret)
+ goto unlock;
}
}
--
2.1.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: allow sync points within batches
On Wed, Sep 3, 2014 at 9:01 PM, Jesse Barnes jbar...@virtuousgeek.org wrote: On Wed, 3 Sep 2014 17:08:53 +0100 Chris Wilson ch...@chris-wilson.co.uk wrote: On Wed, Sep 03, 2014 at 08:41:06AM -0700, Jesse Barnes wrote: On Wed, 3 Sep 2014 08:01:55 +0100 Chris Wilson ch...@chris-wilson.co.uk wrote: These commands are illegal/invalid inside the object, only valid inside the ring. Hm, we ought to be able to write to no privileged space with STORE_DWORD, but that does mean moving to context specific pages in process space, or at least adding them to our existing scheme. The per-process context page also doesn't exist generically. I certainly hope that userspace can't overwrite the hws! Imagine if we were using that for interrupt status reads, or seqno tracking... Yeah I'm thinking of an additional hws that's per-context and userspace mappable. It could come in handy for userspace only sync stuff. Userspace can already do seqno writes with MI_FLUSH_DW or PIPE_CONTROL - lots of igt tests actually do that for correctness checks. So the only thing really is interrupts, and I think for that we really want the full request tracking machinery in the kernel (otherwise I fear we'll have even more fun with lost/spurious interrupts since the hw guys just seem to not be able to get that right). Which means a full batch split. I have no idea how that's supposed to work when userspace does direct hardware submission. But that's kinda a good reason not to do that anyway, and at least for now it looks like direct hw submission is for opencl2 only with interop with other devices (where sync matters) not a use-case. For interop with other processes the gpu can always do a seqno write to some shared page. And busy-looping, but apparently that's what people want for low-latency. Or at least what designers seem to think people want ... -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - 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: allow sync points within batches
On Wed, 3 Sep 2014 21:41:02 +0200 Daniel Vetter dan...@ffwll.ch wrote: On Wed, Sep 3, 2014 at 9:01 PM, Jesse Barnes jbar...@virtuousgeek.org wrote: On Wed, 3 Sep 2014 17:08:53 +0100 Chris Wilson ch...@chris-wilson.co.uk wrote: On Wed, Sep 03, 2014 at 08:41:06AM -0700, Jesse Barnes wrote: On Wed, 3 Sep 2014 08:01:55 +0100 Chris Wilson ch...@chris-wilson.co.uk wrote: These commands are illegal/invalid inside the object, only valid inside the ring. Hm, we ought to be able to write to no privileged space with STORE_DWORD, but that does mean moving to context specific pages in process space, or at least adding them to our existing scheme. The per-process context page also doesn't exist generically. I certainly hope that userspace can't overwrite the hws! Imagine if we were using that for interrupt status reads, or seqno tracking... Yeah I'm thinking of an additional hws that's per-context and userspace mappable. It could come in handy for userspace only sync stuff. Userspace can already do seqno writes with MI_FLUSH_DW or PIPE_CONTROL - lots of igt tests actually do that for correctness checks. So the only thing really is interrupts, and I think for that we really want the full request tracking machinery in the kernel (otherwise I fear we'll have even more fun with lost/spurious interrupts since the hw guys just seem to not be able to get that right). Which means a full batch split. I have no idea how that's supposed to work when userspace does direct hardware submission. But that's kinda a good reason not to do that anyway, and at least for now it looks like direct hw submission is for opencl2 only with interop with other devices (where sync matters) not a use-case. For interop with other processes the gpu can always do a seqno write to some shared page. And busy-looping, but apparently that's what people want for low-latency. Or at least what designers seem to think people want ... Yeah I haven't thought how direct submission will work in terms of IPC. It may just have to be done in userland with a custom cooperative mechanism... -- Jesse Barnes, Intel Open Source Technology Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH -v3 3/4] drm/i915: split intel_cursor_plane_update() into check() and commit()
From: Gustavo Padovan gustavo.pado...@collabora.co.uk
Due to the upcoming atomic modesetting feature we need to separate
some update functions into a check step that can fail and a commit
step that should, ideally, never fail.
The commit part can still fail, but that should be solved in another
upcoming patch.
Signed-off-by: Gustavo Padovan gustavo.pado...@collabora.co.uk
---
drivers/gpu/drm/i915/intel_display.c | 104 ++-
1 file changed, 67 insertions(+), 37 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 22d3902..c3f1967 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -11896,51 +11896,42 @@ intel_cursor_plane_disable(struct drm_plane *plane)
}
static int
-intel_cursor_plane_update(struct drm_plane *plane, struct drm_crtc *crtc,
- struct drm_framebuffer *fb, int crtc_x, int crtc_y,
- unsigned int crtc_w, unsigned int crtc_h,
- uint32_t src_x, uint32_t src_y,
- uint32_t src_w, uint32_t src_h)
+intel_check_cursor_plane(struct drm_plane *plane,
+struct intel_plane_state *state)
{
- struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
- struct intel_framebuffer *intel_fb = to_intel_framebuffer(fb);
- struct drm_i915_gem_object *obj = intel_fb-obj;
- struct drm_rect dest = {
- /* integer pixels */
- .x1 = crtc_x,
- .y1 = crtc_y,
- .x2 = crtc_x + crtc_w,
- .y2 = crtc_y + crtc_h,
- };
- struct drm_rect src = {
- /* 16.16 fixed point */
- .x1 = src_x,
- .y1 = src_y,
- .x2 = src_x + src_w,
- .y2 = src_y + src_h,
- };
- const struct drm_rect clip = {
- /* integer pixels */
- .x2 = intel_crtc-active ? intel_crtc-config.pipe_src_w : 0,
- .y2 = intel_crtc-active ? intel_crtc-config.pipe_src_h : 0,
- };
- bool visible;
- int ret;
+ struct drm_crtc *crtc = state-crtc;
+ struct drm_framebuffer *fb = state-fb;
+ struct drm_rect *dest = state-dst;
+ struct drm_rect *src = state-src;
+ const struct drm_rect *clip = state-clip;
- ret = drm_plane_helper_check_update(plane, crtc, fb,
- src, dest, clip,
+ return drm_plane_helper_check_update(plane, crtc, fb,
+ src, dest, clip,
DRM_PLANE_HELPER_NO_SCALING,
DRM_PLANE_HELPER_NO_SCALING,
- true, true, visible);
- if (ret)
- return ret;
+ true, true, state-visible);
+}
- crtc-cursor_x = crtc_x;
- crtc-cursor_y = crtc_y;
+static int
+intel_commit_cursor_plane(struct drm_plane *plane,
+ struct intel_plane_state *state)
+{
+ struct drm_crtc *crtc = state-crtc;
+ struct drm_framebuffer *fb = state-fb;
+ struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
+ struct intel_framebuffer *intel_fb = to_intel_framebuffer(fb);
+ struct drm_i915_gem_object *obj = intel_fb-obj;
+ struct drm_rect *dest = state-dst;
+ int crtc_w, crtc_h;
+
+ crtc-cursor_x = state-dst.x1;
+ crtc-cursor_y = state-dst.y1;
if (fb != crtc-cursor-fb) {
+ crtc_w = drm_rect_width(dest);
+ crtc_h = drm_rect_height(dest);
return intel_crtc_cursor_set_obj(crtc, obj, crtc_w, crtc_h);
} else {
- intel_crtc_update_cursor(crtc, visible);
+ intel_crtc_update_cursor(crtc, state-visible);
intel_frontbuffer_flip(crtc-dev,
INTEL_FRONTBUFFER_CURSOR(intel_crtc-pipe));
@@ -11948,6 +11939,45 @@ intel_cursor_plane_update(struct drm_plane *plane,
struct drm_crtc *crtc,
return 0;
}
}
+
+static int
+intel_cursor_plane_update(struct drm_plane *plane, struct drm_crtc *crtc,
+ struct drm_framebuffer *fb, int crtc_x, int crtc_y,
+ unsigned int crtc_w, unsigned int crtc_h,
+ uint32_t src_x, uint32_t src_y,
+ uint32_t src_w, uint32_t src_h)
+{
+ struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
+ struct intel_plane_state state;
+ int ret;
+
+ state.crtc = crtc;
+ state.fb = fb;
+
+ /* sample coordinates in 16.16 fixed point */
+ state.src.x1 = src_x;
+ state.src.x2 = src_x + src_w;
+ state.src.y1 = src_y;
+ state.src.y2 = src_y + src_h;
+
+ /* integer pixels */
+ state.dst.x1 = crtc_x;
+
[Intel-gfx] [PATCH -v3 0/4] split plane's updates functions into check() and commit()
From: Gustavo Padovan gustavo.pado...@collabora.co.uk This is the beginning of the work to prepare i915 for the upcoming atomic modesetting API. Here we split the plane update fucntions in the check and commit states. v2: use struct intel_plane_state to keep states between check and commit stages. v3: take Ville's comments - rename pstate to state - get rid of non-drm_rect coordinates in intel_plane_state - keep 'clip' const Gustavo Padovan (4): drm/i915: create struct intel_plane_state drm/i915: split intel_update_plane into check() and commit() drm/i915: split intel_cursor_plane_update() into check() and commit() drm/i915: split intel_primary_plane_setplane() into check() and commit() drivers/gpu/drm/i915/intel_display.c | 234 +++- drivers/gpu/drm/i915/intel_drv.h | 12 ++ drivers/gpu/drm/i915/intel_sprite.c | 253 +-- 3 files changed, 301 insertions(+), 198 deletions(-) -- 1.9.3 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH -v3 4/4] drm/i915: split intel_primary_plane_setplane() into check() and commit()
From: Gustavo Padovan gustavo.pado...@collabora.co.uk
As a preparation for atomic updates we need to split the code to check
everything we are going to commit first. This patch starts the work to
split intel_primary_plane_setplane() into check() and commit() parts.
More work is expected on this to get a better split of the two steps.
Ideally the commit() step should never fail.
Signed-off-by: Gustavo Padovan gustavo.pado...@collabora.co.uk
---
drivers/gpu/drm/i915/intel_display.c | 130 +++
1 file changed, 72 insertions(+), 58 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index c3f1967..1e3985b 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -11663,63 +11663,37 @@ disable_unpin:
}
static int
-intel_primary_plane_setplane(struct drm_plane *plane, struct drm_crtc *crtc,
-struct drm_framebuffer *fb, int crtc_x, int crtc_y,
-unsigned int crtc_w, unsigned int crtc_h,
-uint32_t src_x, uint32_t src_y,
-uint32_t src_w, uint32_t src_h)
+intel_check_primary_plane(struct drm_plane *plane,
+ struct intel_plane_state *state)
+{
+ struct drm_crtc *crtc = state-crtc;
+ struct drm_framebuffer *fb = state-fb;
+ struct drm_rect *dest = state-dst;
+ struct drm_rect *src = state-src;
+ const struct drm_rect *clip = state-clip;
+
+ return drm_plane_helper_check_update(plane, crtc, fb,
+ src, dest, clip,
+ DRM_PLANE_HELPER_NO_SCALING,
+ DRM_PLANE_HELPER_NO_SCALING,
+ false, true, state-visible);
+}
+
+static int
+intel_commit_primary_plane(struct drm_plane *plane,
+ struct intel_plane_state *state)
{
+ struct drm_crtc *crtc = state-crtc;
+ struct drm_framebuffer *fb = state-fb;
struct drm_device *dev = crtc-dev;
struct drm_i915_private *dev_priv = dev-dev_private;
struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
struct drm_i915_gem_object *obj = intel_fb_obj(fb);
struct drm_i915_gem_object *old_obj = intel_fb_obj(plane-fb);
- struct drm_rect dest = {
- /* integer pixels */
- .x1 = crtc_x,
- .y1 = crtc_y,
- .x2 = crtc_x + crtc_w,
- .y2 = crtc_y + crtc_h,
- };
- struct drm_rect src = {
- /* 16.16 fixed point */
- .x1 = src_x,
- .y1 = src_y,
- .x2 = src_x + src_w,
- .y2 = src_y + src_h,
- };
- const struct drm_rect clip = {
- /* integer pixels */
- .x2 = intel_crtc-active ? intel_crtc-config.pipe_src_w : 0,
- .y2 = intel_crtc-active ? intel_crtc-config.pipe_src_h : 0,
- };
- const struct {
- int crtc_x, crtc_y;
- unsigned int crtc_w, crtc_h;
- uint32_t src_x, src_y, src_w, src_h;
- } orig = {
- .crtc_x = crtc_x,
- .crtc_y = crtc_y,
- .crtc_w = crtc_w,
- .crtc_h = crtc_h,
- .src_x = src_x,
- .src_y = src_y,
- .src_w = src_w,
- .src_h = src_h,
- };
struct intel_plane *intel_plane = to_intel_plane(plane);
- bool visible;
+ struct drm_rect *src = state-src;
int ret;
- ret = drm_plane_helper_check_update(plane, crtc, fb,
- src, dest, clip,
- DRM_PLANE_HELPER_NO_SCALING,
- DRM_PLANE_HELPER_NO_SCALING,
- false, true, visible);
-
- if (ret)
- return ret;
-
/*
* If the CRTC isn't enabled, we're just pinning the framebuffer,
* updating the fb pointer, and returning without touching the
@@ -11754,7 +11728,7 @@ intel_primary_plane_setplane(struct drm_plane *plane,
struct drm_crtc *crtc,
* happens if userspace explicitly disables the plane by passing fb=0
* because plane-fb still gets set and pinned.
*/
- if (!visible) {
+ if (!state-visible) {
mutex_lock(dev-struct_mutex);
/*
@@ -11801,7 +11775,7 @@ intel_primary_plane_setplane(struct drm_plane *plane,
struct drm_crtc *crtc,
intel_disable_fbc(dev);
}
}
- ret = intel_pipe_set_base(crtc, src.x1, src.y1, fb);
+ ret = intel_pipe_set_base(crtc, src-x1, src-y1, fb);
if (ret)
return ret;
@@ -11809,19
[Intel-gfx] [PATCH -v3 1/4] drm/i915: create struct intel_plane_state
From: Gustavo Padovan gustavo.pado...@collabora.co.uk
This new struct will be the storage of src and dst coordinates
between the check and commit stages of a plane update.
Signed-off-by: Gustavo Padovan gustavo.pado...@collabora.co.uk
---
drivers/gpu/drm/i915/intel_drv.h | 12
1 file changed, 12 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index d727d20..be668ea 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -34,6 +34,7 @@
#include drm/drm_crtc_helper.h
#include drm/drm_fb_helper.h
#include drm/drm_dp_mst_helper.h
+#include drm/drm_rect.h
/**
* _wait_for - magic (register) wait macro
@@ -237,6 +238,17 @@ typedef struct dpll {
int p;
} intel_clock_t;
+struct intel_plane_state {
+ struct drm_crtc *crtc;
+ struct drm_framebuffer *fb;
+ struct drm_rect src;
+ struct drm_rect dst;
+ struct drm_rect clip;
+ struct drm_rect orig_src;
+ struct drm_rect orig_dst;
+ bool visible;
+};
+
struct intel_plane_config {
bool tiled;
int size;
--
1.9.3
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH -v3 2/4] drm/i915: split intel_update_plane into check() and commit()
From: Gustavo Padovan gustavo.pado...@collabora.co.uk
Due to the upcoming atomic modesetting feature we need to separate
some update functions into a check step that can fail and a commit
step that should, ideally, never fail.
This commit splits intel_update_plane() and its commit part can still
fail due to the fb pinning procedure.
Signed-off-by: Gustavo Padovan gustavo.pado...@collabora.co.uk
---
drivers/gpu/drm/i915/intel_sprite.c | 253 +---
1 file changed, 150 insertions(+), 103 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_sprite.c
b/drivers/gpu/drm/i915/intel_sprite.c
index 07a74ef..7b0d1a9 100644
--- a/drivers/gpu/drm/i915/intel_sprite.c
+++ b/drivers/gpu/drm/i915/intel_sprite.c
@@ -845,57 +845,24 @@ static bool colorkey_enabled(struct intel_plane
*intel_plane)
}
static int
-intel_update_plane(struct drm_plane *plane, struct drm_crtc *crtc,
- struct drm_framebuffer *fb, int crtc_x, int crtc_y,
- unsigned int crtc_w, unsigned int crtc_h,
- uint32_t src_x, uint32_t src_y,
- uint32_t src_w, uint32_t src_h)
+intel_check_sprite_plane(struct drm_plane *plane,
+struct intel_plane_state *state)
{
- struct drm_device *dev = plane-dev;
- struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
+ struct intel_crtc *intel_crtc = to_intel_crtc(state-crtc);
struct intel_plane *intel_plane = to_intel_plane(plane);
- enum pipe pipe = intel_crtc-pipe;
+ struct drm_framebuffer *fb = state-fb;
struct intel_framebuffer *intel_fb = to_intel_framebuffer(fb);
struct drm_i915_gem_object *obj = intel_fb-obj;
- struct drm_i915_gem_object *old_obj = intel_plane-obj;
- int ret;
- bool primary_enabled;
- bool visible;
+ int crtc_x, crtc_y;
+ unsigned int crtc_w, crtc_h;
+ uint32_t src_x, src_y, src_w, src_h;
+ struct drm_rect *src = state-src;
+ struct drm_rect *dst = state-dst;
+ struct drm_rect *orig_src = state-orig_src;
+ const struct drm_rect *clip = state-clip;
int hscale, vscale;
int max_scale, min_scale;
int pixel_size = drm_format_plane_cpp(fb-pixel_format, 0);
- struct drm_rect src = {
- /* sample coordinates in 16.16 fixed point */
- .x1 = src_x,
- .x2 = src_x + src_w,
- .y1 = src_y,
- .y2 = src_y + src_h,
- };
- struct drm_rect dst = {
- /* integer pixels */
- .x1 = crtc_x,
- .x2 = crtc_x + crtc_w,
- .y1 = crtc_y,
- .y2 = crtc_y + crtc_h,
- };
- const struct drm_rect clip = {
- .x2 = intel_crtc-active ? intel_crtc-config.pipe_src_w : 0,
- .y2 = intel_crtc-active ? intel_crtc-config.pipe_src_h : 0,
- };
- const struct {
- int crtc_x, crtc_y;
- unsigned int crtc_w, crtc_h;
- uint32_t src_x, src_y, src_w, src_h;
- } orig = {
- .crtc_x = crtc_x,
- .crtc_y = crtc_y,
- .crtc_w = crtc_w,
- .crtc_h = crtc_h,
- .src_x = src_x,
- .src_y = src_y,
- .src_w = src_w,
- .src_h = src_h,
- };
/* Don't modify another pipe's plane */
if (intel_plane-pipe != intel_crtc-pipe) {
@@ -927,55 +894,55 @@ intel_update_plane(struct drm_plane *plane, struct
drm_crtc *crtc,
max_scale = intel_plane-max_downscale 16;
min_scale = intel_plane-can_scale ? 1 : (1 16);
- drm_rect_rotate(src, fb-width 16, fb-height 16,
+ drm_rect_rotate(src, fb-width 16, fb-height 16,
intel_plane-rotation);
- hscale = drm_rect_calc_hscale_relaxed(src, dst, min_scale, max_scale);
+ hscale = drm_rect_calc_hscale_relaxed(src, dst, min_scale, max_scale);
BUG_ON(hscale 0);
- vscale = drm_rect_calc_vscale_relaxed(src, dst, min_scale, max_scale);
+ vscale = drm_rect_calc_vscale_relaxed(src, dst, min_scale, max_scale);
BUG_ON(vscale 0);
- visible = drm_rect_clip_scaled(src, dst, clip, hscale, vscale);
+ state-visible = drm_rect_clip_scaled(src, dst, clip, hscale, vscale);
- crtc_x = dst.x1;
- crtc_y = dst.y1;
- crtc_w = drm_rect_width(dst);
- crtc_h = drm_rect_height(dst);
+ crtc_x = dst-x1;
+ crtc_y = dst-y1;
+ crtc_w = drm_rect_width(dst);
+ crtc_h = drm_rect_height(dst);
- if (visible) {
+ if (state-visible) {
/* check again in case clipping clamped the results */
- hscale = drm_rect_calc_hscale(src, dst, min_scale, max_scale);
+ hscale = drm_rect_calc_hscale(src, dst, min_scale, max_scale);
if (hscale 0) {
DRM_DEBUG_KMS(Horizontal scaling
Re: [Intel-gfx] [PATCH 1/2] drm/i915: clear up wedged transitions
On Thu, Nov 15, 2012 at 05:17:22PM +0100, Daniel Vetter wrote: We have two important transitions of the wedged state in the current code: - 0 - 1: This means a hang has been detected, and signals to everyone that they please get of any locks, so that the reset work item can do its job. - 1 - 0: The reset handler has completed. Now the last transition mixes up two states: Reset completed and successful and Reset failed. To distinguish these two we do some tricks with the reset completion, but I simply could not convince myself that this doesn't race under odd circumstances. Hence split this up, and add a new terminal state indicating that the hw is gone for good. Also add explicit #defines for both states, update comments. v2: Split out the reset handling bugfix for the throttle ioctl. v3: s/tmp/wedged/ sugested by Chris Wilson. Also fixup up a rebase error which prevented this patch from actually compiling. v4: To unify the wedged state with the reset counter, keep the reset-in-progress state just as a flag. The terminally-wedged state is now denoted with a big number. v5: Add a comment to the reset_counter special values explaining that WEDGED RESET_IN_PROGRESS needs to be true for the code to be correct. v6: Fixup logic errors introduced with the wedged+reset_counter unification. Since WEDGED implies reset-in-progress (in a way we're terminally stuck in the dead-but-reset-not-completed state), we need ensure that we check for this everywhere. The specific bug was in wait_for_error, which would simply have timed out. v7: Extract an inline i915_reset_in_progress helper to make the code more readable. Also annote the reset-in-progress case with an unlikely, to help the compiler optimize the fastpath. Do the same for the terminally wedged case with i915_terminally_wedged. Signed-Off-by: Daniel Vetter daniel.vet...@ffwll.ch @@ -1385,7 +1372,7 @@ out: /* If this -EIO is due to a gpu hang, give the reset code a * chance to clean up the mess. Otherwise return the proper * SIGBUS. */ - if (!atomic_read(dev_priv-gpu_error.wedged)) + if (i915_terminally_wedged(dev_priv-gpu_error)) return VM_FAULT_SIGBUS; (i915_gem_fault()) This if() is backwards. -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 02/12] tests/kms_sink_crc_basic: Use igt_debugfs_fopen
Signed-off-by: Rodrigo Vivi rodrigo.v...@intel.com
---
tests/kms_sink_crc_basic.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tests/kms_sink_crc_basic.c b/tests/kms_sink_crc_basic.c
index 443f82e..3703dc1 100644
--- a/tests/kms_sink_crc_basic.c
+++ b/tests/kms_sink_crc_basic.c
@@ -52,7 +52,7 @@ typedef struct {
static void get_crc(char *crc) {
int ret;
- FILE *file = fopen(/sys/kernel/debug/dri/0/i915_sink_crc_eDP1, r);
+ FILE *file = igt_debugfs_fopen(i915_sink_crc_eDP1, r);
igt_require(file);
ret = fscanf(file, %s\n, crc);
--
1.9.3
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 11/12] tests/kms_psr_sink_crc: Fix blt submission
Putting back a missing dword. Signed-off-by: Rodrigo Vivi rodrigo.v...@intel.com --- tests/kms_psr_sink_crc.c | 1 + 1 file changed, 1 insertion(+) diff --git a/tests/kms_psr_sink_crc.c b/tests/kms_psr_sink_crc.c index 45d2dd9..c265f3a 100644 --- a/tests/kms_psr_sink_crc.c +++ b/tests/kms_psr_sink_crc.c @@ -125,6 +125,7 @@ static void fill_blt(data_t *data, uint32_t handle, unsigned char color) COLOR_BLIT_COPY_BATCH_START(0); OUT_BATCH((1 24) | (0xf0 16) | 0); + OUT_BATCH(0); OUT_BATCH(1 16 | 4); OUT_RELOC(dst, I915_GEM_DOMAIN_RENDER, I915_GEM_DOMAIN_RENDER, 0); OUT_BATCH(color); -- 1.9.3 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 12/12] tests/kms_psr_sink_crc: Wait 2 vblanks before grabing the new crc.
Signed-off-by: Rodrigo Vivi rodrigo.v...@intel.com
---
tests/kms_psr_sink_crc.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/tests/kms_psr_sink_crc.c b/tests/kms_psr_sink_crc.c
index c265f3a..59c99ec 100644
--- a/tests/kms_psr_sink_crc.c
+++ b/tests/kms_psr_sink_crc.c
@@ -246,6 +246,9 @@ static void get_sink_crc(data_t *data, char *crc) {
int ret;
FILE *file;
+ igt_wait_for_vblank(data-drm_fd, 0);
+ igt_wait_for_vblank(data-drm_fd, 0);
+
file = igt_debugfs_fopen(i915_sink_crc_eDP1, r);
igt_require(file);
@@ -390,7 +393,7 @@ static void run_test(data_t *data)
c-connection != DRM_MODE_CONNECTED)
continue;
- igt_output_set_pipe(output, PIPE_ANY);
+ igt_output_set_pipe(output, 0);
data-crtc_id = output-config.crtc-crtc_id;
mode = igt_output_get_mode(output);
--
1.9.3
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 01/12] tests/pm_psr: Update pm_psr for new psr debug interface.
v2: Doesn't duplicate kernel's HAS_PSR. skip based on debugfs output.
Signed-off-by: Rodrigo Vivi rodrigo.v...@intel.com
---
tests/pm_psr.c | 30 +-
1 file changed, 21 insertions(+), 9 deletions(-)
diff --git a/tests/pm_psr.c b/tests/pm_psr.c
index 3ab7e7a..16ec3fa 100644
--- a/tests/pm_psr.c
+++ b/tests/pm_psr.c
@@ -32,6 +32,8 @@
#include errno.h
#include drmtest.h
+#include intel_chipset.h
+#include igt_debugfs.h
#define SLEEP_DURATION 5000 // in milliseconds
@@ -41,22 +43,34 @@ static int get_perf(const char *path)
FILE *file;
char str[4];
- file = fopen(path, r);
- igt_assert(file);
+ file = igt_debugfs_fopen(i915_edp_psr_status, r);
+ igt_require(file);
ret = fscanf(file, Sink_Support: %s\n, str);
igt_skip_on_f(ret == 0,
i915_edp_psr_status format not supported by this test
case\n);
- igt_require(strcmp(str, yes) == 0);
+ igt_skip_on_f(strcmp(str, yes) != 0,
+ PSR not supported on this platform\n);
+
ret = fscanf(file, Source_OK: %s\n, str);
igt_assert(ret != 0);
-
igt_require(strcmp(str, yes) == 0);
ret = fscanf(file, Enabled: %s\n, str);
igt_assert(ret != 0);
igt_assert(strcmp(str, yes) == 0);
+ ret = fscanf(file, Active: %s\n, str);
+ igt_skip_on_f(ret == 0,
+ i915_edp_psr_status format not supported by this test
case\n);
+
+ ret = fscanf(file, Busy frontbuffer bits: %s\n, str);
+ igt_assert(ret != 0);
+ ret = fscanf(file, Re-enable work scheduled: %s\n, str);
+ igt_assert(ret != 0);
+ ret = fscanf(file, HW Enabled Active bit: %s\n, str);
+ igt_assert(ret != 0);
+
ret = fscanf(file, Performance_Counter: %i, perf);
igt_assert(ret != 0);
@@ -68,15 +82,13 @@ static int get_perf(const char *path)
igt_simple_main
{
- int ret, perf1, perf2;
- int device = drm_get_card();
+ int perf1, perf2;
+ int drm_fd = drm_open_any();
+ uint32_t devid = intel_get_drm_devid(drm_fd);
char *path;
igt_skip_on_simulation();
- ret = asprintf(path, /sys/kernel/debug/dri/%d/i915_edp_psr_status,
device);
- igt_assert(ret != -1);
-
perf1 = get_perf(path);
sleep(SLEEP_DURATION / 1000);
perf2 = get_perf(path);
--
1.9.3
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 03/12] tests/kms_sink_crc_basic: Simplify test by using igt_kms functions
Signed-off-by: Rodrigo Vivi rodrigo.v...@intel.com
---
tests/kms_sink_crc_basic.c | 150 +++--
1 file changed, 48 insertions(+), 102 deletions(-)
diff --git a/tests/kms_sink_crc_basic.c b/tests/kms_sink_crc_basic.c
index 3703dc1..e24220e 100644
--- a/tests/kms_sink_crc_basic.c
+++ b/tests/kms_sink_crc_basic.c
@@ -34,20 +34,15 @@
#include igt_debugfs.h
#include igt_kms.h
-enum color {
- WHITE,
- BLACK,
- NUM_COLORS,
-};
-
-typedef struct {
- struct kmstest_connector_config config;
- struct igt_fb fb;
-} connector_t;
+#define CRC_BLACK
+#define CRC_RED c101
+#define CRC_GREEN c101
typedef struct {
int drm_fd;
- drmModeRes *resources;
+ igt_display_t display;
+ struct igt_fb fb_green, fb_red;
+ igt_plane_t *primary;
} data_t;
static void get_crc(char *crc) {
@@ -59,111 +54,64 @@ static void get_crc(char *crc) {
igt_require(ret 0);
fclose(file);
-}
-
-static uint32_t create_fb(data_t *data,
- int w, int h,
- double r, double g, double b,
- struct igt_fb *fb)
-{
- cairo_t *cr;
- uint32_t fb_id;
-
- fb_id = igt_create_fb(data-drm_fd, w, h,
- DRM_FORMAT_XRGB, I915_TILING_NONE, fb);
- igt_assert(fb_id);
-
- cr = igt_get_cairo_ctx(data-drm_fd, fb);
- igt_paint_color(cr, 0, 0, w, h, r, g, b);
- igt_assert(cairo_status(cr) == 0);
- return fb_id;
+ /* Black screen is always invalid */
+ igt_assert(strcmp(crc, CRC_BLACK) != 0);
}
-static bool
-connector_set_mode(data_t *data, connector_t *connector, drmModeModeInfo *mode,
- enum color crtc_color)
+static void basic_sink_crc_check(data_t *data)
{
- struct kmstest_connector_config *config = connector-config;
- unsigned int fb_id;
- int ret;
-
- if (crtc_color == WHITE)
- fb_id = create_fb(data, mode-hdisplay, mode-vdisplay,
- 1.0, 1.0, 1.0, connector-fb);
- else
- fb_id = create_fb(data, mode-hdisplay, mode-vdisplay,
- 0.0, 0.0, 0.0, connector-fb);
- igt_assert(fb_id);
-
- ret = drmModeSetCrtc(data-drm_fd,
-config-crtc-crtc_id,
-connector-fb.fb_id,
-0, 0, /* x, y */
-config-connector-connector_id,
-1,
-mode);
- igt_assert(ret == 0);
-
- return 0;
-}
-
-static void basic_sink_crc_check(data_t *data, uint32_t connector_id)
-{
- connector_t connector;
- char ref_crc_white[12];
- char ref_crc_black[12];
- char crc_check[12];
-
- igt_require(kmstest_get_connector_config(data-drm_fd,
-connector_id,
-1 0,
-connector.config));
+ char crc[12];
- /*Go White*/
- connector_set_mode(data, connector, connector.config.default_mode,
WHITE);
+ /* Go Green */
+ igt_plane_set_fb(data-primary, data-fb_green);
+ igt_display_commit(data-display);
- /* get reference crc for white color */
- get_crc(ref_crc_white);
+ /* It should be Green */
+ get_crc(crc);
+ igt_assert(strcmp(crc, CRC_GREEN) == 0);
- /* Go Black */
- connector_set_mode(data, connector, connector.config.default_mode,
BLACK);
+ /* Go Red */
+ igt_plane_set_fb(data-primary, data-fb_red);
+ igt_display_commit(data-display);
- /* get reference crc for black color */
- get_crc(ref_crc_black);
-
- igt_assert(strcmp(ref_crc_black, ref_crc_white) != 0);
-
- /*Go White again*/
- connector_set_mode(data, connector, connector.config.default_mode,
WHITE);
-
- get_crc(crc_check);
- igt_assert(strcmp(crc_check, ref_crc_white) == 0);
-
- /* Go Black again */
- connector_set_mode(data, connector, connector.config.default_mode,
BLACK);
-
- get_crc(crc_check);
- igt_assert(strcmp(crc_check, ref_crc_black) == 0);
-
- kmstest_free_connector_config(connector.config);
+ /* It should be Red */
+ get_crc(crc);
+ igt_assert(strcmp(crc, CRC_RED) == 0);
}
static void run_test(data_t *data)
{
- int i;
- drmModeConnectorPtr c;
- uint32_t connector_id = 0;
+ igt_display_t *display = data-display;
+ igt_output_t *output;
+ drmModeModeInfo *mode;
- for (i = 0; i data-resources-count_connectors; i++) {
- connector_id = data-resources-connectors[i];
- c = drmModeGetConnector(data-drm_fd, connector_id);
+ for_each_connected_output(display, output) {
+
[Intel-gfx] [PATCH 05/12] tests/kms_psr_sink_crc: Adding test debug options
Just to make life easier and be eable to easily test with
PSR disabled to know exactly what to expect when running it
for real
Signed-off-by: Rodrigo Vivi rodrigo.v...@intel.com
---
tests/kms_psr_sink_crc.c | 22 +-
1 file changed, 21 insertions(+), 1 deletion(-)
diff --git a/tests/kms_psr_sink_crc.c b/tests/kms_psr_sink_crc.c
index 0917a7f..01521bb 100644
--- a/tests/kms_psr_sink_crc.c
+++ b/tests/kms_psr_sink_crc.c
@@ -57,6 +57,11 @@ enum tests {
TEST_SPRITE,
};
+#define DEBUG_CRC 0
+
+/* This is usefull to debug and know what should be expected */
+#define RUNNING_WITH_PSR_DISABLED 0
+
typedef struct {
int drm_fd;
enum tests test;
@@ -264,6 +269,9 @@ static bool psr_enabled(data_t *data)
FILE *file;
char str[4];
+ if (RUNNING_WITH_PSR_DISABLED)
+ return true;
+
file = igt_debugfs_fopen(i915_edp_psr_status, r);
igt_require(file);
@@ -284,6 +292,9 @@ static bool psr_active(data_t *data)
FILE *file;
char str[4];
+ if (RUNNING_WITH_PSR_DISABLED)
+ return true;
+
file = igt_debugfs_fopen(i915_edp_psr_status, r);
igt_require(file);
@@ -327,6 +338,16 @@ static void get_sink_crc(data_t *data, char *crc) {
igt_require(ret 0);
fclose(file);
+
+ if (DEBUG_CRC) {
+ fprintf(stderr, %s\n, crc);
+ sleep(1);
+ }
+
+ /* The important value was already taken.
+* Now give a time for human eyes
+*/
+ usleep(30);
}
static void test_crc(data_t *data)
@@ -342,7 +363,6 @@ static void test_crc(data_t *data)
1, 1) == 0);
}
- usleep(30);
igt_assert(wait_psr_entry(data, 10));
get_sink_crc(data, ref_crc);
--
1.9.3
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 04/12] tests/kms_psr_sink_crc: Fix edp_psr debugfs interface
Tests were broken on platforms that doesn't have psr or on new kernel that
contains new interface.
A lot more need to be done to get these tests really useful, but for now lets
avoid it breaking
tests framework.
v2: Doesn't duplicate kernel's HAS_PSR. skip based on debugfs output.
Signed-off-by: Rodrigo Vivi rodrigo.v...@intel.com
---
tests/kms_psr_sink_crc.c | 27 +--
1 file changed, 17 insertions(+), 10 deletions(-)
diff --git a/tests/kms_psr_sink_crc.c b/tests/kms_psr_sink_crc.c
index 49f9549..0917a7f 100644
--- a/tests/kms_psr_sink_crc.c
+++ b/tests/kms_psr_sink_crc.c
@@ -258,7 +258,7 @@ static void fill_render(data_t *data, uint32_t handle,
gem_bo_busy(data-drm_fd, handle);
}
-static bool psr_sink_support(data_t *data)
+static bool psr_enabled(data_t *data)
{
int ret;
FILE *file;
@@ -268,14 +268,17 @@ static bool psr_sink_support(data_t *data)
igt_require(file);
ret = fscanf(file, Sink_Support: %s\n, str);
- igt_skip_on_f(ret == 0,
- i915_edp_psr_status format not supported by this test
case\n);
+ igt_assert(ret != 0);
+ ret = fscanf(file, Source_OK: %s\n, str);
+ igt_assert(ret != 0);
+ ret = fscanf(file, Enabled: %s\n, str);
+ igt_assert(ret != 0);
fclose(file);
return strcmp(str, yes) == 0;
}
-static bool psr_enabled(data_t *data)
+static bool psr_active(data_t *data)
{
int ret;
FILE *file;
@@ -286,12 +289,18 @@ static bool psr_enabled(data_t *data)
ret = fscanf(file, Sink_Support: %s\n, str);
igt_assert(ret != 0);
-
ret = fscanf(file, Source_OK: %s\n, str);
igt_assert(ret != 0);
-
ret = fscanf(file, Enabled: %s\n, str);
igt_assert(ret != 0);
+ ret = fscanf(file, Active: %s\n, str);
+ igt_assert(ret != 0);
+ ret = fscanf(file, Busy frontbuffer bits: %s\n, str);
+ igt_assert(ret != 0);
+ ret = fscanf(file, Re-enable work scheduled: %s\n, str);
+ igt_assert(ret != 0);
+ ret = fscanf(file, HW Enabled Active bit: %s\n, str);
+ igt_assert(ret != 0);
fclose(file);
return strcmp(str, yes) == 0;
@@ -300,7 +309,7 @@ static bool psr_enabled(data_t *data)
static bool wait_psr_entry(data_t *data, int timeout)
{
while (timeout--) {
- if (psr_enabled(data))
+ if (psr_active(data))
return true;
sleep(1);
}
@@ -512,8 +521,6 @@ static void test_sprite(data_t *data)
igt_output_t *output;
drmModeModeInfo *mode;
- igt_skip_on(IS_HASWELL(data-devid));
-
for_each_connected_output(display, output) {
drmModeConnectorPtr c = output-config.connector;
@@ -592,7 +599,7 @@ igt_main
data.devid = intel_get_drm_devid(data.drm_fd);
- igt_require(psr_sink_support(data));
+ igt_skip_on(!psr_enabled(data));
data.bufmgr = drm_intel_bufmgr_gem_init(data.drm_fd, 4096);
igt_assert(data.bufmgr);
--
1.9.3
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 06/12] tests/kms_psr_sink_crc: Removing context tests.
This tests are unecessary. Mainly now with the software tracking for PSR.
Signed-off-by: Rodrigo Vivi rodrigo.v...@intel.com
---
tests/kms_psr_sink_crc.c | 69 +++-
1 file changed, 3 insertions(+), 66 deletions(-)
diff --git a/tests/kms_psr_sink_crc.c b/tests/kms_psr_sink_crc.c
index 01521bb..ee5ad81 100644
--- a/tests/kms_psr_sink_crc.c
+++ b/tests/kms_psr_sink_crc.c
@@ -47,12 +47,10 @@ enum tests {
TEST_SETDOMAIN_WAIT_WRITE_CPU,
TEST_BLT,
TEST_RENDER,
- TEST_CONTEXT,
TEST_PAGE_FLIP_AND_MMAP_CPU,
TEST_PAGE_FLIP_AND_MMAP_GTT,
TEST_PAGE_FLIP_AND_BLT,
TEST_PAGE_FLIP_AND_RENDER,
- TEST_PAGE_FLIP_AND_CONTEXT,
TEST_CURSOR_MOVE,
TEST_SPRITE,
};
@@ -67,7 +65,6 @@ typedef struct {
enum tests test;
drmModeRes *resources;
drm_intel_bufmgr *bufmgr;
- drm_intel_context *ctx[2];
uint32_t devid;
uint32_t handle[2];
uint32_t crtc_id;
@@ -91,12 +88,10 @@ static const char *tests_str(enum tests test)
[TEST_SETDOMAIN_WAIT_WRITE_CPU] = setdomain_wait_write_cpu,
[TEST_BLT] = blt,
[TEST_RENDER] = render,
- [TEST_CONTEXT] = context,
[TEST_PAGE_FLIP_AND_MMAP_CPU] = page_flip_and_mmap_cpu,
[TEST_PAGE_FLIP_AND_MMAP_GTT] = page_flip_and_mmap_gtt,
[TEST_PAGE_FLIP_AND_BLT] = page_flip_and_blt,
[TEST_PAGE_FLIP_AND_RENDER] = page_flip_and_render,
- [TEST_PAGE_FLIP_AND_CONTEXT] = page_flip_and_context,
[TEST_CURSOR_MOVE] = cursor_move,
[TEST_SPRITE] = sprite,
};
@@ -206,31 +201,7 @@ static void scratch_buf_init(struct igt_buf *buf,
drm_intel_bo *bo)
buf-size = 4096;
}
-static void exec_nop(data_t *data, uint32_t handle, drm_intel_context *context)
-{
- drm_intel_bo *dst;
- struct intel_batchbuffer *batch;
-
- dst = gem_handle_to_libdrm_bo(data-bufmgr, data-drm_fd, , handle);
- igt_assert(dst);
-
- batch = intel_batchbuffer_alloc(data-bufmgr, data-devid);
- igt_assert(batch);
-
- /* add the reloc to make sure the kernel will think we write to dst */
- BEGIN_BATCH(4, 1);
- OUT_BATCH(MI_BATCH_BUFFER_END);
- OUT_BATCH(MI_NOOP);
- OUT_RELOC(dst, I915_GEM_DOMAIN_RENDER, I915_GEM_DOMAIN_RENDER, 0);
- OUT_BATCH(MI_NOOP);
- ADVANCE_BATCH();
-
- intel_batchbuffer_flush_with_context(batch, context);
- intel_batchbuffer_free(batch);
-}
-
-static void fill_render(data_t *data, uint32_t handle,
- drm_intel_context *context, unsigned char color)
+static void fill_render(data_t *data, uint32_t handle, unsigned char color)
{
drm_intel_bo *src, *dst;
struct intel_batchbuffer *batch;
@@ -254,7 +225,7 @@ static void fill_render(data_t *data, uint32_t handle,
batch = intel_batchbuffer_alloc(data-bufmgr, data-devid);
igt_assert(batch);
- rendercopy(batch, context,
+ rendercopy(batch, NULL,
src_buf, 0, 0, 1, 1,
dst_buf, 0, 0);
@@ -444,13 +415,8 @@ static void test_crc(data_t *data)
fill_blt(data, handle, 0xff);
break;
case TEST_RENDER:
- case TEST_CONTEXT:
case TEST_PAGE_FLIP_AND_RENDER:
- case TEST_PAGE_FLIP_AND_CONTEXT:
- fill_render(data, handle,
- (data-test == TEST_CONTEXT ||
-data-test == TEST_PAGE_FLIP_AND_CONTEXT) ?
- data-ctx[1] : NULL, 0xff);
+ fill_render(data, handle, 0xff);
break;
case TEST_CURSOR_MOVE:
igt_assert(drmModeMoveCursor(data-drm_fd, data-crtc_id, 1, 2)
== 0);
@@ -499,42 +465,15 @@ static bool prepare_crtc(data_t *data, uint32_t
connector_id)
connector_set_mode(data, data-config.default_mode,
data-fb_id[1]);
- if (data-test == TEST_CONTEXT ||
- data-test == TEST_PAGE_FLIP_AND_CONTEXT) {
- data-ctx[0] = drm_intel_gem_context_create(data-bufmgr);
- igt_require(data-ctx[0]);
- data-ctx[1] = drm_intel_gem_context_create(data-bufmgr);
- igt_require(data-ctx[1]);
-
- exec_nop(data, data-handle[0], data-ctx[1]);
- exec_nop(data, data-handle[0], data-ctx[0]);
- exec_nop(data, data-handle[0], data-ctx[1]);
- exec_nop(data, data-handle[0], data-ctx[0]);
- }
-
/* scanout = fb[0] */
connector_set_mode(data, data-config.default_mode,
data-fb_id[0]);
- if (data-test == TEST_CONTEXT ||
- data-test == TEST_PAGE_FLIP_AND_CONTEXT) {
- exec_nop(data, data-fb[0].gem_handle, data-ctx[0]);
- }
-
[Intel-gfx] [PATCH 09/12] tests/kms_psr_sink_crc: Fix all testcases.
In order to get all test cases fixed and the matrix planes-operations working
it was needed to use the common new igt kms functions for all cases.
Previously only sprite testcase was using it.
Fixed the fb colors in a way to make tests more clear and be impossible to see
black screen during the tests.
Signed-off-by: Rodrigo Vivi rodrigo.v...@intel.com
---
tests/kms_psr_sink_crc.c | 269 ++-
1 file changed, 101 insertions(+), 168 deletions(-)
diff --git a/tests/kms_psr_sink_crc.c b/tests/kms_psr_sink_crc.c
index 4358889..27f3df9 100644
--- a/tests/kms_psr_sink_crc.c
+++ b/tests/kms_psr_sink_crc.c
@@ -27,8 +27,6 @@
#include stdio.h
#include string.h
-#include drm_fourcc.h
-
#include ioctl_wrappers.h
#include drmtest.h
#include intel_bufmgr.h
@@ -79,88 +77,37 @@ typedef struct {
int drm_fd;
enum planes test_plane;
enum operations op;
- drmModeRes *resources;
- drm_intel_bufmgr *bufmgr;
uint32_t devid;
- uint32_t handle[2];
uint32_t crtc_id;
- uint32_t crtc_idx;
- uint32_t fb_id[3];
- struct kmstest_connector_config config;
igt_display_t display;
- struct igt_fb fb[2];
- igt_plane_t *plane[2];
+ drm_intel_bufmgr *bufmgr;
+ struct igt_fb fb_green, fb_white;
+ igt_plane_t *primary, *sprite, *cursor;
} data_t;
-static uint32_t create_fb(data_t *data,
- int w, int h,
- double r, double g, double b,
- struct igt_fb *fb)
+static void create_cursor_fb(data_t *data)
{
- uint32_t fb_id;
cairo_t *cr;
+ uint32_t fb_id;
- fb_id = igt_create_fb(data-drm_fd, w, h,
- DRM_FORMAT_XRGB, I915_TILING_X, fb);
+ fb_id = igt_create_fb(data-drm_fd, 64, 64,
+ DRM_FORMAT_ARGB, I915_TILING_NONE,
+ data-fb_white);
igt_assert(fb_id);
- cr = igt_get_cairo_ctx(data-drm_fd, fb);
- igt_paint_color(cr, 0, 0, w, h, r, g, b);
- igt_assert(cairo_status(cr) == 0);
- cairo_destroy(cr);
-
- return fb_id;
-}
-
-static void create_cursor_fb(data_t *data, struct igt_fb *fb)
-{
- cairo_t *cr;
-
- data-fb_id[2] = igt_create_fb(data-drm_fd, 64, 64,
- DRM_FORMAT_ARGB, I915_TILING_NONE,
- fb);
- igt_assert(data-fb_id[2]);
-
- cr = igt_get_cairo_ctx(data-drm_fd, fb);
+ cr = igt_get_cairo_ctx(data-drm_fd, data-fb_white);
igt_paint_color_alpha(cr, 0, 0, 64, 64, 1.0, 1.0, 1.0, 1.0);
igt_assert(cairo_status(cr) == 0);
}
-static bool
-connector_set_mode(data_t *data, drmModeModeInfo *mode, uint32_t fb_id)
-{
- struct kmstest_connector_config *config = data-config;
- int ret;
-
-#if 0
- fprintf(stdout, Using pipe %s, %dx%d\n,
kmstest_pipe_name(config-pipe),
- mode-hdisplay, mode-vdisplay);
-#endif
-
- ret = drmModeSetCrtc(data-drm_fd,
-config-crtc-crtc_id,
-fb_id,
-0, 0, /* x, y */
-config-connector-connector_id,
-1,
-mode);
- igt_assert(ret == 0);
-
- return 0;
-}
-
static void display_init(data_t *data)
{
igt_display_init(data-display, data-drm_fd);
- data-resources = drmModeGetResources(data-drm_fd);
- igt_assert(data-resources);
}
static void display_fini(data_t *data)
{
igt_display_fini(data-display);
- drmModeSetCursor(data-drm_fd, data-crtc_id, 0, 0, 0);
- drmModeFreeResources(data-resources);
}
static void fill_blt(data_t *data, uint32_t handle, unsigned char color)
@@ -316,112 +263,105 @@ static void get_sink_crc(data_t *data, char *crc) {
static void test_crc(data_t *data)
{
- uint32_t handle = data-handle[0];
+ uint32_t handle = data-fb_white.gem_handle;
+ igt_plane_t *test_plane;
+ void *ptr;
char ref_crc[12];
char crc[12];
- if (data-op == PLANE_MOVE) {
- igt_assert(drmModeSetCursor(data-drm_fd, data-crtc_id,
- handle, 64, 64) == 0);
- igt_assert(drmModeMoveCursor(data-drm_fd, data-crtc_id,
-1, 1) == 0);
+ igt_plane_set_fb(data-primary, data-fb_green);
+ igt_display_commit(data-display);
+
+ /* Setting a secondary fb/plane */
+ switch (data-test_plane) {
+ case PRIMARY: default: test_plane = data-primary; break;
+ case SPRITE: test_plane = data-sprite; break;
+ case CURSOR: test_plane = data-cursor; break;
}
+ igt_plane_set_fb(test_plane, data-fb_white);
+ igt_display_commit(data-display);
igt_assert(wait_psr_entry(data,
[Intel-gfx] [PATCH 07/12] tests/kms_psr_sink_crc: Cleaning up tests a bit
This is needed to be able to split tests in a matrix that tests different
input/write methods and operations for different type of planes.
Signed-off-by: Rodrigo Vivi rodrigo.v...@intel.com
---
tests/kms_psr_sink_crc.c | 67
1 file changed, 67 deletions(-)
diff --git a/tests/kms_psr_sink_crc.c b/tests/kms_psr_sink_crc.c
index ee5ad81..5da6137 100644
--- a/tests/kms_psr_sink_crc.c
+++ b/tests/kms_psr_sink_crc.c
@@ -41,16 +41,8 @@ enum tests {
TEST_PAGE_FLIP,
TEST_MMAP_CPU,
TEST_MMAP_GTT,
- TEST_MMAP_GTT_NO_BUSY,
- TEST_MMAP_GTT_WAITING_NO_BUSY,
- TEST_SETDOMAIN_WAIT_WRITE_GTT,
- TEST_SETDOMAIN_WAIT_WRITE_CPU,
TEST_BLT,
TEST_RENDER,
- TEST_PAGE_FLIP_AND_MMAP_CPU,
- TEST_PAGE_FLIP_AND_MMAP_GTT,
- TEST_PAGE_FLIP_AND_BLT,
- TEST_PAGE_FLIP_AND_RENDER,
TEST_CURSOR_MOVE,
TEST_SPRITE,
};
@@ -82,16 +74,8 @@ static const char *tests_str(enum tests test)
[TEST_PAGE_FLIP] = page_flip,
[TEST_MMAP_CPU] = mmap_cpu,
[TEST_MMAP_GTT] = mmap_gtt,
- [TEST_MMAP_GTT_NO_BUSY] = mmap_gtt_no_busy,
- [TEST_MMAP_GTT_WAITING_NO_BUSY] = mmap_gtt_waiting_no_busy,
- [TEST_SETDOMAIN_WAIT_WRITE_GTT] = setdomain_wait_write_gtt,
- [TEST_SETDOMAIN_WAIT_WRITE_CPU] = setdomain_wait_write_cpu,
[TEST_BLT] = blt,
[TEST_RENDER] = render,
- [TEST_PAGE_FLIP_AND_MMAP_CPU] = page_flip_and_mmap_cpu,
- [TEST_PAGE_FLIP_AND_MMAP_GTT] = page_flip_and_mmap_gtt,
- [TEST_PAGE_FLIP_AND_BLT] = page_flip_and_blt,
- [TEST_PAGE_FLIP_AND_RENDER] = page_flip_and_render,
[TEST_CURSOR_MOVE] = cursor_move,
[TEST_SPRITE] = sprite,
};
@@ -343,10 +327,6 @@ static void test_crc(data_t *data)
igt_assert(drmModePageFlip(data-drm_fd, data-crtc_id,
data-fb_id[1], 0, NULL) == 0);
break;
- case TEST_PAGE_FLIP_AND_MMAP_CPU:
- handle = data-handle[1];
- igt_assert(drmModePageFlip(data-drm_fd, data-crtc_id,
- data-fb_id[1], 0, NULL) == 0);
case TEST_MMAP_CPU:
ptr = gem_mmap__cpu(data-drm_fd, handle, 4096, PROT_WRITE);
gem_set_domain(data-drm_fd, handle,
@@ -357,10 +337,6 @@ static void test_crc(data_t *data)
sleep(1);
gem_sw_finish(data-drm_fd, handle);
break;
- case TEST_PAGE_FLIP_AND_MMAP_GTT:
- handle = data-handle[1];
- igt_assert(drmModePageFlip(data-drm_fd, data-crtc_id,
- data-fb_id[1], 0, NULL) == 0);
case TEST_MMAP_GTT:
ptr = gem_mmap__gtt(data-drm_fd, handle, 4096, PROT_WRITE);
gem_set_domain(data-drm_fd, handle,
@@ -369,53 +345,10 @@ static void test_crc(data_t *data)
munmap(ptr, 4096);
gem_bo_busy(data-drm_fd, handle);
break;
- case TEST_MMAP_GTT_NO_BUSY:
- ptr = gem_mmap__gtt(data-drm_fd, handle, 4096, PROT_WRITE);
- gem_set_domain(data-drm_fd, handle,
- I915_GEM_DOMAIN_GTT, I915_GEM_DOMAIN_GTT);
- memset(ptr, 0xff, 4);
- munmap(ptr, 4096);
- break;
- case TEST_MMAP_GTT_WAITING_NO_BUSY:
- ptr = gem_mmap__gtt(data-drm_fd, handle, 4096, PROT_WRITE);
- gem_set_domain(data-drm_fd, handle,
- I915_GEM_DOMAIN_GTT, I915_GEM_DOMAIN_GTT);
- igt_info(Sleeping for 10 sec...\n);
-sleep(10);
- memset(ptr, 0xff, 4);
- munmap(ptr, 4096);
- break;
- case TEST_SETDOMAIN_WAIT_WRITE_GTT:
- ptr = gem_mmap__gtt(data-drm_fd, handle, 4096, PROT_WRITE);
- fill_blt(data, handle, 0xff);
- igt_assert(wait_psr_entry(data, 10));
- get_sink_crc(data, ref_crc);
- gem_set_domain(data-drm_fd, handle,
- I915_GEM_DOMAIN_GTT, I915_GEM_DOMAIN_GTT);
- igt_info(Sleeping for 10 sec...\n);
- sleep(10);
- memset(ptr, 0xff, 4);
- munmap(ptr, 4096);
- break;
- case TEST_SETDOMAIN_WAIT_WRITE_CPU:
- ptr = gem_mmap__cpu(data-drm_fd, handle, 4096, PROT_WRITE);
- fill_blt(data, handle, 0xff);
- igt_assert(wait_psr_entry(data, 10));
- get_sink_crc(data, ref_crc);
- gem_set_domain(data-drm_fd, handle,
- I915_GEM_DOMAIN_CPU, I915_GEM_DOMAIN_CPU);
- igt_info(Sleeping for 10 sec...\n);
- sleep(10);
-
[Intel-gfx] [PATCH 10/12] tests/kms_psr_sink_crc: Check color ref CRC
Black screen is forbidden on this test. So let's fail if sink crc shows
it is back.
Also there are many cases where we know for shure it should be all green,
so let's check for them.
Signed-off-by: Rodrigo Vivi rodrigo.v...@intel.com
---
tests/kms_psr_sink_crc.c | 19 +++
1 file changed, 19 insertions(+)
diff --git a/tests/kms_psr_sink_crc.c b/tests/kms_psr_sink_crc.c
index 27f3df9..45d2dd9 100644
--- a/tests/kms_psr_sink_crc.c
+++ b/tests/kms_psr_sink_crc.c
@@ -35,6 +35,9 @@
#include igt_debugfs.h
#include igt_kms.h
+#define CRC_BLACK
+#define CRC_GREEN c101
+
#define DEBUG_CRC 0
/* This is usefull to debug and know what should be expected */
@@ -259,6 +262,9 @@ static void get_sink_crc(data_t *data, char *crc) {
* Now give a time for human eyes
*/
usleep(30);
+
+ /* Black screen is always invalid */
+ igt_assert(strcmp(crc, CRC_BLACK) != 0);
}
static void test_crc(data_t *data)
@@ -272,6 +278,15 @@ static void test_crc(data_t *data)
igt_plane_set_fb(data-primary, data-fb_green);
igt_display_commit(data-display);
+ /* Confirm that screen became Green */
+ get_sink_crc(data, ref_crc);
+ igt_assert(strcmp(ref_crc, CRC_GREEN) == 0);
+
+ /* Confirm screen stays Green after PSR got active */
+ igt_assert(wait_psr_entry(data, 10));
+ get_sink_crc(data, ref_crc);
+ igt_assert(strcmp(ref_crc, CRC_GREEN) == 0);
+
/* Setting a secondary fb/plane */
switch (data-test_plane) {
case PRIMARY: default: test_plane = data-primary; break;
@@ -281,14 +296,18 @@ static void test_crc(data_t *data)
igt_plane_set_fb(test_plane, data-fb_white);
igt_display_commit(data-display);
+ /* Confirm it is not Green anymore */
igt_assert(wait_psr_entry(data, 10));
get_sink_crc(data, ref_crc);
+ igt_assert(strcmp(ref_crc, CRC_GREEN) != 0);
switch (data-op) {
case PAGE_FLIP:
/* Only in use when testing primary plane */
igt_assert(drmModePageFlip(data-drm_fd, data-crtc_id,
data-fb_green.fb_id, 0, NULL) == 0);
+ get_sink_crc(data, crc);
+ igt_assert(strcmp(crc, CRC_GREEN) == 0);
break;
case MMAP_GTT:
ptr = gem_mmap__gtt(data-drm_fd, handle, 4096, PROT_WRITE);
--
1.9.3
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 08/12] tests/kms_psr_sink_crc: Start splitting tests in test_planes and operations.
This will allow us to test input/write oprations on any kind of plane.
At this point PLANE_ONOF is just the new name of TEST_SPRITE and
PLANE_MOVE is the one for TEST_CURSOR_MOVE. They will be extended and fixed
on the following patche(s).
Signed-off-by: Rodrigo Vivi rodrigo.v...@intel.com
---
tests/kms_psr_sink_crc.c | 110 +--
1 file changed, 69 insertions(+), 41 deletions(-)
diff --git a/tests/kms_psr_sink_crc.c b/tests/kms_psr_sink_crc.c
index 5da6137..4358889 100644
--- a/tests/kms_psr_sink_crc.c
+++ b/tests/kms_psr_sink_crc.c
@@ -37,24 +37,48 @@
#include igt_debugfs.h
#include igt_kms.h
-enum tests {
- TEST_PAGE_FLIP,
- TEST_MMAP_CPU,
- TEST_MMAP_GTT,
- TEST_BLT,
- TEST_RENDER,
- TEST_CURSOR_MOVE,
- TEST_SPRITE,
-};
-
#define DEBUG_CRC 0
/* This is usefull to debug and know what should be expected */
#define RUNNING_WITH_PSR_DISABLED 0
+enum planes {
+ PRIMARY,
+ SPRITE,
+ CURSOR,
+};
+
+enum operations {
+ PAGE_FLIP,
+ MMAP_GTT,
+ MMAP_GTT_WAITING,
+ MMAP_CPU,
+ BLT,
+ RENDER,
+ PLANE_MOVE,
+ PLANE_ONOFF,
+};
+
+static const char *op_str(enum operations op)
+{
+ static const char * const name[] = {
+ [PAGE_FLIP] = page_flip,
+ [MMAP_GTT] = mmap_gtt,
+ [MMAP_GTT_WAITING] = mmap_gtt_waiting,
+ [MMAP_CPU] = mmap_cpu,
+ [BLT] = blt,
+ [RENDER] = render,
+ [PLANE_MOVE] = plane_move,
+ [PLANE_ONOFF] = plane_onoff,
+ };
+
+ return name[op];
+}
+
typedef struct {
int drm_fd;
- enum tests test;
+ enum planes test_plane;
+ enum operations op;
drmModeRes *resources;
drm_intel_bufmgr *bufmgr;
uint32_t devid;
@@ -68,21 +92,6 @@ typedef struct {
igt_plane_t *plane[2];
} data_t;
-static const char *tests_str(enum tests test)
-{
- static const char * const testss[] = {
- [TEST_PAGE_FLIP] = page_flip,
- [TEST_MMAP_CPU] = mmap_cpu,
- [TEST_MMAP_GTT] = mmap_gtt,
- [TEST_BLT] = blt,
- [TEST_RENDER] = render,
- [TEST_CURSOR_MOVE] = cursor_move,
- [TEST_SPRITE] = sprite,
- };
-
- return testss[test];
-}
-
static uint32_t create_fb(data_t *data,
int w, int h,
double r, double g, double b,
@@ -311,7 +320,7 @@ static void test_crc(data_t *data)
char ref_crc[12];
char crc[12];
- if (data-test == TEST_CURSOR_MOVE) {
+ if (data-op == PLANE_MOVE) {
igt_assert(drmModeSetCursor(data-drm_fd, data-crtc_id,
handle, 64, 64) == 0);
igt_assert(drmModeMoveCursor(data-drm_fd, data-crtc_id,
@@ -321,13 +330,13 @@ static void test_crc(data_t *data)
igt_assert(wait_psr_entry(data, 10));
get_sink_crc(data, ref_crc);
- switch (data-test) {
+ switch (data-op) {
void *ptr;
- case TEST_PAGE_FLIP:
+ case PAGE_FLIP:
igt_assert(drmModePageFlip(data-drm_fd, data-crtc_id,
data-fb_id[1], 0, NULL) == 0);
break;
- case TEST_MMAP_CPU:
+ case MMAP_CPU:
ptr = gem_mmap__cpu(data-drm_fd, handle, 4096, PROT_WRITE);
gem_set_domain(data-drm_fd, handle,
I915_GEM_DOMAIN_CPU, I915_GEM_DOMAIN_CPU);
@@ -337,7 +346,8 @@ static void test_crc(data_t *data)
sleep(1);
gem_sw_finish(data-drm_fd, handle);
break;
- case TEST_MMAP_GTT:
+ case MMAP_GTT:
+ case MMAP_GTT_WAITING:
ptr = gem_mmap__gtt(data-drm_fd, handle, 4096, PROT_WRITE);
gem_set_domain(data-drm_fd, handle,
I915_GEM_DOMAIN_GTT, I915_GEM_DOMAIN_GTT);
@@ -345,16 +355,16 @@ static void test_crc(data_t *data)
munmap(ptr, 4096);
gem_bo_busy(data-drm_fd, handle);
break;
- case TEST_BLT:
+ case BLT:
fill_blt(data, handle, 0xff);
break;
- case TEST_RENDER:
+ case RENDER:
fill_render(data, handle, 0xff);
break;
- case TEST_CURSOR_MOVE:
+ case PLANE_MOVE:
igt_assert(drmModeMoveCursor(data-drm_fd, data-crtc_id, 1, 2)
== 0);
break;
- case TEST_SPRITE:
+ case PLANE_ONOFF:
igt_plane_set_fb(data-plane[0], data-fb[0]);
igt_display_commit(data-display);
igt_plane_set_fb(data-plane[1], data-fb[1]);
@@ -382,7 +392,7 @@ static bool prepare_crtc(data_t *data, uint32_t
connector_id)
0.0, 1.0, 0.0,
[Intel-gfx] [PATCH 1/4] drm/i915: Increase PSR Idle Frame to 2.
With Software tracking we are going to PSR sooner than we should and staying with blank screens in many cases. Using 2 identical frames to detect idleness is safier. Discovered and validated with refactored igt/kms_sink_psr_crc. Signed-off-by: Rodrigo Vivi rodrigo.v...@intel.com --- drivers/gpu/drm/i915/intel_dp.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c index f79473b..a796831 100644 --- a/drivers/gpu/drm/i915/intel_dp.c +++ b/drivers/gpu/drm/i915/intel_dp.c @@ -1813,7 +1813,7 @@ static void intel_edp_psr_enable_source(struct intel_dp *intel_dp) struct drm_device *dev = dig_port-base.base.dev; struct drm_i915_private *dev_priv = dev-dev_private; uint32_t max_sleep_time = 0x1f; - uint32_t idle_frames = 1; + uint32_t idle_frames = 2; uint32_t val = 0x0; const uint32_t link_entry_time = EDP_PSR_MIN_LINK_ENTRY_TIME_8_LINES; bool only_standby = false; -- 1.9.3 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/4] drm/i915: Remove PSR HW tracking.
Now that we are tracking psr states on Software side we don't need HW help
anymore.
So we can clean up the code a bit and avoid unecessary sets.
Signed-off-by: Rodrigo Vivi rodrigo.v...@intel.com
---
drivers/gpu/drm/i915/intel_dp.c | 12
1 file changed, 12 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index a796831..9414e67 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -1778,10 +1778,7 @@ static void intel_edp_psr_enable_sink(struct intel_dp
*intel_dp)
{
struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp);
struct drm_device *dev = dig_port-base.base.dev;
- struct drm_i915_private *dev_priv = dev-dev_private;
uint32_t aux_clock_divider;
- int precharge = 0x3;
- int msg_size = 5; /* Header(4) + Message(1) */
bool only_standby = false;
aux_clock_divider = intel_dp-get_aux_clock_divider(intel_dp, 0);
@@ -1796,15 +1793,6 @@ static void intel_edp_psr_enable_sink(struct intel_dp
*intel_dp)
else
drm_dp_dpcd_writeb(intel_dp-aux, DP_PSR_EN_CFG,
DP_PSR_ENABLE | DP_PSR_MAIN_LINK_ACTIVE);
-
- /* Setup AUX registers */
- I915_WRITE(EDP_PSR_AUX_DATA1(dev), EDP_PSR_DPCD_COMMAND);
- I915_WRITE(EDP_PSR_AUX_DATA2(dev), EDP_PSR_DPCD_NORMAL_OPERATION);
- I915_WRITE(EDP_PSR_AUX_CTL(dev),
- DP_AUX_CH_CTL_TIME_OUT_400us |
- (msg_size DP_AUX_CH_CTL_MESSAGE_SIZE_SHIFT) |
- (precharge DP_AUX_CH_CTL_PRECHARGE_2US_SHIFT) |
- (aux_clock_divider DP_AUX_CH_CTL_BIT_CLOCK_2X_SHIFT));
}
static void intel_edp_psr_enable_source(struct intel_dp *intel_dp)
--
1.9.3
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 4/4] drm/i915: Rename psr setup vsc function and set it always.
Let's always set VSC header.
Signed-off-by: Rodrigo Vivi rodrigo.v...@intel.com
---
drivers/gpu/drm/i915/intel_dp.c | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index a04b69f..de24e46 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -1755,7 +1755,7 @@ static void intel_edp_psr_write_vsc(struct intel_dp
*intel_dp,
POSTING_READ(ctl_reg);
}
-static void intel_edp_psr_setup(struct intel_dp *intel_dp)
+static void intel_edp_psr_setup_vsc(struct intel_dp *intel_dp)
{
struct edp_vsc_psr psr_vsc;
@@ -1877,6 +1877,8 @@ static void intel_edp_psr_do_enable(struct intel_dp
*intel_dp)
WARN_ON(dev_priv-psr.active);
lockdep_assert_held(dev_priv-psr.lock);
+ intel_edp_psr_setup_vsc(intel_dp);
+
/* Enable PSR on the panel */
intel_edp_psr_enable_sink(intel_dp);
@@ -1910,9 +1912,6 @@ void intel_edp_psr_enable(struct intel_dp *intel_dp)
dev_priv-psr.busy_frontbuffer_bits = 0;
- /* Setup PSR once */
- intel_edp_psr_setup(intel_dp);
-
if (intel_edp_psr_match_conditions(intel_dp))
dev_priv-psr.enabled = intel_dp;
mutex_unlock(dev_priv-psr.lock);
--
1.9.3
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 3/4] drm/i915: Move PSR w/as to enable source.
Lets reorganize stuff and make sure these W/As are always set.
Signed-off-by: Rodrigo Vivi rodrigo.v...@intel.com
---
drivers/gpu/drm/i915/intel_dp.c | 10 --
1 file changed, 4 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 9414e67..a04b69f 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -1757,8 +1757,6 @@ static void intel_edp_psr_write_vsc(struct intel_dp
*intel_dp,
static void intel_edp_psr_setup(struct intel_dp *intel_dp)
{
- struct drm_device *dev = intel_dp_to_dev(intel_dp);
- struct drm_i915_private *dev_priv = dev-dev_private;
struct edp_vsc_psr psr_vsc;
/* Prepare VSC packet as per EDP 1.3 spec, Table 3.10 */
@@ -1768,10 +1766,6 @@ static void intel_edp_psr_setup(struct intel_dp
*intel_dp)
psr_vsc.sdp_header.HB2 = 0x2;
psr_vsc.sdp_header.HB3 = 0x8;
intel_edp_psr_write_vsc(intel_dp, psr_vsc);
-
- /* Avoid continuous PSR exit by masking memup and hpd */
- I915_WRITE(EDP_PSR_DEBUG_CTL(dev), EDP_PSR_DEBUG_MASK_MEMUP |
- EDP_PSR_DEBUG_MASK_HPD | EDP_PSR_DEBUG_MASK_LPSP);
}
static void intel_edp_psr_enable_sink(struct intel_dp *intel_dp)
@@ -1806,6 +1800,10 @@ static void intel_edp_psr_enable_source(struct intel_dp
*intel_dp)
const uint32_t link_entry_time = EDP_PSR_MIN_LINK_ENTRY_TIME_8_LINES;
bool only_standby = false;
+ /* Avoid continuous PSR exit by masking memup and hpd */
+ I915_WRITE(EDP_PSR_DEBUG_CTL(dev), EDP_PSR_DEBUG_MASK_MEMUP |
+ EDP_PSR_DEBUG_MASK_HPD | EDP_PSR_DEBUG_MASK_LPSP);
+
if (IS_BROADWELL(dev) dig_port-port != PORT_A)
only_standby = true;
--
1.9.3
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
