[Intel-gfx] Intel eDP and fixed_mode probing/initialization

2016-04-29 Thread Josh Litherland
Hoping someone can point me in the right direction to understanding
how intel_connector->panel.fixed_mode gets probed, as it's referenced
in function "intel_dp_mode_valid" at drivers/gpu/drm/i915/intel_dp.c.

I am working with a panel hooked up via DSUB to a port that is
internally wired as eDP-1.  The kernel is correctly probing its
EDID-advertised preferred mode, 1360x768@60.  However, in the
above-named function, that mode is then being discarded with status
MODE_PANEL (exceeds panel dimensions).  After poking around a bit and
adding some debugging output, I've gotten as far as the above-named
function and found that fixed_mode is coming in to that function as
1280x800.  Trying to trace back farther than that I get a bit lost.

Thanks in advance if anyone can help me figure out where that spurious
mode limitation is coming from.

Incidentally, commenting out the checks against fixed_mode->hdisplay
and fixed_mode->vdisplay make the panel work correctly, but I'd like
to come at this from the other direction and find out why the probe
failed in the first place.

Thanks!

Kernel is 3.16.0-4-686-pae from Debian Jessie
Device is Intel Atom Processor Z36xxx/Z37xxx (8086:0f31)
Dmesg here, interesting bit starts around line 807:
 http://pastebin.com/kpeWW0iB

-- 
Josh Litherland (j...@temp123.org)
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] [PATCH 0/5] Add automation support for DP compliance Tests

2016-04-29 Thread Manasi Navare
This patch series adds the automation support for DP Compliance Tests
for EDID and Video Pattern generation from CTS specification 1.2 Rev 1.1.

Jim Bride (1):
  Add support for forcing 6 bpc on DP pipes.

Manasi Navare (4):
  drm/i915: Invoke the DP Compliance test request handler in the short
pulse path
  drm/i915: Disable the Link training automation support
  drm/i915: Fixes to support the DP Compliance EDID tests.
  drm/i915: Implement intel_dp_autotest_video_pattern function for
DP Video pattern compliance tests

 drivers/gpu/drm/i915/i915_debugfs.c  | 14 +-
 drivers/gpu/drm/i915/intel_display.c | 32 +-
 drivers/gpu/drm/i915/intel_dp.c  | 86 +---
 drivers/gpu/drm/i915/intel_drv.h | 10 +
 include/drm/drm_dp_helper.h  | 14 +-
 5 files changed, 147 insertions(+), 9 deletions(-)

-- 
1.9.1

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] [PATCH 4/5] Add support for forcing 6 bpc on DP pipes.

2016-04-29 Thread Manasi Navare
From: Jim Bride 

For DP compliance we need to be able to control the output color
type for the pipe associated with the DP port. To do this we rely
on the intel_dp_test_force_bpc debugfs file and the associated value
stored in struct intel_dp. If the debugfs file has a non-zero value
and we're on a display port connector, then we use the value from
debugfs to calculate the bpp for the pipe.  For cases where we are
not on DP or there has not been an overridden value then we behave
as normal.

Signed-off-by: Jim Bride 
Signed-off-by: Manasi Navare 
---
 drivers/gpu/drm/i915/intel_display.c | 32 ++--
 drivers/gpu/drm/i915/intel_drv.h |  1 +
 2 files changed, 31 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 5ffccf6..1618d36 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -12102,11 +12102,39 @@ compute_baseline_pipe_bpp(struct intel_crtc *crtc,
 
/* Clamp display bpp to EDID value */
for_each_connector_in_state(state, connector, connector_state, i) {
+   int type = 0;
+
+   if (connector_state->best_encoder) {
+   struct intel_encoder *ienc;
+
+   ienc = to_intel_encoder(connector_state->best_encoder);
+   type = ienc->type;
+   }
+
if (connector_state->crtc != >base)
continue;
 
-   connected_sink_compute_bpp(to_intel_connector(connector),
-  pipe_config);
+   /* For DP compliance we need to ensure that we can override
+* the computed bpp for the pipe.
+*/
+   if (type == INTEL_OUTPUT_DISPLAYPORT) {
+   struct intel_dp *intel_dp =
+   enc_to_intel_dp(connector_state->best_encoder);
+
+   if (intel_dp &&
+   (intel_dp->compliance_force_bpc != 0)) {
+   pipe_config->pipe_bpp =
+   intel_dp->compliance_force_bpc*3;
+   DRM_DEBUG_KMS("JMB Setting pipe_bpp to %d\n",
+ pipe_config->pipe_bpp);
+   } else {
+   
connected_sink_compute_bpp(to_intel_connector(connector),
+  pipe_config);
+   }
+   } else {
+   
connected_sink_compute_bpp(to_intel_connector(connector),
+  pipe_config);
+   }
}
 
return bpp;
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index e23eed7..10eaff8 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -865,6 +865,7 @@ struct intel_dp {
unsigned long compliance_test_type;
unsigned long compliance_test_data;
bool compliance_test_active;
+   unsigned long compliance_force_bpc; /* 0 for default or bpc to use */
 };
 
 struct intel_digital_port {
-- 
1.9.1

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] [PATCH 3/5] drm/i915: Fixes to support the DP Compliance EDID tests.

2016-04-29 Thread Manasi Navare
This patch addresses a few issues from the original patch for
DP Compliance EDID test support submitted by
Todd Previte

Video Mode requested in the EDID test handler for the EDID Read
test (CTS 4.2.2.3) should be set to PREFERRED as per the CTS spec.
Intel connector status should be connected even if detect_edid is
NULL when compliance_test flag is set. This is required to handle
the corrupt EDID (CTS 4.2.2.6) or EDID Read Failure I2C NACK/I2C
DEFER (CTS 4.2.2.4 and 4.2.2.5) tests from CTS spec.

Signed-off-by: Manasi Navare 
---
 drivers/gpu/drm/i915/intel_dp.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 0961f22..456fc17 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -4023,7 +4023,7 @@ static uint8_t intel_dp_autotest_video_pattern(struct 
intel_dp *intel_dp)
 
 static uint8_t intel_dp_autotest_edid(struct intel_dp *intel_dp)
 {
-   uint8_t test_result = DP_TEST_NAK;
+   uint8_t test_result = DP_TEST_ACK;
struct intel_connector *intel_connector = intel_dp->attached_connector;
struct drm_connector *connector = _connector->base;
 
@@ -4058,7 +4058,7 @@ static uint8_t intel_dp_autotest_edid(struct intel_dp 
*intel_dp)
DRM_DEBUG_KMS("Failed to write EDID checksum\n");
 
test_result = DP_TEST_ACK | DP_TEST_EDID_CHECKSUM_WRITE;
-   intel_dp->compliance_test_data = INTEL_DP_RESOLUTION_STANDARD;
+   intel_dp->compliance_test_data = INTEL_DP_RESOLUTION_PREFERRED;
}
 
/* Set test active flag here so userspace doesn't interrupt things */
@@ -4650,7 +4650,7 @@ intel_dp_detect(struct drm_connector *connector, bool 
force)
 
intel_dp->detect_done = false;
 
-   if (intel_connector->detect_edid)
+   if (intel_connector->detect_edid || intel_dp->compliance_test_active)
return connector_status_connected;
else
return connector_status_disconnected;
-- 
1.9.1

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] [PATCH 5/5] drm/i915: Implement intel_dp_autotest_video_pattern function for DP Video pattern compliance tests

2016-04-29 Thread Manasi Navare
This video pattern test function gets invoked through the
compliance test handler on a HPD short pulse if the test type is
set to DP_TEST_VIDEO_PATTERN. This performs the DPCD registers
reads to read the requested test pattern, video pattern resolution,
frame rate and bits per color value. The results of this analysis
are handed off to userspace so that the userspace app can set the
video pattern mode appropriately for the test result/response.

The compliance_test_active flag is set at the end of the individual
test handling functions. This is so that the kernel-side operations
can be completed without the risk of interruption from the userspace
app that is polling on that flag.

Signed-off-by: Manasi Navare 
---
 drivers/gpu/drm/i915/i915_debugfs.c | 14 ++-
 drivers/gpu/drm/i915/intel_dp.c | 76 +
 drivers/gpu/drm/i915/intel_drv.h|  9 +
 include/drm/drm_dp_helper.h | 14 ++-
 4 files changed, 111 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index 6ee69b1..c8d0805 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -4458,7 +4458,19 @@ static int i915_displayport_test_data_show(struct 
seq_file *m, void *data)
if (connector->status == connector_status_connected &&
connector->encoder != NULL) {
intel_dp = enc_to_intel_dp(connector->encoder);
-   seq_printf(m, "%lx", intel_dp->compliance_test_data);
+   if (intel_dp->compliance_test_type ==
+   DP_TEST_LINK_EDID_READ)
+   seq_printf(m, "%lx",
+  intel_dp->compliance_test_data);
+   else if (intel_dp->compliance_test_type ==
+DP_TEST_LINK_VIDEO_PATTERN) {
+   seq_printf(m, "hdisplay: %lu\n",
+  intel_dp->test_data.hdisplay);
+   seq_printf(m, "vdisplay: %lu\n",
+  intel_dp->test_data.vdisplay);
+   seq_printf(m, "bpc: %u\n",
+  intel_dp->test_data.bpc);
+   }
} else
seq_puts(m, "0");
}
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 456fc17..134cff8 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -4018,6 +4018,82 @@ static uint8_t intel_dp_autotest_link_training(struct 
intel_dp *intel_dp)
 static uint8_t intel_dp_autotest_video_pattern(struct intel_dp *intel_dp)
 {
uint8_t test_result = DP_TEST_NAK;
+   uint8_t test_pattern;
+   uint16_t  h_width, v_height, test_misc;
+   int status = 0;
+
+   /* Automation support for Video Pattern Tests has a dependency
+* on Link training Automation support (CTS Test 4.3.1.11)
+* Hence it returns a TEST NAK until the Link Training automation
+* support is added to the kernel
+*/
+   return test_result;
+
+   /* Read the TEST_PATTERN (DP CTS 3.1.5) */
+   status = drm_dp_dpcd_read(_dp->aux, DP_TEST_PATTERN,
+ _pattern, 1);
+   if (status <= 0) {
+   DRM_DEBUG_KMS("Could not read test pattern from"
+ "refernce sink\n");
+   return 0;
+   }
+   if (test_pattern != DP_COLOR_RAMP)
+   return test_result;
+   intel_dp->test_data.video_pattern = test_pattern;
+
+   status = drm_dp_dpcd_read(_dp->aux, DP_TEST_H_WIDTH,
+ _width, 2);
+   if (status <= 0) {
+   DRM_DEBUG_KMS("Could not read H Width from"
+ "refernce sink\n");
+   return 0;
+   }
+   intel_dp->test_data.hdisplay = (h_width & DP_TEST_MSB_MASK) >> 8 |
+   (h_width << 8);
+
+   status = drm_dp_dpcd_read(_dp->aux, DP_TEST_V_HEIGHT,
+ _height, 2);
+   if (status <= 0) {
+   DRM_DEBUG_KMS("Could not read V Height from"
+ "refernce sink\n");
+   return 0;
+   }
+   intel_dp->test_data.vdisplay = (v_height & DP_TEST_MSB_MASK) >> 8 |
+   (v_height << 8);
+
+   status = drm_dp_dpcd_read(_dp->aux, DP_TEST_MISC,
+ _misc, 1);
+   if (status <= 0) {
+   DRM_DEBUG_KMS("Could not read TEST MISC from"
+ "refernce sink\n");
+   return 0;
+   }
+   if (((test_misc & DP_TEST_COLOR_FORMAT_MASK) >> 1) !=
+   DP_VIDEO_PATTERN_RGB_FORMAT)
+   

[Intel-gfx] [PATCH 1/5] drm/i915: Invoke the DP Compliance test request handler in the short pulse path

2016-04-29 Thread Manasi Navare
HPD Short pulse test requests occur for DP Compliance Link Training
and Video Pattern tests.The DP Test request handler needs to be
invoked by these tests in the short pulse path in order to support
automated DP Compliance tests.

Signed-off-by: Manasi Navare 
---
 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 c12c414..19a95ed 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -4257,7 +4257,7 @@ intel_dp_short_pulse(struct intel_dp *intel_dp)
   sink_irq_vector);
 
if (sink_irq_vector & DP_AUTOMATED_TEST_REQUEST)
-   DRM_DEBUG_DRIVER("Test request in short pulse not 
handled\n");
+   intel_dp_handle_test_request(intel_dp);
if (sink_irq_vector & (DP_CP_IRQ | DP_SINK_SPECIFIC_IRQ))
DRM_DEBUG_DRIVER("CP or sink specific irq unhandled\n");
}
-- 
1.9.1

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] [PATCH 2/5] drm/i915: Disable the Link training automation support

2016-04-29 Thread Manasi Navare
Kernel does not have automation support for DP compliance Link
training tests. So the Link Training test handler should return
a TEST_NAK.

Signed-off-by: Manasi Navare 
---
 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 19a95ed..0961f22 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -4011,7 +4011,7 @@ intel_dp_get_sink_irq_esi(struct intel_dp *intel_dp, u8 
*sink_irq_vector)
 
 static uint8_t intel_dp_autotest_link_training(struct intel_dp *intel_dp)
 {
-   uint8_t test_result = DP_TEST_ACK;
+   uint8_t test_result = DP_TEST_NAK;
return test_result;
 }
 
-- 
1.9.1

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] [PATCH i-g-t] tools: Add intel_dp_compliance for DisplayPort 1.2 compliance automation

2016-04-29 Thread Manasi Navare
This is the userspace component of the Displayport Compliance
testing software required for compliance testing of the I915
Display Port driver. This must be running in order to successfully
complete Display Port compliance testing. This app and the kernel
code that accompanies it has been written to satify the requirements
of the Displayport Link CTS 1.2 rev1.1 specification from VESA.
Note that this application does not support eDP compliance testing.
This utility ahs an automation support for the EDID tests (4.2.2.3
- 4.2.2.6) and Video Pattern generation tests (400.3.3.1) from CTS
specification 1.2 Rev 1.1. Currently the video pattern automation
has been explicitly disabled until the link training automation is
fully supported in the kernel.

The Linux DUT running this utility must be in text (console) mode
and cannot have any other display manager running. Since this uses
sysfs nodes for kernel interaction, this utility should be run as
Root. Once this user application is up and running, waiting for
test requests, the test appliance software on the windows host
can now be used to execute the compliance tests.

This app is based on some prior work done in April 2015 (by
Todd Previte )

Signed-off-by: Todd Previte 
Signed-off-by: Manasi Navare 
---
 tools/Makefile.sources  |1 +
 tools/intel_dp_compliance.c | 1091 +++
 2 files changed, 1092 insertions(+)
 create mode 100644 tools/intel_dp_compliance.c

diff --git a/tools/Makefile.sources b/tools/Makefile.sources
index 5d5958d..3054856 100644
--- a/tools/Makefile.sources
+++ b/tools/Makefile.sources
@@ -13,6 +13,7 @@ bin_PROGRAMS =\
intel_bios_reader   \
intel_display_crc   \
intel_display_poller\
+   intel_dp_compliance \
intel_dump_decode   \
intel_error_decode  \
intel_forcewaked\
diff --git a/tools/intel_dp_compliance.c b/tools/intel_dp_compliance.c
new file mode 100644
index 000..f3449e2
--- /dev/null
+++ b/tools/intel_dp_compliance.c
@@ -0,0 +1,1091 @@
+/*
+ * Displayport Compliance Testing Application
+ *
+ * This is the userspace component of the Displayport Compliance testing
+ * software required for compliance testing of the I915 Display Port driver.
+ * This must be running in order to successfully complete Display Port
+ * compliance testing. This app and the kernel code that accompanies it has 
been
+ * written to satify the requirements of the Displayport Link CTS 1.2 rev1.1
+ * specification from VESA. Note that this application does not support eDP
+ * compliance testing.
+ *
+ * Complaince Testing requires several components:
+ *   - A kernel build that contains the patch set for DP compliance support
+ * Make sure it has the EDID compliance automation patch
+ *   - A Displayport Compliance Testing appliance such as Unigraf-DPR120
+ *   - This user application
+ *   - A windows host machine to run the DPR test software
+ *   - Root access on the DUT due to the use of sysfs utility
+ *
+ * Test Setup:
+ * It is strongly recommended that the windows host, test appliance and DUT
+ * be freshly restarted before any testing begins to ensure that any previous
+ * configurations and settings will not interfere with test process. Refer to
+ * the test appliance documentation for setup, software installation and
+ * operation specific to that device.
+ *
+ * The Linux DUT must be in text (console) mode and cannot have any other
+ * display manager running. You must be logged in as root to run this user app.
+ * Once the user application is up and running, waiting for test requests, the
+ * software on the windows host can now be used to execute the compliance 
tests.
+ *
+ * This userspace application supports following tests from the DP CTS Spec
+ * Rev 1.1:
+ *   - EDID Tests: Supports EDID read (4.2.2.3),EDID Read failure and 
corruption
+ * detection tests (4.2.2.4, 4.2.2.5, 4.2.2.6)
+ *   - Video Pattern generation tests: This supports only the 24 and 18bpp 
color
+ * ramp test pattern (400.3.3.1).
+ *
+ * Connections (required):
+ *   - Test Appliance connected to the external Displayport connector on the 
DUT
+ *   - Test Appliance Monitor Out connected to Displayport connector on the
+ * monitor
+ *   - Test appliance connected to the Windows Host via USB
+ *
+ * Debugfs Files:
+ * The file root for all  the debugfs file:
+ * /sys/kernel/debug/dri/0/
+ *
+ * The specific files are as follows:
+ *
+ * i915_dp_test_active
+ * A simple flag that indicates whether or not compliance testing is currently
+ * active in the kernel. This flag is polled by userspace and once set, invokes
+ * the test handler in the user app.This flag is set by the test handler in the
+ * kernel after reading the registers requested by the test appliance.
+ *
+ * 

[Intel-gfx] [PATCH v2 1/2] drm/i915/execlists: Refactor common engine setup

2016-04-29 Thread Chris Wilson
Move all of the constant assignments up front and into a common
function. This is primarily to ensure the backpointers are set as early
as possible for later use during initialisation.

v2: Use a constant struct so that all the similar values are set
together.
v3: Sanitize the engine's IMR to disable any potential interrupt before
we are ready (enabled in init_hw).

Signed-off-by: Chris Wilson 
Cc: Tvrtko Ursulin 
Cc: Dave Gordon 
---
 drivers/gpu/drm/i915/intel_lrc.c | 180 +--
 1 file changed, 97 insertions(+), 83 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index d8763524319d..8106316ce56f 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -1918,8 +1918,7 @@ void intel_logical_ring_cleanup(struct intel_engine_cs 
*engine)
 }
 
 static void
-logical_ring_default_vfuncs(struct drm_device *dev,
-   struct intel_engine_cs *engine)
+logical_ring_default_vfuncs(struct intel_engine_cs *engine)
 {
/* Default vfuncs which can be overriden by each engine. */
engine->init_hw = gen8_init_common_ring;
@@ -1930,7 +1929,7 @@ logical_ring_default_vfuncs(struct drm_device *dev,
engine->emit_bb_start = gen8_emit_bb_start;
engine->get_seqno = gen8_get_seqno;
engine->set_seqno = gen8_set_seqno;
-   if (IS_BXT_REVID(dev, 0, BXT_REVID_A1)) {
+   if (IS_BXT_REVID(engine->dev, 0, BXT_REVID_A1)) {
engine->irq_seqno_barrier = bxt_a_seqno_barrier;
engine->set_seqno = bxt_a_set_seqno;
}
@@ -1941,6 +1940,7 @@ logical_ring_default_irqs(struct intel_engine_cs *engine, 
unsigned shift)
 {
engine->irq_enable_mask = GT_RENDER_USER_INTERRUPT << shift;
engine->irq_keep_mask = GT_CONTEXT_SWITCH_INTERRUPT << shift;
+   init_waitqueue_head(>irq_queue);
 }
 
 static int
@@ -1961,31 +1961,72 @@ lrc_setup_hws(struct intel_engine_cs *engine,
return 0;
 }
 
-static int
-logical_ring_init(struct drm_device *dev, struct intel_engine_cs *engine)
+static const struct logical_ring_info {
+   const char *name;
+   unsigned exec_id;
+   unsigned guc_id;
+   u32 mmio_base;
+   unsigned irq_shift;
+} logical_rings[] = {
+   [RCS] = {
+   .name = "render ring",
+   .exec_id = I915_EXEC_RENDER,
+   .guc_id = GUC_RENDER_ENGINE,
+   .mmio_base = RENDER_RING_BASE,
+   .irq_shift = GEN8_RCS_IRQ_SHIFT,
+   },
+   [BCS] = {
+   .name = "blitter ring",
+   .exec_id = I915_EXEC_BLT,
+   .guc_id = GUC_BLITTER_ENGINE,
+   .mmio_base = BLT_RING_BASE,
+   .irq_shift = GEN8_BCS_IRQ_SHIFT,
+   },
+   [VCS] = {
+   .name = "bsd ring",
+   .exec_id = I915_EXEC_BSD,
+   .guc_id = GUC_VIDEO_ENGINE,
+   .mmio_base = GEN6_BSD_RING_BASE,
+   .irq_shift = GEN8_VCS1_IRQ_SHIFT,
+   },
+   [VCS2] = {
+   .name = "bsd2 ring",
+   .exec_id = I915_EXEC_BSD,
+   .guc_id = GUC_VIDEO_ENGINE2,
+   .mmio_base = GEN8_BSD2_RING_BASE,
+   .irq_shift = GEN8_VCS2_IRQ_SHIFT,
+   },
+   [VECS] = {
+   .name = "video enhancement ring",
+   .exec_id = I915_EXEC_VEBOX,
+   .guc_id = GUC_VIDEOENHANCE_ENGINE,
+   .mmio_base = VEBOX_RING_BASE,
+   .irq_shift = GEN8_VECS_IRQ_SHIFT,
+   },
+};
+
+static struct intel_engine_cs *
+logical_ring_setup(struct drm_device *dev, enum intel_engine_id id)
 {
+   const struct logical_ring_info *info = _rings[id];
struct drm_i915_private *dev_priv = to_i915(dev);
-   struct intel_context *dctx = dev_priv->kernel_context;
+   struct intel_engine_cs *engine = _priv->engine[id];
enum forcewake_domains fw_domains;
-   int ret;
 
-   /* Intentionally left blank. */
-   engine->buffer = NULL;
+   engine->id = id;
+   engine->name = info->name;
+   engine->exec_id = info->exec_id;
+   engine->guc_id = info->guc_id;
+   engine->mmio_base = info->mmio_base;
 
-   engine->dev = dev;
-   INIT_LIST_HEAD(>active_list);
-   INIT_LIST_HEAD(>request_list);
-   i915_gem_batch_pool_init(dev, >batch_pool);
-   init_waitqueue_head(>irq_queue);
+   /* disable interrupts to this engine before we install ourselves */
+   I915_WRITE_IMR(engine, ~0);
+   POSTING_READ(RING_IMR(engine->mmio_base));
 
-   INIT_LIST_HEAD(>buffers);
-   INIT_LIST_HEAD(>execlist_queue);
-   spin_lock_init(>execlist_lock);
-
-   tasklet_init(>irq_tasklet,
-intel_lrc_irq_handler, (unsigned long)engine);
+   engine->dev = dev;
 
-   logical_ring_init_platform_invariants(engine);
+   /* 

Re: [Intel-gfx] [PATCH v2 06/10] drm/i915: Enable i915 perf stream for Haswell OA unit

2016-04-29 Thread Matthew Auld
> +   bo = i915_gem_object_create(dev_priv->dev, OA_BUFFER_SIZE);
> +   if (bo == NULL) {

IS_ERR()
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] [PATCH v2 10/10] drm/i915: Add more Haswell OA metric sets

2016-04-29 Thread Robert Bragg
This adds 'compute', 'compute extended', 'memory reads', 'memory writes'
and 'sampler balance' metric sets for Haswell.

Signed-off-by: Robert Bragg 
---
 drivers/gpu/drm/i915/i915_oa_hsw.c | 483 -
 1 file changed, 482 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_oa_hsw.c 
b/drivers/gpu/drm/i915/i915_oa_hsw.c
index 3aa22eb..4a2de8a 100644
--- a/drivers/gpu/drm/i915/i915_oa_hsw.c
+++ b/drivers/gpu/drm/i915/i915_oa_hsw.c
@@ -30,9 +30,14 @@
 
 enum metric_set_id {
METRIC_SET_ID_RENDER_BASIC = 1,
+   METRIC_SET_ID_COMPUTE_BASIC,
+   METRIC_SET_ID_COMPUTE_EXTENDED,
+   METRIC_SET_ID_MEMORY_READS,
+   METRIC_SET_ID_MEMORY_WRITES,
+   METRIC_SET_ID_SAMPLER_BALANCE,
 };
 
-int i915_oa_n_builtin_metric_sets_hsw = 1;
+int i915_oa_n_builtin_metric_sets_hsw = 6;
 
 static const struct i915_oa_reg b_counter_config_render_basic[] = {
{ _MMIO(0x2724), 0x0080 },
@@ -118,6 +123,332 @@ static int select_render_basic_config(struct 
drm_i915_private *dev_priv)
return 0;
 }
 
+static const struct i915_oa_reg b_counter_config_compute_basic[] = {
+   { _MMIO(0x2710), 0x },
+   { _MMIO(0x2714), 0x0080 },
+   { _MMIO(0x2718), 0x },
+   { _MMIO(0x271C), 0x },
+   { _MMIO(0x2720), 0x },
+   { _MMIO(0x2724), 0x0080 },
+   { _MMIO(0x2728), 0x },
+   { _MMIO(0x272C), 0x },
+   { _MMIO(0x2740), 0x },
+   { _MMIO(0x2744), 0x },
+   { _MMIO(0x2748), 0x },
+   { _MMIO(0x274C), 0x },
+   { _MMIO(0x2750), 0x },
+   { _MMIO(0x2754), 0x },
+   { _MMIO(0x2758), 0x },
+   { _MMIO(0x275C), 0x },
+};
+
+static const struct i915_oa_reg mux_config_compute_basic[] = {
+   { _MMIO(0x253A4), 0x },
+   { _MMIO(0x2681C), 0x01F00800 },
+   { _MMIO(0x26820), 0x1000 },
+   { _MMIO(0x2781C), 0x01F00800 },
+   { _MMIO(0x26520), 0x0007 },
+   { _MMIO(0x265A0), 0x0007 },
+   { _MMIO(0x25380), 0x0010 },
+   { _MMIO(0x2538C), 0x0030 },
+   { _MMIO(0x25384), 0xAA8A },
+   { _MMIO(0x25404), 0x },
+   { _MMIO(0x26800), 0x4202 },
+   { _MMIO(0x26808), 0x00605817 },
+   { _MMIO(0x2680C), 0x10001005 },
+   { _MMIO(0x26804), 0x },
+   { _MMIO(0x27800), 0x0102 },
+   { _MMIO(0x27808), 0x0C0701E0 },
+   { _MMIO(0x2780C), 0x000200A0 },
+   { _MMIO(0x27804), 0x },
+   { _MMIO(0x26484), 0x4400 },
+   { _MMIO(0x26704), 0x4400 },
+   { _MMIO(0x26500), 0x0006 },
+   { _MMIO(0x26510), 0x0001 },
+   { _MMIO(0x26504), 0x8800 },
+   { _MMIO(0x26580), 0x0006 },
+   { _MMIO(0x26590), 0x0020 },
+   { _MMIO(0x26584), 0x },
+   { _MMIO(0x26104), 0x5582 },
+   { _MMIO(0x26184), 0xAA86 },
+   { _MMIO(0x25420), 0x08320C83 },
+   { _MMIO(0x25424), 0x06820C83 },
+   { _MMIO(0x2541C), 0x },
+   { _MMIO(0x25428), 0x0C03 },
+};
+
+static int select_compute_basic_config(struct drm_i915_private *dev_priv)
+{
+   dev_priv->perf.oa.mux_regs =
+   mux_config_compute_basic;
+   dev_priv->perf.oa.mux_regs_len =
+   ARRAY_SIZE(mux_config_compute_basic);
+
+   dev_priv->perf.oa.b_counter_regs =
+   b_counter_config_compute_basic;
+   dev_priv->perf.oa.b_counter_regs_len =
+   ARRAY_SIZE(b_counter_config_compute_basic);
+
+   return 0;
+}
+
+static const struct i915_oa_reg b_counter_config_compute_extended[] = {
+   { _MMIO(0x2724), 0xf080 },
+   { _MMIO(0x2720), 0x },
+   { _MMIO(0x2714), 0xf080 },
+   { _MMIO(0x2710), 0x },
+   { _MMIO(0x2770), 0x0007fe2a },
+   { _MMIO(0x2774), 0xff00 },
+   { _MMIO(0x2778), 0x0007fe6a },
+   { _MMIO(0x277c), 0xff00 },
+   { _MMIO(0x2780), 0x0007fe92 },
+   { _MMIO(0x2784), 0xff00 },
+   { _MMIO(0x2788), 0x0007fea2 },
+   { _MMIO(0x278c), 0xff00 },
+   { _MMIO(0x2790), 0x0007fe32 },
+   { _MMIO(0x2794), 0xff00 },
+   { _MMIO(0x2798), 0x0007fe9a },
+   { _MMIO(0x279c), 0xff00 },
+   { _MMIO(0x27a0), 0x0007ff23 },
+   { _MMIO(0x27a4), 0xff00 },
+   { _MMIO(0x27a8), 0x0007fff3 },
+   { _MMIO(0x27ac), 0xfffe },
+};
+
+static const struct i915_oa_reg mux_config_compute_extended[] = {
+   { _MMIO(0x2681C), 0x3EB00800 },
+   { _MMIO(0x26820), 0x0090 },
+   { _MMIO(0x25384), 0x02AA },
+   { _MMIO(0x25404), 0x03FF },
+   { _MMIO(0x26800), 0x00142284 },
+   { _MMIO(0x26808), 0x0E629062 },
+   { _MMIO(0x2680C), 0x3F6F55CB },
+   { _MMIO(0x26810), 0x0014 },
+   { _MMIO(0x26804), 0x },
+   { _MMIO(0x26104), 0x02AA },
+   { _MMIO(0x26184), 0x02AA },
+ 

[Intel-gfx] [PATCH v2 09/10] drm/i915: add oa_event_min_timer_exponent sysctl

2016-04-29 Thread Robert Bragg
The minimal sampling period is now configurable via a
dev.i915.oa_min_timer_exponent sysctl parameter.

Following the precedent set by perf, the default is the minimum that
won't (on its own) exceed the default kernel.perf_event_max_sample_rate
default of 10 samples/s.

Signed-off-by: Robert Bragg 
---
 drivers/gpu/drm/i915/i915_perf.c | 42 
 1 file changed, 30 insertions(+), 12 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c
index 3789378..045ffe8 100644
--- a/drivers/gpu/drm/i915/i915_perf.c
+++ b/drivers/gpu/drm/i915/i915_perf.c
@@ -71,6 +71,23 @@ static u32 i915_perf_stream_paranoid = true;
  */
 #define OA_EXPONENT_MAX 31
 
+/* for sysctl proc_dointvec_minmax of i915_oa_min_timer_exponent */
+static int zero;
+static int oa_exponent_max = OA_EXPONENT_MAX;
+
+/* Theoretically we can program the OA unit to sample every 160ns but don't
+ * allow that by default unless root...
+ *
+ * The period is derived from the exponent as:
+ *
+ *   period = 80ns * 2^(exponent + 1)
+ *
+ * Referring to perf's kernel.perf_event_max_sample_rate for a precedent
+ * (10 by default); with an OA exponent of 6 we get a period of 10.240
+ * microseconds - just under 10Hz
+ */
+static u32 i915_oa_min_timer_exponent = 6;
+
 /* XXX: beware if future OA HW adds new report formats that the current
  * code assumes all reports have a power-of-two size and ~(size - 1) can
  * be used as a mask to align the OA tail pointer.
@@ -1229,21 +1246,13 @@ static int read_properties_unlocked(struct 
drm_i915_private *dev_priv,
return -EINVAL;
}
 
-   /* NB: The exponent represents a period as follows:
-*
-*   80ns * 2^(period_exponent + 1)
-*
-* Theoretically we can program the OA unit to sample
+   /* Theoretically we can program the OA unit to sample
 * every 160ns but don't allow that by default unless
 * root.
-*
-* Referring to perf's
-* kernel.perf_event_max_sample_rate for a precedent
-* (10 by default); with an OA exponent of 6 we get
-* a period of 10.240 microseconds -just under 10Hz
 */
-   if (value < 6 && !capable(CAP_SYS_ADMIN)) {
-   DRM_ERROR("Sampling period too high without 
root privileges\n");
+   if (value < i915_oa_min_timer_exponent &&
+   !capable(CAP_SYS_ADMIN)) {
+   DRM_ERROR("OA timer exponent too low without 
root privileges\n");
return -EACCES;
}
 
@@ -1305,6 +1314,15 @@ static struct ctl_table oa_table[] = {
 .mode = 0644,
 .proc_handler = proc_dointvec,
 },
+   {
+.procname = "oa_min_timer_exponent",
+.data = _oa_min_timer_exponent,
+.maxlen = sizeof(i915_oa_min_timer_exponent),
+.mode = 0644,
+.proc_handler = proc_dointvec_minmax,
+.extra1 = ,
+.extra2 = _exponent_max,
+},
{}
 };
 
-- 
2.7.1

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] [PATCH v2 07/10] drm/i915: advertise available metrics via sysfs

2016-04-29 Thread Robert Bragg
Each metric set is given a sysfs entry like:

/sys/class/drm/card0/metrics//id

This allows userspace to enumerate the specific sets that are available
for the current system. The 'id' file contains an unsigned integer that
can be used to open the associated metric set via
DRM_IOCTL_I915_PERF_OPEN. The  is a globally unique ID for a
specific OA unit configuration that can be reliably used as a key to
lookup corresponding counter meta data and normalization equations.

Signed-off-by: Robert Bragg 
---
 drivers/gpu/drm/i915/i915_drv.h|  2 ++
 drivers/gpu/drm/i915/i915_oa_hsw.c | 45 ++
 drivers/gpu/drm/i915/i915_oa_hsw.h |  4 
 drivers/gpu/drm/i915/i915_perf.c   | 18 ++-
 4 files changed, 68 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 602eb03..68fdf1a 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2097,6 +2097,8 @@ struct drm_i915_private {
struct {
bool initialized;
 
+   struct kobject *metrics_kobj;
+
struct mutex lock;
struct list_head streams;
 
diff --git a/drivers/gpu/drm/i915/i915_oa_hsw.c 
b/drivers/gpu/drm/i915/i915_oa_hsw.c
index 5472aa0..3aa22eb 100644
--- a/drivers/gpu/drm/i915/i915_oa_hsw.c
+++ b/drivers/gpu/drm/i915/i915_oa_hsw.c
@@ -24,6 +24,8 @@
  *
  */
 
+#include 
+
 #include "i915_drv.h"
 
 enum metric_set_id {
@@ -130,3 +132,46 @@ int i915_oa_select_metric_set_hsw(struct drm_i915_private 
*dev_priv)
return -ENODEV;
}
 }
+
+static ssize_t
+show_render_basic_id(struct device *kdev, struct device_attribute *attr, char 
*buf)
+{
+   return sprintf(buf, "%d\n", METRIC_SET_ID_RENDER_BASIC);
+}
+
+static struct device_attribute dev_attr_render_basic_id = {
+   .attr = { .name = "id", .mode = S_IRUGO },
+   .show = show_render_basic_id,
+   .store = NULL,
+};
+
+static struct attribute *attrs_render_basic[] = {
+   _attr_render_basic_id.attr,
+   NULL,
+};
+
+static struct attribute_group group_render_basic = {
+   .name = "403d8832-1a27-4aa6-a64e-f5389ce7b212",
+   .attrs =  attrs_render_basic,
+};
+
+int
+i915_perf_init_sysfs_hsw(struct drm_i915_private *dev_priv)
+{
+   int ret;
+
+   ret = sysfs_create_group(dev_priv->perf.metrics_kobj, 
_render_basic);
+   if (ret)
+   goto error_render_basic;
+
+   return 0;
+
+error_render_basic:
+   return ret;
+}
+
+void
+i915_perf_deinit_sysfs_hsw(struct drm_i915_private *dev_priv)
+{
+   sysfs_remove_group(dev_priv->perf.metrics_kobj, _render_basic);
+}
diff --git a/drivers/gpu/drm/i915/i915_oa_hsw.h 
b/drivers/gpu/drm/i915/i915_oa_hsw.h
index b618a1f..e4ba89d 100644
--- a/drivers/gpu/drm/i915/i915_oa_hsw.h
+++ b/drivers/gpu/drm/i915/i915_oa_hsw.h
@@ -31,4 +31,8 @@ extern int i915_oa_n_builtin_metric_sets_hsw;
 
 extern int i915_oa_select_metric_set_hsw(struct drm_i915_private *dev_priv);
 
+extern int i915_perf_init_sysfs_hsw(struct drm_i915_private *dev_priv);
+
+extern void i915_perf_deinit_sysfs_hsw(struct drm_i915_private *dev_priv);
+
 #endif
diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c
index 094c6ed..ef0a240 100644
--- a/drivers/gpu/drm/i915/i915_perf.c
+++ b/drivers/gpu/drm/i915/i915_perf.c
@@ -1295,6 +1295,11 @@ void i915_perf_init(struct drm_device *dev)
if (!IS_HASWELL(dev))
return;
 
+   dev_priv->perf.metrics_kobj =
+   kobject_create_and_add("metrics", >primary->kdev->kobj);
+   if (!dev_priv->perf.metrics_kobj)
+   return;
+
hrtimer_init(_priv->perf.oa.poll_check_timer,
 CLOCK_MONOTONIC, HRTIMER_MODE_REL);
dev_priv->perf.oa.poll_check_timer.function = oa_poll_check_timer_cb;
@@ -1322,9 +1327,15 @@ void i915_perf_init(struct drm_device *dev)
dev_priv->perf.oa.n_builtin_sets =
i915_oa_n_builtin_metric_sets_hsw;
 
-   dev_priv->perf.oa.oa_formats = hsw_oa_formats;
+   if (i915_perf_init_sysfs_hsw(dev_priv)) {
+   kobject_put(dev_priv->perf.metrics_kobj);
+   dev_priv->perf.metrics_kobj = NULL;
+   return;
+   }
 
dev_priv->perf.initialized = true;
+
+   return;
 }
 
 void i915_perf_fini(struct drm_device *dev)
@@ -1334,6 +1345,11 @@ void i915_perf_fini(struct drm_device *dev)
if (!dev_priv->perf.initialized)
return;
 
+   i915_perf_deinit_sysfs_hsw(dev_priv);
+
+   kobject_put(dev_priv->perf.metrics_kobj);
+   dev_priv->perf.metrics_kobj = NULL;
+
dev_priv->perf.oa.ops.init_oa_buffer = NULL;
 
dev_priv->perf.initialized = false;
-- 
2.7.1

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] [PATCH v2 08/10] drm/i915: Add dev.i915.perf_event_paranoid sysctl option

2016-04-29 Thread Robert Bragg
Consistent with the kernel.perf_event_paranoid sysctl option that can
allow non-root users to access system wide cpu metrics, this can
optionally allow non-root users to access system wide OA counter metrics
from Gen graphics hardware.

Signed-off-by: Robert Bragg 
---
 drivers/gpu/drm/i915/i915_drv.h  |  1 +
 drivers/gpu/drm/i915/i915_perf.c | 46 +++-
 2 files changed, 46 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 68fdf1a..91a88fe 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2098,6 +2098,7 @@ struct drm_i915_private {
bool initialized;
 
struct kobject *metrics_kobj;
+   struct ctl_table_header *sysctl_header;
 
struct mutex lock;
struct list_head streams;
diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c
index ef0a240..3789378 100644
--- a/drivers/gpu/drm/i915/i915_perf.c
+++ b/drivers/gpu/drm/i915/i915_perf.c
@@ -59,6 +59,8 @@
 #define POLL_FREQUENCY 200
 #define POLL_PERIOD (NSEC_PER_SEC / POLL_FREQUENCY)
 
+static u32 i915_perf_stream_paranoid = true;
+
 /* The maximum exponent the hardware accepts is 63 (essentially it selects one
  * of the 64bit timestamp bits to trigger reports from) but there's currently
  * no known use case for sampling as infrequently as once per 47 thousand 
years.
@@ -1084,7 +1086,13 @@ int i915_perf_open_ioctl_locked(struct drm_device *dev,
}
}
 
-   if (!specific_ctx && !capable(CAP_SYS_ADMIN)) {
+   /* Similar to perf's kernel.perf_paranoid_cpu sysctl option
+* we check a dev.i915.perf_stream_paranoid sysctl option
+* to determine if it's ok to access system wide OA counters
+* without CAP_SYS_ADMIN privileges.
+*/
+   if (!specific_ctx &&
+   i915_perf_stream_paranoid && !capable(CAP_SYS_ADMIN)) {
DRM_ERROR("Insufficient privileges to open system-wide i915 
perf stream\n");
ret = -EACCES;
goto err_ctx;
@@ -1288,6 +1296,38 @@ int i915_perf_open_ioctl(struct drm_device *dev, void 
*data,
return ret;
 }
 
+
+static struct ctl_table oa_table[] = {
+   {
+.procname = "perf_stream_paranoid",
+.data = _perf_stream_paranoid,
+.maxlen = sizeof(i915_perf_stream_paranoid),
+.mode = 0644,
+.proc_handler = proc_dointvec,
+},
+   {}
+};
+
+static struct ctl_table i915_root[] = {
+   {
+.procname = "i915",
+.maxlen = 0,
+.mode = 0555,
+.child = oa_table,
+},
+   {}
+};
+
+static struct ctl_table dev_root[] = {
+   {
+.procname = "dev",
+.maxlen = 0,
+.mode = 0555,
+.child = i915_root,
+},
+   {}
+};
+
 void i915_perf_init(struct drm_device *dev)
 {
struct drm_i915_private *dev_priv = to_i915(dev);
@@ -1333,6 +1373,8 @@ void i915_perf_init(struct drm_device *dev)
return;
}
 
+   dev_priv->perf.sysctl_header = register_sysctl_table(dev_root);
+
dev_priv->perf.initialized = true;
 
return;
@@ -1345,6 +1387,8 @@ void i915_perf_fini(struct drm_device *dev)
if (!dev_priv->perf.initialized)
return;
 
+   unregister_sysctl_table(dev_priv->perf.sysctl_header);
+
i915_perf_deinit_sysfs_hsw(dev_priv);
 
kobject_put(dev_priv->perf.metrics_kobj);
-- 
2.7.1

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] [PATCH v2 05/10] drm/i915: Add 'render basic' Haswell OA unit config

2016-04-29 Thread Robert Bragg
Adds a static OA unit, MUX + B Counter configuration for basic render
metrics on Haswell. This is autogenerated from an internal XML
description of metric sets.

Signed-off-by: Robert Bragg 
---
 drivers/gpu/drm/i915/Makefile  |   3 +-
 drivers/gpu/drm/i915/i915_drv.h|  14 
 drivers/gpu/drm/i915/i915_oa_hsw.c | 132 +
 drivers/gpu/drm/i915/i915_oa_hsw.h |  34 ++
 4 files changed, 182 insertions(+), 1 deletion(-)
 create mode 100644 drivers/gpu/drm/i915/i915_oa_hsw.c
 create mode 100644 drivers/gpu/drm/i915/i915_oa_hsw.h

diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index d90d907..5293fc7 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -100,7 +100,8 @@ i915-y += dvo_ch7017.o \
 i915-y += i915_vgpu.o
 
 # perf code
-i915-y += i915_perf.o
+i915-y += i915_perf.o \
+ i915_oa_hsw.o
 
 # legacy horrors
 i915-y += i915_dma.o
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 3d2450f..f85fd72 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1712,6 +1712,11 @@ struct intel_wm_config {
bool sprites_scaled;
 };
 
+struct i915_oa_reg {
+   i915_reg_t addr;
+   u32 value;
+};
+
 struct i915_perf_read_state {
int count;
ssize_t read;
@@ -2073,6 +2078,15 @@ struct drm_i915_private {
bool initialized;
struct mutex lock;
struct list_head streams;
+
+   struct {
+   u32 metrics_set;
+
+   const struct i915_oa_reg *mux_regs;
+   int mux_regs_len;
+   const struct i915_oa_reg *b_counter_regs;
+   int b_counter_regs_len;
+   } oa;
} perf;
 
/* Abstract the submission mechanism (legacy ringbuffer or execlists) 
away */
diff --git a/drivers/gpu/drm/i915/i915_oa_hsw.c 
b/drivers/gpu/drm/i915/i915_oa_hsw.c
new file mode 100644
index 000..5472aa0
--- /dev/null
+++ b/drivers/gpu/drm/i915/i915_oa_hsw.c
@@ -0,0 +1,132 @@
+/*
+ * Autogenerated file, DO NOT EDIT manually!
+ *
+ * Copyright (c) 2015 Intel Corporation
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
+ * IN THE SOFTWARE.
+ *
+ */
+
+#include "i915_drv.h"
+
+enum metric_set_id {
+   METRIC_SET_ID_RENDER_BASIC = 1,
+};
+
+int i915_oa_n_builtin_metric_sets_hsw = 1;
+
+static const struct i915_oa_reg b_counter_config_render_basic[] = {
+   { _MMIO(0x2724), 0x0080 },
+   { _MMIO(0x2720), 0x },
+   { _MMIO(0x2714), 0x0080 },
+   { _MMIO(0x2710), 0x },
+};
+
+static const struct i915_oa_reg mux_config_render_basic[] = {
+   { _MMIO(0x253A4), 0x0160 },
+   { _MMIO(0x25440), 0x0010 },
+   { _MMIO(0x25128), 0x },
+   { _MMIO(0x2691C), 0x0800 },
+   { _MMIO(0x26AA0), 0x0150 },
+   { _MMIO(0x26B9C), 0x6000 },
+   { _MMIO(0x2791C), 0x0800 },
+   { _MMIO(0x27AA0), 0x0150 },
+   { _MMIO(0x27B9C), 0x6000 },
+   { _MMIO(0x2641C), 0x0400 },
+   { _MMIO(0x25380), 0x0010 },
+   { _MMIO(0x2538C), 0x },
+   { _MMIO(0x25384), 0x0800 },
+   { _MMIO(0x25400), 0x0004 },
+   { _MMIO(0x2540C), 0x06029000 },
+   { _MMIO(0x25410), 0x0002 },
+   { _MMIO(0x25404), 0x5C30 },
+   { _MMIO(0x25100), 0x0016 },
+   { _MMIO(0x25110), 0x0400 },
+   { _MMIO(0x25104), 0x },
+   { _MMIO(0x26804), 0x1211 },
+   { _MMIO(0x26884), 0x0100 },
+   { _MMIO(0x26900), 0x0002 },
+   { _MMIO(0x26908), 0x0070 },
+   { _MMIO(0x26904), 0x },
+   { _MMIO(0x26984), 0x1022 },
+   { _MMIO(0x26A04), 0x0011 },
+   { _MMIO(0x26A80), 0x0006 },
+   { _MMIO(0x26A88), 0x0C02 },
+

[Intel-gfx] [PATCH v2 03/10] drm/i915: return EACCES for check_cmd() failures

2016-04-29 Thread Robert Bragg
check_cmd() is checking whether a command adheres to certain
restrictions that ensure it's safe to execute within a privileged batch
buffer. Returning false implies a privilege problem, not that the
command is invalid.

The distinction makes the difference between allowing the buffer to be
executed as an unprivileged batch buffer or returning an EINVAL error to
userspace without executing anything.

In a case where userspace may want to test whether it can successfully
write to a register that needs privileges the distinction may be
important and an EINVAL error may be considered fatal.

In particular this is currently true for Mesa, which includes a test for
whether OACONTROL can be written too, but Mesa treats any error when
flushing a batch buffer as fatal, calling exit(1).

As it is currently Mesa can gracefully handle a failure to write to
OACONTROL if the command parser is disabled, but if we were to remove
OACONTROL from the parser's whitelist then the returned EINVAL would
break Mesa applications as they attempt an OACONTROL write.

Signed-off-by: Robert Bragg 
---
 drivers/gpu/drm/i915/i915_cmd_parser.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_cmd_parser.c 
b/drivers/gpu/drm/i915/i915_cmd_parser.c
index 035f2dd..5724d80 100644
--- a/drivers/gpu/drm/i915/i915_cmd_parser.c
+++ b/drivers/gpu/drm/i915/i915_cmd_parser.c
@@ -1245,7 +1245,7 @@ int i915_parse_cmds(struct intel_engine_cs *engine,
 
if (!check_cmd(engine, desc, cmd, length, is_master,
   _set)) {
-   ret = -EINVAL;
+   ret = -EACCES;
break;
}
 
-- 
2.7.1

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] [PATCH v2 01/10] drm/i915: Add i915 perf infrastructure

2016-04-29 Thread Robert Bragg
Adds base i915 perf infrastructure for Gen performance metrics.

This adds a DRM_IOCTL_I915_PERF_OPEN ioctl that takes an array of uint64
properties to configure a stream of metrics and returns a new fd usable
with standard VFS system calls including read() to read typed and sized
records; ioctl() to enable or disable capture and poll() to wait for
data.

A stream is opened something like:

  uint64_t properties[] = {
  /* Single context sampling */
  DRM_I915_PERF_PROP_CTX_HANDLE,ctx_handle,

  /* Include OA reports in samples */
  DRM_I915_PERF_PROP_SAMPLE_OA, true,

  /* OA unit configuration */
  DRM_I915_PERF_PROP_OA_METRICS_SET,metrics_set_id,
  DRM_I915_PERF_PROP_OA_FORMAT, report_format,
  DRM_I915_PERF_PROP_OA_EXPONENT,   period_exponent,
   };
   struct drm_i915_perf_open_param parm = {
  .flags = I915_PERF_FLAG_FD_CLOEXEC |
   I915_PERF_FLAG_FD_NONBLOCK |
   I915_PERF_FLAG_DISABLED,
  .properties_ptr = (uint64_t)properties,
  .num_properties = sizeof(properties) / 16,
   };
   int fd = drmIoctl(drm_fd, DRM_IOCTL_I915_PERF_OPEN, );

Records read all start with a common { type, size } header with
DRM_I915_PERF_RECORD_SAMPLE being of most interest. Sample records
contain an extensible number of fields and it's the
DRM_I915_PERF_PROP_SAMPLE_xyz properties given when opening that
determine what's included in every sample.

No specific streams are supported yet so any attempt to open a stream
will return an error.

Signed-off-by: Robert Bragg 
---
 drivers/gpu/drm/i915/Makefile|   3 +
 drivers/gpu/drm/i915/i915_dma.c  |   8 +
 drivers/gpu/drm/i915/i915_drv.h  |  92 +
 drivers/gpu/drm/i915/i915_perf.c | 431 +++
 include/uapi/drm/i915_drm.h  |  67 ++
 5 files changed, 601 insertions(+)
 create mode 100644 drivers/gpu/drm/i915/i915_perf.c

diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 723c502..d90d907 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -99,6 +99,9 @@ i915-y += dvo_ch7017.o \
 # virtual gpu code
 i915-y += i915_vgpu.o
 
+# perf code
+i915-y += i915_perf.o
+
 # legacy horrors
 i915-y += i915_dma.o
 
diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
index f69330c..89cec21 100644
--- a/drivers/gpu/drm/i915/i915_dma.c
+++ b/drivers/gpu/drm/i915/i915_dma.c
@@ -1074,6 +1074,11 @@ static int i915_driver_init_early(struct 
drm_i915_private *dev_priv,
if (ret < 0)
return ret;
 
+   /* Must at least be initialized before trying to pin any context
+* which i915_perf hooks into.
+*/
+   i915_perf_init(dev);
+
/* This must be called before any calls to HAS_PCH_* */
intel_detect_pch(dev);
 
@@ -1460,6 +1465,8 @@ int i915_driver_unload(struct drm_device *dev)
 
i915_driver_unregister(dev_priv);
 
+   i915_perf_fini(dev);
+
drm_vblank_cleanup(dev);
 
intel_modeset_cleanup(dev);
@@ -1611,6 +1618,7 @@ const struct drm_ioctl_desc i915_ioctls[] = {
DRM_IOCTL_DEF_DRV(I915_GEM_USERPTR, i915_gem_userptr_ioctl, 
DRM_RENDER_ALLOW),
DRM_IOCTL_DEF_DRV(I915_GEM_CONTEXT_GETPARAM, 
i915_gem_context_getparam_ioctl, DRM_RENDER_ALLOW),
DRM_IOCTL_DEF_DRV(I915_GEM_CONTEXT_SETPARAM, 
i915_gem_context_setparam_ioctl, DRM_RENDER_ALLOW),
+   DRM_IOCTL_DEF_DRV(I915_PERF_OPEN, i915_perf_open_ioctl, 
DRM_RENDER_ALLOW),
 };
 
 int i915_max_ioctl = ARRAY_SIZE(i915_ioctls);
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index e2abbcc..3d2450f 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1712,6 +1712,85 @@ struct intel_wm_config {
bool sprites_scaled;
 };
 
+struct i915_perf_read_state {
+   int count;
+   ssize_t read;
+   char __user *buf;
+};
+
+struct i915_perf_stream;
+
+struct i915_perf_stream_ops {
+   /* Enables the collection of HW samples, either in response to
+* I915_PERF_IOCTL_ENABLE or implicitly called when stream is
+* opened without I915_PERF_FLAG_DISABLED.
+*/
+   void (*enable)(struct i915_perf_stream *stream);
+
+   /* Disables the collection of HW samples, either in response to
+* I915_PERF_IOCTL_DISABLE or implicitly called before
+* destroying the stream.
+*/
+   void (*disable)(struct i915_perf_stream *stream);
+
+   /* Return: true if any i915 perf records are ready to read()
+* for this stream.
+*/
+   bool (*can_read)(struct i915_perf_stream *stream);
+
+   /* Call poll_wait, passing a wait queue that will be woken
+* once there is something ready to read() for the stream
+*/
+   void (*poll_wait)(struct i915_perf_stream *stream,
+ struct file *file,
+ poll_table *wait);
+

[Intel-gfx] [PATCH v2 04/10] drm/i915: don't whitelist oacontrol in cmd parser

2016-04-29 Thread Robert Bragg
Being able to program OACONTROL from a non-privileged batch buffer is
not sufficient to be able to configure the OA unit. This was originally
allowed to help enable Mesa to expose OA counters via the
INTEL_performance_query extension, but the current implementation based
on programming OACONTROL via a batch buffer isn't able to report useable
data without a more complete OA unit configuration. Mesa handles the
possibility that writes to OACONTROL may not be allowed and so only
advertises the extension after explicitly testing that a write to
OACONTROL succeeds. Based on this; removing OACONTROL from the whitelist
should be ok for userspace.

Removing this simplifies adding a new kernel api for configuring the OA
unit without needing to consider the possibility that userspace might
trample on OACONTROL state which we'd like to start managing within
the kernel instead. In particular running any Mesa based GL application
currently results in clearing OACONTROL when initializing which would
disable the capturing of metrics.

Signed-off-by: Robert Bragg 
---
 drivers/gpu/drm/i915/i915_cmd_parser.c | 33 ++---
 1 file changed, 2 insertions(+), 31 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_cmd_parser.c 
b/drivers/gpu/drm/i915/i915_cmd_parser.c
index 5724d80..ff2b57b 100644
--- a/drivers/gpu/drm/i915/i915_cmd_parser.c
+++ b/drivers/gpu/drm/i915/i915_cmd_parser.c
@@ -445,7 +445,6 @@ static const struct drm_i915_reg_descriptor 
gen7_render_regs[] = {
REG64(PS_INVOCATION_COUNT),
REG64(PS_DEPTH_COUNT),
REG64_IDX(RING_TIMESTAMP, RENDER_RING_BASE),
-   REG32(GEN7_OACONTROL), /* Only allowed for LRI and SRM. See below. */
REG64(MI_PREDICATE_SRC0),
REG64(MI_PREDICATE_SRC1),
REG32(GEN7_3DPRIM_END_OFFSET),
@@ -1044,8 +1043,7 @@ bool i915_needs_cmd_parser(struct intel_engine_cs *engine)
 static bool check_cmd(const struct intel_engine_cs *engine,
  const struct drm_i915_cmd_descriptor *desc,
  const u32 *cmd, u32 length,
- const bool is_master,
- bool *oacontrol_set)
+ const bool is_master)
 {
if (desc->flags & CMD_DESC_REJECT) {
DRM_DEBUG_DRIVER("CMD: Rejected command: 0x%08X\n", *cmd);
@@ -1083,26 +1081,6 @@ static bool check_cmd(const struct intel_engine_cs 
*engine,
}
 
/*
-* OACONTROL requires some special handling for
-* writes. We want to make sure that any batch which
-* enables OA also disables it before the end of the
-* batch. The goal is to prevent one process from
-* snooping on the perf data from another process. To do
-* that, we need to check the value that will be written
-* to the register. Hence, limit OACONTROL writes to
-* only MI_LOAD_REGISTER_IMM commands.
-*/
-   if (reg_addr == i915_mmio_reg_offset(GEN7_OACONTROL)) {
-   if (desc->cmd.value == MI_LOAD_REGISTER_MEM) {
-   DRM_DEBUG_DRIVER("CMD: Rejected LRM to 
OACONTROL\n");
-   return false;
-   }
-
-   if (desc->cmd.value == MI_LOAD_REGISTER_IMM(1))
-   *oacontrol_set = (cmd[offset + 1] != 0);
-   }
-
-   /*
 * Check the value written to the register against the
 * allowed mask/value pair given in the whitelist entry.
 */
@@ -1186,7 +1164,6 @@ int i915_parse_cmds(struct intel_engine_cs *engine,
 {
u32 *cmd, *batch_base, *batch_end;
struct drm_i915_cmd_descriptor default_desc = { 0 };
-   bool oacontrol_set = false; /* OACONTROL tracking. See check_cmd() */
int ret = 0;
 
batch_base = copy_batch(shadow_batch_obj, batch_obj,
@@ -1243,8 +1220,7 @@ int i915_parse_cmds(struct intel_engine_cs *engine,
break;
}
 
-   if (!check_cmd(engine, desc, cmd, length, is_master,
-  _set)) {
+   if (!check_cmd(engine, desc, cmd, length, is_master)) {
ret = -EACCES;
break;
}
@@ -1252,11 +1228,6 @@ int i915_parse_cmds(struct intel_engine_cs *engine,
cmd += length;
}
 
-   if (oacontrol_set) {
-   DRM_DEBUG_DRIVER("CMD: batch set OACONTROL but did not clear 
it\n");
-   ret = -EINVAL;
-   }
-
if (cmd >= batch_end) {
DRM_DEBUG_DRIVER("CMD: Got to the end of the buffer w/o a BBE 
cmd!\n");
   

[Intel-gfx] [PATCH v2 00/10] Enable Gen 7 Observation Architecture

2016-04-29 Thread Robert Bragg
Hopefully covers the last issues raised by Chris and addresses the open issue I
had with removing OACONTROL from the command parser whitelist.

- Robert

Robert Bragg (10):
  drm/i915: Add i915 perf infrastructure
  drm/i915: rename OACONTROL GEN7_OACONTROL
  drm/i915: return EACCES for check_cmd() failures
  drm/i915: don't whitelist oacontrol in cmd parser
  drm/i915: Add 'render basic' Haswell OA unit config
  drm/i915: Enable i915 perf stream for Haswell OA unit
  drm/i915: advertise available metrics via sysfs
  drm/i915: Add dev.i915.perf_event_paranoid sysctl option
  drm/i915: add oa_event_min_timer_exponent sysctl
  drm/i915: Add more Haswell OA metric sets

 drivers/gpu/drm/i915/Makefile   |4 +
 drivers/gpu/drm/i915/i915_cmd_parser.c  |   35 +-
 drivers/gpu/drm/i915/i915_dma.c |8 +
 drivers/gpu/drm/i915/i915_drv.h |  161 
 drivers/gpu/drm/i915/i915_gem_context.c |   24 +-
 drivers/gpu/drm/i915/i915_oa_hsw.c  |  658 ++
 drivers/gpu/drm/i915/i915_oa_hsw.h  |   38 +
 drivers/gpu/drm/i915/i915_perf.c| 1418 +++
 drivers/gpu/drm/i915/i915_reg.h |  340 +++-
 include/uapi/drm/i915_drm.h |  133 +++
 10 files changed, 2781 insertions(+), 38 deletions(-)
 create mode 100644 drivers/gpu/drm/i915/i915_oa_hsw.c
 create mode 100644 drivers/gpu/drm/i915/i915_oa_hsw.h
 create mode 100644 drivers/gpu/drm/i915/i915_perf.c

-- 
2.7.1

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] [PATCH v2 06/10] drm/i915: Enable i915 perf stream for Haswell OA unit

2016-04-29 Thread Robert Bragg
Gen graphics hardware can be set up to periodically write snapshots of
performance counters into a circular buffer via its Observation
Architecture and this patch exposes that capability to userspace via the
i915 perf interface.

Cc: Chris Wilson 
Signed-off-by: Robert Bragg 
Signed-off-by: Zhenyu Wang 
---
 drivers/gpu/drm/i915/i915_drv.h |  56 +-
 drivers/gpu/drm/i915/i915_gem_context.c |  24 +-
 drivers/gpu/drm/i915/i915_perf.c| 931 +++-
 drivers/gpu/drm/i915/i915_reg.h | 338 
 include/uapi/drm/i915_drm.h |  70 ++-
 5 files changed, 1399 insertions(+), 20 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index f85fd72..602eb03 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1712,6 +1712,11 @@ struct intel_wm_config {
bool sprites_scaled;
 };
 
+struct i915_oa_format {
+   u32 format;
+   int size;
+};
+
 struct i915_oa_reg {
i915_reg_t addr;
u32 value;
@@ -1789,11 +1794,26 @@ struct i915_perf_stream {
struct list_head link;
 
u32 sample_flags;
+   int sample_size;
 
struct intel_context *ctx;
bool enabled;
 
-   struct i915_perf_stream_ops *ops;
+   const struct i915_perf_stream_ops *ops;
+};
+
+struct i915_oa_ops {
+   void (*init_oa_buffer)(struct drm_i915_private *dev_priv);
+   int (*enable_metric_set)(struct drm_i915_private *dev_priv);
+   void (*disable_metric_set)(struct drm_i915_private *dev_priv);
+   void (*oa_enable)(struct drm_i915_private *dev_priv);
+   void (*oa_disable)(struct drm_i915_private *dev_priv);
+   void (*update_oacontrol)(struct drm_i915_private *dev_priv);
+   void (*update_hw_ctx_id_locked)(struct drm_i915_private *dev_priv,
+   u32 ctx_id);
+   int (*read)(struct i915_perf_stream *stream,
+   struct i915_perf_read_state *read_state);
+   bool (*oa_buffer_is_empty)(struct drm_i915_private *dev_priv);
 };
 
 struct drm_i915_private {
@@ -2076,16 +2096,46 @@ struct drm_i915_private {
 
struct {
bool initialized;
+
struct mutex lock;
struct list_head streams;
 
+   spinlock_t hook_lock;
+
struct {
-   u32 metrics_set;
+   struct i915_perf_stream *exclusive_stream;
+
+   u32 specific_ctx_id;
+
+   struct hrtimer poll_check_timer;
+   wait_queue_head_t poll_wq;
+
+   bool periodic;
+   int period_exponent;
+   int timestamp_frequency;
+
+   int tail_margin;
+
+   int metrics_set;
 
const struct i915_oa_reg *mux_regs;
int mux_regs_len;
const struct i915_oa_reg *b_counter_regs;
int b_counter_regs_len;
+
+   struct {
+   struct drm_i915_gem_object *obj;
+   u32 gtt_offset;
+   u8 *addr;
+   int format;
+   int format_size;
+   } oa_buffer;
+
+   u32 gen7_latched_oastatus1;
+
+   struct i915_oa_ops ops;
+   const struct i915_oa_format *oa_formats;
+   int n_builtin_sets;
} oa;
} perf;
 
@@ -3441,6 +3491,8 @@ int i915_gem_context_setparam_ioctl(struct drm_device 
*dev, void *data,
 
 int i915_perf_open_ioctl(struct drm_device *dev, void *data,
 struct drm_file *file);
+void i915_oa_context_pin_notify(struct drm_i915_private *dev_priv,
+   struct intel_context *context);
 
 /* i915_gem_evict.c */
 int __must_check i915_gem_evict_something(struct drm_device *dev,
diff --git a/drivers/gpu/drm/i915/i915_gem_context.c 
b/drivers/gpu/drm/i915/i915_gem_context.c
index b1b704c..4fec631 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/i915_gem_context.c
@@ -135,6 +135,23 @@ static int get_context_size(struct drm_device *dev)
return ret;
 }
 
+static int i915_gem_context_pin_state(struct drm_device *dev,
+ struct intel_context *ctx)
+{
+   int ret;
+
+   BUG_ON(!mutex_is_locked(>struct_mutex));
+
+   ret = i915_gem_obj_ggtt_pin(ctx->legacy_hw_ctx.rcs_state,
+   get_context_alignment(dev), 0);
+   if (ret)
+   return ret;
+
+   i915_oa_context_pin_notify(dev->dev_private, ctx);
+
+   return 0;
+}
+
 static void i915_gem_context_clean(struct intel_context *ctx)
 {

[Intel-gfx] [PATCH v2 02/10] drm/i915: rename OACONTROL GEN7_OACONTROL

2016-04-29 Thread Robert Bragg
OACONTROL changes quite a bit for gen8, with some bits split out into a
per-context OACTXCONTROL register. Rename now before adding more gen7 OA
registers

Signed-off-by: Robert Bragg 
---
 drivers/gpu/drm/i915/i915_cmd_parser.c | 4 ++--
 drivers/gpu/drm/i915/i915_reg.h| 2 +-
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_cmd_parser.c 
b/drivers/gpu/drm/i915/i915_cmd_parser.c
index a337f33..035f2dd 100644
--- a/drivers/gpu/drm/i915/i915_cmd_parser.c
+++ b/drivers/gpu/drm/i915/i915_cmd_parser.c
@@ -445,7 +445,7 @@ static const struct drm_i915_reg_descriptor 
gen7_render_regs[] = {
REG64(PS_INVOCATION_COUNT),
REG64(PS_DEPTH_COUNT),
REG64_IDX(RING_TIMESTAMP, RENDER_RING_BASE),
-   REG32(OACONTROL), /* Only allowed for LRI and SRM. See below. */
+   REG32(GEN7_OACONTROL), /* Only allowed for LRI and SRM. See below. */
REG64(MI_PREDICATE_SRC0),
REG64(MI_PREDICATE_SRC1),
REG32(GEN7_3DPRIM_END_OFFSET),
@@ -1092,7 +1092,7 @@ static bool check_cmd(const struct intel_engine_cs 
*engine,
 * to the register. Hence, limit OACONTROL writes to
 * only MI_LOAD_REGISTER_IMM commands.
 */
-   if (reg_addr == i915_mmio_reg_offset(OACONTROL)) {
+   if (reg_addr == i915_mmio_reg_offset(GEN7_OACONTROL)) {
if (desc->cmd.value == MI_LOAD_REGISTER_MEM) {
DRM_DEBUG_DRIVER("CMD: Rejected LRM to 
OACONTROL\n");
return false;
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 0a2fd30..11eccf4 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -611,7 +611,7 @@ static inline bool i915_mmio_reg_valid(i915_reg_t reg)
 #define HSW_CS_GPR(n)   _MMIO(0x2600 + (n) * 8)
 #define HSW_CS_GPR_UDW(n)   _MMIO(0x2600 + (n) * 8 + 4)
 
-#define OACONTROL _MMIO(0x2360)
+#define GEN7_OACONTROL _MMIO(0x2360)
 
 #define _GEN7_PIPEA_DE_LOAD_SL 0x70068
 #define _GEN7_PIPEB_DE_LOAD_SL 0x71068
-- 
2.7.1

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] xserver crash with linux 4.6.0-rc3 and later

2016-04-29 Thread Chris Wilson
On Fri, Apr 29, 2016 at 01:25:30PM -0400, John S Gruber wrote:
> Starting with linux 4.6.0-rc3 my Ubuntu Wily system no longer allows logons 
> from
> due to an immediate abort in xserver after just after entering my
> userid and password. (lightdm drew the sign on screen OK).
> 
> The xserver problem seems to result from a null reference from
>  __kgem_retire_rq from package xserver-xorg-video-intel version
> 2:2.99.917+git20150808-0ubuntu4.
> 
> Bisecting the kernel I found that this was triggered by commit
> 426960bed3217f72a1b7bb94f084d79cc616ec0f. Reverting this commit based on
> 4.6-rc5 eliminated my crash.
> 
> The problem was specific to my HP Pavilion laptop with Intel HD 5500
> integrated graphics . A desktop Acer, also using Intel graphics, was
> fine. On the laptop it was completely consistent.
> 
> The laptop has:
> 
> 00:02.0 VGA compatible controller: Intel Corporation Broadwell-U
> Integrated Graphics (rev 09) (prog-if 00 [VGA controller])
> DeviceName: Intel(R) Graphics GT2
> 
> Testing the laptop with Ubuntu xenial (with xserver-xorg-video-intel
> version 2:2.99.917+git20160325-1ubuntu1) was fine, however.
> 
> Please let me know if this is problematic, and if so, if I should provide
> additional information. I don't follow the list.
> 
> --
> 
> The triggering commit:
> 
> drm/i915: Seal busy-ioctl uABI and prevent leaking of internal ids

The seeds of that crash were already sown. The error is that on a batch
buffer allocation failure, the preallocated failsafe ended up on the
request list (which is not supposed to happen and so it runs off the end
of the list).

commit 69d8edc11173df021aa2e158b2530257113141fd
Author: Chris Wilson 
Date:   Fri Aug 7 10:08:17 2015 +0100

sna: Handle batch allocation failure

Whilst we currently do not try and submit a failed batch buffer
allocation, we still treat it as a valid request. This explodes much
later when we inspect the NULL rq->bo.

References: https://bugs.freedesktop.org/show_bug.cgi?id=91577
Signed-off-by: Chris Wilson 

is the cause of the crash, but

commit 2d26643cab33a32847afaf13b50d326d09d58bf7
Author: Chris Wilson 
Date:   Fri Nov 13 19:03:36 2015 +

sna/dri2: Drop the reference on the fence when complete

Fixes regression from

commit 8d9e496670f48b4eec64dfe1bcedb49793cf3073
Author: Chris Wilson 
Date:   Wed Jul 22 11:14:01 2015 +0100

sna/dri2: Take over the placeholder vblank

After noting the fence was complete, we would clear it. But I forgot
that we actually held a reference on to it, and so we would leak the 64k
batch, and starve the system of available memory in about 18 minutes of
SwapBuffers.

Reported-by: Arkadiusz Miskiewicz 
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=92911
Signed-off-by: Chris Wilson 

is where the bug began. The kernel just made it easier to hit the
pre-existing bugs in userspace.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [v2,1/2] drm/i915/execlists: Refactor common engine setup

2016-04-29 Thread Patchwork
== Series Details ==

Series: series starting with [v2,1/2] drm/i915/execlists: Refactor common 
engine setup
URL   : https://patchwork.freedesktop.org/series/6549/
State : failure

== Summary ==

  CC [M]  drivers/net/ethernet/intel/igb/e1000_82575.o
  CONMK   drivers/tty/vt/consolemap_deftbl.c
  CC  drivers/tty/vt/vt.o
  CC [M]  drivers/net/ethernet/intel/igbvf/mbx.o
  CC [M]  drivers/net/ethernet/intel/igbvf/ethtool.o
  SHIPPED drivers/tty/vt/defkeymap.c
  CC  drivers/tty/vt/consolemap_deftbl.o
  CC  drivers/tty/vt/defkeymap.o
  CC [M]  drivers/net/ethernet/intel/igb/e1000_mac.o
  CC [M]  drivers/net/ethernet/intel/igbvf/netdev.o
  CC  drivers/usb/host/xhci-pci.o
  CC [M]  drivers/net/ethernet/intel/igb/e1000_nvm.o
  CC [M]  drivers/net/ethernet/intel/igb/e1000_phy.o
  CC [M]  drivers/net/ethernet/intel/igb/e1000_mbx.o
  CC [M]  drivers/net/ethernet/intel/igb/e1000_i210.o
  CC [M]  drivers/net/ethernet/intel/igb/igb_ptp.o
  CC [M]  drivers/net/ethernet/intel/igb/igb_hwmon.o
  LD [M]  drivers/net/ethernet/intel/e1000/e1000.o
  LD  drivers/usb/host/xhci-hcd.o
  LD  drivers/usb/host/built-in.o
  LD  drivers/usb/built-in.o
  LD  drivers/tty/vt/built-in.o
  LD  drivers/tty/built-in.o
  LD [M]  drivers/net/ethernet/intel/igbvf/igbvf.o
  LD [M]  drivers/net/ethernet/intel/igb/igb.o
  LD [M]  drivers/net/ethernet/intel/e1000e/e1000e.o
  LD  drivers/net/ethernet/built-in.o
  LD  drivers/net/built-in.o
Makefile:962: recipe for target 'drivers' failed
make: *** [drivers] Error 2

Full logs at /archive/deploy/logs/CI_Patchwork_build_2117

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] [PATCH v2 1/2] drm/i915/execlists: Refactor common engine setup

2016-04-29 Thread Chris Wilson
Move all of the constant assignments up front and into a common
function. This is primarily to ensure the backpointers are set as early
as possible for later use during initialisation.

v2: Use a constant struct so that all the similar values are set
together.
v3: Sanitize the engine's IMR to disable any potential interrupt before
we are ready (enabled in init_hw).

Signed-off-by: Chris Wilson 
Cc: Tvrtko Ursulin 
Cc: Dave Gordon 
---
 drivers/gpu/drm/i915/intel_lrc.c | 180 +--
 1 file changed, 97 insertions(+), 83 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index d8763524319d..8106316ce56f 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -1918,8 +1918,7 @@ void intel_logical_ring_cleanup(struct intel_engine_cs 
*engine)
 }
 
 static void
-logical_ring_default_vfuncs(struct drm_device *dev,
-   struct intel_engine_cs *engine)
+logical_ring_default_vfuncs(struct intel_engine_cs *engine)
 {
/* Default vfuncs which can be overriden by each engine. */
engine->init_hw = gen8_init_common_ring;
@@ -1930,7 +1929,7 @@ logical_ring_default_vfuncs(struct drm_device *dev,
engine->emit_bb_start = gen8_emit_bb_start;
engine->get_seqno = gen8_get_seqno;
engine->set_seqno = gen8_set_seqno;
-   if (IS_BXT_REVID(dev, 0, BXT_REVID_A1)) {
+   if (IS_BXT_REVID(engine->dev, 0, BXT_REVID_A1)) {
engine->irq_seqno_barrier = bxt_a_seqno_barrier;
engine->set_seqno = bxt_a_set_seqno;
}
@@ -1941,6 +1940,7 @@ logical_ring_default_irqs(struct intel_engine_cs *engine, 
unsigned shift)
 {
engine->irq_enable_mask = GT_RENDER_USER_INTERRUPT << shift;
engine->irq_keep_mask = GT_CONTEXT_SWITCH_INTERRUPT << shift;
+   init_waitqueue_head(>irq_queue);
 }
 
 static int
@@ -1961,31 +1961,72 @@ lrc_setup_hws(struct intel_engine_cs *engine,
return 0;
 }
 
-static int
-logical_ring_init(struct drm_device *dev, struct intel_engine_cs *engine)
+static const struct logical_ring_info {
+   const char *name;
+   unsigned exec_id;
+   unsigned guc_id;
+   u32 mmio_base;
+   unsigned irq_shift;
+} logical_rings[] = {
+   [RCS] = {
+   .name = "render ring",
+   .exec_id = I915_EXEC_RENDER,
+   .guc_id = GUC_RENDER_ENGINE,
+   .mmio_base = RENDER_RING_BASE,
+   .irq_shift = GEN8_RCS_IRQ_SHIFT,
+   },
+   [BCS] = {
+   .name = "blitter ring",
+   .exec_id = I915_EXEC_BLT,
+   .guc_id = GUC_BLITTER_ENGINE,
+   .mmio_base = BLT_RING_BASE,
+   .irq_shift = GEN8_BCS_IRQ_SHIFT,
+   },
+   [VCS] = {
+   .name = "bsd ring",
+   .exec_id = I915_EXEC_BSD,
+   .guc_id = GUC_VIDEO_ENGINE,
+   .mmio_base = GEN6_BSD_RING_BASE,
+   .irq_shift = GEN8_VCS1_IRQ_SHIFT,
+   },
+   [VCS2] = {
+   .name = "bsd2 ring",
+   .exec_id = I915_EXEC_BSD,
+   .guc_id = GUC_VIDEO_ENGINE2,
+   .mmio_base = GEN8_BSD2_RING_BASE,
+   .irq_shift = GEN8_VCS2_IRQ_SHIFT,
+   },
+   [VECS] = {
+   .name = "video enhancement ring",
+   .exec_id = I915_EXEC_VEBOX,
+   .guc_id = GUC_VIDEOENHANCE_ENGINE,
+   .mmio_base = VEBOX_RING_BASE,
+   .irq_shift = GEN8_VECS_IRQ_SHIFT,
+   },
+};
+
+static struct intel_engine_cs *
+logical_ring_setup(struct drm_device *dev, enum intel_engine_id id)
 {
+   const struct logical_ring_info *info = _rings[id];
struct drm_i915_private *dev_priv = to_i915(dev);
-   struct intel_context *dctx = dev_priv->kernel_context;
+   struct intel_engine_cs *engine = _priv->engine[id];
enum forcewake_domains fw_domains;
-   int ret;
 
-   /* Intentionally left blank. */
-   engine->buffer = NULL;
+   engine->id = id;
+   engine->name = info->name;
+   engine->exec_id = info->exec_id;
+   engine->guc_id = info->guc_id;
+   engine->mmio_base = info->mmio_base;
 
-   engine->dev = dev;
-   INIT_LIST_HEAD(>active_list);
-   INIT_LIST_HEAD(>request_list);
-   i915_gem_batch_pool_init(dev, >batch_pool);
-   init_waitqueue_head(>irq_queue);
+   /* disable interrupts to this engine before we install ourselves */
+   I915_WRITE_IMR(engine, ~0);
+   POSTING_READ(RING_IMR(engine->mmio_base));
 
-   INIT_LIST_HEAD(>buffers);
-   INIT_LIST_HEAD(>execlist_queue);
-   spin_lock_init(>execlist_lock);
-
-   tasklet_init(>irq_tasklet,
-intel_lrc_irq_handler, (unsigned long)engine);
+   engine->dev = dev;
 
-   logical_ring_init_platform_invariants(engine);
+   /* 

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/2] drm/i915: Calculate IPS linetime watermark based on future cdclk

2016-04-29 Thread Patchwork
== Series Details ==

Series: series starting with [1/2] drm/i915: Calculate IPS linetime watermark 
based on future cdclk
URL   : https://patchwork.freedesktop.org/series/6544/
State : success

== Summary ==

Series 6544v1 Series without cover letter
http://patchwork.freedesktop.org/api/1.0/series/6544/revisions/1/mbox/


bdw-nuci7-2  total:201  pass:189  dwarn:0   dfail:0   fail:0   skip:12 
bdw-ultratotal:201  pass:176  dwarn:0   dfail:0   fail:0   skip:25 
bsw-nuc-2total:200  pass:159  dwarn:0   dfail:0   fail:0   skip:41 
byt-nuc  total:200  pass:159  dwarn:0   dfail:0   fail:0   skip:41 
hsw-brixbox  total:201  pass:175  dwarn:0   dfail:0   fail:0   skip:26 
hsw-gt2  total:201  pass:179  dwarn:0   dfail:0   fail:1   skip:21 
ivb-t430stotal:201  pass:170  dwarn:0   dfail:0   fail:0   skip:31 
skl-i7k-2total:201  pass:174  dwarn:0   dfail:0   fail:0   skip:27 
skl-nuci5total:201  pass:190  dwarn:0   dfail:0   fail:0   skip:11 
snb-x220ttotal:201  pass:159  dwarn:0   dfail:0   fail:1   skip:41 
snb-dellxps failed to collect. IGT log at Patchwork_2116/snb-dellxps/igt.log

Results at /archive/results/CI_IGT_test/Patchwork_2116/

e88c818eb230a7b07d71843f5eaca1786544c709 drm-intel-nightly: 
2016y-04m-29d-13h-05m-14s UTC integration manifest
f89860a drm/i915: Add a FIXME about crtc !active vs. watermarks
2555e64 drm/i915: Calculate IPS linetime watermark based on future cdclk

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH v2 4/5] drm/i915/guc: rework guc_add_workqueue_item()

2016-04-29 Thread Chris Wilson
On Fri, Apr 29, 2016 at 04:44:24PM +0100, Tvrtko Ursulin wrote:
> 
> On 27/04/16 19:03, Dave Gordon wrote:
> >Mostly little optimisations; for instance, if the driver is correctly
> >following the submission protocol, the "out of space" condition is
> >impossible, so the previous runtime WARN_ON() is promoted to a
> >GEM_BUG_ON() for a more dramatic effect in development and less impact
> >in end-user systems.
> >
> >Similarly we can replace other WARN_ON() conditions that don't relate to
> >the hardware state with either BUILD_BUG_ON() for compile-time-
> >detectable issues, or GEM_BUG_ON() for logical "can't happen" errors.
> >
> >With those changes, we can convert it to void, as suggested by Chris
> >Wilson, and update the calling code appropriately.
> >
> >Signed-off-by: Dave Gordon 
> >Cc: Chris Wilson 
> >
> >---
> >  drivers/gpu/drm/i915/i915_guc_submission.c | 69 
> > +++---
> >  drivers/gpu/drm/i915/intel_guc.h   |  2 +-
> >  drivers/gpu/drm/i915/intel_guc_fwif.h  |  3 +-
> >  3 files changed, 37 insertions(+), 37 deletions(-)
> >
> >diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c 
> >b/drivers/gpu/drm/i915/i915_guc_submission.c
> >index 6626eff..4d2ea84 100644
> >--- a/drivers/gpu/drm/i915/i915_guc_submission.c
> >+++ b/drivers/gpu/drm/i915/i915_guc_submission.c
> >@@ -470,23 +470,28 @@ int i915_guc_wq_check_space(struct 
> >drm_i915_gem_request *request)
> > return -EAGAIN;
> >  }
> >
> >-static int guc_add_workqueue_item(struct i915_guc_client *gc,
> >-  struct drm_i915_gem_request *rq)
> >+static void guc_add_workqueue_item(struct i915_guc_client *gc,
> >+   struct drm_i915_gem_request *rq)
> >  {
> >+/* wqi_len is in DWords, and does not include the one-word header */
> >+const size_t wqi_size = sizeof(struct guc_wq_item);
> 
> Again, u32 is correct I think.
> 
> >+const u32 wqi_len = wqi_size/sizeof(u32) - 1;
> > struct guc_process_desc *desc;
> > struct guc_wq_item *wqi;
> > void *base;
> >-u32 tail, wq_len, wq_off, space;
> >+u32 space, tail, wq_off, wq_page;
> >
> > desc = gc->client_base + gc->proc_desc_offset;
> >+
> >+/* Space was checked earlier, in i915_guc_wq_check_space() above */
> 
> It may be above in the file, but the two do not call one another so
> I recommend saying exactly who called it.
> 
> > space = CIRC_SPACE(gc->wq_tail, desc->head, gc->wq_size);
> >-if (WARN_ON(space < sizeof(struct guc_wq_item)))
> >-return -ENOSPC; /* shouldn't happen */
> >+GEM_BUG_ON(space < wqi_size);
> 
> It is impossible to hit this only because of the struct_mutex
> guarding the whole time window from request creation to submission.
> If in the future, near or far, that gets fixed, then this will need
> reworking.

Request submission will still have to serialised by a "ring" mutex, 
from the time we allocate the request to the time we add it to whatever
submission queue. It should still hold that we can pin all the required
resources (ringbuffer, context state, vm page tables, workqueues) up
front and take any errors early and then rely on our preallocation when
submitting the request.

> I don't have any better ideas though.
> 
> But a WARN_ON and return would be almost as good. Everything is
> better than a dead machine one can't ssh into...
> 
> So I appeal to make this a WARN_ON and return. Nothing bad would
> happen apart from software thinking GPU has hung.

Hence why not make it a bug? If you can't ssh in because the driver died
inside GEM, something is very wrong.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH v2 3/5] drm/i915/guc: don't spinwait if the GuC's workqueue is full

2016-04-29 Thread Tvrtko Ursulin


One late comment:

On 27/04/16 19:03, Dave Gordon wrote:

Rather than wait to see whether more space becomes available in the GuC
submission workqueue, we can just return -EAGAIN and let the caller try
again in a little while. This gets rid of an uninterruptable sleep in
the polling code :)

We'll also add a counter to the GuC client statistics, to see how often
we find the WQ full.

Signed-off-by: Dave Gordon 
---
  drivers/gpu/drm/i915/i915_debugfs.c|  1 +
  drivers/gpu/drm/i915/i915_guc_submission.c | 16 +---
  drivers/gpu/drm/i915/intel_guc.h   |  8 
  3 files changed, 10 insertions(+), 15 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index 8b8d6f0..1024947 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -2509,6 +2509,7 @@ static void i915_guc_client_info(struct seq_file *m,
seq_printf(m, "\tWQ size %d, offset: 0x%x, tail %d\n",
client->wq_size, client->wq_offset, client->wq_tail);

+   seq_printf(m, "\tWork queue full: %u\n", client->no_wq_space);
seq_printf(m, "\tFailed to queue: %u\n", client->q_fail);
seq_printf(m, "\tFailed doorbell: %u\n", client->b_fail);
seq_printf(m, "\tLast submission result: %d\n", client->retcode);
diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c 
b/drivers/gpu/drm/i915/i915_guc_submission.c
index 66af5ce..6626eff 100644
--- a/drivers/gpu/drm/i915/i915_guc_submission.c
+++ b/drivers/gpu/drm/i915/i915_guc_submission.c
@@ -453,27 +453,21 @@ static void guc_fini_ctx_desc(struct intel_guc *guc,

  int i915_guc_wq_check_space(struct drm_i915_gem_request *request)
  {
-   const size_t size = sizeof(struct guc_wq_item);
+   const size_t wqi_size = sizeof(struct guc_wq_item);
struct i915_guc_client *gc = request->i915->guc.execbuf_client;
struct guc_process_desc *desc;
-   int ret = -ETIMEDOUT, timeout_counter = 200;

if (!gc)
return 0;

desc = gc->client_base + gc->proc_desc_offset;

-   while (timeout_counter-- > 0) {
-   if (CIRC_SPACE(gc->wq_tail, desc->head, gc->wq_size) >= size) {
-   ret = 0;
-   break;
-   }
+   if (CIRC_SPACE(gc->wq_tail, desc->head, gc->wq_size) >= wqi_size)
+   return 0;

-   if (timeout_counter)
-   usleep_range(1000, 2000);
-   };
+   gc->no_wq_space += 1;

-   return ret;
+   return -EAGAIN;
  }

  static int guc_add_workqueue_item(struct i915_guc_client *gc,
diff --git a/drivers/gpu/drm/i915/intel_guc.h b/drivers/gpu/drm/i915/intel_guc.h
index b37c731..436f2d6 100644
--- a/drivers/gpu/drm/i915/intel_guc.h
+++ b/drivers/gpu/drm/i915/intel_guc.h
@@ -73,10 +73,10 @@ struct i915_guc_client {

/* GuC submission statistics & status */
uint64_t submissions[GUC_MAX_ENGINES_NUM];
-   uint32_t q_fail;
-   uint32_t b_fail;
-   int retcode;
-   int spare;  /* pad to 32 DWords */
+   uint32_t no_wq_space;   /* Space pre-check failed   */
+   uint32_t q_fail;/* Failed to queue (MBZ)*/
+   uint32_t b_fail;/* Doorbell failure (MBZ)   */


Why MBZ? It is not all used in this context so this will just confuse 
people.



+   int retcode;/* Result of last guc_submit()  */
  };

  enum intel_guc_fw_status {




Regards,

Tvrtko
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH v2 4/5] drm/i915/guc: rework guc_add_workqueue_item()

2016-04-29 Thread Tvrtko Ursulin


On 27/04/16 19:03, Dave Gordon wrote:

Mostly little optimisations; for instance, if the driver is correctly
following the submission protocol, the "out of space" condition is
impossible, so the previous runtime WARN_ON() is promoted to a
GEM_BUG_ON() for a more dramatic effect in development and less impact
in end-user systems.

Similarly we can replace other WARN_ON() conditions that don't relate to
the hardware state with either BUILD_BUG_ON() for compile-time-
detectable issues, or GEM_BUG_ON() for logical "can't happen" errors.

With those changes, we can convert it to void, as suggested by Chris
Wilson, and update the calling code appropriately.

Signed-off-by: Dave Gordon 
Cc: Chris Wilson 

---
  drivers/gpu/drm/i915/i915_guc_submission.c | 69 +++---
  drivers/gpu/drm/i915/intel_guc.h   |  2 +-
  drivers/gpu/drm/i915/intel_guc_fwif.h  |  3 +-
  3 files changed, 37 insertions(+), 37 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c 
b/drivers/gpu/drm/i915/i915_guc_submission.c
index 6626eff..4d2ea84 100644
--- a/drivers/gpu/drm/i915/i915_guc_submission.c
+++ b/drivers/gpu/drm/i915/i915_guc_submission.c
@@ -470,23 +470,28 @@ int i915_guc_wq_check_space(struct drm_i915_gem_request 
*request)
return -EAGAIN;
  }

-static int guc_add_workqueue_item(struct i915_guc_client *gc,
- struct drm_i915_gem_request *rq)
+static void guc_add_workqueue_item(struct i915_guc_client *gc,
+  struct drm_i915_gem_request *rq)
  {
+   /* wqi_len is in DWords, and does not include the one-word header */
+   const size_t wqi_size = sizeof(struct guc_wq_item);


Again, u32 is correct I think.


+   const u32 wqi_len = wqi_size/sizeof(u32) - 1;
struct guc_process_desc *desc;
struct guc_wq_item *wqi;
void *base;
-   u32 tail, wq_len, wq_off, space;
+   u32 space, tail, wq_off, wq_page;

desc = gc->client_base + gc->proc_desc_offset;
+
+   /* Space was checked earlier, in i915_guc_wq_check_space() above */


It may be above in the file, but the two do not call one another so I 
recommend saying exactly who called it.



space = CIRC_SPACE(gc->wq_tail, desc->head, gc->wq_size);
-   if (WARN_ON(space < sizeof(struct guc_wq_item)))
-   return -ENOSPC; /* shouldn't happen */
+   GEM_BUG_ON(space < wqi_size);


It is impossible to hit this only because of the struct_mutex guarding 
the whole time window from request creation to submission. If in the 
future, near or far, that gets fixed, then this will need reworking.


I don't have any better ideas though.

But a WARN_ON and return would be almost as good. Everything is better 
than a dead machine one can't ssh into...


So I appeal to make this a WARN_ON and return. Nothing bad would happen 
apart from software thinking GPU has hung.




-   /* postincrement WQ tail for next time */
-   wq_off = gc->wq_tail;
-   gc->wq_tail += sizeof(struct guc_wq_item);
-   gc->wq_tail &= gc->wq_size - 1;
+   /* The GuC firmware wants the tail index in QWords, not bytes */
+   tail = rq->tail;


Used to be sampled from rq->ringbuf->tail - are those the same?


+   GEM_BUG_ON(tail & 7);
+   tail >>= 3;
+   GEM_BUG_ON(tail > WQ_RING_TAIL_MAX);

/* For now workqueue item is 4 DWs; workqueue buffer is 2 pages. So we
 * should not have the case where structure wqi is across page, neither
@@ -495,19 +500,23 @@ static int guc_add_workqueue_item(struct i915_guc_client 
*gc,
 * XXX: if not the case, we need save data to a temp wqi and copy it to
 * workqueue buffer dw by dw.
 */
-   WARN_ON(sizeof(struct guc_wq_item) != 16);
-   WARN_ON(wq_off & 3);
+   BUILD_BUG_ON(wqi_size != 16);

-   /* wq starts from the page after doorbell / process_desc */
-   base = kmap_atomic(i915_gem_object_get_page(gc->client_obj,
-   (wq_off + GUC_DB_SIZE) >> PAGE_SHIFT));
+   /* postincrement WQ tail for next time */
+   wq_off = gc->wq_tail;
+   gc->wq_tail += wqi_size;
+   gc->wq_tail &= gc->wq_size - 1;
+   GEM_BUG_ON(wq_off & (wqi_size - 1));


Use to be wq_off & 3, now is wq_off & 15, which one is correct?


+
+   /* WQ starts from the page after doorbell / process_desc */
+   wq_page = (wq_off + GUC_DB_SIZE) >> PAGE_SHIFT;
wq_off &= PAGE_SIZE - 1;
+   base = kmap_atomic(i915_gem_object_get_page(gc->client_obj, wq_page));
wqi = (struct guc_wq_item *)((char *)base + wq_off);

-   /* len does not include the header */
-   wq_len = sizeof(struct guc_wq_item) / sizeof(u32) - 1;
+   /* Now fill in the 4-word work queue item */
wqi->header = WQ_TYPE_INORDER |
-   (wq_len << WQ_LEN_SHIFT) |
+   (wqi_len << WQ_LEN_SHIFT) |

Re: [Intel-gfx] [PATCH] prime_mmap_kms: show case dma-buf new API and processes restrictions

2016-04-29 Thread Marius Vlad
On Mon, Apr 25, 2016 at 11:07:48AM -0300, Tiago Vignatti wrote:
> dma-buf new API consists of:
> 
> - mmap(dma_buf_fd): the ability to map a dma-buf file-descriptor to the
> user-space, and most importantly, to actually write on the mapped pointer.
> Worth to note that the Direct Rendering Manager (DRM) and the hardware driver
> implementation are fundamentally important to safely exporting the graphics
> handle to be mapped.
> 
> - ioctl(dma_buf_fd, DMA_BUF_IOCTL_SYNC): cache coherency management in cases
> where the CPU and GPU devices are being accessed through dma-buf at the same
> time. Coherency markers, that forward directly to existing dma-buf device
> drivers vfunc hooks, are exposed to the user-space through the
> DMA_BUF_IOCTL_SYNC ioctl and have to be used before and after the mapped area
> is accessed.
> 
> Signed-off-by: Tiago Vignatti 
> ---
>  tests/Makefile.sources |   1 +
>  tests/prime_mmap_kms.c | 250 
> +
>  2 files changed, 251 insertions(+)
>  create mode 100644 tests/prime_mmap_kms.c
> 
> diff --git a/tests/Makefile.sources b/tests/Makefile.sources
> index abcf325..d672c13 100644
> --- a/tests/Makefile.sources
> +++ b/tests/Makefile.sources
> @@ -111,6 +111,7 @@ TESTS_progs_M = \
>   pm_sseu \
>   prime_mmap \
>   prime_mmap_coherency \
> + prime_mmap_kms \
>   prime_self_import \
>   template \
>   $(NULL)
> diff --git a/tests/prime_mmap_kms.c b/tests/prime_mmap_kms.c
> new file mode 100644
> index 000..c65e208
> --- /dev/null
> +++ b/tests/prime_mmap_kms.c
> @@ -0,0 +1,250 @@
> +/*
> + * Copyright © 2016 Intel Corporation
> + *
> + * Permission is hereby granted, free of charge, to any person obtaining a
> + * copy of this software and associated documentation files (the "Software"),
> + * to deal in the Software without restriction, including without limitation
> + * the rights to use, copy, modify, merge, publish, distribute, sublicense,
> + * and/or sell copies of the Software, and to permit persons to whom the
> + * Software is furnished to do so, subject to the following conditions:
> + *
> + * The above copyright notice and this permission notice (including the next
> + * paragraph) shall be included in all copies or substantial portions of the
> + * Software.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
> + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
> + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
> + * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
> + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER 
> DEALINGS
> + * IN THE SOFTWARE.
> + *
> + * Authors:
> + *Tiago Vignatti 
> + */
> +
> +#include "igt.h"
> +
> +IGT_TEST_DESCRIPTION(
> +   "Efficiently sharing CPU and GPU buffers");
> +
> +/*
> + * render_process_t:
> + *
> + * Render is basically a user-space regular client. It's the unprivileged
> + * process with limited system accesses.
> + *
> + * Worth note the vendor-independent characteristic, meaning that the
> + * client doesn't need to perform any vendor specific calls for buffer
> + * handling. Mesa GBM library is a counter-example because, even though its 
> API
> + * is vendor-independent, under-the-hood the library actually calls vendor
> + * specific ioctls, which is not really sandboxable and not the goal here.
> + */
> +typedef struct {
> + int prime_fd;
> + size_t size;
> + int width;
> + int height;
> +} render_process_t;
> +
> +typedef struct {
> + int x;
> + int y;
> + int w;
> + int h;
> +} rect_t;
> +
> +/* set ptr in a linear view */
> +static void set_pixel(void *_ptr, int index, uint32_t color, int bpp)
> +{
> + if (bpp == 16) {
> + uint16_t *ptr = _ptr;
> + ptr[index] = color;
> + } else if (bpp == 32) {
> + uint32_t *ptr = _ptr;
> + ptr[index] = color;
> + } else {
> + igt_assert_f(false, "bpp: %d\n", bpp);
> + }
> +}
> +
> +static void paint(render_process_t *render)
> +{
> + void *frame;
> + rect_t rect = {
> + .x = 200,
> + .y = 200,
> + .w = render->width / 4,
> + .h = render->height / 4,
> + };
> + int stride, bpp, color = 0xFF;
uint32_t color;
> + int x, y, line_begin;
> +
> + frame = mmap(NULL, render->size, PROT_READ | PROT_WRITE, MAP_SHARED,
> +  render->prime_fd, 0);
> + igt_assert(frame != MAP_FAILED);
> +
> + /* TODO: what's the mmap'ed buffer semantics on tiling, format etc. How
> +  * does the client know whether that the BO was created X-tiled,
> +  * Y-tiled and how it will map back? This is something we need to
> +  * address in this API still. */
> + stride = render->width * 

Re: [Intel-gfx] [PATCH v2 3/5] drm/i915/guc: don't spinwait if the GuC's workqueue is full

2016-04-29 Thread Tvrtko Ursulin


On 27/04/16 19:03, Dave Gordon wrote:

Rather than wait to see whether more space becomes available in the GuC
submission workqueue, we can just return -EAGAIN and let the caller try
again in a little while. This gets rid of an uninterruptable sleep in
the polling code :)

We'll also add a counter to the GuC client statistics, to see how often
we find the WQ full.

Signed-off-by: Dave Gordon 
---
  drivers/gpu/drm/i915/i915_debugfs.c|  1 +
  drivers/gpu/drm/i915/i915_guc_submission.c | 16 +---
  drivers/gpu/drm/i915/intel_guc.h   |  8 
  3 files changed, 10 insertions(+), 15 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index 8b8d6f0..1024947 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -2509,6 +2509,7 @@ static void i915_guc_client_info(struct seq_file *m,
seq_printf(m, "\tWQ size %d, offset: 0x%x, tail %d\n",
client->wq_size, client->wq_offset, client->wq_tail);

+   seq_printf(m, "\tWork queue full: %u\n", client->no_wq_space);
seq_printf(m, "\tFailed to queue: %u\n", client->q_fail);
seq_printf(m, "\tFailed doorbell: %u\n", client->b_fail);
seq_printf(m, "\tLast submission result: %d\n", client->retcode);
diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c 
b/drivers/gpu/drm/i915/i915_guc_submission.c
index 66af5ce..6626eff 100644
--- a/drivers/gpu/drm/i915/i915_guc_submission.c
+++ b/drivers/gpu/drm/i915/i915_guc_submission.c
@@ -453,27 +453,21 @@ static void guc_fini_ctx_desc(struct intel_guc *guc,

  int i915_guc_wq_check_space(struct drm_i915_gem_request *request)
  {
-   const size_t size = sizeof(struct guc_wq_item);
+   const size_t wqi_size = sizeof(struct guc_wq_item);
struct i915_guc_client *gc = request->i915->guc.execbuf_client;
struct guc_process_desc *desc;
-   int ret = -ETIMEDOUT, timeout_counter = 200;

if (!gc)
return 0;


Not part of this patch but spotted it - can this really happen, and if 
so, does it warrant a WARN_ONCE, GEM_BUG_ON or something?




desc = gc->client_base + gc->proc_desc_offset;

-   while (timeout_counter-- > 0) {
-   if (CIRC_SPACE(gc->wq_tail, desc->head, gc->wq_size) >= size) {
-   ret = 0;
-   break;
-   }
+   if (CIRC_SPACE(gc->wq_tail, desc->head, gc->wq_size) >= wqi_size)
+   return 0;


Could stick a likely here to lay out the code for the expected case but 
it could be just OCD. :)




-   if (timeout_counter)
-   usleep_range(1000, 2000);
-   };
+   gc->no_wq_space += 1;

-   return ret;
+   return -EAGAIN;


I suppose it is OK to make userspace pay the cost since this should be 
extremely rare, correct?



  }

  static int guc_add_workqueue_item(struct i915_guc_client *gc,
diff --git a/drivers/gpu/drm/i915/intel_guc.h b/drivers/gpu/drm/i915/intel_guc.h
index b37c731..436f2d6 100644
--- a/drivers/gpu/drm/i915/intel_guc.h
+++ b/drivers/gpu/drm/i915/intel_guc.h
@@ -73,10 +73,10 @@ struct i915_guc_client {

/* GuC submission statistics & status */
uint64_t submissions[GUC_MAX_ENGINES_NUM];
-   uint32_t q_fail;
-   uint32_t b_fail;
-   int retcode;
-   int spare;  /* pad to 32 DWords */
+   uint32_t no_wq_space;   /* Space pre-check failed   */
+   uint32_t q_fail;/* Failed to queue (MBZ)*/
+   uint32_t b_fail;/* Doorbell failure (MBZ)   */
+   int retcode;/* Result of last guc_submit()  */
  };

  enum intel_guc_fw_status {



Reviewed-by: Tvrtko Ursulin 

Regards,

Tvrtko
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH v2 2/5] drm/i915/guc: pass request (not client) to i915_guc_{wq_check_space, submit}()

2016-04-29 Thread Tvrtko Ursulin


On 27/04/16 19:03, Dave Gordon wrote:

The knowledge of how to derive the relevant client from the request
should be localised within i915_guc_submission.c; the LRC code shouldn't
have to know about the internal details of the GuC submission process.
And all the information the GuC code needs should be encapsulated in (or
reachable from) the request.

Signed-off-by: Dave Gordon 
---
  drivers/gpu/drm/i915/i915_guc_submission.c | 11 ++-
  drivers/gpu/drm/i915/intel_guc.h   |  5 ++---
  drivers/gpu/drm/i915/intel_lrc.c   |  9 +++--
  3 files changed, 11 insertions(+), 14 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c 
b/drivers/gpu/drm/i915/i915_guc_submission.c
index 42d2efa..66af5ce 100644
--- a/drivers/gpu/drm/i915/i915_guc_submission.c
+++ b/drivers/gpu/drm/i915/i915_guc_submission.c
@@ -451,10 +451,11 @@ static void guc_fini_ctx_desc(struct intel_guc *guc,
 sizeof(desc) * client->ctx_index);
  }

-int i915_guc_wq_check_space(struct i915_guc_client *gc)
+int i915_guc_wq_check_space(struct drm_i915_gem_request *request)
  {
+   const size_t size = sizeof(struct guc_wq_item);


All the other variables passed to CIRC_SPACE are u32 so this is for the 
worse I think.



+   struct i915_guc_client *gc = request->i915->guc.execbuf_client;
struct guc_process_desc *desc;
-   u32 size = sizeof(struct guc_wq_item);
int ret = -ETIMEDOUT, timeout_counter = 200;

if (!gc)
@@ -537,11 +538,11 @@ static int guc_add_workqueue_item(struct i915_guc_client 
*gc,
   *
   * Return:0 if succeed
   */
-int i915_guc_submit(struct i915_guc_client *client,
-   struct drm_i915_gem_request *rq)
+int i915_guc_submit(struct drm_i915_gem_request *rq)
  {
-   struct intel_guc *guc = client->guc;
unsigned int engine_id = rq->engine->guc_id;
+   struct intel_guc *guc = >i915->guc;
+   struct i915_guc_client *client = guc->execbuf_client;
int q_ret, b_ret;

q_ret = guc_add_workqueue_item(client, rq);
diff --git a/drivers/gpu/drm/i915/intel_guc.h b/drivers/gpu/drm/i915/intel_guc.h
index 9d79c4c..b37c731 100644
--- a/drivers/gpu/drm/i915/intel_guc.h
+++ b/drivers/gpu/drm/i915/intel_guc.h
@@ -148,10 +148,9 @@ extern int intel_guc_resume(struct drm_device *dev);
  /* i915_guc_submission.c */
  int i915_guc_submission_init(struct drm_device *dev);
  int i915_guc_submission_enable(struct drm_device *dev);
-int i915_guc_submit(struct i915_guc_client *client,
-   struct drm_i915_gem_request *rq);
+int i915_guc_wq_check_space(struct drm_i915_gem_request *rq);
+int i915_guc_submit(struct drm_i915_gem_request *rq);
  void i915_guc_submission_disable(struct drm_device *dev);
  void i915_guc_submission_fini(struct drm_device *dev);
-int i915_guc_wq_check_space(struct i915_guc_client *client);

  #endif
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 2b7e6bb..b8ec8c6 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -708,9 +708,7 @@ int intel_logical_ring_alloc_request_extras(struct 
drm_i915_gem_request *request
 * going any further, as the i915_add_request() call
 * later on mustn't fail ...
 */
-   struct intel_guc *guc = >i915->guc;
-
-   ret = i915_guc_wq_check_space(guc->execbuf_client);
+   ret = i915_guc_wq_check_space(request);
if (ret)
return ret;
}
@@ -776,7 +774,6 @@ static int logical_ring_wait_for_space(struct 
drm_i915_gem_request *req,
  intel_logical_ring_advance_and_submit(struct drm_i915_gem_request *request)
  {
struct intel_ringbuffer *ringbuf = request->ringbuf;
-   struct drm_i915_private *dev_priv = request->i915;
struct intel_engine_cs *engine = request->engine;

intel_logical_ring_advance(ringbuf);
@@ -806,8 +803,8 @@ static int logical_ring_wait_for_space(struct 
drm_i915_gem_request *req,
}
}

-   if (dev_priv->guc.execbuf_client)
-   i915_guc_submit(dev_priv->guc.execbuf_client, request);
+   if (i915.enable_guc_submission)
+   i915_guc_submit(request);
else
execlists_context_queue(request);




With the datatype fix (revert) in i915_guc_wq_check_space:

Reviewed-by: Tvrtko Ursulin 

Regards,

Tvrtko
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH v2 1/5] drm/i915/guc: add enable_guc_loading parameter

2016-04-29 Thread Tvrtko Ursulin


Hi,

On 27/04/16 19:03, Dave Gordon wrote:

Split the function of "enable_guc_submission" into two separate
options.  The new one ("enable_guc_loading") controls only the
*fetching and loading* of the GuC firmware image. The existing
one is redefined to control only the *use* of the GuC for batch
submission once the firmware is loaded.

In addition, the degree of control has been refined from a simple
bool to an integer key, allowing several options:
  -1 (default) whatever the platform default is
   0  DISABLE  don't load/use the GuC
   1  BEST EFFORT  try to load/use the GuC, fallback if not available
   2  REQUIRE  must load/use the GuC, else leave the GPU wedged

The new platform default (as coded here) will be to attempt to
load the GuC iff the device has a GuC that requires firmware,
but not yet to use it for submission. A later patch will change
to enable it if appropriate.

Signed-off-by: Dave Gordon 
---
  drivers/gpu/drm/i915/i915_gem.c|  1 -
  drivers/gpu/drm/i915/i915_guc_submission.c |  4 +-
  drivers/gpu/drm/i915/i915_params.c | 14 -
  drivers/gpu/drm/i915/i915_params.h |  3 +-
  drivers/gpu/drm/i915/intel_guc_loader.c| 98 --
  drivers/gpu/drm/i915/intel_uncore.c|  2 +-
  6 files changed, 70 insertions(+), 52 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index d493e79..b04effc 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -4910,7 +4910,6 @@ int i915_gem_init_engines(struct drm_device *dev)
ret = intel_guc_ucode_load(dev);
if (ret) {
DRM_ERROR("Failed to initialize GuC, error %d\n", ret);
-   ret = -EIO;
goto out;
}
}
diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c 
b/drivers/gpu/drm/i915/i915_guc_submission.c
index 72d6665..42d2efa 100644
--- a/drivers/gpu/drm/i915/i915_guc_submission.c
+++ b/drivers/gpu/drm/i915/i915_guc_submission.c
@@ -970,7 +970,7 @@ int intel_guc_suspend(struct drm_device *dev)
struct intel_context *ctx;
u32 data[3];

-   if (!i915.enable_guc_submission)
+   if (guc->guc_fw.guc_fw_load_status != GUC_FIRMWARE_SUCCESS)
return 0;

ctx = dev_priv->kernel_context;
@@ -996,7 +996,7 @@ int intel_guc_resume(struct drm_device *dev)
struct intel_context *ctx;
u32 data[3];

-   if (!i915.enable_guc_submission)
+   if (guc->guc_fw.guc_fw_load_status != GUC_FIRMWARE_SUCCESS)
return 0;


Not terribly important and probably predates your work, but just spotted 
how this reads very redundant - guc->guc_fw.guc_fw_something, while it 
could be much more readable as guc->fw.load_status. Observation only.




ctx = dev_priv->kernel_context;
diff --git a/drivers/gpu/drm/i915/i915_params.c 
b/drivers/gpu/drm/i915/i915_params.c
index 383c076..6a5578c 100644
--- a/drivers/gpu/drm/i915/i915_params.c
+++ b/drivers/gpu/drm/i915/i915_params.c
@@ -54,7 +54,8 @@ struct i915_params i915 __read_mostly = {
.verbose_state_checks = 1,
.nuclear_pageflip = 0,
.edp_vswing = 0,
-   .enable_guc_submission = false,
+   .enable_guc_loading = -1,
+   .enable_guc_submission = 0,
.guc_log_level = -1,
.enable_dp_mst = true,
.inject_load_failure = 0,
@@ -198,8 +199,15 @@ struct i915_params i915 __read_mostly = {
 "(0=use value from vbt [default], 1=low power swing(200mV),"
 "2=default swing(400mV))");

-module_param_named_unsafe(enable_guc_submission, i915.enable_guc_submission, 
bool, 0400);
-MODULE_PARM_DESC(enable_guc_submission, "Enable GuC submission 
(default:false)");
+module_param_named_unsafe(enable_guc_loading, i915.enable_guc_loading, int, 
0400);
+MODULE_PARM_DESC(enable_guc_loading,
+   "Enable GuC firmware loading "
+   "(-1=auto [default], 0=never, 1=if available, 2=required)");
+
+module_param_named_unsafe(enable_guc_submission, i915.enable_guc_submission, 
int, 0400);
+MODULE_PARM_DESC(enable_guc_submission,
+   "Enable GuC submission "
+   "(-1=auto, 0=never [default], 1=if available, 2=required)");

  module_param_named(guc_log_level, i915.guc_log_level, int, 0400);
  MODULE_PARM_DESC(guc_log_level,
diff --git a/drivers/gpu/drm/i915/i915_params.h 
b/drivers/gpu/drm/i915/i915_params.h
index 65e73dd..1323261 100644
--- a/drivers/gpu/drm/i915/i915_params.h
+++ b/drivers/gpu/drm/i915/i915_params.h
@@ -45,6 +45,8 @@ struct i915_params {
int enable_ips;
int invert_brightness;
int enable_cmd_parser;
+   int enable_guc_loading;
+   int enable_guc_submission;
int guc_log_level;
int use_mmio_flip;
int mmio_debug;
@@ -57,7 +59,6 @@ struct i915_params {
bool load_detect_test;
bool 

[Intel-gfx] [PATCH i-g-t] tools/intel_reg_decode: drop confusing use of IS_965()

2016-04-29 Thread Jani Nikula
Unlike in the kernel driver coding style, IS_965() matches the platform
and all subsequent ones. Replace IS_965() with suitable but less
confusing alternatives.

Most occurences are on code paths that only get called for gens 2, 3 and
4, so replace those with IS_GEN4(). In the one other call site just flip
the condition to check for gens 2 and 3 instead.

Signed-off-by: Jani Nikula 
---
 tools/intel_reg_decode.c | 16 
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/tools/intel_reg_decode.c b/tools/intel_reg_decode.c
index 470fecc165c6..253655482290 100644
--- a/tools/intel_reg_decode.c
+++ b/tools/intel_reg_decode.c
@@ -54,7 +54,7 @@ DEBUGSTRING(i830_debug_dcc)
if (!IS_MOBILE(devid))
return;
 
-   if (IS_965(devid)) {
+   if (IS_GEN4(devid)) {
if (val & (1 << 1))
addressing = "dual channel interleaved";
else
@@ -151,11 +151,11 @@ DEBUGSTRING(i830_debug_pipeconf)
char buf[256];
int buf_len;
 
-   if (IS_965(devid))
-   bit30 = val & I965_PIPECONF_ACTIVE ? "active" : "inactive";
+   if (IS_GEN2(devid) || IS_GEN3(devid))
+   bit30 = val & PIPEACONF_DOUBLE_WIDE ?
+   "double-wide" : "single-wide";
else
-   bit30 =
-   val & PIPEACONF_DOUBLE_WIDE ? "double-wide" : "single-wide";
+   bit30 = val & I965_PIPECONF_ACTIVE ? "active" : "inactive";
 
buf_len = snprintf(buf, sizeof(buf), "%s, %s", enabled, bit30);
 
@@ -701,7 +701,7 @@ DEBUGSTRING(i810_debug_915_fence)
unsigned int offset = val & 0x0ff0;
int size = (1024 * 1024) << ((val & 0x700) >> 8);
 
-   if (IS_965(devid) || (IS_915(devid) && reg >= FENCE_NEW))
+   if (IS_GEN4(devid) || (IS_915(devid) && reg >= FENCE_NEW))
return;
 
if (format == 'X')
@@ -722,7 +722,7 @@ DEBUGSTRING(i810_debug_965_fence_start)
int pitch = ((val & 0xffc) >> 2) * 128 + 128;
unsigned int offset = val & 0xf000;
 
-   if (!IS_965(devid))
+   if (!IS_GEN4(devid))
return;
 
snprintf(result, len, "%s, %c tile walk, %4d pitch, 0x%08x start",
@@ -733,7 +733,7 @@ DEBUGSTRING(i810_debug_965_fence_end)
 {
unsigned int end = val & 0xf000;
 
-   if (!IS_965(devid))
+   if (!IS_GEN4(devid))
return;
 
snprintf(result, len, "   0x%08x end", 
end);
-- 
2.1.4

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] [PATCH i-g-t] lib/intel_chipset: drop unused IS_9XX()

2016-04-29 Thread Jani Nikula
It's also confusing as the style differs from the kernel (exact platform
in the kernel vs. the platform and any later ones in igt).

Signed-off-by: Jani Nikula 
---
 lib/intel_chipset.h | 8 
 1 file changed, 8 deletions(-)

diff --git a/lib/intel_chipset.h b/lib/intel_chipset.h
index 4b4061253e75..2f2e435281cc 100644
--- a/lib/intel_chipset.h
+++ b/lib/intel_chipset.h
@@ -477,14 +477,6 @@ void intel_check_pch(void);
 IS_GEN8(devid) || \
 IS_GEN9(devid))
 
-#define IS_9XX(devid)  (IS_GEN3(devid) || \
-IS_GEN4(devid) || \
-IS_GEN5(devid) || \
-IS_GEN6(devid) || \
-IS_GEN7(devid) || \
-IS_GEN8(devid) || \
-IS_GEN9(devid))
-
 #define IS_INTEL(devid)(IS_GEN2(devid) || \
 IS_GEN3(devid) || \
 IS_GEN4(devid) || \
-- 
2.1.4

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH v2 2/2] drm/i915: Render decompression support for Gen9 and above

2016-04-29 Thread Ville Syrjälä
On Fri, Apr 29, 2016 at 08:27:00PM +0530, Vandana Kannan wrote:
> This patch includes enabling render decompression (RC) after checking
> all the requirements (format, tiling, rotation etc.).
> 
> TODO:
> 1. Disable stereo 3D when render decomp is enabled (bit 7:6)
> 2. Render decompression must not be used in VTd pass-through mode
> 3. Program hashing select CHICKEN_MISC1 bit 15
> 4. For Gen10, add support for RGB 1010102
> 5. RC-FBC workaround
> 6. RC watermark calculation
> 
> The reason for using a plane property instead of fb modifier:-
> In Android, OGL passes a render compressed buffer to hardware composer
> (HWC), which would then request a flip on that buffer after checking if
> the target can support render compressed buffer. For example, only planes
> 1 and 2 on pipes 1 and 2 can support RC. In case the target cannot
> support it, HWC will revert back to OGL requesting for uncompressed
> buffer.
> Here,
> if plane property is used, OGL would send back the buffer (same ID) after
> decompression, marked uncompressed. If fb modifier was used, a different
> version of the buffer would have to be maintained for different
> combinations - in the simple case of render compressed vs uncompressed
> buffer, there would be 2 fbs with 2 IDs. So, in this case, OGL would give
> a reference to a fb with a different ID.
> To avoid the difficulty of keeping track of multiple fbs and the subsequent
> complexity in debug, the architecture forum decided to go ahead with a
> plane property for RC.
> 
> [Mayuresh] Added the plane check in skl_check_compression()
> 
> v2: Ville's review comments addressed
> - Removed WAs specific to SKL-C and BXT-A
> - Assign capabilities according to pipe and plane during property creation
> - in skl_check_compression(), check for conditions that must be satisifed
> 
> Maintaining the check for pixel format, even though compressed fb of format
> other RGB should not have been created, to be on the safer side.
> Added checks for BGR too.
> Bitmask is being used for the property to accommodate 2 more options
> expected to be added in future.
> 
> This patch depends on Ville's patch series on fb->offsets.
> (Ref: git://github.com/vsyrjala/linux.git fb_offsets_14)
> 
> Testing is in progress for v2 of the patch.
> 
> Signed-off-by: Vandana Kannan 
> Cc: Ville Syrjälä 
> Cc: Smith, Gary K 
> ---
>  drivers/gpu/drm/i915/i915_drv.h   |   1 +
>  drivers/gpu/drm/i915/i915_reg.h   |  22 +
>  drivers/gpu/drm/i915/intel_atomic_plane.c |  24 +-
>  drivers/gpu/drm/i915/intel_display.c  | 135 
> +-
>  drivers/gpu/drm/i915/intel_drv.h  |  10 +++
>  drivers/gpu/drm/i915/intel_sprite.c   |  27 +-
>  6 files changed, 213 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 32f0597..ba32e7c 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -1901,6 +1901,7 @@ struct drm_i915_private {
>  
>   struct drm_property *broadcast_rgb_property;
>   struct drm_property *force_audio_property;
> + struct drm_property *render_comp_property;
>  
>   /* hda/i915 audio component */
>   struct i915_audio_component *audio_component;
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 25e229b..da45cc9 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -5816,6 +5816,28 @@ enum skl_disp_power_wells {
>   _ID(id, _PS_ECC_STAT_1A, _PS_ECC_STAT_2A),   \
>   _ID(id, _PS_ECC_STAT_1B, _PS_ECC_STAT_2B))
>  
> +#define PLANE_AUX_DIST_1_A   0x701c0
> +#define PLANE_AUX_DIST_2_A   0x702c0
> +#define PLANE_AUX_DIST_1_B   0x711c0
> +#define PLANE_AUX_DIST_2_B   0x712c0
> +#define _PLANE_AUX_DIST_1(pipe) \
> + _PIPE(pipe, PLANE_AUX_DIST_1_A, PLANE_AUX_DIST_1_B)
> +#define _PLANE_AUX_DIST_2(pipe) \
> + _PIPE(pipe, PLANE_AUX_DIST_2_A, PLANE_AUX_DIST_2_B)
> +#define PLANE_AUX_DIST(pipe, plane) \
> + _MMIO_PLANE(plane, _PLANE_AUX_DIST_1(pipe), _PLANE_AUX_DIST_2(pipe))
> +
> +#define PLANE_AUX_OFFSET_1_A 0x701c4
> +#define PLANE_AUX_OFFSET_2_A 0x702c4
> +#define PLANE_AUX_OFFSET_1_B 0x711c4
> +#define PLANE_AUX_OFFSET_2_B 0x712c4
> +#define _PLANE_AUX_OFFSET_1(pipe)   \
> + _PIPE(pipe, PLANE_AUX_OFFSET_1_A, PLANE_AUX_OFFSET_1_B)
> +#define _PLANE_AUX_OFFSET_2(pipe)   \
> + _PIPE(pipe, PLANE_AUX_OFFSET_2_A, PLANE_AUX_OFFSET_2_B)
> +#define PLANE_AUX_OFFSET(pipe, plane)   \
> + _MMIO_PLANE(plane, _PLANE_AUX_OFFSET_1(pipe), _PLANE_AUX_OFFSET_2(pipe))
> +
>  /* legacy palette */
>  #define _LGC_PALETTE_A   0x4a000
>  #define _LGC_PALETTE_B   0x4a800
> diff --git 

[Intel-gfx] [PATCH 2/2] drm/i915: Add a FIXME about crtc !active vs. watermarks

2016-04-29 Thread ville . syrjala
From: Ville Syrjälä 

When the crtc is enabled but !active, we should still compute the
watermarks as if the planes were visible. That would make it more
likely that the we can later transition to active without errors.

Add a FIXME to remind people that we're doing the wrong thing now.
We should perhaps just move the wm computation for each individual plane
into the .check_plane hook, and later we'd just combine the results from
all active planes.

Cc: Maarten Lankhorst 
Cc: Matt Roper 
Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/intel_display.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 5ffccf6e7f36..00059d18b0f0 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -11833,6 +11833,11 @@ int intel_plane_atomic_calc_changes(struct 
drm_crtc_state *crtc_state,
 * Visibility is calculated as if the crtc was on, but
 * after scaler setup everything depends on it being off
 * when the crtc isn't active.
+*
+* FIXME this is wrong for watermarks. Watermarks should also
+* be computed as if the pipe would be active. Perhaps move
+* per-plane wm computation to the .check_plane() hook, and
+* only combine the results from all planes in the current place?
 */
if (!is_crtc_enabled)
to_intel_plane_state(plane_state)->visible = visible = false;
-- 
2.7.4

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [1/2] drm: Add aux plane verification in addFB2 (rev2)

2016-04-29 Thread Patchwork
== Series Details ==

Series: series starting with [1/2] drm: Add aux plane verification in addFB2 
(rev2)
URL   : https://patchwork.freedesktop.org/series/4641/
State : failure

== Summary ==

  CC [M]  drivers/net/ethernet/intel/igb/e1000_nvm.o
  CC [M]  drivers/net/ethernet/intel/igb/e1000_phy.o
  CC [M]  drivers/net/ethernet/intel/igbvf/vf.o
  LD  drivers/usb/host/built-in.o
  CC [M]  drivers/net/ethernet/intel/igbvf/mbx.o
  LD  drivers/usb/built-in.o
  LD [M]  drivers/net/ethernet/intel/e1000/e1000.o
  CC [M]  drivers/net/ethernet/intel/igbvf/ethtool.o
  CC [M]  drivers/net/ethernet/intel/igb/e1000_mbx.o
  CC [M]  drivers/net/ethernet/intel/igbvf/netdev.o
  CC [M]  drivers/net/ethernet/intel/igb/e1000_i210.o
  CC [M]  drivers/net/ethernet/intel/igb/igb_ptp.o
  CC [M]  drivers/net/ethernet/intel/igb/igb_hwmon.o
cc1: some warnings being treated as errors
scripts/Makefile.build:291: recipe for target 
'drivers/gpu/drm/i915/intel_display.o' failed
make[4]: *** [drivers/gpu/drm/i915/intel_display.o] Error 1
scripts/Makefile.build:440: recipe for target 'drivers/gpu/drm/i915' failed
make[3]: *** [drivers/gpu/drm/i915] Error 2
scripts/Makefile.build:440: recipe for target 'drivers/gpu/drm' failed
make[2]: *** [drivers/gpu/drm] Error 2
scripts/Makefile.build:440: recipe for target 'drivers/gpu' failed
make[1]: *** [drivers/gpu] Error 2
make[1]: *** Waiting for unfinished jobs
  LD [M]  drivers/net/ethernet/intel/igbvf/igbvf.o
  LD [M]  drivers/net/ethernet/intel/igb/igb.o
  LD [M]  drivers/net/ethernet/intel/e1000e/e1000e.o
  LD  drivers/net/ethernet/built-in.o
  LD  drivers/net/built-in.o
Makefile:962: recipe for target 'drivers' failed
make: *** [drivers] Error 2

Full logs at /archive/deploy/logs/CI_Patchwork_build_2115

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] [PATCH 1/2] drm/i915: Calculate IPS linetime watermark based on future cdclk

2016-04-29 Thread ville . syrjala
From: Ville Syrjälä 

Use the cdclk we're going to be using when the pipe gets enabled to
compute the IPS linetime watermark. The current cdclk frequency is
irrelevant at this point since it can still change.

Cc: Maarten Lankhorst 
Cc: Matt Roper 
Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/intel_pm.c | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 2422ac38ce5d..964b4eff3087 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -2012,10 +2012,10 @@ static void ilk_compute_wm_level(const struct 
drm_i915_private *dev_priv,
 }
 
 static uint32_t
-hsw_compute_linetime_wm(struct drm_device *dev,
-   struct intel_crtc_state *cstate)
+hsw_compute_linetime_wm(const struct intel_crtc_state *cstate)
 {
-   struct drm_i915_private *dev_priv = dev->dev_private;
+   const struct intel_atomic_state *intel_state =
+   to_intel_atomic_state(cstate->base.state);
const struct drm_display_mode *adjusted_mode =
>base.adjusted_mode;
u32 linetime, ips_linetime;
@@ -2024,7 +2024,7 @@ hsw_compute_linetime_wm(struct drm_device *dev,
return 0;
if (WARN_ON(adjusted_mode->crtc_clock == 0))
return 0;
-   if (WARN_ON(dev_priv->cdclk_freq == 0))
+   if (WARN_ON(intel_state->cdclk == 0))
return 0;
 
/* The WM are computed with base on how long it takes to fill a single
@@ -2033,7 +2033,7 @@ hsw_compute_linetime_wm(struct drm_device *dev,
linetime = DIV_ROUND_CLOSEST(adjusted_mode->crtc_htotal * 1000 * 8,
 adjusted_mode->crtc_clock);
ips_linetime = DIV_ROUND_CLOSEST(adjusted_mode->crtc_htotal * 1000 * 8,
-dev_priv->cdclk_freq);
+intel_state->cdclk);
 
return PIPE_WM_LINETIME_IPS_LINETIME(ips_linetime) |
   PIPE_WM_LINETIME_TIME(linetime);
@@ -2352,7 +2352,7 @@ static int ilk_compute_pipe_wm(struct intel_crtc_state 
*cstate)
pipe_wm->wm[0] = pipe_wm->raw_wm[0];
 
if (IS_HASWELL(dev) || IS_BROADWELL(dev))
-   pipe_wm->linetime = hsw_compute_linetime_wm(dev, cstate);
+   pipe_wm->linetime = hsw_compute_linetime_wm(cstate);
 
if (!ilk_validate_pipe_wm(dev, pipe_wm))
return -EINVAL;
-- 
2.7.4

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] [PATCH v2 2/2] drm/i915: Render decompression support for Gen9 and above

2016-04-29 Thread Vandana Kannan
This patch includes enabling render decompression (RC) after checking
all the requirements (format, tiling, rotation etc.).

TODO:
1. Disable stereo 3D when render decomp is enabled (bit 7:6)
2. Render decompression must not be used in VTd pass-through mode
3. Program hashing select CHICKEN_MISC1 bit 15
4. For Gen10, add support for RGB 1010102
5. RC-FBC workaround
6. RC watermark calculation

The reason for using a plane property instead of fb modifier:-
In Android, OGL passes a render compressed buffer to hardware composer
(HWC), which would then request a flip on that buffer after checking if
the target can support render compressed buffer. For example, only planes
1 and 2 on pipes 1 and 2 can support RC. In case the target cannot
support it, HWC will revert back to OGL requesting for uncompressed
buffer.
Here,
if plane property is used, OGL would send back the buffer (same ID) after
decompression, marked uncompressed. If fb modifier was used, a different
version of the buffer would have to be maintained for different
combinations - in the simple case of render compressed vs uncompressed
buffer, there would be 2 fbs with 2 IDs. So, in this case, OGL would give
a reference to a fb with a different ID.
To avoid the difficulty of keeping track of multiple fbs and the subsequent
complexity in debug, the architecture forum decided to go ahead with a
plane property for RC.

[Mayuresh] Added the plane check in skl_check_compression()

v2: Ville's review comments addressed
- Removed WAs specific to SKL-C and BXT-A
- Assign capabilities according to pipe and plane during property creation
- in skl_check_compression(), check for conditions that must be satisifed

Maintaining the check for pixel format, even though compressed fb of format
other RGB should not have been created, to be on the safer side.
Added checks for BGR too.
Bitmask is being used for the property to accommodate 2 more options
expected to be added in future.

This patch depends on Ville's patch series on fb->offsets.
(Ref: git://github.com/vsyrjala/linux.git fb_offsets_14)

Testing is in progress for v2 of the patch.

Signed-off-by: Vandana Kannan 
Cc: Ville Syrjälä 
Cc: Smith, Gary K 
---
 drivers/gpu/drm/i915/i915_drv.h   |   1 +
 drivers/gpu/drm/i915/i915_reg.h   |  22 +
 drivers/gpu/drm/i915/intel_atomic_plane.c |  24 +-
 drivers/gpu/drm/i915/intel_display.c  | 135 +-
 drivers/gpu/drm/i915/intel_drv.h  |  10 +++
 drivers/gpu/drm/i915/intel_sprite.c   |  27 +-
 6 files changed, 213 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 32f0597..ba32e7c 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1901,6 +1901,7 @@ struct drm_i915_private {
 
struct drm_property *broadcast_rgb_property;
struct drm_property *force_audio_property;
+   struct drm_property *render_comp_property;
 
/* hda/i915 audio component */
struct i915_audio_component *audio_component;
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 25e229b..da45cc9 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -5816,6 +5816,28 @@ enum skl_disp_power_wells {
_ID(id, _PS_ECC_STAT_1A, _PS_ECC_STAT_2A),   \
_ID(id, _PS_ECC_STAT_1B, _PS_ECC_STAT_2B))
 
+#define PLANE_AUX_DIST_1_A 0x701c0
+#define PLANE_AUX_DIST_2_A 0x702c0
+#define PLANE_AUX_DIST_1_B 0x711c0
+#define PLANE_AUX_DIST_2_B 0x712c0
+#define _PLANE_AUX_DIST_1(pipe) \
+   _PIPE(pipe, PLANE_AUX_DIST_1_A, PLANE_AUX_DIST_1_B)
+#define _PLANE_AUX_DIST_2(pipe) \
+   _PIPE(pipe, PLANE_AUX_DIST_2_A, PLANE_AUX_DIST_2_B)
+#define PLANE_AUX_DIST(pipe, plane) \
+   _MMIO_PLANE(plane, _PLANE_AUX_DIST_1(pipe), _PLANE_AUX_DIST_2(pipe))
+
+#define PLANE_AUX_OFFSET_1_A   0x701c4
+#define PLANE_AUX_OFFSET_2_A   0x702c4
+#define PLANE_AUX_OFFSET_1_B   0x711c4
+#define PLANE_AUX_OFFSET_2_B   0x712c4
+#define _PLANE_AUX_OFFSET_1(pipe)   \
+   _PIPE(pipe, PLANE_AUX_OFFSET_1_A, PLANE_AUX_OFFSET_1_B)
+#define _PLANE_AUX_OFFSET_2(pipe)   \
+   _PIPE(pipe, PLANE_AUX_OFFSET_2_A, PLANE_AUX_OFFSET_2_B)
+#define PLANE_AUX_OFFSET(pipe, plane)   \
+   _MMIO_PLANE(plane, _PLANE_AUX_OFFSET_1(pipe), _PLANE_AUX_OFFSET_2(pipe))
+
 /* legacy palette */
 #define _LGC_PALETTE_A   0x4a000
 #define _LGC_PALETTE_B   0x4a800
diff --git a/drivers/gpu/drm/i915/intel_atomic_plane.c 
b/drivers/gpu/drm/i915/intel_atomic_plane.c
index 7de7721..2617b75 100644
--- a/drivers/gpu/drm/i915/intel_atomic_plane.c
+++ b/drivers/gpu/drm/i915/intel_atomic_plane.c
@@ -228,8 +228,16 @@ 

Re: [Intel-gfx] [PATCH 2/2] drm/i915: do not set border enable software state for VLV/CHV

2016-04-29 Thread Jani Nikula
On Fri, 29 Apr 2016, Ville Syrjälä  wrote:
> On Fri, Apr 29, 2016 at 03:34:03PM +0300, Jani Nikula wrote:
>> VLV/CHV use intel_gmch_panel_fitting() for eDP and DSI. They don't use
>> the border enable software state for anything, so don't set it
>> either. This should avoid a state checker warning on lvds_border_bits,
>> although one hasn't been spotted in the wild.
>> 
>> Signed-off-by: Jani Nikula 
>> ---
>>  drivers/gpu/drm/i915/intel_panel.c | 3 ++-
>>  1 file changed, 2 insertions(+), 1 deletion(-)
>> 
>> diff --git a/drivers/gpu/drm/i915/intel_panel.c 
>> b/drivers/gpu/drm/i915/intel_panel.c
>> index 828f0fcaaaf8..d0606b8714a4 100644
>> --- a/drivers/gpu/drm/i915/intel_panel.c
>> +++ b/drivers/gpu/drm/i915/intel_panel.c
>> @@ -371,7 +371,8 @@ out:
>>  
>>  pipe_config->gmch_pfit.control = pfit_control;
>>  pipe_config->gmch_pfit.pgm_ratios = pfit_pgm_ratios;
>> -pipe_config->gmch_pfit.lvds_border_bits = border;
>> +if (INTEL_INFO(dev)->gen < 5)
>> +pipe_config->gmch_pfit.lvds_border_bits = border;
>
> Shouldn't actually be needed since we reject the "center" scaling mode
> on eDP and DSI, and that's the only one to use the border bit on gen4+.
> So no way to get here w/ border!=0 on VLV/CHV I think.

Right. It's more than a little tricky to check all the places to make
sure...

BR,
Jani.

>
>>  }
>>  
>>  enum drm_connector_status
>> -- 
>> 2.1.4
>> 
>> ___
>> Intel-gfx mailing list
>> Intel-gfx@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
Jani Nikula, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH 2/2] drm/i915: do not set border enable software state for VLV/CHV

2016-04-29 Thread Ville Syrjälä
On Fri, Apr 29, 2016 at 03:34:03PM +0300, Jani Nikula wrote:
> VLV/CHV use intel_gmch_panel_fitting() for eDP and DSI. They don't use
> the border enable software state for anything, so don't set it
> either. This should avoid a state checker warning on lvds_border_bits,
> although one hasn't been spotted in the wild.
> 
> Signed-off-by: Jani Nikula 
> ---
>  drivers/gpu/drm/i915/intel_panel.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_panel.c 
> b/drivers/gpu/drm/i915/intel_panel.c
> index 828f0fcaaaf8..d0606b8714a4 100644
> --- a/drivers/gpu/drm/i915/intel_panel.c
> +++ b/drivers/gpu/drm/i915/intel_panel.c
> @@ -371,7 +371,8 @@ out:
>  
>   pipe_config->gmch_pfit.control = pfit_control;
>   pipe_config->gmch_pfit.pgm_ratios = pfit_pgm_ratios;
> - pipe_config->gmch_pfit.lvds_border_bits = border;
> + if (INTEL_INFO(dev)->gen < 5)
> + pipe_config->gmch_pfit.lvds_border_bits = border;

Shouldn't actually be needed since we reject the "center" scaling mode
on eDP and DSI, and that's the only one to use the border bit on gen4+.
So no way to get here w/ border!=0 on VLV/CHV I think.

>  }
>  
>  enum drm_connector_status
> -- 
> 2.1.4
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
Ville Syrjälä
Intel OTC
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH 1/2] drm/i915/lvds: separate border enable readout from panel fitter

2016-04-29 Thread Ville Syrjälä
On Fri, Apr 29, 2016 at 03:34:02PM +0300, Jani Nikula wrote:
> The LVDS border enable is independent from the panel fitter. Move the
> readout of the "border bits" from i9xx_get_pfit_config() to
> intel_lvds_get_config(), where it will be read if LVDS is enabled even
> if the panel fitter is not.
> 
> This fixes the state checker warning:
> 
> [drm:intel_pipe_config_compare [i915]] *ERROR* mismatch in
> gmch_pfit.lvds_border_bits (expected 0x8000, found 0x)
> 
> Cc: Ville Syrjälä 
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=87632
> Signed-off-by: Jani Nikula 

Makes sense to me

Reviewed-by: Ville Syrjälä 

> ---
>  drivers/gpu/drm/i915/intel_display.c | 3 ---
>  drivers/gpu/drm/i915/intel_lvds.c| 4 
>  2 files changed, 4 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_display.c 
> b/drivers/gpu/drm/i915/intel_display.c
> index 5ffccf6e7f36..0fccebbd41a3 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -8022,9 +8022,6 @@ static void i9xx_get_pfit_config(struct intel_crtc 
> *crtc,
>  
>   pipe_config->gmch_pfit.control = tmp;
>   pipe_config->gmch_pfit.pgm_ratios = I915_READ(PFIT_PGM_RATIOS);
> - if (INTEL_INFO(dev)->gen < 5)
> - pipe_config->gmch_pfit.lvds_border_bits =
> - I915_READ(LVDS) & LVDS_BORDER_ENABLE;
>  }
>  
>  static void vlv_crtc_clock_get(struct intel_crtc *crtc,
> diff --git a/drivers/gpu/drm/i915/intel_lvds.c 
> b/drivers/gpu/drm/i915/intel_lvds.c
> index 66e832beeb37..bc53c0dd34d0 100644
> --- a/drivers/gpu/drm/i915/intel_lvds.c
> +++ b/drivers/gpu/drm/i915/intel_lvds.c
> @@ -122,6 +122,10 @@ static void intel_lvds_get_config(struct intel_encoder 
> *encoder,
>  
>   pipe_config->base.adjusted_mode.flags |= flags;
>  
> + if (INTEL_INFO(dev)->gen < 5)
> + pipe_config->gmch_pfit.lvds_border_bits =
> + tmp & LVDS_BORDER_ENABLE;
> +
>   /* gen2/3 store dither state in pfit control, needs to match */
>   if (INTEL_INFO(dev)->gen < 4) {
>   tmp = I915_READ(PFIT_CONTROL);
> -- 
> 2.1.4

-- 
Ville Syrjälä
Intel OTC
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/2] drm/i915/lvds: separate border enable readout from panel fitter

2016-04-29 Thread Patchwork
== Series Details ==

Series: series starting with [1/2] drm/i915/lvds: separate border enable 
readout from panel fitter
URL   : https://patchwork.freedesktop.org/series/6535/
State : success

== Summary ==

Series 6535v1 Series without cover letter
http://patchwork.freedesktop.org/api/1.0/series/6535/revisions/1/mbox/


bdw-nuci7-2  total:201  pass:189  dwarn:0   dfail:0   fail:0   skip:12 
bdw-ultratotal:201  pass:176  dwarn:0   dfail:0   fail:0   skip:25 
bsw-nuc-2total:200  pass:159  dwarn:0   dfail:0   fail:0   skip:41 
byt-nuc  total:200  pass:159  dwarn:0   dfail:0   fail:0   skip:41 
hsw-brixbox  total:201  pass:175  dwarn:0   dfail:0   fail:0   skip:26 
hsw-gt2  total:201  pass:179  dwarn:0   dfail:0   fail:1   skip:21 
ilk-hp8440p  total:201  pass:140  dwarn:0   dfail:0   fail:0   skip:61 
ivb-t430stotal:201  pass:170  dwarn:0   dfail:0   fail:0   skip:31 
skl-i7k-2total:201  pass:174  dwarn:0   dfail:0   fail:0   skip:27 
skl-nuci5total:201  pass:190  dwarn:0   dfail:0   fail:0   skip:11 
snb-dellxps  total:201  pass:159  dwarn:0   dfail:0   fail:0   skip:42 
snb-x220ttotal:201  pass:159  dwarn:0   dfail:0   fail:1   skip:41 

Results at /archive/results/CI_IGT_test/Patchwork_2114/

1d56af10bdd6f4714e0892c05ff01d11e77f54fc drm-intel-nightly: 
2016y-04m-29d-09h-21m-52s UTC integration manifest
b1884d4 drm/i915: do not set border enable software state for VLV/CHV
7a750ca drm/i915/lvds: separate border enable readout from panel fitter

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] [PATCH i-g-t 2/2] autotools, assembler: Fix check target for tests in assembler.

2016-04-29 Thread Marius Vlad
assembler suffers from the same issue as lib/tests, adjust it so
it allows us to do a check. Have to make autotools happy by having
an empty Makefile.am.

Signed-off-by: Marius Vlad 
---
 assembler/Makefile.am  | 108 -
 assembler/test/Makefile.am |  93 --
 assembler/test/run-test.sh |   2 +-
 3 files changed, 107 insertions(+), 96 deletions(-)

diff --git a/assembler/Makefile.am b/assembler/Makefile.am
index fb309ac..bed6c07 100644
--- a/assembler/Makefile.am
+++ b/assembler/Makefile.am
@@ -47,8 +47,112 @@ intel_gen4disasm_LDADD = libbrw.la
 pkgconfigdir = $(libdir)/pkgconfig
 pkgconfig_DATA = intel-gen4asm.pc
 
-CLEANFILES = $(BUILT_SOURCES)
+check_SCRIPTS = test/run-test.sh
+
+TESTS = \
+   test/mov \
+   test/frc \
+   test/rndd \
+   test/rndu \
+   test/rnde \
+   test/rnde-intsrc \
+   test/rndz \
+   test/lzd \
+   test/not \
+   test/immediate \
+   $(NULL)
+
+# Tests that are expected to fail because they contain some inccorect code.
+XFAIL_TESTS =
+
+# Those tests were already failing when the assembler was imported from
+# the intel-gen4asm git repository:
+#   http://cgit.freedesktop.org/xorg/app/intel-gen4asm/
+# We disable them "for now" as a workaround to be able to release i-g-t
+disabled_tests = \
+   test/declare \
+   test/jmpi \
+   test/if \
+   test/iff \
+   test/while \
+   test/else \
+   test/break \
+   test/cont \
+   test/halt \
+   test/wait \
+   test/endif \
+   $(NULL)
+
+disabled_xfail_tests = \
+   test/rnde-intsrc \
+   $(NULL)
+
+TESTDATA = \
+   test/mov.expected \
+   test/mov.g4a \
+   test/frc.expected \
+   test/frc.g4a \
+   test/rndd.expected \
+   test/rndd.g4a \
+   test/rndu.expected \
+   test/rndu.g4a \
+   test/rnde.expected \
+   test/rnde.g4a \
+   test/rnde-intsrc.expected \
+   test/rnde-intsrc.g4a \
+   test/rndz.expected \
+   test/rndz.g4a \
+   test/lzd.expected \
+   test/lzd.g4a \
+   test/not.expected \
+   test/not.g4a \
+   test/jmpi.expected \
+   test/jmpi.g4a \
+   test/if.expected \
+   test/if.g4a \
+   test/iff.expected \
+   test/iff.g4a \
+   test/while.expected \
+   test/while.g4a \
+   test/else.expected \
+   test/else.g4a \
+   test/break.expected \
+   test/break.g4a \
+   test/cont.expected \
+   test/cont.g4a \
+   test/halt.expected \
+   test/halt.g4a \
+   test/wait.expected \
+   test/wait.g4a \
+   test/endif.expected \
+   test/endif.g4a \
+   test/declare.expected \
+   test/declare.g4a \
+   test/immediate.g4a \
+   test/immediate.expected \
+   $(NULL)
+
+test_EXTRA_DIST = \
+   ${TESTDATA} \
+   test/run-test.sh \
+   $(NULL)
+
+$(TESTS): test/run-test.sh
+   sed "s|TEST|$@|g" ${srcdir}/test/run-test.sh > $@
+   chmod +x $@
+
+test_CLEANFILES = \
+   test/*.out \
+   ${TESTS} \
+   $(NULL)
+
+CLEANFILES = $(BUILT_SOURCES) \
+$(test_CLEANFILES) \
+$(NULL)
+
 EXTRA_DIST = \
README \
TODO \
-   intel-gen4asm.pc.in
+   intel-gen4asm.pc.in \
+   $(test_EXTRA_DIST) \
+   $(NULL)
diff --git a/assembler/test/Makefile.am b/assembler/test/Makefile.am
index f113119..e69de29 100644
--- a/assembler/test/Makefile.am
+++ b/assembler/test/Makefile.am
@@ -1,93 +0,0 @@
-check_SCRIPTS = run-test.sh
-
-TESTS_ENVIRONMENT = top_builddir=${top_builddir}
-TESTS = \
-   mov \
-   frc \
-   rndd \
-   rndu \
-   rnde \
-   rnde-intsrc \
-   rndz \
-   lzd \
-   not \
-   immediate
-
-# Tests that are expected to fail because they contain some inccorect code.
-XFAIL_TESTS =
-
-# Those tests were already failing when the assembler was imported from
-# the intel-gen4asm git repository:
-#   http://cgit.freedesktop.org/xorg/app/intel-gen4asm/
-# We disable them "for now" as a workaround to be able to release i-g-t
-disabled_tests = \
-   declare \
-   jmpi \
-   if \
-   iff \
-   while \
-   else \
-   break \
-   cont \
-   halt \
-   wait \
-   endif
-
-disabled_xfail_tests = \
-   rnde-intsrc
-
-TESTDATA = \
-   mov.expected \
-   mov.g4a \
-   frc.expected \
-   frc.g4a \
-   rndd.expected \
-   rndd.g4a \
-   rndu.expected \
-   rndu.g4a \
-   rnde.expected \
-   rnde.g4a \
-   rnde-intsrc.expected \
-   rnde-intsrc.g4a \
-   rndz.expected \
-   rndz.g4a \
-   lzd.expected \
-   lzd.g4a \
-   not.expected \
-   not.g4a \
-   jmpi.expected \
-   jmpi.g4a \
-   if.expected \
-   if.g4a \
-   iff.expected \
-   iff.g4a \
-   while.expected \
-   while.g4a \
-   else.expected \
-   

[Intel-gfx] [PATCH i-g-t 1/2] autotools: Check target requires to a have the list of tests built.

2016-04-29 Thread Marius Vlad
We need to have the test list generated before running the check target.
Migrated igt_command_line.sh to tests/ from lib/tests/, which allows to
building the tests and execute the script.

This would allow cleaning followed by a make check.

Signed-off-by: Marius Vlad 
---
 lib/tests/Makefile.am |  1 -
 lib/tests/Makefile.sources|  3 --
 lib/tests/igt_command_line.sh | 76 ---
 tests/Makefile.am |  2 +-
 tests/Makefile.sources|  8 +
 tests/igt_command_line.sh | 74 +
 6 files changed, 83 insertions(+), 81 deletions(-)
 delete mode 100755 lib/tests/igt_command_line.sh
 create mode 100755 tests/igt_command_line.sh

diff --git a/lib/tests/Makefile.am b/lib/tests/Makefile.am
index 582cc3e..99ab724 100644
--- a/lib/tests/Makefile.am
+++ b/lib/tests/Makefile.am
@@ -4,7 +4,6 @@ AM_TESTS_ENVIRONMENT = \
top_builddir=$(top_builddir) \
top_srcdir=$(top_srcdir)
 
-EXTRA_DIST = $(check_SCRIPTS)
 
 AM_CFLAGS = $(DRM_CFLAGS) $(CWARNFLAGS) $(DEBUG_CFLAGS) \
-I$(srcdir)/../.. \
diff --git a/lib/tests/Makefile.sources b/lib/tests/Makefile.sources
index 707c445..37126f1 100644
--- a/lib/tests/Makefile.sources
+++ b/lib/tests/Makefile.sources
@@ -15,9 +15,6 @@ check_PROGRAMS = \
igt_exit_handler \
$(NULL)
 
-check_SCRIPTS = \
-   igt_command_line.sh \
-   $(NULL)
 
 TESTS = \
$(check_PROGRAMS) \
diff --git a/lib/tests/igt_command_line.sh b/lib/tests/igt_command_line.sh
deleted file mode 100755
index e83a548..000
--- a/lib/tests/igt_command_line.sh
+++ /dev/null
@@ -1,76 +0,0 @@
-#!/bin/sh
-#
-# Copyright © 2014 Intel Corporation
-#
-# Permission is hereby granted, free of charge, to any person obtaining a
-# copy of this software and associated documentation files (the "Software"),
-# to deal in the Software without restriction, including without limitation
-# the rights to use, copy, modify, merge, publish, distribute, sublicense,
-# and/or sell copies of the Software, and to permit persons to whom the
-# Software is furnished to do so, subject to the following conditions:
-#
-# The above copyright notice and this permission notice (including the next
-# paragraph) shall be included in all copies or substantial portions of the
-# Software.
-#
-# THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
-# IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
-# FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
-# THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
-# LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
-# FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
-# IN THE SOFTWARE.
-
-#
-# Check that command line handling works consistently across all tests
-#
-
-TESTLIST=`cat $top_builddir/tests/test-list.txt`
-if [ $? -ne 0 ]; then
-   echo "Error: Could not read test lists"
-   exit 99
-fi
-
-for test in $TESTLIST; do
-
-   if [ "$test" = "TESTLIST" -o "$test" = "END" ]; then
-   continue
-   fi
-
-   if [ -x $top_builddir/tests/$test ]; then
-   test=$top_builddir/tests/$test
-   else
-   # if the test is a script, it will be in $srcdir
-   test=$top_srcdir/tests/$test
-   fi
-
-   echo "$test:"
-
-   # check invalid option handling
-   echo "  Checking invalid option handling..."
-   ./$test --invalid-option 2> /dev/null && exit 1
-
-   # check valid options succeed
-   echo "  Checking valid option handling..."
-   ./$test --help > /dev/null || exit 1
-
-   # check --list-subtests works correctly
-   echo "  Checking subtest enumeration..."
-   LIST=`./$test --list-subtests`
-   RET=$?
-   if [ $RET -ne 0 -a $RET -ne 79 ]; then
-   exit 1
-   fi
-
-   if [ $RET -eq 79 -a -n "$LIST" ]; then
-   exit 1
-   fi
-
-   if [ $RET -eq 0 -a -z "$LIST" ]; then
-   exit 1
-   fi
-
-   # check invalid subtest handling
-   echo "  Checking invalid subtest handling..."
-   ./$test --run-subtest invalid-subtest > /dev/null 2>&1 && exit 1
-done
diff --git a/tests/Makefile.am b/tests/Makefile.am
index 45e3359..79a7324 100644
--- a/tests/Makefile.am
+++ b/tests/Makefile.am
@@ -49,7 +49,7 @@ all-local: .gitignore
 pkgdata_DATA = test-list.txt test-list-full.txt
 
 EXTRA_PROGRAMS = $(HANG)
-EXTRA_DIST = $(common_files)
+EXTRA_DIST = $(common_files) $(check_SCRIPTS)
 
 CLEANFILES = $(EXTRA_PROGRAMS) test-list.txt test-list-full.txt .gitignore
 
diff --git a/tests/Makefile.sources b/tests/Makefile.sources
index b73f48d..28e8695 100644
--- a/tests/Makefile.sources
+++ b/tests/Makefile.sources
@@ -287,6 +287,14 @@ testdisplay_SOURCES = \
 
 TESTS_progs += testdisplay
 
+check_SCRIPTS = \
+   

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [CI,1/5] drm/i915: Apply strongly ordered RCS breadcrumb to gen8/legacy

2016-04-29 Thread Patchwork
== Series Details ==

Series: series starting with [CI,1/5] drm/i915: Apply strongly ordered RCS 
breadcrumb to gen8/legacy
URL   : https://patchwork.freedesktop.org/series/6534/
State : success

== Summary ==

Series 6534v1 Series without cover letter
http://patchwork.freedesktop.org/api/1.0/series/6534/revisions/1/mbox/


bdw-nuci7-2  total:201  pass:189  dwarn:0   dfail:0   fail:0   skip:12 
bdw-ultratotal:201  pass:176  dwarn:0   dfail:0   fail:0   skip:25 
bsw-nuc-2total:200  pass:159  dwarn:0   dfail:0   fail:0   skip:41 
byt-nuc  total:200  pass:159  dwarn:0   dfail:0   fail:0   skip:41 
hsw-brixbox  total:201  pass:175  dwarn:0   dfail:0   fail:0   skip:26 
hsw-gt2  total:201  pass:179  dwarn:0   dfail:0   fail:1   skip:21 
ilk-hp8440p  total:201  pass:140  dwarn:0   dfail:0   fail:0   skip:61 
ivb-t430stotal:201  pass:170  dwarn:0   dfail:0   fail:0   skip:31 
skl-i7k-2total:201  pass:174  dwarn:0   dfail:0   fail:0   skip:27 
skl-nuci5total:201  pass:190  dwarn:0   dfail:0   fail:0   skip:11 
snb-x220ttotal:201  pass:159  dwarn:0   dfail:0   fail:1   skip:41 
snb-dellxps failed to collect. IGT log at Patchwork_2113/snb-dellxps/igt.log

Results at /archive/results/CI_IGT_test/Patchwork_2113/

1d56af10bdd6f4714e0892c05ff01d11e77f54fc drm-intel-nightly: 
2016y-04m-29d-09h-21m-52s UTC integration manifest
f2387cc drm/i915: Reload PD tables after semaphore wait on gen8
88d4855 drm/i915: Fix serialisation of pipecontrol write vs semaphore signal
dd37b7e drm/i915: Fix gen8 semaphores id for legacy mode
5cdc2fe drm/i915: Fix ordering of sanitize ppgtt and sanitize execlists
833e61b drm/i915: Apply strongly ordered RCS breadcrumb to gen8/legacy

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH 05/19] drm/i915: Unify unpin_work and mmio_work into flip_work.

2016-04-29 Thread Patrik Jakobsson
On Tue, Apr 19, 2016 at 09:52:25AM +0200, Maarten Lankhorst wrote:
> Rename intel_unpin_work to intel_flip_work and use it for mmio flips
> and unpinning. Use flip_queued_req to hold the wait request in the
> mmio case, and the vblank counter from intel_crtc_get_vblank_counter.
> 
> Signed-off-by: Maarten Lankhorst 

Reviewed-by: Patrik Jakobsson 

> ---
>  drivers/gpu/drm/i915/i915_debugfs.c  |   6 +-
>  drivers/gpu/drm/i915/intel_display.c | 189 
> +++
>  drivers/gpu/drm/i915/intel_drv.h |  19 ++--
>  drivers/gpu/drm/i915/intel_sprite.c  |   8 +-
>  4 files changed, 98 insertions(+), 124 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
> b/drivers/gpu/drm/i915/i915_debugfs.c
> index def95532d421..aabd7a13cec7 100644
> --- a/drivers/gpu/drm/i915/i915_debugfs.c
> +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> @@ -604,10 +604,10 @@ static int i915_gem_pageflip_info(struct seq_file *m, 
> void *data)
>   for_each_intel_crtc(dev, crtc) {
>   const char pipe = pipe_name(crtc->pipe);
>   const char plane = plane_name(crtc->plane);
> - struct intel_unpin_work *work;
> + struct intel_flip_work *work;
>  
>   spin_lock_irq(>event_lock);
> - work = crtc->unpin_work;
> + work = crtc->flip_work;
>   if (work == NULL) {
>   seq_printf(m, "No flip due on pipe %c (plane %c)\n",
>  pipe, plane);
> @@ -637,7 +637,7 @@ static int i915_gem_pageflip_info(struct seq_file *m, 
> void *data)
>   seq_printf(m, "Flip queued on frame %d, (was ready on 
> frame %d), now %d\n",
>  work->flip_queued_vblank,
>  work->flip_ready_vblank,
> -drm_crtc_vblank_count(>base));
> +intel_crtc_get_vblank_counter(crtc));
>   seq_printf(m, "%d prepares\n", 
> atomic_read(>pending));
>  
>   if (INTEL_INFO(dev)->gen >= 4)
> diff --git a/drivers/gpu/drm/i915/intel_display.c 
> b/drivers/gpu/drm/i915/intel_display.c
> index 2086e8bd10da..1d7ef9fb526c 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -48,6 +48,11 @@
>  #include 
>  #include 
>  
> +static bool is_mmio_work(struct intel_flip_work *work)
> +{
> + return work->mmio_work.func;
> +}
> +
>  /* Primary plane formats for gen <= 3 */
>  static const uint32_t i8xx_primary_formats[] = {
>   DRM_FORMAT_C8,
> @@ -3302,7 +3307,7 @@ static bool intel_crtc_has_pending_flip(struct drm_crtc 
> *crtc)
>   return false;
>  
>   spin_lock_irq(>event_lock);
> - pending = to_intel_crtc(crtc)->unpin_work != NULL;
> + pending = to_intel_crtc(crtc)->flip_work != NULL;
>   spin_unlock_irq(>event_lock);
>  
>   return pending;
> @@ -3881,7 +3886,7 @@ bool intel_has_pending_fb_unpin(struct drm_device *dev)
>   if (atomic_read(>unpin_work_count) == 0)
>   continue;
>  
> - if (crtc->unpin_work)
> + if (crtc->flip_work)
>   intel_wait_for_vblank(dev, crtc->pipe);
>  
>   return true;
> @@ -3893,9 +3898,9 @@ bool intel_has_pending_fb_unpin(struct drm_device *dev)
>  static void page_flip_completed(struct intel_crtc *intel_crtc)
>  {
>   struct drm_i915_private *dev_priv = to_i915(intel_crtc->base.dev);
> - struct intel_unpin_work *work = intel_crtc->unpin_work;
> + struct intel_flip_work *work = intel_crtc->flip_work;
>  
> - intel_crtc->unpin_work = NULL;
> + intel_crtc->flip_work = NULL;
>  
>   if (work->event)
>   drm_crtc_send_vblank_event(_crtc->base, work->event);
> @@ -3903,7 +3908,7 @@ static void page_flip_completed(struct intel_crtc 
> *intel_crtc)
>   drm_crtc_vblank_put(_crtc->base);
>  
>   wake_up_all(_priv->pending_flip_queue);
> - queue_work(dev_priv->wq, >work);
> + queue_work(dev_priv->wq, >unpin_work);
>  
>   trace_i915_flip_complete(intel_crtc->plane,
>work->pending_flip_obj);
> @@ -3927,9 +3932,11 @@ static int intel_crtc_wait_for_pending_flips(struct 
> drm_crtc *crtc)
>  
>   if (ret == 0) {
>   struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
> + struct intel_flip_work *work;
>  
>   spin_lock_irq(>event_lock);
> - if (intel_crtc->unpin_work) {
> + work = intel_crtc->flip_work;
> + if (work && !is_mmio_work(work)) {
>   WARN_ONCE(1, "Removing stuck page flip\n");
>   page_flip_completed(intel_crtc);
>   }
> @@ -6328,7 +6335,7 @@ static void intel_crtc_disable_noatomic(struct drm_crtc 
> *crtc)
>   return;
>  
>   if 

[Intel-gfx] [PATCH i-g-t] tools/intel_watermark: Dump linetime watermarks on hsw/bdw

2016-04-29 Thread ville . syrjala
From: Ville Syrjälä 

Signed-off-by: Ville Syrjälä 
---
 tools/intel_watermark.c | 46 --
 1 file changed, 36 insertions(+), 10 deletions(-)

diff --git a/tools/intel_watermark.c b/tools/intel_watermark.c
index 0b7c5e5193ef..133c058aee97 100644
--- a/tools/intel_watermark.c
+++ b/tools/intel_watermark.c
@@ -95,6 +95,9 @@ struct ilk_wm_level {
 
 struct ilk_wm {
struct ilk_wm_level pipe[3];
+   struct {
+   int linetime, ips;
+   } linetime[3];
struct ilk_wm_level lp[3];
 };
 
@@ -133,6 +136,7 @@ static void ilk_wm_dump(void)
uint32_t dspcntr[3];
uint32_t spcntr[3];
uint32_t wm_pipe[3];
+   uint32_t wm_linetime[3];
uint32_t wm_lp[3];
uint32_t wm_lp_spr[3];
uint32_t arb_ctl, arb_ctl2, wm_misc = 0;
@@ -153,6 +157,13 @@ static void ilk_wm_dump(void)
wm_pipe[1] = read_reg(0x45104);
if (num_pipes == 3)
wm_pipe[2] = read_reg(0x45200);
+
+   if (is_hsw_plus(devid)) {
+   wm_linetime[0] = read_reg(0x45270);
+   wm_linetime[1] = read_reg(0x45274);
+   wm_linetime[2] = read_reg(0x45278);
+   }
+
wm_lp[0] = read_reg(0x45108);
wm_lp[1] = read_reg(0x4510c);
wm_lp[2] = read_reg(0x45110);
@@ -171,25 +182,34 @@ static void ilk_wm_dump(void)
intel_register_access_fini();
 
for (i = 0; i < num_pipes; i++)
-   printf("  WM_PIPE_%c = 0x%08x\n", pipe_name(i), wm_pipe[i]);
-   printf(" WM_LP1 = 0x%08x\n", wm_lp[0]);
-   printf(" WM_LP2 = 0x%08x\n", wm_lp[1]);
-   printf(" WM_LP3 = 0x%08x\n", wm_lp[2]);
-   printf(" WM_LP1_SPR = 0x%08x\n", wm_lp_spr[0]);
+   printf("WM_PIPE_%c = 0x%08x\n", pipe_name(i), wm_pipe[i]);
+   if (is_hsw_plus(devid)) {
+   for (i = 0; i < num_pipes; i++)
+   printf("WM_LINETIME_%c = 0x%08x\n", pipe_name(i), 
wm_linetime[i]);
+   }
+   printf("   WM_LP1 = 0x%08x\n", wm_lp[0]);
+   printf("   WM_LP2 = 0x%08x\n", wm_lp[1]);
+   printf("   WM_LP3 = 0x%08x\n", wm_lp[2]);
+   printf("   WM_LP1_SPR = 0x%08x\n", wm_lp_spr[0]);
if (is_gen7_plus(devid)) {
-   printf(" WM_LP2_SPR = 0x%08x\n", wm_lp_spr[1]);
-   printf(" WM_LP3_SPR = 0x%08x\n", wm_lp_spr[2]);
+   printf("   WM_LP2_SPR = 0x%08x\n", wm_lp_spr[1]);
+   printf("   WM_LP3_SPR = 0x%08x\n", wm_lp_spr[2]);
}
-   printf("ARB_CTL = 0x%08x\n", arb_ctl);
-   printf("   ARB_CTL2 = 0x%08x\n", arb_ctl2);
+   printf("  ARB_CTL = 0x%08x\n", arb_ctl);
+   printf(" ARB_CTL2 = 0x%08x\n", arb_ctl2);
if (is_hsw_plus(devid))
-   printf("WM_MISC = 0x%08x\n", wm_misc);
+   printf("  WM_MISC = 0x%08x\n", wm_misc);
 
for (i = 0 ; i < num_pipes; i++) {
wm.pipe[i].primary = REG_DECODE1(wm_pipe[i], 16, 8);
wm.pipe[i].sprite = REG_DECODE1(wm_pipe[i], 8, 8);
wm.pipe[i].cursor = REG_DECODE1(wm_pipe[i], 0, 6);
 
+   if (is_hsw_plus(devid)) {
+   wm.linetime[i].linetime = REG_DECODE1(wm_linetime[i], 
0, 9);
+   wm.linetime[i].ips = REG_DECODE1(wm_linetime[i], 16, 9);
+   }
+
wm.pipe[i].primary_trickle_feed_dis =
REG_DECODE1(dspcntr[i], 14, 1);
if (!IS_GEN5(devid))
@@ -218,6 +238,12 @@ static void ilk_wm_dump(void)
printf("WM_PIPE_%c: primary=%d, cursor=%d, sprite=%d\n",
   pipe_name(i), wm.pipe[i].primary, wm.pipe[i].cursor, 
wm.pipe[i].sprite);
}
+   if (is_hsw_plus(devid)) {
+   for (i = 0; i < num_pipes; i++) {
+   printf("WM_LINETIME_%c: line time=%d, ips line 
time=%d\n",
+  pipe_name(i), wm.linetime[i].linetime, 
wm.linetime[i].ips);
+   }
+   }
if (is_gen7_plus(devid)) {
for (i = 0; i < 3; i++) {
printf("WM_LP%d: %s, latency=%d, fbc=%d, primary=%d, 
cursor=%d, sprite=%d\n",
-- 
2.7.4

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH] drm/i915/lvds: do not set border bits when panel fitter is not enabled

2016-04-29 Thread Jani Nikula
On Fri, 29 Apr 2016, Ville Syrjälä  wrote:
> On Fri, Apr 29, 2016 at 01:12:33PM +0300, Ville Syrjälä wrote:
>> On Fri, Apr 29, 2016 at 12:36:35PM +0300, Jani Nikula wrote:
>> > We also don't read the border bits in i9xx_get_pfit_config() when the
>> > panel fitter is not enabled, causing the state checker warning:
>> > 
>> > [drm:intel_pipe_config_compare [i915]] *ERROR* mismatch in
>> > gmch_pfit.lvds_border_bits (expected 0x8000, found 0x)
>> > 
>> > Cc: Ville Syrjälä 
>> > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=87632
>> > Signed-off-by: Jani Nikula 
>> > ---
>> >  drivers/gpu/drm/i915/intel_panel.c | 1 +
>> >  1 file changed, 1 insertion(+)
>> > 
>> > diff --git a/drivers/gpu/drm/i915/intel_panel.c 
>> > b/drivers/gpu/drm/i915/intel_panel.c
>> > index 828f0fcaaaf8..67cf2e22ba51 100644
>> > --- a/drivers/gpu/drm/i915/intel_panel.c
>> > +++ b/drivers/gpu/drm/i915/intel_panel.c
>> > @@ -363,6 +363,7 @@ out:
>> >if ((pfit_control & PFIT_ENABLE) == 0) {
>> >pfit_control = 0;
>> >pfit_pgm_ratios = 0;
>> > +  border = 0;
>> 
>> That doesn't seem right. We especially want the border for "center".

Doh.

> So after looking at this again, I think we should just move the border
> bit readout to the lvds get_config() hook.

Agreed. Patches sent [1].

> Or was there some magic reason for doing the readout in the wrong
> place? Daniel?

I tried to dig the history, didn't find anything.

BR,
Jani.


[1] 
http://patchwork.freedesktop.org/patch/msgid/1461933243-2140-1-git-send-email-jani.nik...@intel.com

-- 
Jani Nikula, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] [PATCH 1/2] drm/i915/lvds: separate border enable readout from panel fitter

2016-04-29 Thread Jani Nikula
The LVDS border enable is independent from the panel fitter. Move the
readout of the "border bits" from i9xx_get_pfit_config() to
intel_lvds_get_config(), where it will be read if LVDS is enabled even
if the panel fitter is not.

This fixes the state checker warning:

[drm:intel_pipe_config_compare [i915]] *ERROR* mismatch in
gmch_pfit.lvds_border_bits (expected 0x8000, found 0x)

Cc: Ville Syrjälä 
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=87632
Signed-off-by: Jani Nikula 
---
 drivers/gpu/drm/i915/intel_display.c | 3 ---
 drivers/gpu/drm/i915/intel_lvds.c| 4 
 2 files changed, 4 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 5ffccf6e7f36..0fccebbd41a3 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -8022,9 +8022,6 @@ static void i9xx_get_pfit_config(struct intel_crtc *crtc,
 
pipe_config->gmch_pfit.control = tmp;
pipe_config->gmch_pfit.pgm_ratios = I915_READ(PFIT_PGM_RATIOS);
-   if (INTEL_INFO(dev)->gen < 5)
-   pipe_config->gmch_pfit.lvds_border_bits =
-   I915_READ(LVDS) & LVDS_BORDER_ENABLE;
 }
 
 static void vlv_crtc_clock_get(struct intel_crtc *crtc,
diff --git a/drivers/gpu/drm/i915/intel_lvds.c 
b/drivers/gpu/drm/i915/intel_lvds.c
index 66e832beeb37..bc53c0dd34d0 100644
--- a/drivers/gpu/drm/i915/intel_lvds.c
+++ b/drivers/gpu/drm/i915/intel_lvds.c
@@ -122,6 +122,10 @@ static void intel_lvds_get_config(struct intel_encoder 
*encoder,
 
pipe_config->base.adjusted_mode.flags |= flags;
 
+   if (INTEL_INFO(dev)->gen < 5)
+   pipe_config->gmch_pfit.lvds_border_bits =
+   tmp & LVDS_BORDER_ENABLE;
+
/* gen2/3 store dither state in pfit control, needs to match */
if (INTEL_INFO(dev)->gen < 4) {
tmp = I915_READ(PFIT_CONTROL);
-- 
2.1.4

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] [PATCH 2/2] drm/i915: do not set border enable software state for VLV/CHV

2016-04-29 Thread Jani Nikula
VLV/CHV use intel_gmch_panel_fitting() for eDP and DSI. They don't use
the border enable software state for anything, so don't set it
either. This should avoid a state checker warning on lvds_border_bits,
although one hasn't been spotted in the wild.

Signed-off-by: Jani Nikula 
---
 drivers/gpu/drm/i915/intel_panel.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_panel.c 
b/drivers/gpu/drm/i915/intel_panel.c
index 828f0fcaaaf8..d0606b8714a4 100644
--- a/drivers/gpu/drm/i915/intel_panel.c
+++ b/drivers/gpu/drm/i915/intel_panel.c
@@ -371,7 +371,8 @@ out:
 
pipe_config->gmch_pfit.control = pfit_control;
pipe_config->gmch_pfit.pgm_ratios = pfit_pgm_ratios;
-   pipe_config->gmch_pfit.lvds_border_bits = border;
+   if (INTEL_INFO(dev)->gen < 5)
+   pipe_config->gmch_pfit.lvds_border_bits = border;
 }
 
 enum drm_connector_status
-- 
2.1.4

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] [CI 2/5] drm/i915: Fix ordering of sanitize ppgtt and sanitize execlists

2016-04-29 Thread Chris Wilson
The i915.enable_ppgtt option depends upon the state of
i915.enable_execlists option - so we need to sanitize execlists first.

Signed-off-by: Chris Wilson 
Reviewed-by: Joonas Lahtinen 
---
 drivers/gpu/drm/i915/i915_dma.c | 13 +
 drivers/gpu/drm/i915/i915_drv.h |  2 ++
 drivers/gpu/drm/i915/i915_gem.c |  3 ---
 drivers/gpu/drm/i915/i915_gem_gtt.c | 16 +---
 drivers/gpu/drm/i915/intel_lrc.c|  2 --
 5 files changed, 20 insertions(+), 16 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
index f69330cf0118..c91387f1aedd 100644
--- a/drivers/gpu/drm/i915/i915_dma.c
+++ b/drivers/gpu/drm/i915/i915_dma.c
@@ -968,6 +968,19 @@ static void intel_device_info_runtime_init(struct 
drm_device *dev)
 info->has_subslice_pg ? "y" : "n");
DRM_DEBUG_DRIVER("has EU power gating: %s\n",
 info->has_eu_pg ? "y" : "n");
+
+   i915.enable_execlists =
+   intel_sanitize_enable_execlists(dev, i915.enable_execlists);
+
+   /*
+* i915.enable_ppgtt is read-only, so do an early pass to validate the
+* user's requested state against the hardware/driver capabilities.  We
+* do this now so that we can print out any log messages once rather
+* than every time we check intel_enable_ppgtt().
+*/
+   i915.enable_ppgtt =
+   intel_sanitize_enable_ppgtt(dev, i915.enable_ppgtt);
+   DRM_DEBUG_DRIVER("ppgtt mode: %i\n", i915.enable_ppgtt);
 }
 
 static void intel_init_dpio(struct drm_i915_private *dev_priv)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 7d15930b69b1..02c619e7af05 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2753,6 +2753,8 @@ extern int i915_max_ioctl;
 extern int i915_suspend_switcheroo(struct drm_device *dev, pm_message_t state);
 extern int i915_resume_switcheroo(struct drm_device *dev);
 
+int intel_sanitize_enable_ppgtt(struct drm_device *dev, int enable_ppgtt);
+
 /* i915_dma.c */
 void __printf(3, 4)
 __i915_printk(struct drm_i915_private *dev_priv, const char *level,
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 96fbc9ab4039..bd6061f177fe 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -4901,9 +4901,6 @@ int i915_gem_init(struct drm_device *dev)
struct drm_i915_private *dev_priv = dev->dev_private;
int ret;
 
-   i915.enable_execlists = intel_sanitize_enable_execlists(dev,
-   i915.enable_execlists);
-
mutex_lock(>struct_mutex);
 
if (!i915.enable_execlists) {
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c 
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index 59a78f760b6b..364cf8236021 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -110,7 +110,7 @@ const struct i915_ggtt_view i915_ggtt_view_rotated = {
.type = I915_GGTT_VIEW_ROTATED,
 };
 
-static int sanitize_enable_ppgtt(struct drm_device *dev, int enable_ppgtt)
+int intel_sanitize_enable_ppgtt(struct drm_device *dev, int enable_ppgtt)
 {
bool has_aliasing_ppgtt;
bool has_full_ppgtt;
@@ -123,12 +123,14 @@ static int sanitize_enable_ppgtt(struct drm_device *dev, 
int enable_ppgtt)
if (intel_vgpu_active(dev))
has_full_ppgtt = false; /* emulation is too hard */
 
+   if (!has_aliasing_ppgtt)
+   return 0;
+
/*
 * We don't allow disabling PPGTT for gen9+ as it's a requirement for
 * execlists, the sole mechanism available to submit work.
 */
-   if (INTEL_INFO(dev)->gen < 9 &&
-   (enable_ppgtt == 0 || !has_aliasing_ppgtt))
+   if (enable_ppgtt == 0 && INTEL_INFO(dev)->gen < 9)
return 0;
 
if (enable_ppgtt == 1)
@@ -3219,14 +3221,6 @@ int i915_ggtt_init_hw(struct drm_device *dev)
if (intel_iommu_gfx_mapped)
DRM_INFO("VT-d active for gfx access\n");
 #endif
-   /*
-* i915.enable_ppgtt is read-only, so do an early pass to validate the
-* user's requested state against the hardware/driver capabilities.  We
-* do this now so that we can print out any log messages once rather
-* than every time we check intel_enable_ppgtt().
-*/
-   i915.enable_ppgtt = sanitize_enable_ppgtt(dev, i915.enable_ppgtt);
-   DRM_DEBUG_DRIVER("ppgtt mode: %i\n", i915.enable_ppgtt);
 
return 0;
 
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index b2a9072c5753..d8763524319d 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -248,8 +248,6 @@ static int intel_lr_context_pin(struct intel_context *ctx,
  */
 int intel_sanitize_enable_execlists(struct drm_device *dev, int 
enable_execlists)
 {
-   

[Intel-gfx] [CI 5/5] drm/i915: Reload PD tables after semaphore wait on gen8

2016-04-29 Thread Chris Wilson
When the engine idles waiting upon a semaphore, it loses its
pagetables and we must reload them before executing the batch.

v2: Restrict w/a to non-RCS rings (RCS works correctly apparently).

Signed-off-by: Chris Wilson 
Cc: Ville Syrjälä 
Reviewed-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/intel_ringbuffer.c | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c 
b/drivers/gpu/drm/i915/intel_ringbuffer.c
index 533ebbd384f6..70738a54ed0f 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.c
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
@@ -1481,6 +1481,7 @@ gen8_ring_sync(struct drm_i915_gem_request *waiter_req,
 {
struct intel_engine_cs *waiter = waiter_req->engine;
struct drm_i915_private *dev_priv = waiter->dev->dev_private;
+   struct i915_hw_ppgtt *ppgtt;
int ret;
 
ret = intel_ring_begin(waiter_req, 4);
@@ -1496,6 +1497,15 @@ gen8_ring_sync(struct drm_i915_gem_request *waiter_req,
intel_ring_emit(waiter,
upper_32_bits(GEN8_WAIT_OFFSET(waiter, signaller->id)));
intel_ring_advance(waiter);
+
+   /* When the !RCS engines idle waiting upon a semaphore, they lose their
+* pagetables and we must reload them before executing the batch.
+* We do this on the i915_switch_context() following the wait and
+* before the dispatch.
+*/
+   ppgtt = waiter_req->ctx->ppgtt;
+   if (ppgtt && waiter_req->engine->id != RCS)
+   ppgtt->pd_dirty_rings |= intel_engine_flag(waiter_req->engine);
return 0;
 }
 
-- 
2.8.1

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] [CI 4/5] drm/i915: Fix serialisation of pipecontrol write vs semaphore signal

2016-04-29 Thread Chris Wilson
In order for the MI_SEMAPHORE_SIGNAL command to wait until after the
pipecontrol writing the signal value is complete, we have to pause the
CS inside the PIPE_CONTROL with the CS_STALL bit.

Signed-off-by: Chris Wilson 
Reviewed-by: Ville Syrjälä 
Cc: Ville Syrjälä 
---
 drivers/gpu/drm/i915/intel_ringbuffer.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c 
b/drivers/gpu/drm/i915/intel_ringbuffer.c
index ef3468956fae..533ebbd384f6 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.c
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
@@ -1307,7 +1307,7 @@ static int gen8_rcs_signal(struct drm_i915_gem_request 
*signaller_req,
intel_ring_emit(signaller, GFX_OP_PIPE_CONTROL(6));
intel_ring_emit(signaller, PIPE_CONTROL_GLOBAL_GTT_IVB |
   PIPE_CONTROL_QW_WRITE |
-  PIPE_CONTROL_FLUSH_ENABLE);
+  PIPE_CONTROL_CS_STALL);
intel_ring_emit(signaller, lower_32_bits(gtt_offset));
intel_ring_emit(signaller, upper_32_bits(gtt_offset));
intel_ring_emit(signaller, seqno);
@@ -1489,7 +1489,6 @@ gen8_ring_sync(struct drm_i915_gem_request *waiter_req,
 
intel_ring_emit(waiter, MI_SEMAPHORE_WAIT |
MI_SEMAPHORE_GLOBAL_GTT |
-   MI_SEMAPHORE_POLL |
MI_SEMAPHORE_SAD_GTE_SDD);
intel_ring_emit(waiter, seqno);
intel_ring_emit(waiter,
-- 
2.8.1

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] [CI 1/5] drm/i915: Apply strongly ordered RCS breadcrumb to gen8/legacy

2016-04-29 Thread Chris Wilson
For legacy ringbuffer mode, we need the new ordered breadcrumb emission
tried and tested on execlists in order to avoid the dreaded "missed
interrupt" syndrome. A secondary advantage of the execlists method is
that it writes to an arbitrary address, useful if one wants to write a
breadcrumb elsewhere.

This fix is taken from commit 7c17d377374dd (drm/i915: Use ordered seqno
write interrupt generation on gen8+ execlists).

Signed-off-by: Chris Wilson 
Cc: Mika Kuoppala 
Reviewed-by: Joonas Lahtinen 
---
 drivers/gpu/drm/i915/intel_lrc.c| 10 +++---
 drivers/gpu/drm/i915/intel_ringbuffer.c | 32 ++--
 drivers/gpu/drm/i915/intel_ringbuffer.h |  5 +
 3 files changed, 38 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index ec2522243b5e..b2a9072c5753 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -1767,11 +1767,6 @@ static void bxt_a_set_seqno(struct intel_engine_cs 
*engine, u32 seqno)
  */
 #define WA_TAIL_DWORDS 2
 
-static inline u32 hws_seqno_address(struct intel_engine_cs *engine)
-{
-   return engine->status_page.gfx_addr + I915_GEM_HWS_INDEX_ADDR;
-}
-
 static int gen8_emit_request(struct drm_i915_gem_request *request)
 {
struct intel_ringbuffer *ringbuf = request->ringbuf;
@@ -1787,7 +1782,7 @@ static int gen8_emit_request(struct drm_i915_gem_request 
*request)
intel_logical_ring_emit(ringbuf,
(MI_FLUSH_DW + 1) | MI_FLUSH_DW_OP_STOREDW);
intel_logical_ring_emit(ringbuf,
-   hws_seqno_address(request->engine) |
+   intel_hws_seqno_address(request->engine) |
MI_FLUSH_DW_USE_GTT);
intel_logical_ring_emit(ringbuf, 0);
intel_logical_ring_emit(ringbuf, i915_gem_request_get_seqno(request));
@@ -1817,7 +1812,8 @@ static int gen8_emit_request_render(struct 
drm_i915_gem_request *request)
(PIPE_CONTROL_GLOBAL_GTT_IVB |
 PIPE_CONTROL_CS_STALL |
 PIPE_CONTROL_QW_WRITE));
-   intel_logical_ring_emit(ringbuf, hws_seqno_address(request->engine));
+   intel_logical_ring_emit(ringbuf,
+   intel_hws_seqno_address(request->engine));
intel_logical_ring_emit(ringbuf, 0);
intel_logical_ring_emit(ringbuf, i915_gem_request_get_seqno(request));
/* We're thrashing one dword of HWS. */
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c 
b/drivers/gpu/drm/i915/intel_ringbuffer.c
index c7637ceec1f4..c1472d62b663 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.c
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
@@ -1430,6 +1430,35 @@ gen6_add_request(struct drm_i915_gem_request *req)
return 0;
 }
 
+static int
+gen8_render_add_request(struct drm_i915_gem_request *req)
+{
+   struct intel_engine_cs *engine = req->engine;
+   int ret;
+
+   if (engine->semaphore.signal)
+   ret = engine->semaphore.signal(req, 8);
+   else
+   ret = intel_ring_begin(req, 8);
+   if (ret)
+   return ret;
+
+   intel_ring_emit(engine, GFX_OP_PIPE_CONTROL(6));
+   intel_ring_emit(engine, (PIPE_CONTROL_GLOBAL_GTT_IVB |
+PIPE_CONTROL_CS_STALL |
+PIPE_CONTROL_QW_WRITE));
+   intel_ring_emit(engine, intel_hws_seqno_address(req->engine));
+   intel_ring_emit(engine, 0);
+   intel_ring_emit(engine, i915_gem_request_get_seqno(req));
+   /* We're thrashing one dword of HWS. */
+   intel_ring_emit(engine, 0);
+   intel_ring_emit(engine, MI_USER_INTERRUPT);
+   intel_ring_emit(engine, MI_NOOP);
+   __intel_ring_advance(engine);
+
+   return 0;
+}
+
 static inline bool i915_gem_has_seqno_wrapped(struct drm_device *dev,
  u32 seqno)
 {
@@ -2751,12 +2780,11 @@ int intel_init_render_ring_buffer(struct drm_device 
*dev)
}
 
engine->init_context = intel_rcs_ctx_init;
-   engine->add_request = gen6_add_request;
+   engine->add_request = gen8_render_add_request;
engine->flush = gen8_render_ring_flush;
engine->irq_get = gen8_ring_get_irq;
engine->irq_put = gen8_ring_put_irq;
engine->irq_enable_mask = GT_RENDER_USER_INTERRUPT;
-   engine->irq_seqno_barrier = gen6_seqno_barrier;
engine->get_seqno = ring_get_seqno;
engine->set_seqno = ring_set_seqno;
if (i915_semaphore_is_enabled(dev)) {
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.h 
b/drivers/gpu/drm/i915/intel_ringbuffer.h
index d7082124eee3..55b0438b2fa1 100644
--- 

[Intel-gfx] [CI 3/5] drm/i915: Fix gen8 semaphores id for legacy mode

2016-04-29 Thread Chris Wilson
With the introduction of a distinct engine->id vs the hardware id, we need
to fix up the value we use for selecting the target engine when signaling
a semaphore. Note that these values can be merged with engine->guc_id.

Fixes: de1add360522c876c25ef2ab1c94bdb509ab
Signed-off-by: Chris Wilson 
Cc: Tvrtko Ursulin 
Cc: Ville Syrjälä 
---
 drivers/gpu/drm/i915/intel_ringbuffer.c | 9 +++--
 drivers/gpu/drm/i915/intel_ringbuffer.h | 3 ++-
 2 files changed, 9 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c 
b/drivers/gpu/drm/i915/intel_ringbuffer.c
index c1472d62b663..ef3468956fae 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.c
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
@@ -1313,7 +1313,7 @@ static int gen8_rcs_signal(struct drm_i915_gem_request 
*signaller_req,
intel_ring_emit(signaller, seqno);
intel_ring_emit(signaller, 0);
intel_ring_emit(signaller, MI_SEMAPHORE_SIGNAL |
-  MI_SEMAPHORE_TARGET(waiter->id));
+  MI_SEMAPHORE_TARGET(waiter->hw_id));
intel_ring_emit(signaller, 0);
}
 
@@ -1353,7 +1353,7 @@ static int gen8_xcs_signal(struct drm_i915_gem_request 
*signaller_req,
intel_ring_emit(signaller, upper_32_bits(gtt_offset));
intel_ring_emit(signaller, seqno);
intel_ring_emit(signaller, MI_SEMAPHORE_SIGNAL |
-  MI_SEMAPHORE_TARGET(waiter->id));
+  MI_SEMAPHORE_TARGET(waiter->hw_id));
intel_ring_emit(signaller, 0);
}
 
@@ -2759,6 +2759,7 @@ int intel_init_render_ring_buffer(struct drm_device *dev)
engine->name = "render ring";
engine->id = RCS;
engine->exec_id = I915_EXEC_RENDER;
+   engine->hw_id = 0;
engine->mmio_base = RENDER_RING_BASE;
 
if (INTEL_INFO(dev)->gen >= 8) {
@@ -2909,6 +2910,7 @@ int intel_init_bsd_ring_buffer(struct drm_device *dev)
engine->name = "bsd ring";
engine->id = VCS;
engine->exec_id = I915_EXEC_BSD;
+   engine->hw_id = 1;
 
engine->write_tail = ring_write_tail;
if (INTEL_INFO(dev)->gen >= 6) {
@@ -2987,6 +2989,7 @@ int intel_init_bsd2_ring_buffer(struct drm_device *dev)
engine->name = "bsd2 ring";
engine->id = VCS2;
engine->exec_id = I915_EXEC_BSD;
+   engine->hw_id = 4;
 
engine->write_tail = ring_write_tail;
engine->mmio_base = GEN8_BSD2_RING_BASE;
@@ -3019,6 +3022,7 @@ int intel_init_blt_ring_buffer(struct drm_device *dev)
engine->name = "blitter ring";
engine->id = BCS;
engine->exec_id = I915_EXEC_BLT;
+   engine->hw_id = 2;
 
engine->mmio_base = BLT_RING_BASE;
engine->write_tail = ring_write_tail;
@@ -3078,6 +3082,7 @@ int intel_init_vebox_ring_buffer(struct drm_device *dev)
engine->name = "video enhancement ring";
engine->id = VECS;
engine->exec_id = I915_EXEC_VEBOX;
+   engine->hw_id = 3;
 
engine->mmio_base = VEBOX_RING_BASE;
engine->write_tail = ring_write_tail;
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.h 
b/drivers/gpu/drm/i915/intel_ringbuffer.h
index 55b0438b2fa1..723ff6160fbb 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.h
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.h
@@ -153,7 +153,8 @@ struct  intel_engine_cs {
 #define I915_NUM_ENGINES 5
 #define _VCS(n) (VCS + (n))
unsigned int exec_id;
-   unsigned int guc_id;
+   unsigned int hw_id;
+   unsigned int guc_id; /* XXX same as hw_id? */
u32 mmio_base;
struct  drm_device *dev;
struct intel_ringbuffer *buffer;
-- 
2.8.1

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH] drm/i915/lvds: do not set border bits when panel fitter is not enabled

2016-04-29 Thread Ville Syrjälä
On Fri, Apr 29, 2016 at 01:12:33PM +0300, Ville Syrjälä wrote:
> On Fri, Apr 29, 2016 at 12:36:35PM +0300, Jani Nikula wrote:
> > We also don't read the border bits in i9xx_get_pfit_config() when the
> > panel fitter is not enabled, causing the state checker warning:
> > 
> > [drm:intel_pipe_config_compare [i915]] *ERROR* mismatch in
> > gmch_pfit.lvds_border_bits (expected 0x8000, found 0x)
> > 
> > Cc: Ville Syrjälä 
> > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=87632
> > Signed-off-by: Jani Nikula 
> > ---
> >  drivers/gpu/drm/i915/intel_panel.c | 1 +
> >  1 file changed, 1 insertion(+)
> > 
> > diff --git a/drivers/gpu/drm/i915/intel_panel.c 
> > b/drivers/gpu/drm/i915/intel_panel.c
> > index 828f0fcaaaf8..67cf2e22ba51 100644
> > --- a/drivers/gpu/drm/i915/intel_panel.c
> > +++ b/drivers/gpu/drm/i915/intel_panel.c
> > @@ -363,6 +363,7 @@ out:
> > if ((pfit_control & PFIT_ENABLE) == 0) {
> > pfit_control = 0;
> > pfit_pgm_ratios = 0;
> > +   border = 0;
> 
> That doesn't seem right. We especially want the border for "center".

So after looking at this again, I think we should just move the border
bit readout to the lvds get_config() hook.

Or was there some magic reason for doing the readout in the wrong
place? Daniel?

-- 
Ville Syrjälä
Intel OTC
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] ✗ Fi.CI.BAT: warning for series starting with [CI,1/7] drm/i915: Apply strongly ordered RCS breadcrumb to gen8/legacy

2016-04-29 Thread Patchwork
== Series Details ==

Series: series starting with [CI,1/7] drm/i915: Apply strongly ordered RCS 
breadcrumb to gen8/legacy
URL   : https://patchwork.freedesktop.org/series/6532/
State : warning

== Summary ==

Series 6532v1 Series without cover letter
http://patchwork.freedesktop.org/api/1.0/series/6532/revisions/1/mbox/

Test gem_exec_suspend:
Subgroup basic-s3:
pass   -> DMESG-WARN (bsw-nuc-2)
Test kms_force_connector_basic:
Subgroup force-edid:
pass   -> SKIP   (ivb-t430s)

bdw-nuci7-2  total:201  pass:189  dwarn:0   dfail:0   fail:0   skip:12 
bdw-ultratotal:201  pass:176  dwarn:0   dfail:0   fail:0   skip:25 
bsw-nuc-2total:200  pass:158  dwarn:1   dfail:0   fail:0   skip:41 
byt-nuc  total:200  pass:159  dwarn:0   dfail:0   fail:0   skip:41 
hsw-brixbox  total:201  pass:175  dwarn:0   dfail:0   fail:0   skip:26 
hsw-gt2  total:201  pass:179  dwarn:0   dfail:0   fail:1   skip:21 
ilk-hp8440p  total:201  pass:140  dwarn:0   dfail:0   fail:0   skip:61 
ivb-t430stotal:201  pass:169  dwarn:0   dfail:0   fail:0   skip:32 
skl-i7k-2total:201  pass:174  dwarn:0   dfail:0   fail:0   skip:27 
skl-nuci5total:201  pass:190  dwarn:0   dfail:0   fail:0   skip:11 
snb-dellxps  total:201  pass:159  dwarn:0   dfail:0   fail:0   skip:42 
snb-x220ttotal:201  pass:159  dwarn:0   dfail:0   fail:1   skip:41 

Results at /archive/results/CI_IGT_test/Patchwork_2112/

1d56af10bdd6f4714e0892c05ff01d11e77f54fc drm-intel-nightly: 
2016y-04m-29d-09h-21m-52s UTC integration manifest
3d3b8b2 drm/i915: Enable legacy/semaphores for CI
9a603b6 drm/i915: Enable semaphores for legacy submission on gen8
b208441 drm/i915: Reload PD tables after semaphore wait on gen8
f667059 drm/i915: Fix serialisation of pipecontrol write vs semaphore signal
95243ff drm/i915: Fix gen8 semaphores id for legacy mode
71cf798 drm/i915: Fix ordering of sanitize ppgtt and sanitize execlists
006506f drm/i915: Apply strongly ordered RCS breadcrumb to gen8/legacy

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for drm/gem: support BO freeing without dev->struct_mutex

2016-04-29 Thread Chris Wilson
On Fri, Apr 29, 2016 at 11:18:18AM -, Patchwork wrote:
> == Series Details ==
> 
> Series: drm/gem: support BO freeing without dev->struct_mutex
> URL   : https://patchwork.freedesktop.org/series/6527/
> State : failure
> 
> == Summary ==
> 
> Series 6527v1 drm/gem: support BO freeing without dev->struct_mutex
> http://patchwork.freedesktop.org/api/1.0/series/6527/revisions/1/mbox/
> 
> Test drv_getparams_basic:
> Subgroup basic-eu-total:
> pass   -> DMESG-WARN (bsw-nuc-2)

Hmm, I guess that we call drm_gem_object_unreference on a unlocked path
during init/fini.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] [CI 6/7] drm/i915: Enable semaphores for legacy submission on gen8

2016-04-29 Thread Chris Wilson
We have sufficient evidence from igt to support that semaphores are in
a working state. Enabling semaphores now for legacy provides a better
comparison of execlists against legacy ring submission.

Signed-off-by: Chris Wilson 
Acked-by: Daniel Vetter 
---
 drivers/gpu/drm/i915/i915_drv.c | 4 
 1 file changed, 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index d37c0a671eed..9fd221c97275 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -542,10 +542,6 @@ bool i915_semaphore_is_enabled(struct drm_device *dev)
if (i915.enable_execlists)
return false;
 
-   /* Until we get further testing... */
-   if (IS_GEN8(dev))
-   return false;
-
 #ifdef CONFIG_INTEL_IOMMU
/* Enable semaphores on SNB when IO remapping is off */
if (INTEL_INFO(dev)->gen == 6 && intel_iommu_gfx_mapped)
-- 
2.8.1

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] [CI 7/7] drm/i915: Enable legacy/semaphores for CI

2016-04-29 Thread Chris Wilson
---
 drivers/gpu/drm/i915/intel_lrc.c | 4 
 1 file changed, 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index d8763524319d..0713acb52ce4 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -260,10 +260,6 @@ int intel_sanitize_enable_execlists(struct drm_device 
*dev, int enable_execlists
if (enable_execlists == 0)
return 0;
 
-   if (HAS_LOGICAL_RING_CONTEXTS(dev) && USES_PPGTT(dev) &&
-   i915.use_mmio_flip >= 0)
-   return 1;
-
return 0;
 }
 
-- 
2.8.1

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] [CI 2/7] drm/i915: Fix ordering of sanitize ppgtt and sanitize execlists

2016-04-29 Thread Chris Wilson
The i915.enable_ppgtt option depends upon the state of
i915.enable_execlists option - so we need to sanitize execlists first.

Signed-off-by: Chris Wilson 
Reviewed-by: Joonas Lahtinen 
---
 drivers/gpu/drm/i915/i915_dma.c | 13 +
 drivers/gpu/drm/i915/i915_drv.h |  2 ++
 drivers/gpu/drm/i915/i915_gem.c |  3 ---
 drivers/gpu/drm/i915/i915_gem_gtt.c | 16 +---
 drivers/gpu/drm/i915/intel_lrc.c|  2 --
 5 files changed, 20 insertions(+), 16 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
index f69330cf0118..c91387f1aedd 100644
--- a/drivers/gpu/drm/i915/i915_dma.c
+++ b/drivers/gpu/drm/i915/i915_dma.c
@@ -968,6 +968,19 @@ static void intel_device_info_runtime_init(struct 
drm_device *dev)
 info->has_subslice_pg ? "y" : "n");
DRM_DEBUG_DRIVER("has EU power gating: %s\n",
 info->has_eu_pg ? "y" : "n");
+
+   i915.enable_execlists =
+   intel_sanitize_enable_execlists(dev, i915.enable_execlists);
+
+   /*
+* i915.enable_ppgtt is read-only, so do an early pass to validate the
+* user's requested state against the hardware/driver capabilities.  We
+* do this now so that we can print out any log messages once rather
+* than every time we check intel_enable_ppgtt().
+*/
+   i915.enable_ppgtt =
+   intel_sanitize_enable_ppgtt(dev, i915.enable_ppgtt);
+   DRM_DEBUG_DRIVER("ppgtt mode: %i\n", i915.enable_ppgtt);
 }
 
 static void intel_init_dpio(struct drm_i915_private *dev_priv)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 7d15930b69b1..02c619e7af05 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2753,6 +2753,8 @@ extern int i915_max_ioctl;
 extern int i915_suspend_switcheroo(struct drm_device *dev, pm_message_t state);
 extern int i915_resume_switcheroo(struct drm_device *dev);
 
+int intel_sanitize_enable_ppgtt(struct drm_device *dev, int enable_ppgtt);
+
 /* i915_dma.c */
 void __printf(3, 4)
 __i915_printk(struct drm_i915_private *dev_priv, const char *level,
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 96fbc9ab4039..bd6061f177fe 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -4901,9 +4901,6 @@ int i915_gem_init(struct drm_device *dev)
struct drm_i915_private *dev_priv = dev->dev_private;
int ret;
 
-   i915.enable_execlists = intel_sanitize_enable_execlists(dev,
-   i915.enable_execlists);
-
mutex_lock(>struct_mutex);
 
if (!i915.enable_execlists) {
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c 
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index 59a78f760b6b..364cf8236021 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -110,7 +110,7 @@ const struct i915_ggtt_view i915_ggtt_view_rotated = {
.type = I915_GGTT_VIEW_ROTATED,
 };
 
-static int sanitize_enable_ppgtt(struct drm_device *dev, int enable_ppgtt)
+int intel_sanitize_enable_ppgtt(struct drm_device *dev, int enable_ppgtt)
 {
bool has_aliasing_ppgtt;
bool has_full_ppgtt;
@@ -123,12 +123,14 @@ static int sanitize_enable_ppgtt(struct drm_device *dev, 
int enable_ppgtt)
if (intel_vgpu_active(dev))
has_full_ppgtt = false; /* emulation is too hard */
 
+   if (!has_aliasing_ppgtt)
+   return 0;
+
/*
 * We don't allow disabling PPGTT for gen9+ as it's a requirement for
 * execlists, the sole mechanism available to submit work.
 */
-   if (INTEL_INFO(dev)->gen < 9 &&
-   (enable_ppgtt == 0 || !has_aliasing_ppgtt))
+   if (enable_ppgtt == 0 && INTEL_INFO(dev)->gen < 9)
return 0;
 
if (enable_ppgtt == 1)
@@ -3219,14 +3221,6 @@ int i915_ggtt_init_hw(struct drm_device *dev)
if (intel_iommu_gfx_mapped)
DRM_INFO("VT-d active for gfx access\n");
 #endif
-   /*
-* i915.enable_ppgtt is read-only, so do an early pass to validate the
-* user's requested state against the hardware/driver capabilities.  We
-* do this now so that we can print out any log messages once rather
-* than every time we check intel_enable_ppgtt().
-*/
-   i915.enable_ppgtt = sanitize_enable_ppgtt(dev, i915.enable_ppgtt);
-   DRM_DEBUG_DRIVER("ppgtt mode: %i\n", i915.enable_ppgtt);
 
return 0;
 
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index b2a9072c5753..d8763524319d 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -248,8 +248,6 @@ static int intel_lr_context_pin(struct intel_context *ctx,
  */
 int intel_sanitize_enable_execlists(struct drm_device *dev, int 
enable_execlists)
 {
-   

[Intel-gfx] [CI 5/7] drm/i915: Reload PD tables after semaphore wait on gen8

2016-04-29 Thread Chris Wilson
When the engine idles waiting upon a semaphore, it loses its
pagetables and we must reload them before executing the batch.

v2: Restrict w/a to non-RCS rings (RCS works correctly apparently).

Signed-off-by: Chris Wilson 
Cc: Ville Syrjälä 
Reviewed-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/intel_ringbuffer.c | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c 
b/drivers/gpu/drm/i915/intel_ringbuffer.c
index 533ebbd384f6..70738a54ed0f 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.c
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
@@ -1481,6 +1481,7 @@ gen8_ring_sync(struct drm_i915_gem_request *waiter_req,
 {
struct intel_engine_cs *waiter = waiter_req->engine;
struct drm_i915_private *dev_priv = waiter->dev->dev_private;
+   struct i915_hw_ppgtt *ppgtt;
int ret;
 
ret = intel_ring_begin(waiter_req, 4);
@@ -1496,6 +1497,15 @@ gen8_ring_sync(struct drm_i915_gem_request *waiter_req,
intel_ring_emit(waiter,
upper_32_bits(GEN8_WAIT_OFFSET(waiter, signaller->id)));
intel_ring_advance(waiter);
+
+   /* When the !RCS engines idle waiting upon a semaphore, they lose their
+* pagetables and we must reload them before executing the batch.
+* We do this on the i915_switch_context() following the wait and
+* before the dispatch.
+*/
+   ppgtt = waiter_req->ctx->ppgtt;
+   if (ppgtt && waiter_req->engine->id != RCS)
+   ppgtt->pd_dirty_rings |= intel_engine_flag(waiter_req->engine);
return 0;
 }
 
-- 
2.8.1

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] [CI 4/7] drm/i915: Fix serialisation of pipecontrol write vs semaphore signal

2016-04-29 Thread Chris Wilson
In order for the MI_SEMAPHORE_SIGNAL command to wait until after the
pipecontrol writing the signal value is complete, we have to pause the
CS inside the PIPE_CONTROL with the CS_STALL bit.

Signed-off-by: Chris Wilson 
Reviewed-by: Ville Syrjälä 
Cc: Ville Syrjälä 
---
 drivers/gpu/drm/i915/intel_ringbuffer.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c 
b/drivers/gpu/drm/i915/intel_ringbuffer.c
index ef3468956fae..533ebbd384f6 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.c
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
@@ -1307,7 +1307,7 @@ static int gen8_rcs_signal(struct drm_i915_gem_request 
*signaller_req,
intel_ring_emit(signaller, GFX_OP_PIPE_CONTROL(6));
intel_ring_emit(signaller, PIPE_CONTROL_GLOBAL_GTT_IVB |
   PIPE_CONTROL_QW_WRITE |
-  PIPE_CONTROL_FLUSH_ENABLE);
+  PIPE_CONTROL_CS_STALL);
intel_ring_emit(signaller, lower_32_bits(gtt_offset));
intel_ring_emit(signaller, upper_32_bits(gtt_offset));
intel_ring_emit(signaller, seqno);
@@ -1489,7 +1489,6 @@ gen8_ring_sync(struct drm_i915_gem_request *waiter_req,
 
intel_ring_emit(waiter, MI_SEMAPHORE_WAIT |
MI_SEMAPHORE_GLOBAL_GTT |
-   MI_SEMAPHORE_POLL |
MI_SEMAPHORE_SAD_GTE_SDD);
intel_ring_emit(waiter, seqno);
intel_ring_emit(waiter,
-- 
2.8.1

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] [CI 1/7] drm/i915: Apply strongly ordered RCS breadcrumb to gen8/legacy

2016-04-29 Thread Chris Wilson
For legacy ringbuffer mode, we need the new ordered breadcrumb emission
tried and tested on execlists in order to avoid the dreaded "missed
interrupt" syndrome. A secondary advantage of the execlists method is
that it writes to an arbitrary address, useful if one wants to write a
breadcrumb elsewhere.

This fix is taken from commit 7c17d377374dd (drm/i915: Use ordered seqno
write interrupt generation on gen8+ execlists).

Signed-off-by: Chris Wilson 
Cc: Mika Kuoppala 
Reviewed-by: Joonas Lahtinen 
---
 drivers/gpu/drm/i915/intel_lrc.c| 10 +++---
 drivers/gpu/drm/i915/intel_ringbuffer.c | 32 ++--
 drivers/gpu/drm/i915/intel_ringbuffer.h |  5 +
 3 files changed, 38 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index ec2522243b5e..b2a9072c5753 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -1767,11 +1767,6 @@ static void bxt_a_set_seqno(struct intel_engine_cs 
*engine, u32 seqno)
  */
 #define WA_TAIL_DWORDS 2
 
-static inline u32 hws_seqno_address(struct intel_engine_cs *engine)
-{
-   return engine->status_page.gfx_addr + I915_GEM_HWS_INDEX_ADDR;
-}
-
 static int gen8_emit_request(struct drm_i915_gem_request *request)
 {
struct intel_ringbuffer *ringbuf = request->ringbuf;
@@ -1787,7 +1782,7 @@ static int gen8_emit_request(struct drm_i915_gem_request 
*request)
intel_logical_ring_emit(ringbuf,
(MI_FLUSH_DW + 1) | MI_FLUSH_DW_OP_STOREDW);
intel_logical_ring_emit(ringbuf,
-   hws_seqno_address(request->engine) |
+   intel_hws_seqno_address(request->engine) |
MI_FLUSH_DW_USE_GTT);
intel_logical_ring_emit(ringbuf, 0);
intel_logical_ring_emit(ringbuf, i915_gem_request_get_seqno(request));
@@ -1817,7 +1812,8 @@ static int gen8_emit_request_render(struct 
drm_i915_gem_request *request)
(PIPE_CONTROL_GLOBAL_GTT_IVB |
 PIPE_CONTROL_CS_STALL |
 PIPE_CONTROL_QW_WRITE));
-   intel_logical_ring_emit(ringbuf, hws_seqno_address(request->engine));
+   intel_logical_ring_emit(ringbuf,
+   intel_hws_seqno_address(request->engine));
intel_logical_ring_emit(ringbuf, 0);
intel_logical_ring_emit(ringbuf, i915_gem_request_get_seqno(request));
/* We're thrashing one dword of HWS. */
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c 
b/drivers/gpu/drm/i915/intel_ringbuffer.c
index c7637ceec1f4..c1472d62b663 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.c
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
@@ -1430,6 +1430,35 @@ gen6_add_request(struct drm_i915_gem_request *req)
return 0;
 }
 
+static int
+gen8_render_add_request(struct drm_i915_gem_request *req)
+{
+   struct intel_engine_cs *engine = req->engine;
+   int ret;
+
+   if (engine->semaphore.signal)
+   ret = engine->semaphore.signal(req, 8);
+   else
+   ret = intel_ring_begin(req, 8);
+   if (ret)
+   return ret;
+
+   intel_ring_emit(engine, GFX_OP_PIPE_CONTROL(6));
+   intel_ring_emit(engine, (PIPE_CONTROL_GLOBAL_GTT_IVB |
+PIPE_CONTROL_CS_STALL |
+PIPE_CONTROL_QW_WRITE));
+   intel_ring_emit(engine, intel_hws_seqno_address(req->engine));
+   intel_ring_emit(engine, 0);
+   intel_ring_emit(engine, i915_gem_request_get_seqno(req));
+   /* We're thrashing one dword of HWS. */
+   intel_ring_emit(engine, 0);
+   intel_ring_emit(engine, MI_USER_INTERRUPT);
+   intel_ring_emit(engine, MI_NOOP);
+   __intel_ring_advance(engine);
+
+   return 0;
+}
+
 static inline bool i915_gem_has_seqno_wrapped(struct drm_device *dev,
  u32 seqno)
 {
@@ -2751,12 +2780,11 @@ int intel_init_render_ring_buffer(struct drm_device 
*dev)
}
 
engine->init_context = intel_rcs_ctx_init;
-   engine->add_request = gen6_add_request;
+   engine->add_request = gen8_render_add_request;
engine->flush = gen8_render_ring_flush;
engine->irq_get = gen8_ring_get_irq;
engine->irq_put = gen8_ring_put_irq;
engine->irq_enable_mask = GT_RENDER_USER_INTERRUPT;
-   engine->irq_seqno_barrier = gen6_seqno_barrier;
engine->get_seqno = ring_get_seqno;
engine->set_seqno = ring_set_seqno;
if (i915_semaphore_is_enabled(dev)) {
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.h 
b/drivers/gpu/drm/i915/intel_ringbuffer.h
index d7082124eee3..55b0438b2fa1 100644
--- 

[Intel-gfx] [CI 3/7] drm/i915: Fix gen8 semaphores id for legacy mode

2016-04-29 Thread Chris Wilson
With the introduction of a distinct engine->id vs the hardware id, we need
to fix up the value we use for selecting the target engine when signaling
a semaphore. Note that these values can be merged with engine->guc_id.

Fixes: de1add360522c876c25ef2ab1c94bdb509ab
Signed-off-by: Chris Wilson 
Cc: Tvrtko Ursulin 
Cc: Ville Syrjälä 
---
 drivers/gpu/drm/i915/intel_ringbuffer.c | 9 +++--
 drivers/gpu/drm/i915/intel_ringbuffer.h | 3 ++-
 2 files changed, 9 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c 
b/drivers/gpu/drm/i915/intel_ringbuffer.c
index c1472d62b663..ef3468956fae 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.c
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
@@ -1313,7 +1313,7 @@ static int gen8_rcs_signal(struct drm_i915_gem_request 
*signaller_req,
intel_ring_emit(signaller, seqno);
intel_ring_emit(signaller, 0);
intel_ring_emit(signaller, MI_SEMAPHORE_SIGNAL |
-  MI_SEMAPHORE_TARGET(waiter->id));
+  MI_SEMAPHORE_TARGET(waiter->hw_id));
intel_ring_emit(signaller, 0);
}
 
@@ -1353,7 +1353,7 @@ static int gen8_xcs_signal(struct drm_i915_gem_request 
*signaller_req,
intel_ring_emit(signaller, upper_32_bits(gtt_offset));
intel_ring_emit(signaller, seqno);
intel_ring_emit(signaller, MI_SEMAPHORE_SIGNAL |
-  MI_SEMAPHORE_TARGET(waiter->id));
+  MI_SEMAPHORE_TARGET(waiter->hw_id));
intel_ring_emit(signaller, 0);
}
 
@@ -2759,6 +2759,7 @@ int intel_init_render_ring_buffer(struct drm_device *dev)
engine->name = "render ring";
engine->id = RCS;
engine->exec_id = I915_EXEC_RENDER;
+   engine->hw_id = 0;
engine->mmio_base = RENDER_RING_BASE;
 
if (INTEL_INFO(dev)->gen >= 8) {
@@ -2909,6 +2910,7 @@ int intel_init_bsd_ring_buffer(struct drm_device *dev)
engine->name = "bsd ring";
engine->id = VCS;
engine->exec_id = I915_EXEC_BSD;
+   engine->hw_id = 1;
 
engine->write_tail = ring_write_tail;
if (INTEL_INFO(dev)->gen >= 6) {
@@ -2987,6 +2989,7 @@ int intel_init_bsd2_ring_buffer(struct drm_device *dev)
engine->name = "bsd2 ring";
engine->id = VCS2;
engine->exec_id = I915_EXEC_BSD;
+   engine->hw_id = 4;
 
engine->write_tail = ring_write_tail;
engine->mmio_base = GEN8_BSD2_RING_BASE;
@@ -3019,6 +3022,7 @@ int intel_init_blt_ring_buffer(struct drm_device *dev)
engine->name = "blitter ring";
engine->id = BCS;
engine->exec_id = I915_EXEC_BLT;
+   engine->hw_id = 2;
 
engine->mmio_base = BLT_RING_BASE;
engine->write_tail = ring_write_tail;
@@ -3078,6 +3082,7 @@ int intel_init_vebox_ring_buffer(struct drm_device *dev)
engine->name = "video enhancement ring";
engine->id = VECS;
engine->exec_id = I915_EXEC_VEBOX;
+   engine->hw_id = 3;
 
engine->mmio_base = VEBOX_RING_BASE;
engine->write_tail = ring_write_tail;
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.h 
b/drivers/gpu/drm/i915/intel_ringbuffer.h
index 55b0438b2fa1..723ff6160fbb 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.h
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.h
@@ -153,7 +153,8 @@ struct  intel_engine_cs {
 #define I915_NUM_ENGINES 5
 #define _VCS(n) (VCS + (n))
unsigned int exec_id;
-   unsigned int guc_id;
+   unsigned int hw_id;
+   unsigned int guc_id; /* XXX same as hw_id? */
u32 mmio_base;
struct  drm_device *dev;
struct intel_ringbuffer *buffer;
-- 
2.8.1

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/lvds: do not set border bits when panel fitter is not enabled

2016-04-29 Thread Patchwork
== Series Details ==

Series: drm/i915/lvds: do not set border bits when panel fitter is not enabled
URL   : https://patchwork.freedesktop.org/series/6530/
State : success

== Summary ==

Series 6530v1 drm/i915/lvds: do not set border bits when panel fitter is not 
enabled
http://patchwork.freedesktop.org/api/1.0/series/6530/revisions/1/mbox/


bdw-nuci7-2  total:201  pass:189  dwarn:0   dfail:0   fail:0   skip:12 
bdw-ultratotal:201  pass:176  dwarn:0   dfail:0   fail:0   skip:25 
bsw-nuc-2total:200  pass:159  dwarn:0   dfail:0   fail:0   skip:41 
byt-nuc  total:200  pass:159  dwarn:0   dfail:0   fail:0   skip:41 
hsw-brixbox  total:201  pass:175  dwarn:0   dfail:0   fail:0   skip:26 
hsw-gt2  total:201  pass:179  dwarn:0   dfail:0   fail:1   skip:21 
ilk-hp8440p  total:201  pass:140  dwarn:0   dfail:0   fail:0   skip:61 
ivb-t430stotal:201  pass:170  dwarn:0   dfail:0   fail:0   skip:31 
skl-i7k-2total:201  pass:174  dwarn:0   dfail:0   fail:0   skip:27 
skl-nuci5total:201  pass:190  dwarn:0   dfail:0   fail:0   skip:11 
snb-dellxps  total:201  pass:159  dwarn:0   dfail:0   fail:0   skip:42 
snb-x220ttotal:201  pass:159  dwarn:0   dfail:0   fail:1   skip:41 

Results at /archive/results/CI_IGT_test/Patchwork_2111/

1d56af10bdd6f4714e0892c05ff01d11e77f54fc drm-intel-nightly: 
2016y-04m-29d-09h-21m-52s UTC integration manifest
42aec19 drm/i915/lvds: do not set border bits when panel fitter is not enabled

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/gem: support BO freeing without dev->struct_mutex

2016-04-29 Thread Patchwork
== Series Details ==

Series: drm/gem: support BO freeing without dev->struct_mutex
URL   : https://patchwork.freedesktop.org/series/6527/
State : failure

== Summary ==

Series 6527v1 drm/gem: support BO freeing without dev->struct_mutex
http://patchwork.freedesktop.org/api/1.0/series/6527/revisions/1/mbox/

Test drv_getparams_basic:
Subgroup basic-eu-total:
pass   -> DMESG-WARN (bsw-nuc-2)
pass   -> DMESG-WARN (skl-nuci5)
pass   -> DMESG-WARN (bdw-nuci7-2)
pass   -> DMESG-WARN (ivb-t430s)
pass   -> DMESG-WARN (bdw-ultra)
pass   -> DMESG-WARN (skl-i7k-2)
pass   -> DMESG-WARN (byt-nuc)
pass   -> DMESG-WARN (snb-x220t)
pass   -> DMESG-WARN (snb-dellxps)
pass   -> DMESG-WARN (hsw-brixbox)
pass   -> DMESG-WARN (ilk-hp8440p)
Subgroup basic-subslice-total:
pass   -> DMESG-WARN (bsw-nuc-2)
pass   -> DMESG-WARN (skl-nuci5)
pass   -> DMESG-WARN (bdw-nuci7-2)
pass   -> DMESG-WARN (ivb-t430s)
pass   -> DMESG-WARN (bdw-ultra)
pass   -> DMESG-WARN (skl-i7k-2)
pass   -> DMESG-WARN (byt-nuc)
pass   -> DMESG-WARN (snb-x220t)
pass   -> DMESG-WARN (snb-dellxps)
pass   -> DMESG-WARN (hsw-brixbox)
pass   -> DMESG-WARN (ilk-hp8440p)
Test drv_hangman:
Subgroup error-state-basic:
pass   -> DMESG-WARN (bsw-nuc-2)
pass   -> DMESG-WARN (hsw-gt2)
pass   -> DMESG-WARN (bdw-nuci7-2)
pass   -> DMESG-WARN (ivb-t430s)
pass   -> DMESG-WARN (bdw-ultra)
pass   -> DMESG-WARN (skl-i7k-2)
pass   -> DMESG-WARN (byt-nuc)
pass   -> DMESG-WARN (snb-x220t)
pass   -> DMESG-WARN (snb-dellxps)
pass   -> DMESG-WARN (hsw-brixbox)
pass   -> DMESG-WARN (ilk-hp8440p)
Test drv_module_reload_basic:
pass   -> DMESG-WARN (bsw-nuc-2)
pass   -> DMESG-WARN (bdw-nuci7-2)
pass   -> DMESG-WARN (ivb-t430s)
pass   -> DMESG-WARN (bdw-ultra)
pass   -> DMESG-WARN (skl-i7k-2)
pass   -> DMESG-WARN (byt-nuc)
pass   -> DMESG-WARN (snb-x220t)
pass   -> DMESG-WARN (snb-dellxps)
pass   -> DMESG-WARN (hsw-brixbox)
pass   -> DMESG-WARN (ilk-hp8440p)
Test gem_basic:
Subgroup bad-close:
pass   -> DMESG-WARN (bsw-nuc-2)
pass   -> DMESG-WARN (skl-nuci5)
pass   -> DMESG-WARN (bdw-nuci7-2)
pass   -> DMESG-WARN (ivb-t430s)
pass   -> DMESG-WARN (bdw-ultra)
pass   -> DMESG-WARN (skl-i7k-2)
pass   -> DMESG-WARN (byt-nuc)
pass   -> DMESG-WARN (snb-x220t)
pass   -> DMESG-WARN (snb-dellxps)
pass   -> DMESG-WARN (hsw-brixbox)
pass   -> DMESG-WARN (ilk-hp8440p)
Subgroup create-close:
pass   -> DMESG-WARN (bsw-nuc-2)
pass   -> DMESG-WARN (bdw-nuci7-2)
pass   -> DMESG-WARN (ivb-t430s)
pass   -> DMESG-WARN (bdw-ultra)
pass   -> DMESG-WARN (skl-i7k-2)
pass   -> DMESG-WARN (byt-nuc)
pass   -> DMESG-WARN (snb-x220t)
pass   -> DMESG-WARN (snb-dellxps)
pass   -> DMESG-WARN (hsw-brixbox)
pass   -> DMESG-WARN (ilk-hp8440p)
Subgroup create-fd-close:
pass   -> DMESG-WARN (bsw-nuc-2)
pass   -> DMESG-WARN (skl-nuci5)
pass   -> DMESG-WARN (bdw-nuci7-2)
pass   -> DMESG-WARN (ivb-t430s)
pass   -> DMESG-WARN (bdw-ultra)
pass   -> DMESG-WARN (skl-i7k-2)
pass   -> DMESG-WARN (byt-nuc)
pass   -> DMESG-WARN (snb-x220t)
pass   -> DMESG-WARN (snb-dellxps)
pass   -> DMESG-WARN (hsw-brixbox)
pass   -> DMESG-WARN (ilk-hp8440p)
Test gem_busy:
Subgroup basic-blt:
pass   -> DMESG-WARN (bsw-nuc-2)
pass   -> DMESG-WARN (skl-nuci5)
pass   -> DMESG-WARN (bdw-nuci7-2)
pass   -> DMESG-WARN (hsw-gt2)
pass   -> DMESG-WARN (bdw-ultra)
pass   -> DMESG-WARN (skl-i7k-2)
pass 

Re: [Intel-gfx] [PATCH 11/12] drm/i915: Extend GET_APERTURE ioctl to report available map space

2016-04-29 Thread Chris Wilson
On Fri, Apr 29, 2016 at 11:56:28AM +0100, Tvrtko Ursulin wrote:
> 
> On 29/04/16 11:39, Chris Wilson wrote:
> >On Fri, Apr 29, 2016 at 11:26:45AM +0100, Tvrtko Ursulin wrote:
> >>
> >>On 29/04/16 11:18, Chris Wilson wrote:
> >>>On Fri, Apr 29, 2016 at 11:06:49AM +0100, Tvrtko Ursulin wrote:
> I don't get it - if we are adding something why not add it in a way
> that makes it clear and self-contained - what is the downside of
> what I propose to meet such resistance?
> >>>
> >>>You're suggesting to add a field I'm not going to use. Is any one?
> >>>Until there is an actual use (which would afaict be if one of the
> >>>existing values changed meaning, which itself would be an abi break) I'm
> >>>not convinced we should be designing for the unknowable. If we did need
> >>>to version would we not be better off with a new ioctl?
> >>
> >>I am suggesting if we are adding aper_total_size, or whatever it is
> >>called, to make it usable in an self-contained matter.
> >>
> >>My impression was you want aper_total_size so I was simply objecting
> >>to adding it without being able to directly tell if kernel actually
> >>supports that extension.
> >
> >The two additions that I thought we have reduced it to:
> >
> > u64 mappable_aperture_size
> > u64 stolen_size;
> >
> >Of which I agree that the first has some ambiguity over 0. But I don't
> >think it makes a difference in practice. I for one would not bother with
> >checking a version. I already have a cascade here to deal with not being
> >able to use various probes, with an eventual fallback to a safe value.
> >
> >We know the mappable_aperture_size cannot be zero with the exception
> >that the device is disabled - but we have opened the device already.
> 
> Since you agree there is ambiguity lets just add a version. You
> don't have to use it, but someone will.
> 
>   u32 version; // == 1
>   u64 mappable_aperture_size;
> 
> And then it is clear and self-contained.

u64 version;

or

u32 version;
u32 flags;

uABI fields need to be naturally aligned.

Hah, you didn't mention the trump card you pulled on IRC. In light of
that issue ever being a problem (that we may be faced with 0 aperture),
yes.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH 02/10] drm/i915: Fix ordering of sanitize ppgtt and sanitize execlists

2016-04-29 Thread Joonas Lahtinen
On to, 2016-04-28 at 17:24 +0100, Chris Wilson wrote:
> The i915.enable_ppgtt option depends upon the state of
> i915.enable_execlists option - so we need to sanitize execlists first.
> 

Reviewed-by: Joonas Lahtinen 

> Signed-off-by: Chris Wilson 
> ---
>  drivers/gpu/drm/i915/i915_dma.c | 13 +
>  drivers/gpu/drm/i915/i915_drv.h |  2 ++
>  drivers/gpu/drm/i915/i915_gem.c |  3 ---
>  drivers/gpu/drm/i915/i915_gem_gtt.c | 16 +---
>  drivers/gpu/drm/i915/intel_lrc.c|  2 --
>  5 files changed, 20 insertions(+), 16 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
> index f69330cf0118..c91387f1aedd 100644
> --- a/drivers/gpu/drm/i915/i915_dma.c
> +++ b/drivers/gpu/drm/i915/i915_dma.c
> @@ -968,6 +968,19 @@ static void intel_device_info_runtime_init(struct 
> drm_device *dev)
>    info->has_subslice_pg ? "y" : "n");
>   DRM_DEBUG_DRIVER("has EU power gating: %s\n",
>    info->has_eu_pg ? "y" : "n");
> +
> + i915.enable_execlists =
> + intel_sanitize_enable_execlists(dev, i915.enable_execlists);
> +
> + /*
> +  * i915.enable_ppgtt is read-only, so do an early pass to validate the
> +  * user's requested state against the hardware/driver capabilities.  We
> +  * do this now so that we can print out any log messages once rather
> +  * than every time we check intel_enable_ppgtt().
> +  */
> + i915.enable_ppgtt =
> + intel_sanitize_enable_ppgtt(dev, i915.enable_ppgtt);
> + DRM_DEBUG_DRIVER("ppgtt mode: %i\n", i915.enable_ppgtt);
>  }
>  
>  static void intel_init_dpio(struct drm_i915_private *dev_priv)
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index e2abbcc27f2c..17f22009f2b3 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -2753,6 +2753,8 @@ extern int i915_max_ioctl;
>  extern int i915_suspend_switcheroo(struct drm_device *dev, pm_message_t 
> state);
>  extern int i915_resume_switcheroo(struct drm_device *dev);
>  
> +int intel_sanitize_enable_ppgtt(struct drm_device *dev, int enable_ppgtt);
> +
>  /* i915_dma.c */
>  void __printf(3, 4)
>  __i915_printk(struct drm_i915_private *dev_priv, const char *level,
> diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
> index 96fbc9ab4039..bd6061f177fe 100644
> --- a/drivers/gpu/drm/i915/i915_gem.c
> +++ b/drivers/gpu/drm/i915/i915_gem.c
> @@ -4901,9 +4901,6 @@ int i915_gem_init(struct drm_device *dev)
>   struct drm_i915_private *dev_priv = dev->dev_private;
>   int ret;
>  
> - i915.enable_execlists = intel_sanitize_enable_execlists(dev,
> - i915.enable_execlists);
> -
>   mutex_lock(>struct_mutex);
>  
>   if (!i915.enable_execlists) {
> diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c 
> b/drivers/gpu/drm/i915/i915_gem_gtt.c
> index 59a78f760b6b..364cf8236021 100644
> --- a/drivers/gpu/drm/i915/i915_gem_gtt.c
> +++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
> @@ -110,7 +110,7 @@ const struct i915_ggtt_view i915_ggtt_view_rotated = {
>   .type = I915_GGTT_VIEW_ROTATED,
>  };
>  
> -static int sanitize_enable_ppgtt(struct drm_device *dev, int enable_ppgtt)
> +int intel_sanitize_enable_ppgtt(struct drm_device *dev, int enable_ppgtt)
>  {
>   bool has_aliasing_ppgtt;
>   bool has_full_ppgtt;
> @@ -123,12 +123,14 @@ static int sanitize_enable_ppgtt(struct drm_device 
> *dev, int enable_ppgtt)
>   if (intel_vgpu_active(dev))
>   has_full_ppgtt = false; /* emulation is too hard */
>  
> + if (!has_aliasing_ppgtt)
> + return 0;
> +
>   /*
>    * We don't allow disabling PPGTT for gen9+ as it's a requirement for
>    * execlists, the sole mechanism available to submit work.
>    */
> - if (INTEL_INFO(dev)->gen < 9 &&
> - (enable_ppgtt == 0 || !has_aliasing_ppgtt))
> + if (enable_ppgtt == 0 && INTEL_INFO(dev)->gen < 9)
>   return 0;
>  
>   if (enable_ppgtt == 1)
> @@ -3219,14 +3221,6 @@ int i915_ggtt_init_hw(struct drm_device *dev)
>   if (intel_iommu_gfx_mapped)
>   DRM_INFO("VT-d active for gfx access\n");
>  #endif
> - /*
> -  * i915.enable_ppgtt is read-only, so do an early pass to validate the
> -  * user's requested state against the hardware/driver capabilities.  We
> -  * do this now so that we can print out any log messages once rather
> -  * than every time we check intel_enable_ppgtt().
> -  */
> - i915.enable_ppgtt = sanitize_enable_ppgtt(dev, i915.enable_ppgtt);
> - DRM_DEBUG_DRIVER("ppgtt mode: %i\n", i915.enable_ppgtt);
>  
>   return 0;
>  
> diff --git a/drivers/gpu/drm/i915/intel_lrc.c 
> b/drivers/gpu/drm/i915/intel_lrc.c
> index 874c2515f9d4..4c832f90fe49 100644
> --- a/drivers/gpu/drm/i915/intel_lrc.c
> +++ 

Re: [Intel-gfx] [PATCH 11/12] drm/i915: Extend GET_APERTURE ioctl to report available map space

2016-04-29 Thread Tvrtko Ursulin


On 29/04/16 11:39, Chris Wilson wrote:

On Fri, Apr 29, 2016 at 11:26:45AM +0100, Tvrtko Ursulin wrote:


On 29/04/16 11:18, Chris Wilson wrote:

On Fri, Apr 29, 2016 at 11:06:49AM +0100, Tvrtko Ursulin wrote:

I don't get it - if we are adding something why not add it in a way
that makes it clear and self-contained - what is the downside of
what I propose to meet such resistance?


You're suggesting to add a field I'm not going to use. Is any one?
Until there is an actual use (which would afaict be if one of the
existing values changed meaning, which itself would be an abi break) I'm
not convinced we should be designing for the unknowable. If we did need
to version would we not be better off with a new ioctl?


I am suggesting if we are adding aper_total_size, or whatever it is
called, to make it usable in an self-contained matter.

My impression was you want aper_total_size so I was simply objecting
to adding it without being able to directly tell if kernel actually
supports that extension.


The two additions that I thought we have reduced it to:

u64 mappable_aperture_size
u64 stolen_size;

Of which I agree that the first has some ambiguity over 0. But I don't
think it makes a difference in practice. I for one would not bother with
checking a version. I already have a cascade here to deal with not being
able to use various probes, with an eventual fallback to a safe value.

We know the mappable_aperture_size cannot be zero with the exception
that the device is disabled - but we have opened the device already.


Since you agree there is ambiguity lets just add a version. You don't 
have to use it, but someone will.


u32 version; // == 1
u64 mappable_aperture_size;

And then it is clear and self-contained.

Regards,

Tvrtko
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH 11/12] drm/i915: Extend GET_APERTURE ioctl to report available map space

2016-04-29 Thread Chris Wilson
On Fri, Apr 29, 2016 at 11:26:45AM +0100, Tvrtko Ursulin wrote:
> 
> On 29/04/16 11:18, Chris Wilson wrote:
> >On Fri, Apr 29, 2016 at 11:06:49AM +0100, Tvrtko Ursulin wrote:
> >>I don't get it - if we are adding something why not add it in a way
> >>that makes it clear and self-contained - what is the downside of
> >>what I propose to meet such resistance?
> >
> >You're suggesting to add a field I'm not going to use. Is any one?
> >Until there is an actual use (which would afaict be if one of the
> >existing values changed meaning, which itself would be an abi break) I'm
> >not convinced we should be designing for the unknowable. If we did need
> >to version would we not be better off with a new ioctl?
> 
> I am suggesting if we are adding aper_total_size, or whatever it is
> called, to make it usable in an self-contained matter.
> 
> My impression was you want aper_total_size so I was simply objecting
> to adding it without being able to directly tell if kernel actually
> supports that extension.

The two additions that I thought we have reduced it to:

u64 mappable_aperture_size
u64 stolen_size;

Of which I agree that the first has some ambiguity over 0. But I don't
think it makes a difference in practice. I for one would not bother with
checking a version. I already have a cascade here to deal with not being
able to use various probes, with an eventual fallback to a safe value.

We know the mappable_aperture_size cannot be zero with the exception
that the device is disabled - but we have opened the device already.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] i915 ERRORs and WARN_ON()s

2016-04-29 Thread David Weinehall
On Fri, Apr 29, 2016 at 04:27:08AM +0200, Florian Zumbiehl wrote:
> Hi,
> 
> > The Bugzilla at https://bugs.freedesktop.org is our tool of choice for
> > tracking bugs in drm/i915. It's your choice to not create an account
> > there, but please, don't expect us to work as a proxy between you and
> > bugzilla either. It's a much bigger and unscalable inconvenience for us
> > than it is for you to create that account.
> 
> Hu? I don't quite get it. Communicating via email is an unscalable
> inconvenience? So, if I asked you to create an account with my todo tracker
> instead, would that be more scalable and convenient? Using everyone's
> software of choice instead of my own most certainly is neither scalable nor
> convenient for me at all.

I think you're missing the point here. First of all, your bug report
isn't the only bug report. If all bug reports were posted here rather
than reported in our bug tracker, it would definitely be more likely
that some bugs would get lost. It works for small projects with a low
influx of bug reports, but it's less convenient for larger projects.
This is the scalability factor.

Second of all, convenience. Your convenience, while of course a
consideration, isn't the primary concern. The convenience of the
developers is.  You're reporting one bug, but the developers here
have to keep track of, and fix, hundreds (and that's on top of
new features, support for new platforms, test cases, and performance
improvements).

If we were asking for support for software you develop, you'd obviously
be the one to set the rules (and yes, that includes your TODO tracker,
closed forums or what not). Reporting bugs in a bug tracking system
isn't exactly a novelty. Rather the opposite.


Kind regards, David Weinehall
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH 11/12] drm/i915: Extend GET_APERTURE ioctl to report available map space

2016-04-29 Thread Tvrtko Ursulin


On 29/04/16 11:18, Chris Wilson wrote:

On Fri, Apr 29, 2016 at 11:06:49AM +0100, Tvrtko Ursulin wrote:

I don't get it - if we are adding something why not add it in a way
that makes it clear and self-contained - what is the downside of
what I propose to meet such resistance?


You're suggesting to add a field I'm not going to use. Is any one?
Until there is an actual use (which would afaict be if one of the
existing values changed meaning, which itself would be an abi break) I'm
not convinced we should be designing for the unknowable. If we did need
to version would we not be better off with a new ioctl?


I am suggesting if we are adding aper_total_size, or whatever it is 
called, to make it usable in an self-contained matter.


My impression was you want aper_total_size so I was simply objecting to 
adding it without being able to directly tell if kernel actually 
supports that extension.


Regards,

Tvrtko

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH v2] drm/i915/execlists: Refactor common engine setup

2016-04-29 Thread Chris Wilson
On Fri, Apr 29, 2016 at 11:11:20AM +0100, Tvrtko Ursulin wrote:
> 
> On 29/04/16 11:00, Chris Wilson wrote:
> >On Fri, Apr 29, 2016 at 10:50:02AM +0100, Tvrtko Ursulin wrote:
> >>
> >>On 29/04/16 10:39, Chris Wilson wrote:
> >>>On Fri, Apr 29, 2016 at 10:25:41AM +0100, Tvrtko Ursulin wrote:
> On 29/04/16 10:15, Chris Wilson wrote:
> >diff --git a/drivers/gpu/drm/i915/intel_lrc.c 
> >b/drivers/gpu/drm/i915/intel_lrc.c
> >index 2e0eaa9fa240..2c94072ab085 100644
> >--- a/drivers/gpu/drm/i915/intel_lrc.c
> >+++ b/drivers/gpu/drm/i915/intel_lrc.c
> >@@ -2016,14 +2016,17 @@ logical_ring_setup(struct drm_device *dev, enum 
> >intel_engine_id id)
> > struct intel_engine_cs *engine = _priv->engine[id];
> > enum forcewake_domains fw_domains;
> >
> >-   engine->dev = dev;
> >-
> > engine->id = id;
> > engine->name = info->name;
> > engine->exec_id = info->exec_id;
> > engine->guc_id = info->guc_id;
> > engine->mmio_base = info->mmio_base;
> >
> >+   /* disable interrupts to this engine before we install 
> >ourselves*/
> >+   I915_WRITE_IMR(engine, ~0);
> >+
> >+   engine->dev = dev;
> >+
> > /* Intentionally left blank. */
> > engine->buffer = NULL;
> >
> >Make sense?
> 
> Not the most elegant because all the hw access we have so far is in
> engine->init_hw. Why can't we just make intel_engine_initialized
> return false until the very last thing in engine constructors?
> >>>
> >>>In my defence sanitizing the hw before we are ready is common practice
> >>>across the driver. The unfun part is that irq install is before gem_init
> >>>(because modeset init wants irq enabled for GMBUS/dp-aux). gem init
> >>>itself could be split up and moved around so that the setup and init_hw
> >>>phases are separate (which would be next on the init ordering hitlist I
> >>>hope).
> >>>
> >>>I want engine->dev/engine->i915 set early so we can use it during setup
> >>>and init-hw and so that for_each_engine() works as expected in that
> >>>time.
> >>
> >>Why wouldn't an explicit engine->initialized flag solve that? You
> >>could keep setting engine->dev early (as it should be) and then set
> >>engine->initialized at the end of per-engine constructors.
> >
> >Because it becomes irrelevant very shortly. The only interesting
> >question remaining is whether or not we should be sanitizing the IMR
> >first. It has been suggested elsewhere (in Ville's review of the GT
> >interrupt handling) that doing the sanitization would be useful.
> 
> How come it becomes irrelevant? Will there not be
> intel_engine_initialized? Because as long as there is, imho it makes
> sense not to use engine->dev for it.

The only argument here is how to handle an interrupt left over from
before the driver loads. At all other times engine->dev means precisely
that. I do not agree that you need to duplicate the state.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] ✗ Fi.CI.BAT: failure for Support blending modes of display planes (rev2)

2016-04-29 Thread Patchwork
== Series Details ==

Series: Support blending modes of display planes (rev2)
URL   : https://patchwork.freedesktop.org/series/2582/
State : failure

== Summary ==

Series 2582v2 Support blending modes of display planes
http://patchwork.freedesktop.org/api/1.0/series/2582/revisions/2/mbox/

Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-a:
pass   -> INCOMPLETE (hsw-gt2)

bdw-nuci7-2  total:201  pass:189  dwarn:0   dfail:0   fail:0   skip:12 
bdw-ultratotal:201  pass:176  dwarn:0   dfail:0   fail:0   skip:25 
bsw-nuc-2total:200  pass:159  dwarn:0   dfail:0   fail:0   skip:41 
byt-nuc  total:200  pass:159  dwarn:0   dfail:0   fail:0   skip:41 
hsw-brixbox  total:201  pass:175  dwarn:0   dfail:0   fail:0   skip:26 
hsw-gt2  total:151  pass:132  dwarn:0   dfail:0   fail:0   skip:18 
ilk-hp8440p  total:201  pass:140  dwarn:0   dfail:0   fail:0   skip:61 
ivb-t430stotal:201  pass:170  dwarn:0   dfail:0   fail:0   skip:31 
skl-i7k-2total:201  pass:174  dwarn:0   dfail:0   fail:0   skip:27 
snb-dellxps  total:201  pass:159  dwarn:0   dfail:0   fail:0   skip:42 
snb-x220ttotal:201  pass:159  dwarn:0   dfail:0   fail:1   skip:41 

Results at /archive/results/CI_IGT_test/Patchwork_2109/

1d56af10bdd6f4714e0892c05ff01d11e77f54fc drm-intel-nightly: 
2016y-04m-29d-09h-21m-52s UTC integration manifest
f078b1b drm/i915/skl: Add support for blending modes
0910f9d drm: Add an blend_color property
ab2afbf drm: Introduce DRM_MODE_COLOR()
5f3d082 drm/i915/skl: Add blend_func to SKL/BXT sprite planes
2426e80 drm: Introduce the blend-func property

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH 11/12] drm/i915: Extend GET_APERTURE ioctl to report available map space

2016-04-29 Thread Chris Wilson
On Fri, Apr 29, 2016 at 11:06:49AM +0100, Tvrtko Ursulin wrote:
> I don't get it - if we are adding something why not add it in a way
> that makes it clear and self-contained - what is the downside of
> what I propose to meet such resistance?

You're suggesting to add a field I'm not going to use. Is any one?
Until there is an actual use (which would afaict be if one of the
existing values changed meaning, which itself would be an abi break) I'm
not convinced we should be designing for the unknowable. If we did need
to version would we not be better off with a new ioctl? 
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH] drm/i915/lvds: do not set border bits when panel fitter is not enabled

2016-04-29 Thread Ville Syrjälä
On Fri, Apr 29, 2016 at 12:36:35PM +0300, Jani Nikula wrote:
> We also don't read the border bits in i9xx_get_pfit_config() when the
> panel fitter is not enabled, causing the state checker warning:
> 
> [drm:intel_pipe_config_compare [i915]] *ERROR* mismatch in
> gmch_pfit.lvds_border_bits (expected 0x8000, found 0x)
> 
> Cc: Ville Syrjälä 
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=87632
> Signed-off-by: Jani Nikula 
> ---
>  drivers/gpu/drm/i915/intel_panel.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/gpu/drm/i915/intel_panel.c 
> b/drivers/gpu/drm/i915/intel_panel.c
> index 828f0fcaaaf8..67cf2e22ba51 100644
> --- a/drivers/gpu/drm/i915/intel_panel.c
> +++ b/drivers/gpu/drm/i915/intel_panel.c
> @@ -363,6 +363,7 @@ out:
>   if ((pfit_control & PFIT_ENABLE) == 0) {
>   pfit_control = 0;
>   pfit_pgm_ratios = 0;
> + border = 0;

That doesn't seem right. We especially want the border for "center".

>   }
>  
>   /* Make sure pre-965 set dither correctly for 18bpp panels. */
> -- 
> 2.1.4

-- 
Ville Syrjälä
Intel OTC
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH v2] drm/i915/execlists: Refactor common engine setup

2016-04-29 Thread Tvrtko Ursulin


On 29/04/16 11:00, Chris Wilson wrote:

On Fri, Apr 29, 2016 at 10:50:02AM +0100, Tvrtko Ursulin wrote:


On 29/04/16 10:39, Chris Wilson wrote:

On Fri, Apr 29, 2016 at 10:25:41AM +0100, Tvrtko Ursulin wrote:

On 29/04/16 10:15, Chris Wilson wrote:

diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 2e0eaa9fa240..2c94072ab085 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -2016,14 +2016,17 @@ logical_ring_setup(struct drm_device *dev, enum 
intel_engine_id id)
 struct intel_engine_cs *engine = _priv->engine[id];
 enum forcewake_domains fw_domains;

-   engine->dev = dev;
-
 engine->id = id;
 engine->name = info->name;
 engine->exec_id = info->exec_id;
 engine->guc_id = info->guc_id;
 engine->mmio_base = info->mmio_base;

+   /* disable interrupts to this engine before we install ourselves*/
+   I915_WRITE_IMR(engine, ~0);
+
+   engine->dev = dev;
+
 /* Intentionally left blank. */
 engine->buffer = NULL;

Make sense?


Not the most elegant because all the hw access we have so far is in
engine->init_hw. Why can't we just make intel_engine_initialized
return false until the very last thing in engine constructors?


In my defence sanitizing the hw before we are ready is common practice
across the driver. The unfun part is that irq install is before gem_init
(because modeset init wants irq enabled for GMBUS/dp-aux). gem init
itself could be split up and moved around so that the setup and init_hw
phases are separate (which would be next on the init ordering hitlist I
hope).

I want engine->dev/engine->i915 set early so we can use it during setup
and init-hw and so that for_each_engine() works as expected in that
time.


Why wouldn't an explicit engine->initialized flag solve that? You
could keep setting engine->dev early (as it should be) and then set
engine->initialized at the end of per-engine constructors.


Because it becomes irrelevant very shortly. The only interesting
question remaining is whether or not we should be sanitizing the IMR
first. It has been suggested elsewhere (in Ville's review of the GT
interrupt handling) that doing the sanitization would be useful.


How come it becomes irrelevant? Will there not be 
intel_engine_initialized? Because as long as there is, imho it makes 
sense not to use engine->dev for it.


Regards,

Tvrtko
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH 11/12] drm/i915: Extend GET_APERTURE ioctl to report available map space

2016-04-29 Thread Tvrtko Ursulin


On 28/04/16 11:24, Chris Wilson wrote:

On Thu, Apr 28, 2016 at 10:30:32AM +0100, Tvrtko Ursulin wrote:


On 26/04/16 10:44, Chris Wilson wrote:

On Mon, Apr 25, 2016 at 03:51:09PM +0100, Tvrtko Ursulin wrote:


On 25/04/16 11:35, Ankitprasad Sharma wrote:

On Thu, 2016-04-21 at 15:59 +0100, Tvrtko Ursulin wrote:

On 21/04/16 15:46, Chris Wilson wrote:

On Thu, Apr 21, 2016 at 03:04:52PM +0100, Tvrtko Ursulin wrote:


Hi,

On 20/04/16 12:17, ankitprasad.r.sha...@intel.com wrote:

+   mutex_unlock(>struct_mutex);
+
+   seq_printf(m, "Total size of the GTT: %llu bytes\n",
+  arg.aper_size);
+   seq_printf(m, "Available space in the GTT: %llu bytes\n",
+  arg.aper_available_size);
+   seq_printf(m, "Total space in the mappable aperture: %llu bytes\n",
+  arg.map_total_size);
+   seq_printf(m, "Available space in the mappable aperture: %llu bytes\n",
+  map_space);
+   seq_printf(m, "Single largest space in the mappable aperture: %llu 
bytes\n",
+  map_largest);
+   seq_printf(m, "Available space for fences: %llu bytes\n",
+  fence_space);
+   seq_printf(m, "Single largest fence available: %llu bytes\n",
+  fence_largest);
+
+   return 0;
+}
+


In general I find this a lot of code for a feature of questionable
utility. As such I would prefer someone really stated the need for
this and explained how it really is useful - even though whetever
number they get from this may be completely irrelevant by the time
it is acted upon.


Yes, with the exception of the size of the mappable aperture, this is
really is debug info. It will get automatically dumped by userspace
when it sees an ENOSPC, and that may prove enough to solve the riddle of
why it failed. However, this information is terrible outdated and now
longer of such relevance.

As for the mappable aperture size, there has been a request many years
ago! could we provide it without resorting to a privilege operation. I
guess by know that request has died out - but there is still the issue
with libpciassess that make it unsuitable for use inside a library where
one may want to avoid it and use a simple ioctl on the device you
already have open.

Yes, it is meh.


Aperture size in the ioctl is fine I think, just that detection caveat
what I asked in the other reply.

Here I wanted to suggest dropping all the non-trivial debugfs stuff and
just leave the info queried via i915_gem_get_aperture ioctl. So
effectively dropping the list traversal and vma sorting bits.


I think, debug info regarding the mappable space is good to have for
debugging purpose as Chris mentioned.
Also, the list traversal and the vma sorting stuff will only be called
for debugging purposes, not slowing anything down or so.


I am pretty indifferent on the topic of debugfs edition.

But for the ioctl extension, how about adding a version field as the
first one in the extended area?


A version number only makes sense when you are changing the meaning of
an existing field. Adding one implies that we are planning to do so, are
we?

In the scenarios, I've run through I haven't found one where a caller
would behave any differently faced with "0 - ioctl version not
supported" and "0 - no available space (mappable/stolen)". Adding a
version doesn't help using the new fields afaict. The argument is the
same as whether a flags field is forward thinking or unthinkingly
forward.


I was thinking that if 0 = no aperture or ioctl not supported
userspace has to try one mmap_gtt to find out which is true, will it
be ENODEV or ENOSPC (assuming, haven't checked). If we put a version
in there then it can avoid doing that. Sounds like a better
interface to me and I don't see any downsides to it.


I was thinking either userspace already cares and has a method for
finding the size of the PCI memory region or it doesn't. If it doesn't
and the ioctl reports 0 and its older second method fails with EPERM/EACCESS
then it is no worse off than before.


I don't get it - if we are adding something why not add it in a way that 
makes it clear and self-contained - what is the downside of what I 
propose to meet such resistance?


Regards,

Tvrtko
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCHv2 1/5] drm: Introduce the blend-func property

2016-04-29 Thread Ville Syrjälä
On Fri, Apr 29, 2016 at 02:59:13PM +0530, Vandita Kulkarni wrote:
> From: Damien Lespiau 
> 
> We'd like to be able to program the blending modes of display planes.
> Ville suggested to use something similar to the GL blend states, which
> does seem like a good idea.
> 
> For now, we only consider blend factors, but room is left for
> extensions: blend equation, separate rgb/alpha blend factors, blend
> color.
> 
> V2: Added the belnd func property support in get property.
> 
> Suggested-by: Ville Syrjälä 
> Signed-off-by: Damien Lespiau 
> Signed-off-by: Vandita Kulkarni 
> ---
>  Documentation/DocBook/gpu.tmpl | 11 +--
>  drivers/gpu/drm/drm_atomic.c   | 14 ++
>  drivers/gpu/drm/drm_crtc.c |  5 +
>  include/drm/drm_crtc.h | 20 
>  4 files changed, 48 insertions(+), 2 deletions(-)
> 
> diff --git a/Documentation/DocBook/gpu.tmpl b/Documentation/DocBook/gpu.tmpl
> index 1464fb2..f673989 100644
> --- a/Documentation/DocBook/gpu.tmpl
> +++ b/Documentation/DocBook/gpu.tmpl
> @@ -1816,7 +1816,7 @@ void intel_crt_init(struct drm_device *dev)
>   Description/Restrictions
>   
>   
> - DRM
> + DRM
>   Generic
>   “rotation”
>   BITMASK
> @@ -1868,7 +1868,7 @@ void intel_crt_init(struct drm_device *dev)
>   CRTC that connector is attached to (atomic)
>   
>   
> - Plane
> + Plane
>   “type”
>   ENUM | IMMUTABLE
>   { "Overlay", "Primary", "Cursor" }
> @@ -1946,6 +1946,13 @@ void intel_crt_init(struct drm_device *dev)
>   CRTC that plane is attached to (atomic)
>   
>   
> + “blend_func”
> + None
> + DRM_BLEND_FUNC()
> + Plane
> + Source and destination blending factors
> + 
> + 
>   DVI-I
>   “subconnector”
>   ENUM
> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> index 8ee1db8..c2ead2d 100644
> --- a/drivers/gpu/drm/drm_atomic.c
> +++ b/drivers/gpu/drm/drm_atomic.c
> @@ -701,6 +701,18 @@ int drm_atomic_plane_set_property(struct drm_plane 
> *plane,
>   state->src_h = val;
>   } else if (property == config->rotation_property) {
>   state->rotation = val;
> + } else if (property == config->prop_blend_func) {
> + enum drm_blend_factor src_factor, dst_factor;
> +
> + src_factor = DRM_BLEND_FUNC_SRC_FACTOR(val);
> + dst_factor = DRM_BLEND_FUNC_DST_FACTOR(val);
> +
> + if (src_factor != dst_factor &&
> + (src_factor == DRM_BLEND_FACTOR_AUTO ||
> + dst_factor == DRM_BLEND_FACTOR_AUTO))
> + return -EINVAL;
> +
> + state->blend_mode.func = val & GENMASK(31, 0);
>   } else if (plane->funcs->atomic_set_property) {
>   return plane->funcs->atomic_set_property(plane, state,
>   property, val);
> @@ -757,6 +769,8 @@ drm_atomic_plane_get_property(struct drm_plane *plane,
>   *val = state->src_h;
>   } else if (property == config->rotation_property) {
>   *val = state->rotation;
> + } else if (property == config->prop_blend_func) {
> + *val = state->blend_mode.func;
>   } else if (plane->funcs->atomic_get_property) {
>   return plane->funcs->atomic_get_property(plane, state, 
> property, val);
>   } else {
> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> index f7fe9e1..2cac5e1 100644
> --- a/drivers/gpu/drm/drm_crtc.c
> +++ b/drivers/gpu/drm/drm_crtc.c
> @@ -1587,6 +1587,11 @@ static int drm_mode_create_standard_properties(struct 
> drm_device *dev)
>   return -ENOMEM;
>   dev->mode_config.gamma_lut_size_property = prop;
>  
> + prop = drm_property_create_range(dev, 0, "blend_func", 0, U32_MAX);
> + if (!prop)
> + return -ENOMEM;
> + dev->mode_config.prop_blend_func = prop;
> +
>   return 0;
>  }
>  
> diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
> index 6d46842..269f660 100644
> --- a/include/drm/drm_crtc.h
> +++ b/include/drm/drm_crtc.h
> @@ -89,6 +89,23 @@ static inline uint64_t I642U64(int64_t val)
>  #define DRM_REFLECT_X4
>  #define DRM_REFLECT_Y5
>  
> +enum drm_blend_factor {
> + DRM_BLEND_FACTOR_AUTO,
> + DRM_BLEND_FACTOR_ZERO,
> + DRM_BLEND_FACTOR_ONE,
> + DRM_BLEND_FACTOR_SRC_ALPHA,
> + DRM_BLEND_FACTOR_ONE_MINUS_SRC_ALPHA,

Based on what I remember of the earlier discussion I don't think these
are quite enough. We could want some way to deal with the constant alpha
as well. Hmm. I think I need to refresh my brain a bit on this before I
can say anything really.

Also IIRC I was thinking that the premult vs. non-premult would be a
separate thing outside the blend equation. That's how we have it some
hw at least AFAIK, so be shoving it all 

Re: [Intel-gfx] [PATCH v2] drm/i915/execlists: Refactor common engine setup

2016-04-29 Thread Chris Wilson
On Fri, Apr 29, 2016 at 10:50:02AM +0100, Tvrtko Ursulin wrote:
> 
> On 29/04/16 10:39, Chris Wilson wrote:
> >On Fri, Apr 29, 2016 at 10:25:41AM +0100, Tvrtko Ursulin wrote:
> >>On 29/04/16 10:15, Chris Wilson wrote:
> >>>diff --git a/drivers/gpu/drm/i915/intel_lrc.c 
> >>>b/drivers/gpu/drm/i915/intel_lrc.c
> >>>index 2e0eaa9fa240..2c94072ab085 100644
> >>>--- a/drivers/gpu/drm/i915/intel_lrc.c
> >>>+++ b/drivers/gpu/drm/i915/intel_lrc.c
> >>>@@ -2016,14 +2016,17 @@ logical_ring_setup(struct drm_device *dev, enum 
> >>>intel_engine_id id)
> >>> struct intel_engine_cs *engine = _priv->engine[id];
> >>> enum forcewake_domains fw_domains;
> >>>
> >>>-   engine->dev = dev;
> >>>-
> >>> engine->id = id;
> >>> engine->name = info->name;
> >>> engine->exec_id = info->exec_id;
> >>> engine->guc_id = info->guc_id;
> >>> engine->mmio_base = info->mmio_base;
> >>>
> >>>+   /* disable interrupts to this engine before we install ourselves*/
> >>>+   I915_WRITE_IMR(engine, ~0);
> >>>+
> >>>+   engine->dev = dev;
> >>>+
> >>> /* Intentionally left blank. */
> >>> engine->buffer = NULL;
> >>>
> >>>Make sense?
> >>
> >>Not the most elegant because all the hw access we have so far is in
> >>engine->init_hw. Why can't we just make intel_engine_initialized
> >>return false until the very last thing in engine constructors?
> >
> >In my defence sanitizing the hw before we are ready is common practice
> >across the driver. The unfun part is that irq install is before gem_init
> >(because modeset init wants irq enabled for GMBUS/dp-aux). gem init
> >itself could be split up and moved around so that the setup and init_hw
> >phases are separate (which would be next on the init ordering hitlist I
> >hope).
> >
> >I want engine->dev/engine->i915 set early so we can use it during setup
> >and init-hw and so that for_each_engine() works as expected in that
> >time.
> 
> Why wouldn't an explicit engine->initialized flag solve that? You
> could keep setting engine->dev early (as it should be) and then set
> engine->initialized at the end of per-engine constructors.

Because it becomes irrelevant very shortly. The only interesting
question remaining is whether or not we should be sanitizing the IMR
first. It has been suggested elsewhere (in Ville's review of the GT
interrupt handling) that doing the sanitization would be useful.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH v2] drm/i915/execlists: Refactor common engine setup

2016-04-29 Thread Tvrtko Ursulin


On 29/04/16 10:39, Chris Wilson wrote:

On Fri, Apr 29, 2016 at 10:25:41AM +0100, Tvrtko Ursulin wrote:

On 29/04/16 10:15, Chris Wilson wrote:

diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 2e0eaa9fa240..2c94072ab085 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -2016,14 +2016,17 @@ logical_ring_setup(struct drm_device *dev, enum 
intel_engine_id id)
 struct intel_engine_cs *engine = _priv->engine[id];
 enum forcewake_domains fw_domains;

-   engine->dev = dev;
-
 engine->id = id;
 engine->name = info->name;
 engine->exec_id = info->exec_id;
 engine->guc_id = info->guc_id;
 engine->mmio_base = info->mmio_base;

+   /* disable interrupts to this engine before we install ourselves*/
+   I915_WRITE_IMR(engine, ~0);
+
+   engine->dev = dev;
+
 /* Intentionally left blank. */
 engine->buffer = NULL;

Make sense?


Not the most elegant because all the hw access we have so far is in
engine->init_hw. Why can't we just make intel_engine_initialized
return false until the very last thing in engine constructors?


In my defence sanitizing the hw before we are ready is common practice
across the driver. The unfun part is that irq install is before gem_init
(because modeset init wants irq enabled for GMBUS/dp-aux). gem init
itself could be split up and moved around so that the setup and init_hw
phases are separate (which would be next on the init ordering hitlist I
hope).

I want engine->dev/engine->i915 set early so we can use it during setup
and init-hw and so that for_each_engine() works as expected in that
time.


Why wouldn't an explicit engine->initialized flag solve that? You could 
keep setting engine->dev early (as it should be) and then set 
engine->initialized at the end of per-engine constructors.


Engine setup would then work fine - I don't see it needed 
for_each_engine or intel_engine_initialized ?


And problem of hw sanitation could then be left out of this 
patch/discussion, no?


Regards,

Tvrtko




___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH v2] drm/i915/execlists: Refactor common engine setup

2016-04-29 Thread Chris Wilson
On Fri, Apr 29, 2016 at 10:25:41AM +0100, Tvrtko Ursulin wrote:
> Not the most elegant because all the hw access we have so far is in
> engine->init_hw. Why can't we just make intel_engine_initialized
> return false until the very last thing in engine constructors?

The other thing I've been mulling over is just making for_each_engine
iterate over the ring_mask. Means the reinstatement of temporary
variables (at least for the macros I've sketched) :(
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH] i915 suspend/resume_noirq instead of suspend_late/resume_early

2016-04-29 Thread Ville Syrjälä
On Wed, Apr 27, 2016 at 11:46:22AM -0700, Todd Brandt wrote:
>  I'd like to propose that we push the i915 suspend_late/resume_early code
>  into suspend_noirq/resume_noirq in order to reduce the total suspend time
>  by ~15ms. According to the comments, when i915_pm_suspend_late was first 
>  added to the kernel back in April 2014, it was done so to ensure that it
>  was called after the snd_hda_intel driver had finished its suspend.
> 
> The comments in i915_drv.c are here:
> 
> /*
>  * We have a suspedn ordering issue with the snd-hda driver also
>  * requiring our device to be power up. Due to the lack of a
>  * parent/child relationship we currently solve this with an late
>  * suspend hook.
>  *
>  * FIXME: This should be solved with a special hdmi sink device or
>  * similar so that power domains can be employed.
>  */
> 
> I believe we could achieve the same ordering by simply pushing it to
> suspend/resume_noirq. Thus we can effectively eliminate the suspend_late
> and resume_early phases altogether in most simple systems. Does anyone see
> a problem with this?
> 
> analyzesuspend outputs for freeze/suspend/hibernate (WITHOUT PATCH):
> https://01org.github.io/suspendresume/i915/freeze-160422-155931-ivybridge-dev-late/
> https://01org.github.io/suspendresume/i915/suspend-160422-155735-ivybridge-dev-late/
> https://01org.github.io/suspendresume/i915/hibernate-160422-163915-ivybridge-dev-late/
> 
> analyzesuspend outputs for freeze/suspend/hibernate (WITH PATCH):
> https://01org.github.io/suspendresume/i915/freeze-160422-162811-ivybridge-dev-noirq/
> https://01org.github.io/suspendresume/i915/suspend-160422-162700-ivybridge-dev-noirq/
> https://01org.github.io/suspendresume/i915/hibernate-160422-162952-ivybridge-dev-noirq/

BTW couple of unrelated observations from this data:

- The boot clock power cycle delay thing *seems* to be working. The
  schedule_timeout() wasn't actually shown in the data, but there were
  cases where the late vs. noirq had a huge difference in resume time.
  I can only assume that's because it spent more time actually suspended
  in one of the cases, and that allowd the power cycle delay to
  be shorter. Would be nice to see these sorts of things
  (wait_remaining_ms_from_jiffies(), wait_panel_status()) explicitly
  in the data.

- we really need to make the display ->detect() async at resume time.
  HDMI live status checks cost a ton of time. I think here too I might
  just suggest injecting a hpd for every connector and let the hpd
  machinery deal with it. Or we just toss out an uncoditional uevent
  and let userspace reprobe? But maybe this is still stuck behind MST
  explosions?

- With async modesets coming perhaps, we should make the resume modeset
  async as well

- We need to parallelize ->detect() for all connectors even from normal
  HPD. Again, HDMI live status checks do add up. The main snag here
  might be gmbus since we only have the one. It has a lock, but I'm not
  sure if it's a bit too low level to do this efficiently. Would need to
  measure it I suppose. I thought we had more gmbus instances on BXT,
  but now I can't find them anywhere, so maybe I was just confusing it
  with blc/pps or something.
  
> 
> Signed-off-by: Todd Brandt 
> ---
>  drivers/gpu/drm/i915/i915_drv.c | 12 ++--
>  1 file changed, 6 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
> index 30798cb..759d93c 100644
> --- a/drivers/gpu/drm/i915/i915_drv.c
> +++ b/drivers/gpu/drm/i915/i915_drv.c
> @@ -1628,8 +1628,8 @@ static const struct dev_pm_ops i915_pm_ops = {
>* PMSG_RESUME]
>*/
>   .suspend = i915_pm_suspend,
> - .suspend_late = i915_pm_suspend_late,
> - .resume_early = i915_pm_resume_early,
> + .suspend_noirq = i915_pm_suspend_late,
> + .resume_noirq = i915_pm_resume_early,
>   .resume = i915_pm_resume,
>  
>   /*
> @@ -1648,12 +1648,12 @@ static const struct dev_pm_ops i915_pm_ops = {
>*hibernation image [PMSG_RESTORE]
>*/
>   .freeze = i915_pm_suspend,
> - .freeze_late = i915_pm_suspend_late,
> - .thaw_early = i915_pm_resume_early,
> + .freeze_noirq = i915_pm_suspend_late,
> + .thaw_noirq = i915_pm_resume_early,
>   .thaw = i915_pm_resume,
>   .poweroff = i915_pm_suspend,
> - .poweroff_late = i915_pm_poweroff_late,
> - .restore_early = i915_pm_resume_early,
> + .poweroff_noirq = i915_pm_poweroff_late,
> + .restore_noirq = i915_pm_resume_early,
>   .restore = i915_pm_resume,
>  
>   /* S0ix (via runtime suspend) event handlers */
> -- 
> 2.1.4
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
Ville Syrjälä
Intel OTC
___
Intel-gfx mailing 

[Intel-gfx] [PATCH] drm/i915/lvds: do not set border bits when panel fitter is not enabled

2016-04-29 Thread Jani Nikula
We also don't read the border bits in i9xx_get_pfit_config() when the
panel fitter is not enabled, causing the state checker warning:

[drm:intel_pipe_config_compare [i915]] *ERROR* mismatch in
gmch_pfit.lvds_border_bits (expected 0x8000, found 0x)

Cc: Ville Syrjälä 
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=87632
Signed-off-by: Jani Nikula 
---
 drivers/gpu/drm/i915/intel_panel.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/i915/intel_panel.c 
b/drivers/gpu/drm/i915/intel_panel.c
index 828f0fcaaaf8..67cf2e22ba51 100644
--- a/drivers/gpu/drm/i915/intel_panel.c
+++ b/drivers/gpu/drm/i915/intel_panel.c
@@ -363,6 +363,7 @@ out:
if ((pfit_control & PFIT_ENABLE) == 0) {
pfit_control = 0;
pfit_pgm_ratios = 0;
+   border = 0;
}
 
/* Make sure pre-965 set dither correctly for 18bpp panels. */
-- 
2.1.4

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH v2] drm/i915/execlists: Refactor common engine setup

2016-04-29 Thread Chris Wilson
On Fri, Apr 29, 2016 at 10:25:41AM +0100, Tvrtko Ursulin wrote:
> On 29/04/16 10:15, Chris Wilson wrote:
> >diff --git a/drivers/gpu/drm/i915/intel_lrc.c 
> >b/drivers/gpu/drm/i915/intel_lrc.c
> >index 2e0eaa9fa240..2c94072ab085 100644
> >--- a/drivers/gpu/drm/i915/intel_lrc.c
> >+++ b/drivers/gpu/drm/i915/intel_lrc.c
> >@@ -2016,14 +2016,17 @@ logical_ring_setup(struct drm_device *dev, enum 
> >intel_engine_id id)
> > struct intel_engine_cs *engine = _priv->engine[id];
> > enum forcewake_domains fw_domains;
> >
> >-   engine->dev = dev;
> >-
> > engine->id = id;
> > engine->name = info->name;
> > engine->exec_id = info->exec_id;
> > engine->guc_id = info->guc_id;
> > engine->mmio_base = info->mmio_base;
> >
> >+   /* disable interrupts to this engine before we install ourselves*/
> >+   I915_WRITE_IMR(engine, ~0);
> >+
> >+   engine->dev = dev;
> >+
> > /* Intentionally left blank. */
> > engine->buffer = NULL;
> >
> >Make sense?
> 
> Not the most elegant because all the hw access we have so far is in
> engine->init_hw. Why can't we just make intel_engine_initialized
> return false until the very last thing in engine constructors?

In my defence sanitizing the hw before we are ready is common practice
across the driver. The unfun part is that irq install is before gem_init
(because modeset init wants irq enabled for GMBUS/dp-aux). gem init
itself could be split up and moved around so that the setup and init_hw
phases are separate (which would be next on the init ordering hitlist I
hope).

I want engine->dev/engine->i915 set early so we can use it during setup
and init-hw and so that for_each_engine() works as expected in that
time.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH 21/21] drm/i915/slpc: Fail intel_runtime_suspend if SLPC or RPS not active

2016-04-29 Thread Imre Deak
On to, 2016-04-28 at 09:00 +0100, Chris Wilson wrote:
> On Thu, Apr 28, 2016 at 10:57:20AM +0300, Imre Deak wrote:
> > On to, 2016-04-28 at 07:56 +0100, Chris Wilson wrote:
> > > On Wed, Apr 27, 2016 at 06:11:05PM -0700, tom.orou...@intel.com
> > > wrote:
> > > > From: Sagar Arun Kamble 
> > > > 
> > > > intel_runtime_suspend failed with warning if RPS was disabled.
> > > > With SLPC enabled, RPS is disabled. With SLPC, warning is now
> > > > changed
> > > > to consider SLPC active status as well. This will ensure
> > > > runtime suspend
> > > > proceeds when SLPC enabled.
> > > > 
> > > > v2: Commit message update. (Tom)
> > > > 
> > > > Signed-off-by: Sagar Arun Kamble 
> > > > Signed-off-by: Tom O'Rourke 
> > > > ---
> > > >  drivers/gpu/drm/i915/i915_drv.c | 3 ++-
> > > >  1 file changed, 2 insertions(+), 1 deletion(-)
> > > > 
> > > > diff --git a/drivers/gpu/drm/i915/i915_drv.c
> > > > b/drivers/gpu/drm/i915/i915_drv.c
> > > > index cc22fa0..00a2713 100644
> > > > --- a/drivers/gpu/drm/i915/i915_drv.c
> > > > +++ b/drivers/gpu/drm/i915/i915_drv.c
> > > > @@ -1474,7 +1474,8 @@ static int intel_runtime_suspend(struct
> > > > device *device)
> > > >     struct drm_i915_private *dev_priv = dev->dev_private;
> > > >     int ret;
> > > >  
> > > > -   if (WARN_ON_ONCE(!(dev_priv->rps.enabled &&
> > > > intel_enable_rc6(dev
> > > > +   if (WARN_ON_ONCE(!((dev_priv->rps.enabled ||
> > > > intel_slpc_active(dev)) &&
> > > > +      intel_enable_rc6(dev
> > > 
> > > The real question here is why does runtime suspend depend on
> > > either of
> > > these being enabled (espcially rps!).
> > 
> > We need RC6 enabled across a runtime suspend/resume since we depend
> > on
> > the RC6 context to be retained across these transitions. There is
> > no
> > separate knob for RPS and we enable RC6 and RPS together, that's
> > why
> > rps.enabled is checked.
> 
> So, from the standpoint of this series, we should be separating the
> two
> and giving rc6 its own bit of bookkeeping.

Yes, separating RC6 and RPS enabling would be the clean way for this
and other purposes too. This patchset enables RC6
from intel_enable_gt_powersave() directly in case SLPC is enabled but
schedules a work for enabling RC6 if SLPC is not enabled. So while the
above works it could be done in a cleaner way.

--Imre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] [PATCH] drm/gem: support BO freeing without dev->struct_mutex

2016-04-29 Thread Daniel Vetter
Finally all the core gem and a lot of drivers are entirely free of
dev->struct_mutex depencies, and we can start to have an entirely
lockless unref path.

To make sure that no one who touches the core code accidentally breaks
existing drivers which still require dev->struct_mutex I've made the
might_lock check unconditional.

While at it de-inline the ref/unref functions, they've become a bit
too big.

v2: Make it not leak like a sieve.

v3: Review from Lucas:
- drop != NULL in pointer checks.
- fixup copypasted kerneldoc to actually match the functions.

v4:
Add __drm_gem_object_unreference as a fastpath helper for drivers who
abolished dev->struct_mutex, requested by Chris.

Cc: Chris Wilson 
Cc: Alex Deucher 
Cc: Lucas Stach 
Reviewed-by: Lucas Stach 
Reviewed-by: Chris Wilson 
Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/drm_gem.c | 54 ++-
 include/drm/drmP.h| 15 ++---
 include/drm/drm_gem.h | 48 +
 3 files changed, 80 insertions(+), 37 deletions(-)

diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
index 25dac31eef37..750d8975c318 100644
--- a/drivers/gpu/drm/drm_gem.c
+++ b/drivers/gpu/drm/drm_gem.c
@@ -806,12 +806,64 @@ drm_gem_object_free(struct kref *kref)
 
WARN_ON(!mutex_is_locked(>struct_mutex));
 
-   if (dev->driver->gem_free_object != NULL)
+   if (dev->driver->gem_free_object_unlocked)
+   dev->driver->gem_free_object_unlocked(obj);
+   else if (dev->driver->gem_free_object)
dev->driver->gem_free_object(obj);
 }
 EXPORT_SYMBOL(drm_gem_object_free);
 
 /**
+ * drm_gem_object_unreference_unlocked - release a GEM BO reference
+ * @obj: GEM buffer object
+ *
+ * This releases a reference to @obj. Callers must not hold the
+ * dev->struct_mutex lock when calling this function.
+ *
+ * See also __drm_gem_object_unreference().
+ */
+void
+drm_gem_object_unreference_unlocked(struct drm_gem_object *obj)
+{
+   struct drm_device *dev;
+
+   if (!obj)
+   return;
+
+   dev = obj->dev;
+   might_lock(>struct_mutex);
+
+   if (dev->driver->gem_free_object)
+   kref_put(>refcount, drm_gem_object_free);
+   else if (kref_put_mutex(>refcount, drm_gem_object_free,
+   >struct_mutex))
+   mutex_unlock(>struct_mutex);
+}
+EXPORT_SYMBOL(drm_gem_object_unreference_unlocked);
+
+/**
+ * drm_gem_object_unreference - release a GEM BO reference
+ * @obj: GEM buffer object
+ *
+ * This releases a reference to @obj. Callers must hold the dev->struct_mutex
+ * lock when calling this function, even when the driver doesn't use
+ * dev->struct_mutex for anything.
+ *
+ * For drivers not encumbered with legacy locking use
+ * drm_gem_object_unreference_unlocked() instead.
+ */
+void
+drm_gem_object_unreference(struct drm_gem_object *obj)
+{
+   if (obj) {
+   WARN_ON(!mutex_is_locked(>dev->struct_mutex));
+
+   kref_put(>refcount, drm_gem_object_free);
+   }
+}
+EXPORT_SYMBOL(drm_gem_object_unreference);
+
+/**
  * drm_gem_vm_open - vma->ops->open implementation for GEM
  * @vma: VM area structure
  *
diff --git a/include/drm/drmP.h b/include/drm/drmP.h
index c81dd2250fc6..bd7b262d7af0 100644
--- a/include/drm/drmP.h
+++ b/include/drm/drmP.h
@@ -580,12 +580,21 @@ struct drm_driver {
void (*debugfs_cleanup)(struct drm_minor *minor);
 
/**
-* Driver-specific constructor for drm_gem_objects, to set up
-* obj->driver_private.
+* @gem_free_object: deconstructor for drm_gem_objects
 *
-* Returns 0 on success.
+* This is deprecated and should not be used by new drivers. Use
+* @gem_free_object_unlocked instead.
 */
void (*gem_free_object) (struct drm_gem_object *obj);
+
+   /**
+* @gem_free_object_unlocked: deconstructor for drm_gem_objects
+*
+* This is for drivers which are not encumbered with dev->struct_mutex
+* legacy locking schemes. Use this hook instead of @gem_free_object.
+*/
+   void (*gem_free_object_unlocked) (struct drm_gem_object *obj);
+
int (*gem_open_object) (struct drm_gem_object *, struct drm_file *);
void (*gem_close_object) (struct drm_gem_object *, struct drm_file *);
 
diff --git a/include/drm/drm_gem.h b/include/drm/drm_gem.h
index 0b3e11ab8757..408d6c47d98b 100644
--- a/include/drm/drm_gem.h
+++ b/include/drm/drm_gem.h
@@ -200,47 +200,29 @@ drm_gem_object_reference(struct drm_gem_object *obj)
 }
 
 /**
- * drm_gem_object_unreference - release a GEM BO reference
+ * __drm_gem_object_unreference - raw function to release a GEM BO reference
  * @obj: GEM buffer object
  *
- * This releases a reference to @obj. Callers 

Re: [Intel-gfx] [PATCH] mfd: intel_soc_pmic_core: Terminate panel control GPIO lookup table correctly

2016-04-29 Thread Linus Walleij
On Fri, Apr 22, 2016 at 9:38 PM,   wrote:

> From: Ville Syrjälä 
>
> GPIO lookup tables are supposed to be zero terminated. Let's do that
> and avoid accidentally walking off the end.
>
> Cc: Shobhit Kumar 
> Cc: Samuel Ortiz 
> Cc: Linus Walleij 
> Cc: Alexandre Courbot 
> Cc: Thierry Reding 
> Cc: Lee Jones 
> Cc: sta...@vger.kernel.org
> Fixes: 61dd2ca2d44e ("mfd: intel_soc_pmic_core: Add lookup table for Panel 
> Control as GPIO signal")
> Signed-off-by: Ville Syrjälä 

Acked-by: Linus Walleij 

Yours,
Linus Walleij
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] [PATCHv2 1/5] drm: Introduce the blend-func property

2016-04-29 Thread Vandita Kulkarni
From: Damien Lespiau 

We'd like to be able to program the blending modes of display planes.
Ville suggested to use something similar to the GL blend states, which
does seem like a good idea.

For now, we only consider blend factors, but room is left for
extensions: blend equation, separate rgb/alpha blend factors, blend
color.

V2: Added the belnd func property support in get property.

Suggested-by: Ville Syrjälä 
Signed-off-by: Damien Lespiau 
Signed-off-by: Vandita Kulkarni 
---
 Documentation/DocBook/gpu.tmpl | 11 +--
 drivers/gpu/drm/drm_atomic.c   | 14 ++
 drivers/gpu/drm/drm_crtc.c |  5 +
 include/drm/drm_crtc.h | 20 
 4 files changed, 48 insertions(+), 2 deletions(-)

diff --git a/Documentation/DocBook/gpu.tmpl b/Documentation/DocBook/gpu.tmpl
index 1464fb2..f673989 100644
--- a/Documentation/DocBook/gpu.tmpl
+++ b/Documentation/DocBook/gpu.tmpl
@@ -1816,7 +1816,7 @@ void intel_crt_init(struct drm_device *dev)
Description/Restrictions


-   DRM
+   DRM
Generic
“rotation”
BITMASK
@@ -1868,7 +1868,7 @@ void intel_crt_init(struct drm_device *dev)
CRTC that connector is attached to (atomic)


-   Plane
+   Plane
“type”
ENUM | IMMUTABLE
{ "Overlay", "Primary", "Cursor" }
@@ -1946,6 +1946,13 @@ void intel_crt_init(struct drm_device *dev)
CRTC that plane is attached to (atomic)


+   “blend_func”
+   None
+   DRM_BLEND_FUNC()
+   Plane
+   Source and destination blending factors
+   
+   
DVI-I
“subconnector”
ENUM
diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index 8ee1db8..c2ead2d 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -701,6 +701,18 @@ int drm_atomic_plane_set_property(struct drm_plane *plane,
state->src_h = val;
} else if (property == config->rotation_property) {
state->rotation = val;
+   } else if (property == config->prop_blend_func) {
+   enum drm_blend_factor src_factor, dst_factor;
+
+   src_factor = DRM_BLEND_FUNC_SRC_FACTOR(val);
+   dst_factor = DRM_BLEND_FUNC_DST_FACTOR(val);
+
+   if (src_factor != dst_factor &&
+   (src_factor == DRM_BLEND_FACTOR_AUTO ||
+   dst_factor == DRM_BLEND_FACTOR_AUTO))
+   return -EINVAL;
+
+   state->blend_mode.func = val & GENMASK(31, 0);
} else if (plane->funcs->atomic_set_property) {
return plane->funcs->atomic_set_property(plane, state,
property, val);
@@ -757,6 +769,8 @@ drm_atomic_plane_get_property(struct drm_plane *plane,
*val = state->src_h;
} else if (property == config->rotation_property) {
*val = state->rotation;
+   } else if (property == config->prop_blend_func) {
+   *val = state->blend_mode.func;
} else if (plane->funcs->atomic_get_property) {
return plane->funcs->atomic_get_property(plane, state, 
property, val);
} else {
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index f7fe9e1..2cac5e1 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -1587,6 +1587,11 @@ static int drm_mode_create_standard_properties(struct 
drm_device *dev)
return -ENOMEM;
dev->mode_config.gamma_lut_size_property = prop;
 
+   prop = drm_property_create_range(dev, 0, "blend_func", 0, U32_MAX);
+   if (!prop)
+   return -ENOMEM;
+   dev->mode_config.prop_blend_func = prop;
+
return 0;
 }
 
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index 6d46842..269f660 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -89,6 +89,23 @@ static inline uint64_t I642U64(int64_t val)
 #define DRM_REFLECT_X  4
 #define DRM_REFLECT_Y  5
 
+enum drm_blend_factor {
+   DRM_BLEND_FACTOR_AUTO,
+   DRM_BLEND_FACTOR_ZERO,
+   DRM_BLEND_FACTOR_ONE,
+   DRM_BLEND_FACTOR_SRC_ALPHA,
+   DRM_BLEND_FACTOR_ONE_MINUS_SRC_ALPHA,
+};
+
+#define DRM_BLEND_FUNC(src_factor, dst_factor) \
+   (DRM_BLEND_FACTOR_##src_factor << 16 | DRM_BLEND_FACTOR_##dst_factor)
+#define DRM_BLEND_FUNC_SRC_FACTOR(val) (((val) >> 16) & 0x)
+#define DRM_BLEND_FUNC_DST_FACTOR(val) ((val) & 0x)
+
+struct drm_blend_mode {
+   uint64_t func;
+};
+
 enum drm_connector_force {
DRM_FORCE_UNSPECIFIED,
DRM_FORCE_OFF,
@@ -1273,6 +1290,8 @@ struct drm_plane_state {
/* Plane rotation */
unsigned int rotation;
 
+   struct drm_blend_mode blend_mode;
+
struct drm_atomic_state *state;
 };
 
@@ -2125,6 +2144,7 

[Intel-gfx] [PATCHv2 4/5] drm: Add an blend_color property

2016-04-29 Thread Vandita Kulkarni
From: Damien Lespiau 

Add blend color property and update the
documentation for the same

V2: Add blend color support in get property.

Signed-off-by: Damien Lespiau 
Signed-off-by: vandita kulkarni 
---
 Documentation/DocBook/gpu.tmpl | 11 +--
 drivers/gpu/drm/drm_atomic.c   |  4 
 drivers/gpu/drm/drm_crtc.c |  5 +
 include/drm/drm_crtc.h |  6 ++
 4 files changed, 24 insertions(+), 2 deletions(-)

diff --git a/Documentation/DocBook/gpu.tmpl b/Documentation/DocBook/gpu.tmpl
index f673989..8572c9a 100644
--- a/Documentation/DocBook/gpu.tmpl
+++ b/Documentation/DocBook/gpu.tmpl
@@ -1816,7 +1816,7 @@ void intel_crt_init(struct drm_device *dev)
Description/Restrictions


-   DRM
+   DRM
Generic
“rotation”
BITMASK
@@ -1868,7 +1868,7 @@ void intel_crt_init(struct drm_device *dev)
CRTC that connector is attached to (atomic)


-   Plane
+   Plane
“type”
ENUM | IMMUTABLE
{ "Overlay", "Primary", "Cursor" }
@@ -1953,6 +1953,13 @@ void intel_crt_init(struct drm_device *dev)
Source and destination blending factors


+   “blend_color”
+   Color
+   DRM_MODE_COLOR()
+   Plane
+   Blend constant color
+   
+   
DVI-I
“subconnector”
ENUM
diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index c2ead2d..20340de 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -713,6 +713,8 @@ int drm_atomic_plane_set_property(struct drm_plane *plane,
return -EINVAL;
 
state->blend_mode.func = val & GENMASK(31, 0);
+   } else if (property == config->prop_blend_color) {
+   state->blend_mode.color = val;
} else if (plane->funcs->atomic_set_property) {
return plane->funcs->atomic_set_property(plane, state,
property, val);
@@ -771,6 +773,8 @@ drm_atomic_plane_get_property(struct drm_plane *plane,
*val = state->rotation;
} else if (property == config->prop_blend_func) {
*val = state->blend_mode.func;
+   } else if (property == config->prop_blend_color) {
+   *val = state->blend_mode.color;
} else if (plane->funcs->atomic_get_property) {
return plane->funcs->atomic_get_property(plane, state, 
property, val);
} else {
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 2cac5e1..65cbaea 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -1592,6 +1592,11 @@ static int drm_mode_create_standard_properties(struct 
drm_device *dev)
return -ENOMEM;
dev->mode_config.prop_blend_func = prop;
 
+   prop = drm_property_create_range(dev, 0, "blend_color", 0, U64_MAX);
+   if (!prop)
+   return -ENOMEM;
+   dev->mode_config.prop_blend_color = prop;
+
return 0;
 }
 
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index 269f660..33d5845 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -95,6 +95,10 @@ enum drm_blend_factor {
DRM_BLEND_FACTOR_ONE,
DRM_BLEND_FACTOR_SRC_ALPHA,
DRM_BLEND_FACTOR_ONE_MINUS_SRC_ALPHA,
+   DRM_BLEND_FACTOR_CONSTANT_ALPHA,
+   DRM_BLEND_FACTOR_ONE_MINUS_CONSTANT_ALPHA,
+   DRM_BLEND_FACTOR_CONSTANT_ALPHA_TIMES_SRC_ALPHA,
+   DRM_BLEND_FACTOR_ONE_MINUS_CONSTANT_ALPHA_TIMES_SRC_ALPHA,
 };
 
 #define DRM_BLEND_FUNC(src_factor, dst_factor) \
@@ -103,6 +107,7 @@ enum drm_blend_factor {
 #define DRM_BLEND_FUNC_DST_FACTOR(val) ((val) & 0x)
 
 struct drm_blend_mode {
+   uint64_t color;
uint64_t func;
 };
 
@@ -2145,6 +2150,7 @@ struct drm_mode_config {
struct drm_property *prop_active;
struct drm_property *prop_mode_id;
struct drm_property *prop_blend_func;
+   struct drm_property *prop_blend_color;
 
/* DVI-I properties */
struct drm_property *dvi_i_subconnector_property;
-- 
1.9.1

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] [PATCHv2 5/5] drm/i915/skl: Add support for blending modes

2016-04-29 Thread Vandita Kulkarni
From: Damien Lespiau 

This patch adds support for blending modes involving
color.

V2: Add support for primary plane.
Separate out plane alpha disable functionality from per pixel
drop_alpha blend function and add another blend function case for
disabling plane alpha.

Signed-off-by: Damien Lespiau 
Signed-off-by: vandita kulkarni 
---
 drivers/gpu/drm/i915/i915_reg.h  |  4 +++
 drivers/gpu/drm/i915/intel_display.c | 47 
 drivers/gpu/drm/i915/intel_drv.h |  3 +++
 drivers/gpu/drm/i915/intel_sprite.c  |  9 +--
 4 files changed, 61 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 9464ba3..4d0c39d 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -5515,6 +5515,10 @@ enum skl_disp_power_wells {
 #define PLANE_KEYMAX(pipe, plane)  \
_MMIO_PLANE(plane, _PLANE_KEYMAX_1(pipe), _PLANE_KEYMAX_2(pipe))
 
+#define PLANE_KEYMAX_ALPHA_MASK0x00ff
+#define PLANE_KEY_MASK_ALPHA_EN31
+#define PLANE_KEY_MAX_ALPHA_SHIFT  24
+
 #define _PLANE_BUF_CFG_1_B 0x7127c
 #define _PLANE_BUF_CFG_2_B 0x7137c
 #define _PLANE_BUF_CFG_1(pipe) \
diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 037407f..31755f2 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -3032,6 +3032,8 @@ static void skylake_update_primary_plane(struct drm_plane 
*plane,
struct intel_crtc *intel_crtc = to_intel_crtc(crtc_state->base.crtc);
struct drm_framebuffer *fb = plane_state->base.fb;
struct drm_i915_gem_object *obj = intel_fb_obj(fb);
+   const struct drm_intel_sprite_colorkey *key =
+   _intel_plane_state(plane->state)->ckey;
int pipe = intel_crtc->pipe;
u32 plane_ctl, stride_div, stride;
u32 tile_height, plane_offset, plane_size;
@@ -3064,6 +3066,15 @@ static void skylake_update_primary_plane(struct 
drm_plane *plane,
 
WARN_ON(drm_rect_width(_state->src) == 0);
 
+   I915_WRITE(PLANE_KEYMAX(pipe, 0), (DRM_MODE_COLOR_ALPHA_8
+   (plane_state->base.blend_mode.color)
+   << PLANE_KEY_MAX_ALPHA_SHIFT) |
+   (key->max_value & PLANE_KEYMAX_ALPHA_MASK));
+   I915_WRITE(PLANE_KEYMSK(pipe, 0),
+   (plane_state->use_plane_alpha
+   << PLANE_KEY_MASK_ALPHA_EN) |
+   (key->channel_mask & GENMASK(0, 26)));
+
if (intel_rotation_90_or_270(rotation)) {
int cpp = drm_format_plane_cpp(fb->pixel_format, 0);
 
@@ -3146,6 +3157,7 @@ static int intel_plane_state_check_blend(struct 
drm_plane_state *plane_state)
case DRM_BLEND_FUNC(AUTO, AUTO):
if (has_per_pixel_blending)
state->per_pixel_alpha = PRE_MULTIPLIED_ALPHA;
+   state->use_plane_alpha = false;
break;
/* fbs without an alpha channel, or dropping the alpha channel */
case DRM_BLEND_FUNC(ONE, ZERO):
@@ -3158,6 +3170,7 @@ static int intel_plane_state_check_blend(struct 
drm_plane_state *plane_state)
state->per_pixel_alpha = DROP_ALPHA;
else
state->per_pixel_alpha = PRE_MULTIPLIED_ALPHA;
+   state->use_plane_alpha = false;
break;
/* non pre-multiplied alpha */
case DRM_BLEND_FUNC(SRC_ALPHA, ONE_MINUS_SRC_ALPHA):
@@ -3165,6 +3178,34 @@ static int intel_plane_state_check_blend(struct 
drm_plane_state *plane_state)
state->per_pixel_alpha = DROP_ALPHA;
else
state->per_pixel_alpha = NON_PRE_MULTIPLIED_ALPHA;
+   state->use_plane_alpha = false;
+   break;
+   /* plane alpha */
+   case DRM_BLEND_FUNC(CONSTANT_ALPHA, ONE_MINUS_CONSTANT_ALPHA):
+   state->use_plane_alpha = true;
+   break;
+   /* plane alpha, pre-multiplied fb */
+   case DRM_BLEND_FUNC(CONSTANT_ALPHA,
+   ONE_MINUS_CONSTANT_ALPHA_TIMES_SRC_ALPHA):
+   if (!has_per_pixel_blending)
+   state->per_pixel_alpha = DROP_ALPHA;
+   else
+   state->per_pixel_alpha = PRE_MULTIPLIED_ALPHA;
+   /*TBD bspec check*/
+   state->use_plane_alpha = true;
+   break;
+   /* plane alpha, non pre-multiplied fb */
+   case DRM_BLEND_FUNC(CONSTANT_ALPHA_TIMES_SRC_ALPHA,
+   ONE_MINUS_CONSTANT_ALPHA_TIMES_SRC_ALPHA):
+   if (!has_per_pixel_blending)
+   state->per_pixel_alpha = DROP_ALPHA;
+   else

[Intel-gfx] [PATCHv2 0/5] Support blending modes of display planes

2016-04-29 Thread Vandita Kulkarni
From: vandita kulkarni 

The below patches support plane and pixel blending
by adding two properties blend_func and blend_color.
As per Damien's initial patches, this design based on 
OpenGL's blend equations is suggested by Ville.
All the below patches are tested on BXT android platform.

V2: Squashed all the blend color related patches to one
single patch and blend func related pathces into one single
patch.

The initial kernel patches from damien can be found at
https://github.com/dlespiau/linux/commits/20150708-alpha-blending
Damien Lespiau (5):
  drm: Introduce the blend-func property
  drm/i915/skl: Add blend_func to SKL/BXT sprite planes
  drm: Introduce DRM_MODE_COLOR()
  drm: Add an blend_color property
  drm/i915/skl: Add support for blending modes

The initial version of kms_blend, igt by Damien
can be found at
https://github.com/dlespiau/intel-gpu-tools/commits/20150613-blend


Damien Lespiau (5):
  drm: Introduce the blend-func property
  drm/i915/skl: Add blend_func to SKL/BXT sprite planes
  drm: Introduce DRM_MODE_COLOR()
  drm: Add an blend_color property
  drm/i915/skl: Add support for blending modes

 Documentation/DocBook/gpu.tmpl   |  18 +++-
 drivers/gpu/drm/drm_atomic.c |  18 
 drivers/gpu/drm/drm_crtc.c   |  10 +++
 drivers/gpu/drm/i915/i915_reg.h  |   4 +
 drivers/gpu/drm/i915/intel_display.c | 168 +--
 drivers/gpu/drm/i915/intel_drv.h |  17 +++-
 drivers/gpu/drm/i915/intel_sprite.c  |  15 +++-
 include/drm/drm_crtc.h   |  26 ++
 include/uapi/drm/drm_mode.h  |  34 +++
 9 files changed, 298 insertions(+), 12 deletions(-)

-- 
1.9.1

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] [PATCHv2 2/5] drm/i915/skl: Add blend_func to SKL/BXT sprite planes

2016-04-29 Thread Vandita Kulkarni
From: Damien Lespiau 

This patch adds the blend functions, and as per the
blend function, updates the plane control register values

V2: Add blend support for all RGB formats
Fix the reg writes on plane_ctl_alpha bits.

V3: Add support support for primary and cursor planes.
fix an issue where the previous value was not
retained, change the logic to do so.

Signed-off-by: Damien Lespiau 
Signed-off-by: vandita kulkarni 
---
 drivers/gpu/drm/i915/intel_display.c | 121 +--
 drivers/gpu/drm/i915/intel_drv.h |  14 +++-
 drivers/gpu/drm/i915/intel_sprite.c  |   6 +-
 3 files changed, 133 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index c5b9687..037407f 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -2921,8 +2921,29 @@ static void skl_detach_scalers(struct intel_crtc 
*intel_crtc)
}
 }
 
-u32 skl_plane_ctl_format(uint32_t pixel_format)
+u32 skl_plane_ctl_format(uint32_t pixel_format,
+   enum per_pixel_alpha_state alpha)
 {
+   u32 plane_ctl_alpha = 0;
+
+   if (pixel_format == DRM_FORMAT_ABGR ||
+   pixel_format == DRM_FORMAT_ARGB) {
+
+   switch (alpha) {
+   case DROP_ALPHA:
+   plane_ctl_alpha = PLANE_CTL_ALPHA_DISABLE;
+   break;
+   case PRE_MULTIPLIED_ALPHA:
+   plane_ctl_alpha = PLANE_CTL_ALPHA_SW_PREMULTIPLY;
+   break;
+   case NON_PRE_MULTIPLIED_ALPHA:
+   plane_ctl_alpha = PLANE_CTL_ALPHA_HW_PREMULTIPLY;
+   break;
+   default:
+   MISSING_CASE(alpha);
+   }
+   }
+
switch (pixel_format) {
case DRM_FORMAT_C8:
return PLANE_CTL_FORMAT_INDEXED;
@@ -2938,11 +2959,11 @@ u32 skl_plane_ctl_format(uint32_t pixel_format)
 * DRM_FORMAT) for user-space to configure that.
 */
case DRM_FORMAT_ABGR:
-   return PLANE_CTL_FORMAT_XRGB_ | PLANE_CTL_ORDER_RGBX |
-   PLANE_CTL_ALPHA_SW_PREMULTIPLY;
+   return ((PLANE_CTL_FORMAT_XRGB_ | (PLANE_CTL_ORDER_RGBX
+   & (~PLANE_CTL_ALPHA_MASK))) | plane_ctl_alpha);
case DRM_FORMAT_ARGB:
-   return PLANE_CTL_FORMAT_XRGB_ |
-   PLANE_CTL_ALPHA_SW_PREMULTIPLY;
+   return ((PLANE_CTL_FORMAT_XRGB_ & ~PLANE_CTL_ALPHA_MASK)
+   | plane_ctl_alpha);
case DRM_FORMAT_XRGB2101010:
return PLANE_CTL_FORMAT_XRGB_2101010;
case DRM_FORMAT_XBGR2101010:
@@ -3031,7 +3052,8 @@ static void skylake_update_primary_plane(struct drm_plane 
*plane,
PLANE_CTL_PIPE_GAMMA_ENABLE |
PLANE_CTL_PIPE_CSC_ENABLE;
 
-   plane_ctl |= skl_plane_ctl_format(fb->pixel_format);
+   plane_ctl |= skl_plane_ctl_format(fb->pixel_format,
+   plane_state->per_pixel_alpha);
plane_ctl |= skl_plane_ctl_tiling(fb->modifier[0]);
plane_ctl |= PLANE_CTL_PLANE_GAMMA_DISABLE;
plane_ctl |= skl_plane_ctl_rotation(rotation);
@@ -3087,6 +3109,69 @@ static void skylake_update_primary_plane(struct 
drm_plane *plane,
POSTING_READ(PLANE_SURF(pipe, 0));
 }
 
+static int intel_plane_state_check_blend(struct drm_plane_state *plane_state)
+{
+   struct drm_device *dev = plane_state->state->dev;
+   struct intel_plane_state *state = to_intel_plane_state(plane_state);
+   const struct drm_framebuffer *fb = plane_state->fb;
+   const struct drm_blend_mode *mode = >base.blend_mode;
+   bool has_per_pixel_blending;
+
+   /*
+* We don't install the properties pre-SKL, so this is SKL+ specific
+* code for now.
+*/
+   if (INTEL_INFO(dev)->gen < 9)
+   return 0;
+
+   if (!fb)
+   return 0;
+
+   has_per_pixel_blending = fb->pixel_format == DRM_FORMAT_ABGR ||
+   fb->pixel_format == DRM_FORMAT_RGBA ||
+   fb->pixel_format == DRM_FORMAT_ARGB ||
+   fb->pixel_format == DRM_FORMAT_BGRA;
+
+   /* drop alpha for all fbs without an alpha channel */
+   if (!has_per_pixel_blending)
+   state->per_pixel_alpha = DROP_ALPHA;
+
+   switch (mode->func) {
+   /*
+* The 'AUTO' behaviour is the default and keeps compatibility with
+* kernels before the introduction of the blend_func property:
+*   - pre-multiplied alpha if the fb has an alpha channel
+*   - usual DRM_BLEND_FUNC(ONE, ZERO) otherwise
+*/
+   case 

[Intel-gfx] [PATCHv2 3/5] drm: Introduce DRM_MODE_COLOR()

2016-04-29 Thread Vandita Kulkarni
From: Damien Lespiau 

In the hope of expressing colors in the KMS API in a consitant want,
let's introduce a ARGB 16161616 color and a few convinience macros
around it.

Signed-off-by: Damien Lespiau 
---
 include/uapi/drm/drm_mode.h | 34 ++
 1 file changed, 34 insertions(+)

diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
index 7a7856e..203c7ab0 100644
--- a/include/uapi/drm/drm_mode.h
+++ b/include/uapi/drm/drm_mode.h
@@ -295,6 +295,40 @@ struct drm_mode_get_connector {
  */
 #define DRM_MODE_PROP_ATOMIC0x8000
 
+/* Color for the KMS API, ARGB (msb -> lsb) 16bits per component. */
+#define DRM_MODE_COLOR(a, r, b, g) \
+   (((__u64)(a) << 48) | ((__u64)(r) << 32) | \
+((__u64)(g) << 16) | (__u64)(b))
+
+/* Extract full precision, 8 bits, 10 bits and 12 bits components. */
+#define DRM_MODE_COLOR_ALPHA(color)(((color) >> 48) & 0x)
+#define DRM_MODE_COLOR_RED(color)  (((color) >> 32) & 0x)
+#define DRM_MODE_COLOR_BLUE(color) (((color) >> 16) & 0x)
+#define DRM_MODE_COLOR_GREEN(color)((color) & 0x)
+#define DRM_MODE_COLOR_ALPHA_8(color)  (((color) >> (48 + 8)) & 0xff)
+#define DRM_MODE_COLOR_RED_8(color)(((color) >> (32 + 8)) & 0xff)
+#define DRM_MODE_COLOR_BLUE_8(color)   (((color) >> (16 + 8)) & 0xff)
+#define DRM_MODE_COLOR_GREEN_8(color)  (((color) >>  8) & 0xff)
+#define DRM_MODE_COLOR_ALPHA_10(color) (((color) >> (48 + 6)) & 0x3ff)
+#define DRM_MODE_COLOR_RED_10(color)   (((color) >> (32 + 6)) & 0x3ff)
+#define DRM_MODE_COLOR_BLUE_10(color)  (((color) >> (16 + 6)) & 0x3ff)
+#define DRM_MODE_COLOR_GREEN_10(color) (((color) >>  6) & 0x3ff)
+#define DRM_MODE_COLOR_ALPHA_12(color) (((color) >> (48 + 4)) & 0xfff)
+#define DRM_MODE_COLOR_RED_12(color)   (((color) >> (32 + 4)) & 0xfff)
+#define DRM_MODE_COLOR_BLUE_12(color)  (((color) >> (16 + 4)) & 0xfff)
+#define DRM_MODE_COLOR_GREEN_12(color) (((color) >>  4) & 0xfff)
+
+/* Handy macros to convert a DRM_MODE_COLOR() into common precisions */
+#define DRM_MODE_COLOR_TO_ARGB_(color)  \
+   ((DRM_MODE_COLOR_ALPHA_8(color) << 24) | \
+(DRM_MODE_COLOR_RED_8(color)   << 16) | \
+(DRM_MODE_COLOR_GREEN_8(color) << 8)  | \
+DRM_MODE_COLOR_BLUE_8(color))
+#define DRM_MODE_COLOR_TO_RGB_101010(color)  \
+((DRM_MODE_COLOR_RED_10(color)  << 20) | \
+(DRM_MODE_COLOR_GREEN_10(color) << 10) | \
+DRM_MODE_COLOR_BLUE_10(color))
+
 struct drm_mode_property_enum {
__u64 value;
char name[DRM_PROP_NAME_LEN];
-- 
1.9.1

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH v2] drm/i915/execlists: Refactor common engine setup

2016-04-29 Thread Tvrtko Ursulin


On 29/04/16 10:15, Chris Wilson wrote:

On Fri, Apr 29, 2016 at 10:04:35AM +0100, Tvrtko Ursulin wrote:


On 28/04/16 18:35, Chris Wilson wrote:

Move all of the constant assignments up front and into a common
function. This is primarily to ensure the backpointers are set as early
as possible for later use during initialisation.

v2: Use a constant struct so that all the similar values are set
together.

Signed-off-by: Chris Wilson 
Cc: Tvrtko Ursulin 
Cc: Dave Gordon 
---
  drivers/gpu/drm/i915/intel_lrc.c | 176 +--
  1 file changed, 93 insertions(+), 83 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 874c2515f9d4..2e0eaa9fa240 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -1921,8 +1921,7 @@ void intel_logical_ring_cleanup(struct intel_engine_cs 
*engine)
  }

  static void
-logical_ring_default_vfuncs(struct drm_device *dev,
-   struct intel_engine_cs *engine)
+logical_ring_default_vfuncs(struct intel_engine_cs *engine)
  {
/* Default vfuncs which can be overriden by each engine. */
engine->init_hw = gen8_init_common_ring;
@@ -1933,7 +1932,7 @@ logical_ring_default_vfuncs(struct drm_device *dev,
engine->emit_bb_start = gen8_emit_bb_start;
engine->get_seqno = gen8_get_seqno;
engine->set_seqno = gen8_set_seqno;
-   if (IS_BXT_REVID(dev, 0, BXT_REVID_A1)) {
+   if (IS_BXT_REVID(engine->dev, 0, BXT_REVID_A1)) {
engine->irq_seqno_barrier = bxt_a_seqno_barrier;
engine->set_seqno = bxt_a_set_seqno;
}
@@ -1944,6 +1943,7 @@ logical_ring_default_irqs(struct intel_engine_cs *engine, 
unsigned shift)
  {
engine->irq_enable_mask = GT_RENDER_USER_INTERRUPT << shift;
engine->irq_keep_mask = GT_CONTEXT_SWITCH_INTERRUPT << shift;
+   init_waitqueue_head(>irq_queue);
  }

  static int
@@ -1964,31 +1964,68 @@ lrc_setup_hws(struct intel_engine_cs *engine,
return 0;
  }

-static int
-logical_ring_init(struct drm_device *dev, struct intel_engine_cs *engine)
+static const struct logical_ring_info {
+   const char *name;
+   unsigned exec_id;
+   unsigned guc_id;
+   u32 mmio_base;
+   unsigned irq_shift;
+} logical_rings[] = {
+   [RCS] = {
+   .name = "render ring",
+   .exec_id = I915_EXEC_RENDER,
+   .guc_id = GUC_RENDER_ENGINE,
+   .mmio_base = RENDER_RING_BASE,
+   .irq_shift = GEN8_RCS_IRQ_SHIFT,
+   },
+   [BCS] = {
+   .name = "blitter ring",
+   .exec_id = I915_EXEC_BLT,
+   .guc_id = GUC_BLITTER_ENGINE,
+   .mmio_base = BLT_RING_BASE,
+   .irq_shift = GEN8_BCS_IRQ_SHIFT,
+   },
+   [VCS] = {
+   .name = "bsd ring",
+   .exec_id = I915_EXEC_BSD,
+   .guc_id = GUC_VIDEO_ENGINE,
+   .mmio_base = GEN6_BSD_RING_BASE,
+   .irq_shift = GEN8_VCS1_IRQ_SHIFT,
+   },
+   [VCS2] = {
+   .name = "bsd2 ring",
+   .exec_id = I915_EXEC_BSD,
+   .guc_id = GUC_VIDEO_ENGINE2,
+   .mmio_base = GEN8_BSD2_RING_BASE,
+   .irq_shift = GEN8_VCS2_IRQ_SHIFT,
+   },
+   [VECS] = {
+   .name = "video enhancement ring",
+   .exec_id = I915_EXEC_VEBOX,
+   .guc_id = GUC_VIDEOENHANCE_ENGINE,
+   .mmio_base = VEBOX_RING_BASE,
+   .irq_shift = GEN8_VECS_IRQ_SHIFT,
+   },
+};
+
+static struct intel_engine_cs *
+logical_ring_setup(struct drm_device *dev, enum intel_engine_id id)
  {


Would dev_priv be better? Just to gradually move towards the correct
state of things.


I have a patch queued up to do engine->i915 (1 KiB in object code
reduction) next.


+   const struct logical_ring_info *info = _rings[id];
struct drm_i915_private *dev_priv = to_i915(dev);
-   struct intel_context *dctx = dev_priv->kernel_context;
+   struct intel_engine_cs *engine = _priv->engine[id];
enum forcewake_domains fw_domains;
-   int ret;
-
-   /* Intentionally left blank. */
-   engine->buffer = NULL;

engine->dev = dev;


Looking at usages of intel_engine_initialized... one potential
danger scenario would be interrupt noise during driver load end in
notify ring and explodes. Sounds very unlikely but theoretically it
is a regression compared to where engine->dev initialization was
before.

We should really move away from engine->dev for this and just add an
explicit flag.


Hmm. not that but I think we really should be sanitizing the irq here
and enabling them last.

Like:

diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 2e0eaa9fa240..2c94072ab085 100644
--- 

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [CI,1/3] drm/i915: Bump reserved size for legacy gen8 semaphore emission

2016-04-29 Thread Patchwork
== Series Details ==

Series: series starting with [CI,1/3] drm/i915: Bump reserved size for legacy 
gen8 semaphore emission
URL   : https://patchwork.freedesktop.org/series/6523/
State : success

== Summary ==

Series 6523v1 Series without cover letter
http://patchwork.freedesktop.org/api/1.0/series/6523/revisions/1/mbox/

Test gem_exec_whisper:
Subgroup basic:
dmesg-warn -> PASS   (ilk-hp8440p)
Test gem_sync:
Subgroup basic-render:
dmesg-warn -> PASS   (ilk-hp8440p)
Test kms_force_connector_basic:
Subgroup force-load-detect:
skip   -> PASS   (hsw-gt2)

bdw-nuci7-2  total:201  pass:189  dwarn:0   dfail:0   fail:0   skip:12 
bdw-ultratotal:201  pass:176  dwarn:0   dfail:0   fail:0   skip:25 
bsw-nuc-2total:200  pass:159  dwarn:0   dfail:0   fail:0   skip:41 
byt-nuc  total:200  pass:159  dwarn:0   dfail:0   fail:0   skip:41 
hsw-brixbox  total:201  pass:175  dwarn:0   dfail:0   fail:0   skip:26 
hsw-gt2  total:201  pass:179  dwarn:0   dfail:0   fail:1   skip:21 
ilk-hp8440p  total:201  pass:140  dwarn:0   dfail:0   fail:0   skip:61 
ivb-t430stotal:201  pass:170  dwarn:0   dfail:0   fail:0   skip:31 
skl-i7k-2total:201  pass:174  dwarn:0   dfail:0   fail:0   skip:27 
skl-nuci5total:201  pass:190  dwarn:0   dfail:0   fail:0   skip:11 
snb-x220ttotal:201  pass:159  dwarn:0   dfail:0   fail:1   skip:41 
snb-dellxps failed to collect. IGT log at Patchwork_2108/snb-dellxps/igt.log

Results at /archive/results/CI_IGT_test/Patchwork_2108/

f739e448f0278feb6bfcbf2f0caf6fa9a6a2b0a1 drm-intel-nightly: 
2016y-04m-29d-08h-04m-09s UTC integration manifest
1ad60b0 drm/i915: Trim the flush for the execlists request emission
5c6cb25 drm/i915: Trim the flush for the legacy request emission
acee343 drm/i915: Bump reserved size for legacy gen8 semaphore emission

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH v2] drm/i915/execlists: Refactor common engine setup

2016-04-29 Thread Chris Wilson
On Fri, Apr 29, 2016 at 10:04:35AM +0100, Tvrtko Ursulin wrote:
> 
> On 28/04/16 18:35, Chris Wilson wrote:
> >Move all of the constant assignments up front and into a common
> >function. This is primarily to ensure the backpointers are set as early
> >as possible for later use during initialisation.
> >
> >v2: Use a constant struct so that all the similar values are set
> >together.
> >
> >Signed-off-by: Chris Wilson 
> >Cc: Tvrtko Ursulin 
> >Cc: Dave Gordon 
> >---
> >  drivers/gpu/drm/i915/intel_lrc.c | 176 
> > +--
> >  1 file changed, 93 insertions(+), 83 deletions(-)
> >
> >diff --git a/drivers/gpu/drm/i915/intel_lrc.c 
> >b/drivers/gpu/drm/i915/intel_lrc.c
> >index 874c2515f9d4..2e0eaa9fa240 100644
> >--- a/drivers/gpu/drm/i915/intel_lrc.c
> >+++ b/drivers/gpu/drm/i915/intel_lrc.c
> >@@ -1921,8 +1921,7 @@ void intel_logical_ring_cleanup(struct intel_engine_cs 
> >*engine)
> >  }
> >
> >  static void
> >-logical_ring_default_vfuncs(struct drm_device *dev,
> >-struct intel_engine_cs *engine)
> >+logical_ring_default_vfuncs(struct intel_engine_cs *engine)
> >  {
> > /* Default vfuncs which can be overriden by each engine. */
> > engine->init_hw = gen8_init_common_ring;
> >@@ -1933,7 +1932,7 @@ logical_ring_default_vfuncs(struct drm_device *dev,
> > engine->emit_bb_start = gen8_emit_bb_start;
> > engine->get_seqno = gen8_get_seqno;
> > engine->set_seqno = gen8_set_seqno;
> >-if (IS_BXT_REVID(dev, 0, BXT_REVID_A1)) {
> >+if (IS_BXT_REVID(engine->dev, 0, BXT_REVID_A1)) {
> > engine->irq_seqno_barrier = bxt_a_seqno_barrier;
> > engine->set_seqno = bxt_a_set_seqno;
> > }
> >@@ -1944,6 +1943,7 @@ logical_ring_default_irqs(struct intel_engine_cs 
> >*engine, unsigned shift)
> >  {
> > engine->irq_enable_mask = GT_RENDER_USER_INTERRUPT << shift;
> > engine->irq_keep_mask = GT_CONTEXT_SWITCH_INTERRUPT << shift;
> >+init_waitqueue_head(>irq_queue);
> >  }
> >
> >  static int
> >@@ -1964,31 +1964,68 @@ lrc_setup_hws(struct intel_engine_cs *engine,
> > return 0;
> >  }
> >
> >-static int
> >-logical_ring_init(struct drm_device *dev, struct intel_engine_cs *engine)
> >+static const struct logical_ring_info {
> >+const char *name;
> >+unsigned exec_id;
> >+unsigned guc_id;
> >+u32 mmio_base;
> >+unsigned irq_shift;
> >+} logical_rings[] = {
> >+[RCS] = {
> >+.name = "render ring",
> >+.exec_id = I915_EXEC_RENDER,
> >+.guc_id = GUC_RENDER_ENGINE,
> >+.mmio_base = RENDER_RING_BASE,
> >+.irq_shift = GEN8_RCS_IRQ_SHIFT,
> >+},
> >+[BCS] = {
> >+.name = "blitter ring",
> >+.exec_id = I915_EXEC_BLT,
> >+.guc_id = GUC_BLITTER_ENGINE,
> >+.mmio_base = BLT_RING_BASE,
> >+.irq_shift = GEN8_BCS_IRQ_SHIFT,
> >+},
> >+[VCS] = {
> >+.name = "bsd ring",
> >+.exec_id = I915_EXEC_BSD,
> >+.guc_id = GUC_VIDEO_ENGINE,
> >+.mmio_base = GEN6_BSD_RING_BASE,
> >+.irq_shift = GEN8_VCS1_IRQ_SHIFT,
> >+},
> >+[VCS2] = {
> >+.name = "bsd2 ring",
> >+.exec_id = I915_EXEC_BSD,
> >+.guc_id = GUC_VIDEO_ENGINE2,
> >+.mmio_base = GEN8_BSD2_RING_BASE,
> >+.irq_shift = GEN8_VCS2_IRQ_SHIFT,
> >+},
> >+[VECS] = {
> >+.name = "video enhancement ring",
> >+.exec_id = I915_EXEC_VEBOX,
> >+.guc_id = GUC_VIDEOENHANCE_ENGINE,
> >+.mmio_base = VEBOX_RING_BASE,
> >+.irq_shift = GEN8_VECS_IRQ_SHIFT,
> >+},
> >+};
> >+
> >+static struct intel_engine_cs *
> >+logical_ring_setup(struct drm_device *dev, enum intel_engine_id id)
> >  {
> 
> Would dev_priv be better? Just to gradually move towards the correct
> state of things.

I have a patch queued up to do engine->i915 (1 KiB in object code
reduction) next.

> >+const struct logical_ring_info *info = _rings[id];
> > struct drm_i915_private *dev_priv = to_i915(dev);
> >-struct intel_context *dctx = dev_priv->kernel_context;
> >+struct intel_engine_cs *engine = _priv->engine[id];
> > enum forcewake_domains fw_domains;
> >-int ret;
> >-
> >-/* Intentionally left blank. */
> >-engine->buffer = NULL;
> >
> > engine->dev = dev;
> 
> Looking at usages of intel_engine_initialized... one potential
> danger scenario would be interrupt noise during driver load end in
> notify ring and explodes. Sounds very unlikely but theoretically it
> is a regression compared to where engine->dev initialization was
> before.
> 
> We should really move away from engine->dev for this and just add an
> explicit flag.

Hmm. not that but I think we really should be sanitizing the irq here
and enabling them last.

Like:

diff --git 

Re: [Intel-gfx] [PATCH 15/21] drm/i915/slpc: Notification of Refresh Rate change

2016-04-29 Thread Ville Syrjälä
On Wed, Apr 27, 2016 at 06:10:59PM -0700, tom.orou...@intel.com wrote:
> From: Sagar Arun Kamble 
> 
> This patch will inform GuC SLPC about changes in the refresh rate
> due to Seamless DRRS. Refresh rate changes due to Static DRRS will
> be notified via commit path.
> 
> v2: Rebased on previous changed patch and printed error message if
> H2G action fails.
> v2(torourke): Updates suggested by Paulo: replace HAS_SLPC with
> intel_slpc_active. return void instead of ignored error code.
> 
> Signed-off-by: Sagar Arun Kamble 
> Signed-off-by: Tom O'Rourke 
> ---
>  drivers/gpu/drm/i915/intel_dp.c   |  2 ++
>  drivers/gpu/drm/i915/intel_slpc.c | 23 +++
>  drivers/gpu/drm/i915/intel_slpc.h |  1 +
>  3 files changed, 26 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index c12c414..3d41f7b 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -5379,6 +5379,8 @@ static void intel_dp_set_drrs_state(struct drm_device 
> *dev, int refresh_rate)
>   dev_priv->drrs.refresh_rate_type = index;
>  
>   DRM_DEBUG_KMS("eDP Refresh Rate set to : %dHz\n", refresh_rate);
> +
> + intel_slpc_update_display_rr_info(dev, refresh_rate);
>  }
>  
>  /**
> diff --git a/drivers/gpu/drm/i915/intel_slpc.c 
> b/drivers/gpu/drm/i915/intel_slpc.c
> index 7f26284..9e0bc96 100644
> --- a/drivers/gpu/drm/i915/intel_slpc.c
> +++ b/drivers/gpu/drm/i915/intel_slpc.c
> @@ -364,3 +364,26 @@ void intel_slpc_update_atomic_commit_info(struct 
> drm_device *dev,
>   if (notify)
>   host2guc_slpc_display_mode_change(dev);
>  }
> +
> +void intel_slpc_update_display_rr_info(struct drm_device *dev, u32 
> refresh_rate)
> +{
> + struct drm_i915_private *dev_priv = dev->dev_private;
> + struct drm_crtc *crtc;
> + struct intel_display_pipe_info *per_pipe_info;
> + struct intel_slpc_display_mode_event_params *display_params;
> +
> + if (!intel_slpc_active(dev))
> + return;
> +
> + if (!refresh_rate)
> + return;
> +
> + display_params = _priv->guc.slpc.display_mode_params;
> + crtc = dp_to_dig_port(dev_priv->drrs.dp)->base.base.crtc;
> +
> + per_pipe_info = 
> _params->per_pipe_info[to_intel_crtc(crtc)->pipe];
> + per_pipe_info->refresh_rate = refresh_rate;
> + per_pipe_info->vsync_ft_usec = 100 / refresh_rate;
> +
> + host2guc_slpc_display_mode_change(dev);
> +}

Other people already commented, but I'll just add that this in any case
looks rather bogus. Only updated for a single pipe when it has drrs
enabled, non-drrs and all the other pipes left out. What's that about?

> diff --git a/drivers/gpu/drm/i915/intel_slpc.h 
> b/drivers/gpu/drm/i915/intel_slpc.h
> index 39b4657..0b251a1 100644
> --- a/drivers/gpu/drm/i915/intel_slpc.h
> +++ b/drivers/gpu/drm/i915/intel_slpc.h
> @@ -153,5 +153,6 @@ void intel_slpc_reset(struct drm_device *dev);
>  void intel_slpc_update_display_mode_info(struct drm_device *dev);
>  void intel_slpc_update_atomic_commit_info(struct drm_device *dev,
> struct drm_atomic_state *state);
> +void intel_slpc_update_display_rr_info(struct drm_device *dev, u32 
> refresh_rate);
>  
>  #endif
> -- 
> 1.9.1
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
Ville Syrjälä
Intel OTC
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


  1   2   >