Re: [Intel-gfx] [PATCH v2 02/12] drm/i915: Update atomic state when removing mst connector.
On 7/27/2015 6:05 PM, Maarten Lankhorst wrote:
Signed-off-by: Maarten Lankhorst maarten.lankho...@linux.intel.com
---
drivers/gpu/drm/i915/intel_display.c | 7 --
drivers/gpu/drm/i915/intel_dp_mst.c | 45 +++-
2 files changed, 44 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 7747520bf9f6..3ab0a8a8e702 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -12751,13 +12751,6 @@ check_encoder_state(struct drm_device *dev)
encoder-base.crtc,
connector's crtc doesn't match encoder crtc\n);
}
- /*
-* for MST connectors if we unplug the connector is gone
-* away but the encoder is still connected to a crtc
-* until a modeset happens in response to the hotplug.
-*/
- if (!enabled encoder-base.encoder_type ==
DRM_MODE_ENCODER_DPMST)
- continue;
I915_STATE_WARN(!!encoder-base.crtc != enabled,
encoder's enabled state mismatch
diff --git a/drivers/gpu/drm/i915/intel_dp_mst.c
b/drivers/gpu/drm/i915/intel_dp_mst.c
index 585f0a45b3f1..35f2eb59818a 100644
--- a/drivers/gpu/drm/i915/intel_dp_mst.c
+++ b/drivers/gpu/drm/i915/intel_dp_mst.c
@@ -448,6 +448,49 @@ static struct drm_connector
*intel_dp_add_mst_connector(struct drm_dp_mst_topolo
return connector;
}
+static void
+intel_dp_unbind_mst_connector(struct drm_device *dev,
+ struct drm_connector *connector)
+{
+ struct drm_atomic_state *state;
+ struct drm_connector_state *conn_state;
+ struct drm_crtc *crtc = connector-state-crtc;
+ int ret;
+
+ if (!crtc)
+ return;
+
why cant we call drm_atomic_helper_set_config with just crtc copied into
struct drm_mode_set ?
+ state = drm_atomic_state_alloc(dev);
+ if (!state)
+ return;
+
+ state-acquire_ctx = dev-mode_config.acquire_ctx;
+
+ conn_state = drm_atomic_get_connector_state(state, connector);
+ ret = PTR_ERR_OR_ZERO(conn_state);
+ if (!ret)
+ ret = drm_atomic_set_crtc_for_connector(conn_state, NULL);
+
+ if (!ret)
+ ret = drm_atomic_add_affected_connectors(state, crtc);
+
+ if (!ret !drm_atomic_connectors_for_crtc(state, crtc)) {
+ struct drm_crtc_state *crtc_state =
+ drm_atomic_get_existing_crtc_state(state, crtc);
+
+ crtc_state-active = false;
+ ret = drm_atomic_set_mode_for_crtc(crtc_state, NULL);
+ }
+
+ if (!ret)
+ ret = drm_atomic_commit(state);
+
+ if (ret)
+ drm_atomic_state_free(state);
+
+ I915_STATE_WARN_ON(ret);
+}
+
static void intel_dp_destroy_mst_connector(struct drm_dp_mst_topology_mgr
*mgr,
struct drm_connector *connector)
{
@@ -455,7 +498,7 @@ static void intel_dp_destroy_mst_connector(struct
drm_dp_mst_topology_mgr *mgr,
struct drm_device *dev = connector-dev;
/* need to nuke the connector */
drm_modeset_lock_all(dev);
- intel_connector_dpms(connector, DRM_MODE_DPMS_OFF);
+ intel_dp_unbind_mst_connector(dev, connector);
drm_modeset_unlock_all(dev);
intel_connector-unregister(intel_connector);
--
regards,
Sivakumar
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/skl: Update DDI buffer translation programming.
Hi, Vivi:
Do you think this patch could resolve the following two issues ?
https://bugs.freedesktop.org/show_bug.cgi?id=91050
https://bugs.freedesktop.org/show_bug.cgi?id=91269
thanks
-Original Message-
From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of
Rodrigo Vivi
Sent: Thursday, August 6, 2015 5:59 AM
To: intel-gfx@lists.freedesktop.org
Cc: Runyan, Arthur J; Vivi, Rodrigo
Subject: [Intel-gfx] [PATCH] drm/i915/skl: Update DDI buffer translation
programming.
SKL-Y can now use the same programming for all VccIO values after an
adjustment to I_boost.
SKL-U DP table adjustments.
1. Remove SKL Y 0.95V from SKL H and S columns in all tables. The
other SKL Y column removes the 0.85V VccIO so it now applies to all
voltages.
2. DP table changes SKL U 400mV+0db dword 0 value from 2016h to
201Bh.
3. DP table changes SKL U 600mv+0db dword 0 value from 2016h to
201Bh.
4. DP table increases I_boost to level 3 for SKL Y 400mv+9.5db.
Reference: Graphics Spec Change r97962
Cc: Arthur Runyan arthur.j.run...@intel.com
Signed-off-by: Rodrigo Vivi rodrigo.v...@intel.com
---
drivers/gpu/drm/i915/intel_ddi.c | 73
++--
1 file changed, 25 insertions(+), 48 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_ddi.c
b/drivers/gpu/drm/i915/intel_ddi.c
index 9a40bfb..9e5a21b 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -128,7 +128,7 @@ static const struct ddi_buf_trans
bdw_ddi_translations_hdmi[] = {
{ 0x80FF, 0x001B0002, 0x0 },/* 9: 100010000 */
};
-/* Skylake H, S, and Skylake Y with 0.95V VccIO */
+/* Skylake H and S */
static const struct ddi_buf_trans skl_ddi_translations_dp[] = {
{ 0x2016, 0x00A0, 0x0 },
{ 0x5012, 0x009B, 0x0 },
@@ -143,23 +143,23 @@ static const struct ddi_buf_trans
skl_ddi_translations_dp[] = {
/* Skylake U */
static const struct ddi_buf_trans skl_u_ddi_translations_dp[] = {
- { 0x2016, 0x00A2, 0x0 },
+ { 0x201B, 0x00A2, 0x0 },
{ 0x5012, 0x0088, 0x0 },
{ 0x7011, 0x0087, 0x0 },
- { 0x80009010, 0x00C7, 0x1 },/* Uses I_boost */
- { 0x2016, 0x009D, 0x0 },
+ { 0x80009010, 0x00C7, 0x1 },/* Uses I_boost level 0x1 */
+ { 0x201B, 0x009D, 0x0 },
{ 0x5012, 0x00C7, 0x0 },
{ 0x7011, 0x00C7, 0x0 },
{ 0x2016, 0x0088, 0x0 },
{ 0x5012, 0x00C7, 0x0 },
};
-/* Skylake Y with 0.85V VccIO */
-static const struct ddi_buf_trans skl_y_085v_ddi_translations_dp[] = {
+/* Skylake Y */
+static const struct ddi_buf_trans skl_y_ddi_translations_dp[] = {
{ 0x0018, 0x00A2, 0x0 },
{ 0x5012, 0x0088, 0x0 },
{ 0x7011, 0x0087, 0x0 },
- { 0x80009010, 0x00C7, 0x1 },/* Uses I_boost */
+ { 0x80009010, 0x00C7, 0x3 },/* Uses I_boost level 0x3 */
{ 0x0018, 0x009D, 0x0 },
{ 0x5012, 0x00C7, 0x0 },
{ 0x7011, 0x00C7, 0x0 },
@@ -168,7 +168,7 @@ static const struct ddi_buf_trans
skl_y_085v_ddi_translations_dp[] = { };
/*
- * Skylake H and S, and Skylake Y with 0.95V VccIO
+ * Skylake H and S
* eDP 1.4 low vswing translation parameters
*/
static const struct ddi_buf_trans skl_ddi_translations_edp[] = { @@ -202,10
+202,10 @@ static const struct ddi_buf_trans skl_u_ddi_translations_edp[] =
{ };
/*
- * Skylake Y with 0.95V VccIO
+ * Skylake Y
* eDP 1.4 low vswing translation parameters
*/
-static const struct ddi_buf_trans skl_y_085v_ddi_translations_edp[] = {
+static const struct ddi_buf_trans skl_y_ddi_translations_edp[] = {
{ 0x0018, 0x00A8, 0x0 },
{ 0x4013, 0x00AB, 0x0 },
{ 0x7011, 0x00A4, 0x0 },
@@ -218,7 +218,7 @@ static const struct ddi_buf_trans
skl_y_085v_ddi_translations_edp[] = {
{ 0x0018, 0x008A, 0x0 },
};
-/* Skylake H, S and U, and Skylake Y with 0.95V VccIO */
+/* Skylake U, H and S */
static const struct ddi_buf_trans skl_ddi_translations_hdmi[] = {
{ 0x0018, 0x00AC, 0x0 },
{ 0x5012, 0x009D, 0x0 },
@@ -233,8 +233,8 @@ static const struct ddi_buf_trans
skl_ddi_translations_hdmi[] = {
{ 0x0018, 0x00C7, 0x0 },
};
-/* Skylake Y with 0.85V VccIO */
-static const struct ddi_buf_trans skl_y_085v_ddi_translations_hdmi[] = {
+/* Skylake Y */
+static const struct ddi_buf_trans skl_y_ddi_translations_hdmi[] = {
{ 0x0018, 0x00A1, 0x0 },
{ 0x5012, 0x00DF, 0x0 },
{ 0x7011, 0x0084, 0x0 },
@@ -244,7 +244,7 @@ static const struct ddi_buf_trans
skl_y_085v_ddi_translations_hdmi[] = {
{ 0x6013, 0x00C7, 0x0 },
{ 0x0018, 0x008A, 0x0 },
{ 0x3015, 0x00C7, 0x0 },
Re: [Intel-gfx] [PATCH 1/2] drm/i915: Use CPU mapping for userspace dma-buf mmap()
On Tue, Aug 04, 2015 at 06:30:25PM -0300, Tiago Vignatti wrote:
On 07/31/2015 06:02 PM, Chris Wilson wrote:
The first problem is that llc does not guarrantee that the buffer is
cache coherent with all aspects of the GPU. For scanout and similar
writes need to be WC.
if (obj-has_framebuffer_references) would at least catch where the fb
is made before the mmap.
Equally this buffer could then be shared with other devices and exposing
a CPU mmap to userspace (and no flush/set-domain protocol) will result in
corruption.
I've built an igt test to catch this corruption but it's not really falling
there in my IvyBridge. If what you described is right (and so what I coded)
then this test should write in the mapped buffer but not update the screen.
Any idea what's going on?
https://github.com/tiagovignatti/intel-gpu-tools/commit/3e130ac2b274f1a3f6889c78cb72d0673ca2.patch
From 3e130ac2b274f1a3f6889c78cb72d0673ca2 Mon Sep 17 00:00:00 2001
From: Tiago Vignatti tiago.vigna...@intel.com
Date: Tue, 4 Aug 2015 13:38:09 -0300
Subject: [PATCH] tests: Add prime_crc for cache coherency
This program can be used to detect when the writes don't land in scanout,
due
cache incoherency.
Run it like ./prime_crc --interactive-debug=crc
Signed-off-by: Tiago Vignatti tiago.vigna...@intel.com
---
tests/.gitignore | 1 +
tests/Makefile.sources | 1 +
tests/prime_crc.c | 201
+
3 files changed, 203 insertions(+)
create mode 100644 tests/prime_crc.c
diff --git a/tests/.gitignore b/tests/.gitignore
index 5bc4a58..96dbf57 100644
--- a/tests/.gitignore
+++ b/tests/.gitignore
@@ -160,6 +160,7 @@ pm_rc6_residency
pm_rpm
pm_rps
pm_sseu
+prime_crc
prime_nv_api
prime_nv_pcopy
prime_nv_test
diff --git a/tests/Makefile.sources b/tests/Makefile.sources
index 5b2072e..c05b5a7 100644
--- a/tests/Makefile.sources
+++ b/tests/Makefile.sources
@@ -90,6 +90,7 @@ TESTS_progs_M = \
pm_rps \
pm_rc6_residency \
pm_sseu \
+ prime_crc \
prime_mmap \
prime_self_import \
template \
diff --git a/tests/prime_crc.c b/tests/prime_crc.c
new file mode 100644
index 000..3474cc9
--- /dev/null
+++ b/tests/prime_crc.c
@@ -0,0 +1,201 @@
+/*
+ * Copyright © 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.
+ *
+ * Authors:
+ *Tiago Vignatti tiago.vignatti at intel.com
+ *
+ */
+
+/* This program can detect when the writes don't land in scanout, due cache
+ * incoherency. */
+
+#include drmtest.h
+#include igt_debugfs.h
+#include igt_kms.h
+
+#define MAX_CONNECTORS 32
+
+struct modeset_params {
+ uint32_t crtc_id;
+ uint32_t connector_id;
+ drmModeModeInfoPtr mode;
+};
+
+int drm_fd;
+drmModeResPtr drm_res;
+drmModeConnectorPtr drm_connectors[MAX_CONNECTORS];
+drm_intel_bufmgr *bufmgr;
+igt_pipe_crc_t *pipe_crc;
+
+struct modeset_params ms;
+
+static void find_modeset_params(void)
+{
+ int i;
+ uint32_t connector_id = 0, crtc_id;
+ drmModeModeInfoPtr mode = NULL;
+
+ for (i = 0; i drm_res-count_connectors; i++) {
+ drmModeConnectorPtr c = drm_connectors[i];
+
+ if (c-count_modes) {
+ connector_id = c-connector_id;
+ mode = c-modes[0];
+ break;
+ }
+ }
+ igt_require(connector_id);
+
+ crtc_id = drm_res-crtcs[0];
+ igt_assert(crtc_id);
+ igt_assert(mode);
+
+ ms.connector_id = connector_id;
+ ms.crtc_id = crtc_id;
+ ms.mode = mode;
+
+}
+
+#define BO_SIZE (16*1024)
+
+char pattern[] = {0xff, 0x00, 0x00, 0x00,
+ 0x00, 0xff, 0x00, 0x00,
+ 0x00, 0x00, 0xff, 0x00,
+ 0x00, 0x00, 0x00, 0xff};
+
+static void mess_with_coherency(char *ptr)
+{
+
Re: [Intel-gfx] [PATCH] drm/i915/gen9: Update null batch to follow VF state restriction
Arun Siluvery arun.siluv...@linux.intel.com writes:
Atleast one component of one valid vertex element must be enabled.
Cc: Ben Widawsky benjamin.widaw...@intel.com
Cc: Chris Wilson ch...@chris-wilson.co.uk
Signed-off-by: Arun Siluvery arun.siluv...@linux.intel.com
---
Please resend the newly generated one when the IGT parts are merged.
That way we get the igt version info in the comment to match.
-Mika
drivers/gpu/drm/i915/intel_renderstate_gen9.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_renderstate_gen9.c
b/drivers/gpu/drm/i915/intel_renderstate_gen9.c
index 16a7ec2..fa86431 100644
--- a/drivers/gpu/drm/i915/intel_renderstate_gen9.c
+++ b/drivers/gpu/drm/i915/intel_renderstate_gen9.c
@@ -873,7 +873,7 @@ static const u32 gen9_null_state_batch[] = {
0x,
0x,
0x78550003,
- 0x,
+ 0x0001,
0x,
0x,
0x,
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC CABC PATCH v2 3/3] drm/i915: CABC support for backlight control
On 7/30/2015 4:18 PM, Singh, Gaurav K wrote:
On 7/24/2015 5:54 PM, Deepak M wrote:
In CABC (Content Adaptive Brightness Control) content grey level
scale can be increased while simultaneously decreasing
brightness of the backlight to achieve same perceived brightness.
The CABC is not standardized and panel vendors are free to follow
their implementation. The CABC implementaion here assumes that the
panels use standard SW register for control.
In this design there will be no PWM signal from the SoC and DCS
commands are sent to enable and control the backlight brightness.
v2:
- Created a new backlight driver for cabc, which will be registered
only when it cabc is supported by panel.
(Addressed comment from Daniel Vetter)
Signed-off-by: Deepak M m.dee...@intel.com
---
drivers/gpu/drm/i915/Makefile |1 +
drivers/gpu/drm/i915/intel_drv.h |3 +-
drivers/gpu/drm/i915/intel_dsi.c | 13 ++
drivers/gpu/drm/i915/intel_dsi_cabc.c | 349
+
drivers/gpu/drm/i915/intel_dsi_cabc.h | 45 +
drivers/gpu/drm/i915/intel_panel.c| 22 ++-
include/video/mipi_display.h |8 +
7 files changed, 436 insertions(+), 5 deletions(-)
create mode 100644 drivers/gpu/drm/i915/intel_dsi_cabc.c
create mode 100644 drivers/gpu/drm/i915/intel_dsi_cabc.h
diff --git a/drivers/gpu/drm/i915/Makefile
b/drivers/gpu/drm/i915/Makefile
index de21965..a73953c 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -75,6 +75,7 @@ i915-y += dvo_ch7017.o \
intel_dp_mst.o \
intel_dsi.o \
intel_dsi_pll.o \
+ intel_dsi_cabc.o \
intel_dsi_panel_vbt.o \
intel_dvo.o \
intel_hdmi.o \
diff --git a/drivers/gpu/drm/i915/intel_drv.h
b/drivers/gpu/drm/i915/intel_drv.h
index 3f0a890..9f806dd5 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -1319,7 +1319,8 @@ extern struct drm_display_mode
*intel_find_panel_downclock(
struct drm_connector *connector);
void intel_backlight_register(struct drm_device *dev);
void intel_backlight_unregister(struct drm_device *dev);
-
+extern int cabc_backlight_device_register(struct intel_connector
*connector);
+extern void cabc_backlight_device_unregister(struct intel_connector
*connector);
/* intel_psr.c */
void intel_psr_enable(struct intel_dp *intel_dp);
diff --git a/drivers/gpu/drm/i915/intel_dsi.c
b/drivers/gpu/drm/i915/intel_dsi.c
index 98998e9..8f006f2 100644
--- a/drivers/gpu/drm/i915/intel_dsi.c
+++ b/drivers/gpu/drm/i915/intel_dsi.c
@@ -34,6 +34,7 @@
#include i915_drv.h
#include intel_drv.h
#include intel_dsi.h
+#include intel_dsi_cabc.h
static const struct {
u16 panel_id;
@@ -376,6 +377,7 @@ static void intel_dsi_enable(struct intel_encoder
*encoder)
struct drm_device *dev = encoder-base.dev;
struct drm_i915_private *dev_priv = dev-dev_private;
struct intel_dsi *intel_dsi = enc_to_intel_dsi(encoder-base);
+struct intel_connector *connector = intel_dsi-attached_connector;
enum port port;
DRM_DEBUG_KMS(\n);
@@ -396,6 +398,9 @@ static void intel_dsi_enable(struct intel_encoder
*encoder)
intel_dsi_port_enable(encoder);
}
+
+if (dev_priv-vbt.dsi.config-cabc_supported)
+cabc_enable_backlight(connector);
}
static void intel_dsi_pre_enable(struct intel_encoder *encoder)
@@ -469,11 +474,15 @@ static void intel_dsi_disable(struct
intel_encoder *encoder)
struct drm_device *dev = encoder-base.dev;
struct drm_i915_private *dev_priv = dev-dev_private;
struct intel_dsi *intel_dsi = enc_to_intel_dsi(encoder-base);
+struct intel_connector *connector = intel_dsi-attached_connector;
enum port port;
u32 temp;
DRM_DEBUG_KMS(\n);
+if (dev_priv-vbt.dsi.config-cabc_supported)
+cabc_disable_backlight(connector);
+
if (is_vid_mode(intel_dsi)) {
for_each_dsi_port(port, intel_dsi-ports)
wait_for_dsi_fifo_empty(intel_dsi, port);
@@ -1099,6 +1108,10 @@ void intel_dsi_init(struct drm_device *dev)
intel_panel_init(intel_connector-panel, fixed_mode, NULL);
+if (dev_priv-vbt.dsi.config-cabc_supported)
+cabc_setup_backlight(connector,
+intel_encoder-crtc_mask ==
+(1 PIPE_A) ? PIPE_A : PIPE_B);
return;
err:
diff --git a/drivers/gpu/drm/i915/intel_dsi_cabc.c
b/drivers/gpu/drm/i915/intel_dsi_cabc.c
new file mode 100644
index 000..2a78326
--- /dev/null
+++ b/drivers/gpu/drm/i915/intel_dsi_cabc.c
@@ -0,0 +1,349 @@
+/*
+ * Copyright © 2006-2010 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,
Re: [Intel-gfx] [PATCH 4/4] drm/i915: special-case dirtyfb for frontbuffer tracking
On Thu, Jul 30, 2015 at 11:48:12PM +, Rodrigo Vivi wrote:
Very good. I should've added this when adding the dirtyfb flush...
Thanks,
Reviewed-by: Rodrigo Vivi rodrigo.v...@intel.com
Merged entire series, thanks.
-Daniel
On Tue, Jul 14, 2015 at 12:30 PM Paulo Zanoni przan...@gmail.com wrote:
From: Paulo Zanoni paulo.r.zan...@intel.com
First, an introduction. We currently have two types of GTT mmaps: the
normal old mmap, and the WC mmap. For frontbuffer-related features
that have automatic hardware tracking, only the non-WC mmap writes are
detected by the hardware. Since inside the Kernel both are treated as
ORIGIN_GTT, any features ignoring ORIGIN_GTT because of the hardware
tracking are destined to fail.
One of the special rules defined for the WC mmaps is that the user
should call the dirtyfb IOCTL after he is done using the pointers, so
that results in an intel_fb_obj_flush() call. The problem is that the
dirtyfb is passing ORIGIN_GTT, so it is being ignored by FBC - even
though the hardware tracking is not detecing the WC mmap operations.
So in order to fix that without having to give up the automatic
hardware tracking for GTT mmaps we transform the flush operation from
dirtyfb into a special operation: ORIGIN_DIRTYFB.
This commit fixes all the kms_frontbuffer_tracking subtests that
contain fbc and mmap-wc in their names and are currently failing
(for a total of 16 subtests).
Signed-off-by: Paulo Zanoni paulo.r.zan...@intel.com
---
drivers/gpu/drm/i915/i915_drv.h | 1 +
drivers/gpu/drm/i915/intel_display.c | 2 +-
2 files changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h
b/drivers/gpu/drm/i915/i915_drv.h
index cf6761c..78d21c1 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -894,6 +894,7 @@ enum fb_op_origin {
ORIGIN_CPU,
ORIGIN_CS,
ORIGIN_FLIP,
+ ORIGIN_DIRTYFB,
};
struct i915_fbc {
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 6e3ba5f..cffaaf4a3 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -14479,7 +14479,7 @@ static int intel_user_framebuffer_dirty(struct
drm_framebuffer *fb,
struct drm_i915_gem_object *obj = intel_fb-obj;
mutex_lock(dev-struct_mutex);
- intel_fb_obj_flush(obj, false, ORIGIN_GTT);
+ intel_fb_obj_flush(obj, false, ORIGIN_DIRTYFB);
mutex_unlock(dev-struct_mutex);
return 0;
--
2.1.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC 7/9] drm/i915: Interrupt driven fences
On Mon, Aug 03, 2015 at 10:20:29AM +0100, Tvrtko Ursulin wrote: On 07/27/2015 03:00 PM, Daniel Vetter wrote: On Mon, Jul 27, 2015 at 02:20:43PM +0100, Tvrtko Ursulin wrote: On 07/17/2015 03:31 PM, john.c.harri...@intel.com wrote: From: John Harrison john.c.harri...@intel.com The intended usage model for struct fence is that the signalled status should be set on demand rather than polled. That is, there should not be a need for a 'signaled' function to be called everytime the status is queried. Instead, 'something' should be done to enable a signal callback from the hardware which will update the state directly. In the case of requests, this is the seqno update interrupt. The idea is that this callback will only be enabled on demand when something actually tries to wait on the fence. This change removes the polling test and replaces it with the callback scheme. Each fence is added to a 'please poke me' list at the start of i915_add_request(). The interrupt handler then scans through the 'poke me' list when a new seqno pops out and signals any matching fence/request. The fence is then removed from the list so the entire request stack does not need to be scanned every time. Note that the fence is added to the list before the commands to generate the seqno interrupt are added to the ring. Thus the sequence is guaranteed to be race free if the interrupt is already enabled. Note that the interrupt is only enabled on demand (i.e. when __wait_request() is called). Thus there is still a potential race when enabling the interrupt as the request may already have completed. However, this is simply solved by calling the interrupt processing code immediately after enabling the interrupt and thereby checking for already completed requests. Lastly, the ring clean up code has the possibility to cancel outstanding requests (e.g. because TDR has reset the ring). These requests will never get signalled and so must be removed from the signal list manually. This is done by setting a 'cancelled' flag and then calling the regular notify/retire code path rather than attempting to duplicate the list manipulatation and clean up code in multiple places. This also avoid any race condition where the cancellation request might occur after/during the completion interrupt actually arriving. v2: Updated to take advantage of the request unreference no longer requiring the mutex lock. For: VIZ-5190 Signed-off-by: John Harrison john.c.harri...@intel.com --- [snip] @@ -1382,6 +1387,10 @@ static void i915_gem_request_retire(struct drm_i915_gem_request *request) list_del_init(request-list); i915_gem_request_remove_from_client(request); + /* In case the request is still in the signal pending list */ + if (!list_empty(request-signal_list)) + request-cancelled = true; + Another thing I did not see implemented is the sync_fence error state. This is more about the Android part, but related to this canceled flag so I am commenting here. I thought when TDR kicks in and we set request-cancelled to true, there should be a code path which somehow makes sync_fence-status negative. As it is, because fence_signal will not be called on canceled, I thought waiters will wait until timeout, rather than being woken up and return error status. For this to work you would somehow need to make sync_fence-status go negative. With normal fence completion it goes from 1 - 0, via the completion callback. I did not immediately see how to make it go negative using the existing API. I think back when we did struct fence we decided that we won't care yet about forwarding error state since doing that across drivers if you have a chain of fences looked complicated. And no one had any clear idea about what kind of semantics we really want. If we want this we'd need to add it, but probably better to do that as a follow-up (usual caveat about open-source userspace and demonstration vehicles apply and all that). Hm, I am not sure but it feels to me not having an error state is a problem. Without it userspace can just keep waiting and waiting upon a fence even though the driver has discarded that workload and never plans to resubmit it. Am I missing something? fences still must complete eventually, they simply won't tell you whether the gpu died before completing the fence or not. Which is in line with gl spec for fences and arb_robustness - inquiring about gpu hangs is done through sideband apis. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Split sink_crc function in start, stop and read.
On Thu, Jul 30, 2015 at 04:26:39PM -0700, Rodrigo Vivi wrote:
This is just a preparation patch to make clear what operation we
are performing. There is no functional change on the sink crc
logic.
hsw_disable_ips has been moved a bit further in the start function
to avoid disabling ips when sink crc is not going to be started.
and to avoid goto on this function.
v2: explain why hsw_disable_ips() call place has changed.
Cc: Daniel Vetter daniel.vet...@ffwll.ch
Reviewed-by: Rafael Antognolli rafael.antogno...@intel.com
Signed-off-by: Rodrigo Vivi rodrigo.v...@intel.com
Thanks for the updated commit message. Queued for -next, thanks for the
patch.
-Daniel
---
drivers/gpu/drm/i915/intel_dp.c | 89
+++--
1 file changed, 50 insertions(+), 39 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 44f8a32..10cbc98 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -3958,40 +3958,64 @@ intel_dp_probe_mst(struct intel_dp *intel_dp)
return intel_dp-is_mst;
}
-int intel_dp_sink_crc(struct intel_dp *intel_dp, u8 *crc)
+static void intel_dp_sink_crc_stop(struct intel_dp *intel_dp)
{
- struct intel_digital_port *intel_dig_port = dp_to_dig_port(intel_dp);
- struct drm_device *dev = intel_dig_port-base.base.dev;
- struct intel_crtc *intel_crtc =
- to_intel_crtc(intel_dig_port-base.base.crtc);
+ struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp);
+ struct intel_crtc *intel_crtc = to_intel_crtc(dig_port-base.base.crtc);
u8 buf;
- int test_crc_count;
- int attempts = 6;
- int ret = 0;
-
- hsw_disable_ips(intel_crtc);
- if (drm_dp_dpcd_readb(intel_dp-aux, DP_TEST_SINK_MISC, buf) 0) {
- ret = -EIO;
- goto out;
+ if (drm_dp_dpcd_readb(intel_dp-aux, DP_TEST_SINK, buf) 0) {
+ DRM_DEBUG_KMS(Sink CRC couldn't be stopped properly\n);
+ return;
}
- if (!(buf DP_TEST_CRC_SUPPORTED)) {
- ret = -ENOTTY;
- goto out;
- }
+ if (drm_dp_dpcd_writeb(intel_dp-aux, DP_TEST_SINK,
+buf ~DP_TEST_SINK_START) 0)
+ DRM_DEBUG_KMS(Sink CRC couldn't be stopped properly\n);
- if (drm_dp_dpcd_readb(intel_dp-aux, DP_TEST_SINK, buf) 0) {
- ret = -EIO;
- goto out;
- }
+ hsw_enable_ips(intel_crtc);
+}
+
+static int intel_dp_sink_crc_start(struct intel_dp *intel_dp)
+{
+ struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp);
+ struct intel_crtc *intel_crtc = to_intel_crtc(dig_port-base.base.crtc);
+ u8 buf;
+
+ if (drm_dp_dpcd_readb(intel_dp-aux, DP_TEST_SINK_MISC, buf) 0)
+ return -EIO;
+
+ if (!(buf DP_TEST_CRC_SUPPORTED))
+ return -ENOTTY;
+
+ if (drm_dp_dpcd_readb(intel_dp-aux, DP_TEST_SINK, buf) 0)
+ return -EIO;
+
+ hsw_disable_ips(intel_crtc);
if (drm_dp_dpcd_writeb(intel_dp-aux, DP_TEST_SINK,
- buf | DP_TEST_SINK_START) 0) {
- ret = -EIO;
- goto out;
+buf | DP_TEST_SINK_START) 0) {
+ hsw_enable_ips(intel_crtc);
+ return -EIO;
}
+ return 0;
+}
+
+int intel_dp_sink_crc(struct intel_dp *intel_dp, u8 *crc)
+{
+ struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp);
+ struct drm_device *dev = dig_port-base.base.dev;
+ struct intel_crtc *intel_crtc = to_intel_crtc(dig_port-base.base.crtc);
+ u8 buf;
+ int test_crc_count;
+ int attempts = 6;
+ int ret;
+
+ ret = intel_dp_sink_crc_start(intel_dp);
+ if (ret)
+ return ret;
+
if (drm_dp_dpcd_readb(intel_dp-aux, DP_TEST_SINK_MISC, buf) 0) {
ret = -EIO;
goto stop;
@@ -4014,23 +4038,10 @@ int intel_dp_sink_crc(struct intel_dp *intel_dp, u8
*crc)
goto stop;
}
- if (drm_dp_dpcd_read(intel_dp-aux, DP_TEST_CRC_R_CR, crc, 6) 0) {
+ if (drm_dp_dpcd_read(intel_dp-aux, DP_TEST_CRC_R_CR, crc, 6) 0)
ret = -EIO;
- goto stop;
- }
-
stop:
- if (drm_dp_dpcd_readb(intel_dp-aux, DP_TEST_SINK, buf) 0) {
- DRM_DEBUG_KMS(Sink CRC couldn't be stopped properly\n);
- goto out;
- }
- if (drm_dp_dpcd_writeb(intel_dp-aux, DP_TEST_SINK,
-buf ~DP_TEST_SINK_START) 0) {
- DRM_DEBUG_KMS(Sink CRC couldn't be stopped properly\n);
- goto out;
- }
-out:
- hsw_enable_ips(intel_crtc);
+ intel_dp_sink_crc_stop(intel_dp);
return ret;
}
--
2.1.0
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: VLV/CHV PSR: Increase wait delay time before active PSR.
On Thu, Jul 30, 2015 at 05:07:55PM -0700, Rodrigo Vivi wrote:
Since active function on VLV immediately activate PSR let's give more
time for idleness. Different from core platforms where we have idle_frames
count.
Also kms_psr_sink_crc now is automated and always get this:
[drm:intel_enable_pipe] enabling pipe A
[drm:intel_edp_backlight_on]
[drm:intel_panel_enable_backlight] pipe
[drm:intel_panel_enable_backlight] pipe A
[drm:intel_panel_actually_set_backlight] set backlight PWM = 7812
PSR gets enabled somewhere here after backlight.
[drm:intel_get_hpd_pins] hotplug event received, stat 0x, dig 0x0
[drm:vlv_pipe_set_fifo_size] Pipe A FIFO split 511 / 511 / 511
[drm:vlv_update_wm] Setting FIFO watermarks - A: plane=391, cursor=63, sp
PSR gets flushed around here by intel_atomic_commit
[drm:vlv_pipe_set_fifo_size] Pipe A FIFO split 511 / 511 / 511
[drm:vlv_update_wm] Setting FIFO watermarks - A: plane=391, cursor=63, sp
[drm:intel_set_memory_cxsr] memory self-refresh is enabled
[drm:intel_connector_check_state] [CONNECTOR:39:eDP-1]
[drm:check_encoder_state] [ENCODER:30:DAC-30]
[drm:check_encoder_state] [ENCODER:31:TMDS-31]
[drm:check_encoder_state] [ENCODER:36:TMDS-36]
[drm:check_encoder_state] [ENCODER:38:TMDS-38]
[drm:check_crtc_state] [CRTC:21]
[drm:check_crtc_state] [CRTC:26]
[drm:intel_psr_activate [i915]] *ERROR* PSR Active
[drm:intel_get_hpd_pins] hotplug event received, stat 0x, dig 0x
[drm:intel_set_cpu_fifo_underrun_reporting [i915]] *ERROR* pipe A underrun
[drm:intel_cpu_fifo_underrun_irq_handler [i915]] *ERROR* CPU pipe A FIFO
Underrun.
It is true that in a product we won't keep disabling and enabling planes so
frequently, but for safeness let's stay conservative.
It is also true that 500ms is an etternity. But PSR is anyway a power saving
feature for idle scenario. So if it is idle feature stays on and 500ms to get
it reanabled is not that insane.
Yeah I really like this level of detail in commit messages for tricky
bugs. Queued for -next, thanks for the patch.
-Daniel
v2: Rebase over intel_psr.c and fix typo.
v3: Revival: Manual tests indicated that this is needed. With a short delay
there is a huge risk of getting blank screens when planes are being
enabled.
v4: Revival 2 with reasonable delay. 1/2 sec instead of 5. VBT is 10 sec but
actually time for link training what we aren't doing, but with only 100
sec
in some cases kms_psr_sink_crc manual was showing blank screen,
so let's use this for now. Also changed comment by a FIXME.
v5: Rebase after a long time, remove FIXME and update comment above.
v6: msecs_to_jiffies is already on delay. remove duplication.
v7: use msecs_to_jiffies on schedule_delayed_work call.
Reviewed-by: Durgadoss R durgados...@intel.com (v4)
Signed-off-by: Rodrigo Vivi rodrigo.v...@intel.com
Tested-By: Intel Graphics QA PRTS (Patch Regression Test System Contact:
shuang...@intel.com)
Signed-off-by: Rodrigo Vivi rodrigo.v...@intel.com
---
drivers/gpu/drm/i915/intel_psr.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_psr.c
b/drivers/gpu/drm/i915/intel_psr.c
index acd8ec8..a04b4dc 100644
--- a/drivers/gpu/drm/i915/intel_psr.c
+++ b/drivers/gpu/drm/i915/intel_psr.c
@@ -698,6 +698,7 @@ void intel_psr_flush(struct drm_device *dev,
struct drm_i915_private *dev_priv = dev-dev_private;
struct drm_crtc *crtc;
enum pipe pipe;
+ int delay_ms = HAS_DDI(dev) ? 100 : 500;
mutex_lock(dev_priv-psr.lock);
if (!dev_priv-psr.enabled) {
@@ -733,7 +734,7 @@ void intel_psr_flush(struct drm_device *dev,
if (!dev_priv-psr.active !dev_priv-psr.busy_frontbuffer_bits)
schedule_delayed_work(dev_priv-psr.work,
- msecs_to_jiffies(100));
+ msecs_to_jiffies(delay_ms));
mutex_unlock(dev_priv-psr.lock);
}
--
2.1.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] tools/null_state/gen9: Send atleast one valid component in VF state
Ben Widawsky benjamin.widaw...@intel.com writes: On Fri, Jul 31, 2015 at 04:27:07PM +0100, Arun Siluvery wrote: A programming restriction exists for this instruction, atleast one component of one valid vertex element must be enabled. Cc: Ben Widawsky benjamin.widaw...@intel.com Cc: Chris Wilson ch...@chris-wilson.co.uk Signed-off-by: Arun Siluvery arun.siluv...@linux.intel.com --- tools/null_state_gen/intel_renderstate_gen9.c | 7 ++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/tools/null_state_gen/intel_renderstate_gen9.c b/tools/null_state_gen/intel_renderstate_gen9.c index 6f808f8..b3766ea 100644 --- a/tools/null_state_gen/intel_renderstate_gen9.c +++ b/tools/null_state_gen/intel_renderstate_gen9.c @@ -440,7 +440,12 @@ int gen9_setup_null_render_state(struct intel_batchbuffer *batch) /* Vertex buffers */ gen8_emit_vertex_buffers(batch); gen8_emit_vertex_elements(batch); -OUT_CMD(GEN9_3DSTATE_COMPONENT_PACKING, 5); + +OUT_BATCH(GEN9_3DSTATE_COMPONENT_PACKING | 3); +OUT_BATCH(1); +OUT_BATCH(0); +OUT_BATCH(0); +OUT_BATCH(0); OUT_BATCH(GEN6_3DSTATE_VF_STATISTICS | 1 /* Enable */); Like I said on IRC, I don't think this does anything unless you set bit 9 of 3DSTATE_VF.0. Also, I believe you should be setting 0xf, not 1 since you'd want to use all 4 components. So I'm not really sure what we're aiming to do. If you make it 0xf, and add a comment about how this command doesn't do anything because we're not setting up 3DSTATE_VF packing, it's: Reviewed-by: Ben Widawsky b...@bwidawsk.net I'm still more in favor of dropping the command altogether, that too would be: Reviewed-by: Ben Widawsky b...@bwidawsk.net We are trying here just to satisfy the minimum requirements the bspec states. The bspec also states that with gen9+, the 3d pipeline state doesn't need to be initialized. We should seek confirmation about this and if it is so, remove the null state for gen9+. -Mika -- Ben Widawsky, Intel Open Source Technology Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/skl: revert duplicated WaBarrierPerformanceFixDisable:skl
On Thu, Jul 30, 2015 at 02:52:07PM -0700, Rodrigo Vivi wrote:
good catch.
Reviewed-by: Rodrigo Vivi rodrigo.v...@intel.com
Queued for -next, thanks for the patch.
-Daniel
On Wed, Jul 29, 2015 at 12:21 PM, Marc Herbert marc.herb...@intel.com wrote:
With this simple git diff command one can see that skl_init_workarounds()
got two copies of WaBarrierPerformanceFixDisable:skl:
git diff -U21 ca6e4405779e^1 ca6e4405779e
drivers/gpu/drm/i915/intel_ringbuffer.c
This happened when the backmerge of drm-intel-fixes-2015-07-15
Merged the same fix on both sides. Same fix but not identical enough for
git: with a different surrounding context; hence the code duplication.
This commit merely reverts the output of the git command above
= the duplication introduced in the backmerge.
(This duplication was found while running git sanity checks on a
_linearized_ i915 forklift for ChromeOS.)
Signed-off-by: Marc Herbert marc.herb...@intel.com
---
drivers/gpu/drm/i915/intel_ringbuffer.c | 7 ---
1 file changed, 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c
b/drivers/gpu/drm/i915/intel_ringbuffer.c
index 177f7ed16cf0..1c14233d179f 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.c
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
@@ -1041,13 +1041,6 @@ static int skl_init_workarounds(struct
intel_engine_cs *ring)
WA_SET_BIT_MASKED(HIZ_CHICKEN,
BDW_HIZ_POWER_COMPILER_CLOCK_GATING_DISABLE);
- if (INTEL_REVID(dev) == SKL_REVID_C0 ||
- INTEL_REVID(dev) == SKL_REVID_D0)
- /* WaBarrierPerformanceFixDisable:skl */
- WA_SET_BIT_MASKED(HDC_CHICKEN0,
- HDC_FENCE_DEST_SLM_DISABLE |
- HDC_BARRIER_PERFORMANCE_DISABLE);
-
if (INTEL_REVID(dev) = SKL_REVID_D0) {
/*
*Use Force Non-Coherent whenever executing a 3D context.
This
--
2.1.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Rodrigo Vivi
Blog: http://blog.vivi.eng.br
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/6] drm/atomic: pass old crtc state to atomic_begin/flush.
Hi, On 21/07/15 14:28, Maarten Lankhorst wrote: In intel it's useful to keep track of some state changes with old crtc state vs new state, for example to disable initial planes or when a modeset's prevented during fastboot. Cc: dri-de...@lists.freedesktop.org Signed-off-by: Maarten Lankhorst maarten.lankho...@linux.intel.com --- drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c | 6 -- drivers/gpu/drm/drm_atomic_helper.c| 8 drivers/gpu/drm/drm_plane_helper.c | 4 ++-- drivers/gpu/drm/i915/intel_display.c | 10 ++ drivers/gpu/drm/msm/mdp/mdp4/mdp4_crtc.c | 6 -- drivers/gpu/drm/msm/mdp/mdp5/mdp5_crtc.c | 6 -- drivers/gpu/drm/rcar-du/rcar_du_crtc.c | 6 -- drivers/gpu/drm/sti/sti_drm_crtc.c | 6 -- drivers/gpu/drm/tegra/dc.c | 6 -- include/drm/drm_crtc_helper.h | 6 -- 10 files changed, 40 insertions(+), 24 deletions(-) Looks like this broke omapdrm in linux-next: drivers/gpu/drm/omapdrm/omap_crtc.c:470:2: error: initialization from incompatible pointer type [-Werror] drivers/gpu/drm/omapdrm/omap_crtc.c:470:2: error: (near initialization for ‘omap_crtc_helper_funcs.atomic_begin’) [-Werror] drivers/gpu/drm/omapdrm/omap_crtc.c:471:2: error: initialization from incompatible pointer type [-Werror] drivers/gpu/drm/omapdrm/omap_crtc.c:471:2: error: (near initialization for ‘omap_crtc_helper_funcs.atomic_flush’) [-Werror] Tomi signature.asc Description: OpenPGP digital signature ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 3/4] drm/i915: Make turning on/off PW1 and Misc I/O part of the init/fini sequences
On Thu, Jul 30, 2015 at 06:20:28PM -0300, Paulo Zanoni wrote:
From: Damien Lespiau damien.lesp...@intel.com
Before this patch, we used the intel_display_power_{get,put} functions
to make sure the PW1 and Misc I/O power wells were enabled all the
time while LCPLL was enabled. We called a get() at
intel_ddi_pll_init() when we discovered that LCPLL was enabled, then
we would call put/get at skl_{un,}init_cdclk().
The problem is that skl_uninit_cdclk() is indirectly called by
intel_runtime_suspend(). So it will only release its power well
_after_ we already decided to runtime suspend. But since we only
decide to runtime suspend after all power wells and refcounts are
released, that basically means we will never decide to runtime
suspend.
So what this patch does to fix that problem is move the PW1 + Misc I/O
power well handling out of the runtime PM mechanism: instead of
calling intel_display_power_{get_put} - functions that touch the
refcount -, we'll call the low level intel_power_well_{en,dis}able,
which don't change the refcount. This way, it is now possible for the
refcount to actually reach zero, and we'll now start runtime
suspending/resuming.
v2 (from Paulo):
- Write a commit message since the original patch left it empty.
- Rebase after the intel_power_well_{en,dis}able rename.
- Use lookup_power_well() instead of hardcoded indexes.
Testcase: igt/pm_rpm/rte (and every other rpm test)
Signed-off-by: Damien Lespiau damien.lesp...@intel.com
Reviewed-by: Paulo Zanoni paulo.r.zan...@intel.com
Signed-off-by: Paulo Zanoni paulo.r.zan...@intel.com
This is imo too much of a hack. If we go with this then we should either
completely remove the pw1 and misc pw from the power well code and just
directly call the relevant functions.
Or we fix up the ordering and stop lcpll before dropping pw1, which
probably means that skl dp aux and gmbus need to adjust their divisors for
every transaction since those change when lcpll changes.
I don't really have clue about which is the right option, but it seems
like dmc will take control of pw1pw-misc anyway, so probably we don't
need to manage them explicitly on skl anyway.
-Daniel
---
drivers/gpu/drm/i915/intel_ddi.c| 2 --
drivers/gpu/drm/i915/intel_display.c| 5 +++--
drivers/gpu/drm/i915/intel_drv.h| 2 ++
drivers/gpu/drm/i915/intel_runtime_pm.c | 29 +
4 files changed, 34 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_ddi.c
b/drivers/gpu/drm/i915/intel_ddi.c
index 9a40bfb..e629ad3 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -2931,8 +2931,6 @@ void intel_ddi_pll_init(struct drm_device *dev)
dev_priv-skl_boot_cdclk = cdclk_freq;
if (!(I915_READ(LCPLL1_CTL) LCPLL_PLL_ENABLE))
DRM_ERROR(LCPLL1 is disabled\n);
- else
- intel_display_power_get(dev_priv, POWER_DOMAIN_PLLS);
} else if (IS_BROXTON(dev)) {
broxton_init_cdclk(dev);
broxton_ddi_phy_init(dev);
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 43b0f17..34cbe4a 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -5680,7 +5680,8 @@ void skl_uninit_cdclk(struct drm_i915_private *dev_priv)
if (wait_for(!(I915_READ(LCPLL1_CTL) LCPLL_PLL_LOCK), 1))
DRM_ERROR(Couldn't disable DPLL0\n);
- intel_display_power_put(dev_priv, POWER_DOMAIN_PLLS);
+ /* disable PG1 and Misc I/O */
+ skl_pw1_misc_io_fini(dev_priv);
}
void skl_init_cdclk(struct drm_i915_private *dev_priv)
@@ -5693,7 +5694,7 @@ void skl_init_cdclk(struct drm_i915_private *dev_priv)
I915_WRITE(HSW_NDE_RSTWRN_OPT, val | RESET_PCH_HANDSHAKE_ENABLE);
/* enable PG1 and Misc I/O */
- intel_display_power_get(dev_priv, POWER_DOMAIN_PLLS);
+ skl_pw1_misc_io_init(dev_priv);
/* DPLL0 already enabed !? */
if (I915_READ(LCPLL1_CTL) LCPLL_PLL_ENABLE) {
diff --git a/drivers/gpu/drm/i915/intel_drv.h
b/drivers/gpu/drm/i915/intel_drv.h
index 320c9e6..10e8a2f 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -1325,6 +1325,8 @@ void intel_psr_single_frame_update(struct drm_device
*dev,
int intel_power_domains_init(struct drm_i915_private *);
void intel_power_domains_fini(struct drm_i915_private *);
void intel_power_domains_init_hw(struct drm_i915_private *dev_priv);
+void skl_pw1_misc_io_init(struct drm_i915_private *dev_priv);
+void skl_pw1_misc_io_fini(struct drm_i915_private *dev_priv);
void intel_runtime_pm_enable(struct drm_i915_private *dev_priv);
bool intel_display_power_is_enabled(struct drm_i915_private *dev_priv,
diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c
b/drivers/gpu/drm/i915/intel_runtime_pm.c
index 821644d..d62b030
Re: [Intel-gfx] [PATCH] drm/i915: fix stolen bios_reserved checks
On Tue, Aug 04, 2015 at 06:30:08PM -0300, Paulo Zanoni wrote:
I started digging this when I noticed that the BDW code was just
reserving 1mb by coincidence since it was reading reserved fields.
Then I noticed we didn't have any values set for SNB and earlier, and
that the HSW sizes were wrong. After that, I noticed that the reserved
area has a specific start, and may not exactly end where the stolen
memory ends. I also noticed the base pointer can be zero. So I decided
to just write a single patch fixing everything instead of 20 patches
that would be much harder to review.
This patch may solve random stolen memory corruption/problems on
almost all platforms. Notice that since this is always dealing with
the top of the stolen memory, the problems are not so easy to
reproduce - especially since FBC is still disabled by default.
One of the major differences of this patch is that we now look at both
the size and base address. By only looking at the size we were
assuming that the bios reserved area was always at the very top of
stolen, which is not always true: I have a HSW machine that falls into
this category.
After we merge the patch series that allows user space to allocate
stolen memory we'll be able to write IGT tests that maybe catch the
bugs fixed by this patch.
Looks fun. Whilst we are here, can we drop the notion of BIOS reserved
and just label it as resered. It is reserved for functional aspects of
the display engine, not for the bios itself. (Calling it BIOS reserved
either makes me think the BIOS is operating behind our backs or the
reservation is only required across suspend etc)
GEN6_STOLEN_RESERVED makes much more sense both here and out-of-context.
int i915_gem_init_stolen(struct drm_device *dev)
{
struct drm_i915_private *dev_priv = dev-dev_private;
- u32 tmp;
- int bios_reserved = 0;
+ unsigned long bios_rsvd_total, bios_rsvd_base, bios_rsvd_size;
+ unsigned long stolen_top;
mutex_init(dev_priv-mm.stolen_lock);
@@ -211,23 +303,61 @@ int i915_gem_init_stolen(struct drm_device *dev)
DRM_DEBUG_KMS(found %zd bytes of stolen memory at %08lx\n,
dev_priv-gtt.stolen_size, dev_priv-mm.stolen_base);
- if (INTEL_INFO(dev)-gen = 8) {
- tmp = I915_READ(GEN7_BIOS_RESERVED);
- tmp = GEN8_BIOS_RESERVED_SHIFT;
- tmp = GEN8_BIOS_RESERVED_MASK;
- bios_reserved = (1024*1024) tmp;
- } else if (IS_GEN7(dev)) {
- tmp = I915_READ(GEN7_BIOS_RESERVED);
- bios_reserved = tmp GEN7_BIOS_RESERVED_256K ?
- 256*1024 : 1024*1024;
+ stolen_top = dev_priv-mm.stolen_base + dev_priv-gtt.stolen_size;
+
+ switch (INTEL_INFO(dev_priv)-gen) {
+ case 2:
+ case 3:
+ case 4:
+ case 5:
+ /* Assume the gen6 maximum for the older platforms. */
+ bios_rsvd_size = 1024 * 1024;
+ bios_rsvd_base = stolen_top - bios_rsvd_size;
+ break;
+ case 6:
+ gen6_get_bios_reserved(dev_priv, bios_rsvd_base,
+bios_rsvd_size);
+ break;
+ case 7:
+ if (IS_HASWELL(dev_priv))
+ gen6_get_bios_reserved(dev_priv, bios_rsvd_base,
+bios_rsvd_size);
+ else
+ gen7_get_bios_reserved(dev_priv, bios_rsvd_base,
+bios_rsvd_size);
+ break;
+ default:
+ if (IS_BROADWELL(dev_priv) || IS_SKYLAKE(dev_priv))
+ bdw_get_bios_reserved(dev_priv, bios_rsvd_base,
+ bios_rsvd_size);
+ else
+ gen8_get_bios_reserved(dev_priv, bios_rsvd_base,
+bios_rsvd_size);
+ break;
+ }
+
+ /* It is possible for the BIOS reserved base to be zero, but the
+ * register field for size doesn't have a zero option. */
+ if (bios_rsvd_base == 0) {
+ bios_rsvd_size = 0;
+ bios_rsvd_base = stolen_top;
}
- if (WARN_ON(bios_reserved dev_priv-gtt.stolen_size))
+ if (bios_rsvd_base dev_priv-mm.stolen_base ||
+ bios_rsvd_base + bios_rsvd_size stolen_top) {
+ DRM_ERROR(BIOS reserved area outside stolen memory\n);
This is not a driver error, nor something the user can fix, and the
message doesn't contain enough clues for the developer.
DRM_DEBUG_DRIVER(Reserved area [%x+%x] outside of stolen memory [%x+%x]\n,
...)
If you add a DRM_INFO() to report the amount of memory reserved by the
BIOS for the GPU and the amount of memory usable, that is both
interesting for the user (they see something that vaguely resembles a
BIOS option) and for us.
e.g.
DRM_INFO(Memory reserved for graphics device = %luM, usable %luM,
Re: [Intel-gfx] [PATCH igt] tests/gem_mmap_wc: SKIP if the Kernel is too old for the getparam flag
On Tue, Aug 04, 2015 at 04:53:11PM -0300, Paulo Zanoni wrote: If the Kernel is too old, getparam will return -EINVAL. Just SKIP on this case. Nope. Just replace do_ioctl() with drmIoctl. Better would be to actually do a gem_get_param(). -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Tone done *ERROR* for an expected VBT condition
On Fri, Jul 31, 2015 at 11:15:27AM +0100, Chris Wilson wrote:
Older VBT (e.g. gen2) have smaller child block defintions, so do not cry
wolf over an error that is outside of our control and is not an error
anyway.
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
---
drivers/gpu/drm/i915/intel_bios.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_bios.c
b/drivers/gpu/drm/i915/intel_bios.c
index 2ff9eb00fdec..f8afbafa8e02 100644
--- a/drivers/gpu/drm/i915/intel_bios.c
+++ b/drivers/gpu/drm/i915/intel_bios.c
@@ -1023,7 +1023,7 @@ parse_device_mapping(struct drm_i915_private *dev_priv,
return;
}
if (p_defs-child_dev_size sizeof(*p_child)) {
This line was added in
commit 90e4f1592bb6e82f6690f0e05a8aadcf04d7bce7
Author: Ville Syrjälä ville.syrj...@linux.intel.com
Date: Wed Mar 25 18:45:58 2015 +0200
drm/i915: Fix the VBT child device parsing for BSW
Since vbt is complete pain I started requiring that we match expected
sizes with vbt versions. Can some one please fix this?
Or we can just revert the old patch.
-Daniel
- DRM_ERROR(General definiton block child device size is too
small.\n);
+ DRM_DEBUG_KMS(General definiton block child device size is too
small.\n);
return;
}
/* get the block size of general definitions */
--
2.5.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/5] lib: adding drm_open_driver() interface
On Fri, Jul 31, 2015 at 04:11:07PM -0400, Micah Fedke wrote:
---
lib/drmtest.c | 108
++
lib/drmtest.h | 18 +++---
2 files changed, 86 insertions(+), 40 deletions(-)
diff --git a/lib/drmtest.c b/lib/drmtest.c
index ee5c123..4e3ddd6 100644
--- a/lib/drmtest.c
+++ b/lib/drmtest.c
@@ -75,23 +75,43 @@
uint16_t __drm_device_id;
-static int is_i915_device(int fd)
+/**
+ * __get_drm_device_name:
+ *
+ * Obtains the name of the drm device driver of the opened drm fd
+ *
+ * @fd: opened drm file descriptor to query
+ * @name: output: pointer to string to be filled with the device name
+ *
+ * Returns:
+ * 0 if the name was successfully written to @name, or -1 on error
+ */
We don't do api docs for static functions. And imo this doesn't need a
comment either. lgtm otherwise.
-Daniel
+static int __get_drm_device_name(int fd, char *name)
{
drm_version_t version;
- char name[5] = ;
memset(version, 0, sizeof(version));
version.name_len = 4;
version.name = name;
- if (drmIoctl(fd, DRM_IOCTL_VERSION, version))
+ if (!drmIoctl(fd, DRM_IOCTL_VERSION, version)){
return 0;
+ }
- return strcmp(i915, name) == 0;
+ return -1;
}
-static int
-is_intel(int fd)
+static bool is_i915_device(int fd)
+{
+ int ret;
+ char name[5] = ;
+
+ ret = __get_drm_device_name(fd, name);
+
+ return !ret strcmp(i915, name) == 0;
+}
+
+static bool is_intel(int fd)
{
struct drm_i915_getparam gp;
int devid = 0;
@@ -101,13 +121,13 @@ is_intel(int fd)
gp.value = devid;
if (ioctl(fd, DRM_IOCTL_I915_GETPARAM, gp, sizeof(gp)))
- return 0;
+ return false;
if (!IS_INTEL(devid))
- return 0;
+ return false;
__drm_device_id = devid;
- return 1;
+ return true;
}
static void check_stop_rings(void)
@@ -230,19 +250,31 @@ int drm_get_card(void)
return -1;
}
-/** Open the first DRM device we can find, searching up to 16 device nodes */
-int __drm_open_any(void)
+/**
+ * __drm_open_driver:
+ *
+ * Open the first DRM device we can find, searching up to 16 device nodes
+ *
+ * @chipset: OR'd flags for each chipset to search, eg. DRIVER_INTEL
+ *
+ * Returns:
+ * An open DRM fd or -1 on error
+ */
+int __drm_open_driver(int chipset)
{
for (int i = 0; i 16; i++) {
char name[80];
int fd;
+ bool found_intel;
sprintf(name, /dev/dri/card%u, i);
fd = open(name, O_RDWR);
if (fd == -1)
continue;
+
+ found_intel = is_i915_device(fd) is_intel(fd) (chipset
DRIVER_INTEL);
- if (is_i915_device(fd) is_intel(fd))
+ if ((chipset OPEN_ANY_GPU) || found_intel)
return fd;
close(fd);
@@ -252,7 +284,7 @@ int __drm_open_any(void)
return -1;
}
-static int __drm_open_any_render(void)
+static int __drm_open_driver_render(int chipset)
{
char *name;
int i, fd;
@@ -307,41 +339,43 @@ static void quiescent_gpu_at_exit_render(int sig)
}
/**
- * drm_open_any:
+ * drm_open_driver:
*
- * Open an i915 drm legacy device node. This function always returns a valid
+ * Open a drm legacy device node. This function always returns a valid
* file descriptor.
*
- * Returns: a i915 drm file descriptor
+ * Returns: a drm file descriptor
*/
-int drm_open_any(void)
+int drm_open_driver(int chipset)
{
static int open_count;
- int fd = __drm_open_any();
+ int fd = __drm_open_driver(chipset);
igt_require(fd = 0);
if (__sync_fetch_and_add(open_count, 1))
return fd;
- gem_quiescent_gpu(fd);
- at_exit_drm_fd = __drm_open_any();
- igt_install_exit_handler(quiescent_gpu_at_exit);
+ if(chipset DRIVER_INTEL){
+gem_quiescent_gpu(fd);
+igt_install_exit_handler(quiescent_gpu_at_exit);
+ }
+ at_exit_drm_fd = __drm_open_driver(chipset);
return fd;
}
/**
- * drm_open_any_master:
+ * drm_open_driver_master:
*
- * Open an i915 drm legacy device node and ensure that it is drm master.
+ * Open a drm legacy device node and ensure that it is drm master.
*
* Returns:
- * The i915 drm file descriptor or -1 on error
+ * The drm file descriptor or -1 on error
*/
-int drm_open_any_master(void)
+int drm_open_driver_master(int chipset)
{
- int fd = drm_open_any();
+ int fd = drm_open_driver(chipset);
igt_require(fd = 0);
igt_require_f(drmSetMaster(fd) == 0, Can't become DRM master,
@@ -351,28 +385,30 @@ int drm_open_any_master(void)
}
/**
- * drm_open_any_render:
+ * drm_open_driver_render:
*
- * Open an i915 drm render device node.
+ * Open a drm render
Re: [Intel-gfx] [PATCH 2/5] convert drm_open_any*() calls to drm_open_driver*(DRIVER_INTEL) calls with cocci
On Fri, Jul 31, 2015 at 04:11:08PM -0400, Micah Fedke wrote: As Chris suggested please include the cocci snippet in the commit message. It's easier to review that than the massive patch. Also in case of conflicts I can just regen. In general please don't do 1-line commit message like in this entire series. Usually there's a bit to say about motivation and stuff like that for a given change, and that should be included. Also we more-or-less follow http://developercertificate.org/ for igt too, so please include your signed-off-yb lines. -Daniel --- benchmarks/gem_userptr_benchmark.c | 2 +- benchmarks/intel_upload_blit_large.c | 2 +- benchmarks/intel_upload_blit_large_gtt.c | 2 +- benchmarks/intel_upload_blit_large_map.c | 2 +- benchmarks/intel_upload_blit_small.c | 2 +- debugger/eudb.c | 2 +- lib/igt_gt.c | 2 +- lib/igt_kms.c| 2 +- tests/core_get_client_auth.c | 6 ++--- tests/core_getclient.c | 2 +- tests/core_getstats.c| 2 +- tests/core_getversion.c | 2 +- tests/drm_import_export.c| 4 ++-- tests/drm_read.c | 2 +- tests/drm_vma_limiter.c | 2 +- tests/drm_vma_limiter_cached.c | 2 +- tests/drm_vma_limiter_cpu.c | 2 +- tests/drm_vma_limiter_gtt.c | 2 +- tests/drv_getparams.c| 2 +- tests/drv_hangman.c | 4 ++-- tests/drv_suspend.c | 2 +- tests/eviction_common.c | 2 +- tests/gem_alive.c| 2 +- tests/gem_bad_address.c | 2 +- tests/gem_bad_batch.c| 2 +- tests/gem_bad_blit.c | 2 +- tests/gem_bad_length.c | 2 +- tests/gem_bad_reloc.c| 2 +- tests/gem_basic.c| 2 +- tests/gem_caching.c | 2 +- tests/gem_concurrent_blit.c | 4 ++-- tests/gem_cpu_reloc.c| 2 +- tests/gem_cs_prefetch.c | 2 +- tests/gem_cs_tlb.c | 2 +- tests/gem_ctx_bad_destroy.c | 2 +- tests/gem_ctx_bad_exec.c | 2 +- tests/gem_ctx_basic.c| 4 ++-- tests/gem_ctx_create.c | 2 +- tests/gem_ctx_exec.c | 2 +- tests/gem_ctx_param_basic.c | 2 +- tests/gem_ctx_thrash.c | 4 ++-- tests/gem_double_irq_loop.c | 2 +- tests/gem_dummy_reloc_loop.c | 4 ++-- tests/gem_evict_alignment.c | 2 +- tests/gem_evict_everything.c | 2 +- tests/gem_exec_bad_domains.c | 2 +- tests/gem_exec_big.c | 2 +- tests/gem_exec_blt.c | 2 +- tests/gem_exec_faulting_reloc.c | 2 +- tests/gem_exec_lut_handle.c | 2 +- tests/gem_exec_nop.c | 2 +- tests/gem_exec_params.c | 2 +- tests/gem_exec_parse.c | 2 +- tests/gem_fd_exhaustion.c| 2 +- tests/gem_fence_thrash.c | 2 +- tests/gem_fence_upload.c | 8 +++ tests/gem_fenced_exec_thrash.c | 2 +- tests/gem_flink.c| 6 ++--- tests/gem_flink_race.c | 6 ++--- tests/gem_gpgpu_fill.c | 2 +- tests/gem_gtt_cpu_tlb.c | 2 +- tests/gem_gtt_hog.c | 4 ++-- tests/gem_gtt_speed.c| 2 +- tests/gem_hang.c | 2 +- tests/gem_hangcheck_forcewake.c | 2 +- tests/gem_largeobject.c | 2 +- tests/gem_linear_blits.c | 2 +- tests/gem_lut_handle.c | 2 +- tests/gem_madvise.c | 8 +++ tests/gem_media_fill.c | 2 +- tests/gem_mmap.c | 2 +- tests/gem_mmap_gtt.c | 4 ++-- tests/gem_mmap_offset_exhaustion.c | 2 +- tests/gem_mmap_wc.c | 2 +- tests/gem_multi_bsd_sync_loop.c | 4 ++-- tests/gem_non_secure_batch.c | 2 +- tests/gem_partial_pwrite_pread.c | 2 +- tests/gem_persistent_relocs.c| 2 +- tests/gem_pin.c | 2 +- tests/gem_pipe_control_store_loop.c | 2 +- tests/gem_ppgtt.c| 4 ++-- tests/gem_pread.c| 2 +- tests/gem_pread_after_blit.c | 2 +- tests/gem_pwrite.c | 2 +- tests/gem_pwrite_pread.c | 2 +- tests/gem_readwrite.c| 2 +-
Re: [Intel-gfx] [PATCH 1/5] lib: adding drm_open_driver() interface
On Fri, Jul 31, 2015 at 04:11:07PM -0400, Micah Fedke wrote:
---
lib/drmtest.c | 108
++
lib/drmtest.h | 18 +++---
2 files changed, 86 insertions(+), 40 deletions(-)
diff --git a/lib/drmtest.c b/lib/drmtest.c
index ee5c123..4e3ddd6 100644
--- a/lib/drmtest.c
+++ b/lib/drmtest.c
@@ -75,23 +75,43 @@
uint16_t __drm_device_id;
-static int is_i915_device(int fd)
+/**
+ * __get_drm_device_name:
+ *
+ * Obtains the name of the drm device driver of the opened drm fd
+ *
+ * @fd: opened drm file descriptor to query
+ * @name: output: pointer to string to be filled with the device name
+ *
+ * Returns:
+ * 0 if the name was successfully written to @name, or -1 on error
+ */
+static int __get_drm_device_name(int fd, char *name)
{
drm_version_t version;
- char name[5] = ;
memset(version, 0, sizeof(version));
version.name_len = 4;
version.name = name;
- if (drmIoctl(fd, DRM_IOCTL_VERSION, version))
+ if (!drmIoctl(fd, DRM_IOCTL_VERSION, version)){
return 0;
+ }
- return strcmp(i915, name) == 0;
+ return -1;
}
-static int
-is_intel(int fd)
+static bool is_i915_device(int fd)
+{
+ int ret;
+ char name[5] = ;
+
+ ret = __get_drm_device_name(fd, name);
+
+ return !ret strcmp(i915, name) == 0;
+}
+
+static bool is_intel(int fd)
{
struct drm_i915_getparam gp;
int devid = 0;
@@ -101,13 +121,13 @@ is_intel(int fd)
gp.value = devid;
if (ioctl(fd, DRM_IOCTL_I915_GETPARAM, gp, sizeof(gp)))
- return 0;
+ return false;
if (!IS_INTEL(devid))
- return 0;
+ return false;
__drm_device_id = devid;
- return 1;
+ return true;
}
static void check_stop_rings(void)
@@ -230,19 +250,31 @@ int drm_get_card(void)
return -1;
}
-/** Open the first DRM device we can find, searching up to 16 device nodes */
-int __drm_open_any(void)
+/**
+ * __drm_open_driver:
+ *
+ * Open the first DRM device we can find, searching up to 16 device nodes
+ *
+ * @chipset: OR'd flags for each chipset to search, eg. DRIVER_INTEL
+ *
+ * Returns:
+ * An open DRM fd or -1 on error
+ */
+int __drm_open_driver(int chipset)
{
for (int i = 0; i 16; i++) {
char name[80];
int fd;
+ bool found_intel;
sprintf(name, /dev/dri/card%u, i);
fd = open(name, O_RDWR);
if (fd == -1)
continue;
+
+ found_intel = is_i915_device(fd) is_intel(fd) (chipset
DRIVER_INTEL);
- if (is_i915_device(fd) is_intel(fd))
+ if ((chipset OPEN_ANY_GPU) || found_intel)
return fd;
close(fd);
@@ -252,7 +284,7 @@ int __drm_open_any(void)
return -1;
}
-static int __drm_open_any_render(void)
+static int __drm_open_driver_render(int chipset)
{
char *name;
int i, fd;
@@ -307,41 +339,43 @@ static void quiescent_gpu_at_exit_render(int sig)
}
/**
- * drm_open_any:
+ * drm_open_driver:
*
- * Open an i915 drm legacy device node. This function always returns a valid
+ * Open a drm legacy device node. This function always returns a valid
* file descriptor.
*
- * Returns: a i915 drm file descriptor
+ * Returns: a drm file descriptor
*/
-int drm_open_any(void)
+int drm_open_driver(int chipset)
{
static int open_count;
- int fd = __drm_open_any();
+ int fd = __drm_open_driver(chipset);
igt_require(fd = 0);
if (__sync_fetch_and_add(open_count, 1))
return fd;
- gem_quiescent_gpu(fd);
- at_exit_drm_fd = __drm_open_any();
- igt_install_exit_handler(quiescent_gpu_at_exit);
+ if(chipset DRIVER_INTEL){
+gem_quiescent_gpu(fd);
+igt_install_exit_handler(quiescent_gpu_at_exit);
+ }
+ at_exit_drm_fd = __drm_open_driver(chipset);
return fd;
}
/**
- * drm_open_any_master:
+ * drm_open_driver_master:
*
- * Open an i915 drm legacy device node and ensure that it is drm master.
+ * Open a drm legacy device node and ensure that it is drm master.
*
* Returns:
- * The i915 drm file descriptor or -1 on error
+ * The drm file descriptor or -1 on error
*/
-int drm_open_any_master(void)
+int drm_open_driver_master(int chipset)
{
- int fd = drm_open_any();
+ int fd = drm_open_driver(chipset);
igt_require(fd = 0);
igt_require_f(drmSetMaster(fd) == 0, Can't become DRM master,
@@ -351,28 +385,30 @@ int drm_open_any_master(void)
}
/**
- * drm_open_any_render:
+ * drm_open_driver_render:
*
- * Open an i915 drm render device node.
+ * Open a drm render device node.
*
* Returns:
- * The i915 drm file descriptor or -1 on error
+ * The drm file descriptor or
Re: [Intel-gfx] [PATCH] drm/i915: Tone done *ERROR* for an expected VBT condition
On Wed, Aug 05, 2015 at 10:34:07AM +0200, Daniel Vetter wrote:
On Fri, Jul 31, 2015 at 11:15:27AM +0100, Chris Wilson wrote:
Older VBT (e.g. gen2) have smaller child block defintions, so do not cry
wolf over an error that is outside of our control and is not an error
anyway.
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
---
drivers/gpu/drm/i915/intel_bios.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_bios.c
b/drivers/gpu/drm/i915/intel_bios.c
index 2ff9eb00fdec..f8afbafa8e02 100644
--- a/drivers/gpu/drm/i915/intel_bios.c
+++ b/drivers/gpu/drm/i915/intel_bios.c
@@ -1023,7 +1023,7 @@ parse_device_mapping(struct drm_i915_private
*dev_priv,
return;
}
if (p_defs-child_dev_size sizeof(*p_child)) {
This line was added in
commit 90e4f1592bb6e82f6690f0e05a8aadcf04d7bce7
Author: Ville Syrjälä ville.syrj...@linux.intel.com
Date: Wed Mar 25 18:45:58 2015 +0200
drm/i915: Fix the VBT child device parsing for BSW
Since vbt is complete pain I started requiring that we match expected
sizes with vbt versions. Can some one please fix this?
I hope id:20150804135552.GC6150@boom does.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 4/5] lib/tests: make kmstest_get_pipe_from_crtc_id and igt_enable_connectors generic to prepare for platform agnostic tests
On Fri, Jul 31, 2015 at 04:11:10PM -0400, Micah Fedke wrote:
---
lib/igt_kms.c | 13 +++--
lib/igt_kms.h | 2 +-
tests/kms_flip.c | 2 +-
tests/kms_pipe_crc_basic.c | 2 +-
4 files changed, 10 insertions(+), 9 deletions(-)
diff --git a/lib/igt_kms.c b/lib/igt_kms.c
index 7e956b4..c067443 100644
--- a/lib/igt_kms.c
+++ b/lib/igt_kms.c
@@ -294,7 +294,8 @@ int kmstest_get_pipe_from_crtc_id(int fd, int crtc_id)
memset(pfci, 0, sizeof(pfci));
pfci.crtc_id = crtc_id;
ret = drmIoctl(fd, DRM_IOCTL_I915_GET_PIPE_FROM_CRTC_ID, pfci);
- igt_assert(ret == 0);
+ if(ret)
+ return -1;
We follow kernel coding style in igt and are fairly consistent about it,
please follow suit.
Also funny truth is that the kernel's implementation of get_pipe_from_crtc
matches what you do below (it's how the vblank ioctl abi works), so you
can just outright replace this all with the generic version.
-Daniel
return pfci.pipe;
}
@@ -631,6 +632,10 @@ found:
config-crtc_idx = i;
config-pipe = kmstest_get_pipe_from_crtc_id(drm_fd,
config-crtc-crtc_id);
+ if(config-pipe == -1) {
+ igt_warn(could not get pipe from crtc id, using index\n);
+ config-pipe = i;
+ }
drmModeFreeResources(resources);
@@ -1801,13 +1806,10 @@ void igt_wait_for_vblank(int drm_fd, enum pipe pipe)
* An exit handler is installed to ensure connectors are reset when the test
* exits.
*/
-void igt_enable_connectors(void)
+void igt_enable_connectors(int drm_fd)
{
drmModeRes *res;
drmModeConnector *c;
- int drm_fd;
-
- drm_fd = drm_open_driver(DRIVER_INTEL);
res = drmModeGetResources(drm_fd);
@@ -1830,7 +1832,6 @@ void igt_enable_connectors(void)
drmModeFreeConnector(c);
}
- close(drm_fd);
}
/**
diff --git a/lib/igt_kms.h b/lib/igt_kms.h
index 565df14..b5f007d 100644
--- a/lib/igt_kms.h
+++ b/lib/igt_kms.h
@@ -270,7 +270,7 @@ void igt_wait_for_vblank(int drm_fd, enum pipe pipe);
#define IGT_FIXED(i,f) ((i) 16 | (f))
-void igt_enable_connectors(void);
+void igt_enable_connectors(int drm_fd);
void igt_reset_connectors(void);
#define EDID_LENGTH 128
diff --git a/tests/kms_flip.c b/tests/kms_flip.c
index 4d8d0c0..a88e707 100644
--- a/tests/kms_flip.c
+++ b/tests/kms_flip.c
@@ -1702,7 +1702,7 @@ int main(int argc, char **argv)
igt_fixture {
drm_fd = drm_open_driver_master(DRIVER_INTEL);
- igt_enable_connectors();
+ igt_enable_connectors(drm_fd);
kmstest_set_vt_graphics_mode();
igt_install_exit_handler(kms_flip_exit_handler);
diff --git a/tests/kms_pipe_crc_basic.c b/tests/kms_pipe_crc_basic.c
index fc4ad46..10ef097 100644
--- a/tests/kms_pipe_crc_basic.c
+++ b/tests/kms_pipe_crc_basic.c
@@ -228,7 +228,7 @@ igt_main
igt_fixture {
data.drm_fd = drm_open_driver_master(DRIVER_INTEL);
- igt_enable_connectors();
+ igt_enable_connectors(data.drm_fd);
kmstest_set_vt_graphics_mode();
--
2.1.4
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 5/5] tests: make drm_read platform agnostic
On Fri, Jul 31, 2015 at 04:11:11PM -0400, Micah Fedke wrote:
Same comment about lack of commit message and coding style mangling. Also
seems to contain some unrelated changes ...
-Daniel
---
tests/drm_read.c | 101
++-
1 file changed, 55 insertions(+), 46 deletions(-)
diff --git a/tests/drm_read.c b/tests/drm_read.c
index fdaf126..f60e21c 100644
--- a/tests/drm_read.c
+++ b/tests/drm_read.c
@@ -45,10 +45,15 @@
#include drm.h
#include ioctl_wrappers.h
#include drmtest.h
+#include igt_core.h
#include igt_aux.h
+#include igt_kms.h
IGT_TEST_DESCRIPTION(Call read(drm) and see if it behaves.);
+static drmModeRes *resources;
+static int crtc_idx;
+
static void sighandler(int sig)
{
}
@@ -61,16 +66,19 @@ static void assert_empty(int fd)
static void generate_event(int fd)
{
- union drm_wait_vblank vbl;
+ drmVBlank wait_vbl;
+ unsigned crtc_idx_mask;
+ memset(wait_vbl, 0, sizeof(wait_vbl));
- /* We require that pipe 0 is running */
+ crtc_idx_mask = crtc_idx DRM_VBLANK_HIGH_CRTC_SHIFT;
+ igt_assert(!(crtc_idx_mask ~DRM_VBLANK_HIGH_CRTC_MASK));
- vbl.request.type =
- DRM_VBLANK_RELATIVE |
- DRM_VBLANK_EVENT;
- vbl.request.sequence = 0;
+ wait_vbl.request.type = crtc_idx_mask;
+ wait_vbl.request.type |= DRM_VBLANK_RELATIVE;
+ wait_vbl.request.type |= DRM_VBLANK_EVENT;
+ wait_vbl.request.sequence = 1;
- do_ioctl(fd, DRM_IOCTL_WAIT_VBLANK, vbl);
+ igt_assert(!drmWaitVBlank(fd, wait_vbl));
}
static void wait_for_event(int fd)
@@ -154,44 +162,23 @@ static void test_short_buffer(int in, int nonblock)
static int pipe0_enabled(int fd)
{
- struct drm_mode_card_res res;
- uint32_t crtcs[32];
- int i;
-
- /* We assume we can generate events on pipe 0. So we have better
- * make sure that is running!
- */
-
- memset(res, 0, sizeof(res));
- res.count_crtcs = 32;
- res.crtc_id_ptr = (uintptr_t)crtcs;
-
- if (drmIoctl(fd, DRM_IOCTL_MODE_GETRESOURCES, res))
- return 0;
-
- if (res.count_crtcs 32)
- return 0;
-
- for (i = 0; i res.count_crtcs; i++) {
- struct drm_i915_get_pipe_from_crtc_id get_pipe;
- struct drm_mode_crtc mode;
-
- memset(get_pipe, 0, sizeof(get_pipe));
- memset(mode, 0, sizeof(mode));
-
- mode.crtc_id = crtcs[i];
-
- get_pipe.pipe = -1;
- get_pipe.crtc_id = mode.crtc_id;
- drmIoctl(fd, DRM_IOCTL_I915_GET_PIPE_FROM_CRTC_ID, get_pipe);
- if (get_pipe.pipe)
- continue;
-
- drmIoctl(fd, DRM_IOCTL_MODE_GETCRTC, mode);
- return mode.mode_valid mode.mode.clock;
- }
-
- return 0;
+ drmModeRes *res;
+ drmModeCrtc *crtc;
+
+ /* We assume we can generate events on pipe 0. So we have better
+* make sure that is running!
+*/
+
+ res = drmModeGetResources(fd);
+ igt_assert(res);
+ crtc = drmModeGetCrtc(fd, res-crtcs[crtc_idx]);
+ if (!crtc){
+ return 0;
+ }
+ drmModeFreeCrtc(crtc);
+ drmModeFreeResources(res);
+
+ return crtc-mode_valid crtc-mode.clock;
}
igt_main
@@ -202,8 +189,30 @@ igt_main
siginterrupt(SIGALRM, 1);
igt_fixture {
- fd = drm_open_driver_master(DRIVER_INTEL);
+struct kmstest_connector_config config;
+ int i, n;
+
+ fd = drm_open_driver_master(OPEN_ANY_GPU);
+ igt_enable_connectors(fd);
+ kmstest_set_vt_graphics_mode();
+
igt_require(pipe0_enabled(fd));
+
+resources = drmModeGetResources(fd);
+igt_assert(resources);
+
+ for (i = 0; i resources-count_connectors; i++) {
+ for (n = 0; n resources-count_crtcs; n++) {
+//use the first connector config we find
+ if(kmstest_get_connector_config(fd, resources-connectors[i],
+1 n, config)){
+ crtc_idx = config.crtc_idx;
+ break;
+}
+ }
+ }
+ drmModeFreeCrtc(config.crtc);
+
}
igt_subtest(invalid-buffer)
--
2.1.4
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/vlv: Add RPS debugfs disabling for vlv/chv
On Mon, Aug 03, 2015 at 03:01:01PM +0530, Praveen Paneri wrote:
This patch exposes a new debugfs interface 'i915_rps_disable'
Following 2 values shall be echoed into this file.
'0' - RPS explicitly enabled .
'1' - RPS explicitly disabled.
This interface provides capabilty to enable/disable Turbo feature
at runtime, which is needed for its validation.
Signed-off-by: Deepak S deepa...@intel.com
Signed-off-by: Praveen Paneri praveen.pan...@intel.com
If you need this for validation I want to see that validation test commit
to igt.
Thanks, Daniel
---
drivers/gpu/drm/i915/i915_debugfs.c | 55
+
drivers/gpu/drm/i915/i915_drv.h | 2 ++
2 files changed, 57 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index 23a69307..9124654 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -4771,6 +4771,60 @@ DEFINE_SIMPLE_ATTRIBUTE(i915_min_freq_fops,
i915_min_freq_get, i915_min_freq_set,
%llu\n);
+static int i915_rps_disable_get(void *data, u64 *val)
+{
+ struct drm_device *dev = data;
+ struct drm_i915_private *dev_priv = dev-dev_private;
+
+ if (!IS_VALLEYVIEW(dev))
+ return -ENODEV;
+
+ flush_delayed_work(dev_priv-rps.delayed_resume_work);
+
+ *val = dev_priv-rps.rps_disable;
+
+ return 0;
+}
+
+static int i915_rps_disable_set(void *data, u64 val)
+{
+ struct drm_device *dev = data;
+ struct drm_i915_private *dev_priv = dev-dev_private;
+ int ret;
+
+ if (!IS_VALLEYVIEW(dev))
+ return -ENODEV;
+
+ flush_delayed_work(dev_priv-rps.delayed_resume_work);
+
+ DRM_DEBUG_DRIVER(Setting RPS disable %s\n,
+ val ? true : false);
+
+ ret = mutex_lock_interruptible(dev_priv-rps.hw_lock);
+ if (ret)
+ return ret;
+
+ dev_priv-rps.rps_disable = val;
+
+ if (val)
+ I915_WRITE(GEN6_RP_CONTROL, 0);
+ else
+ I915_WRITE(GEN6_RP_CONTROL, GEN6_RP_MEDIA_TURBO |
+ GEN6_RP_MEDIA_HW_NORMAL_MODE |
+ GEN6_RP_MEDIA_IS_GFX |
+ GEN6_RP_ENABLE |
+ GEN6_RP_UP_BUSY_AVG |
+ GEN6_RP_DOWN_IDLE_CONT);
+
+ mutex_unlock(dev_priv-rps.hw_lock);
+
+ return 0;
+}
+
+DEFINE_SIMPLE_ATTRIBUTE(i915_rps_disable_fops,
+ i915_rps_disable_get, i915_rps_disable_set,
+ %llu\n);
+
static int
i915_cache_sharing_get(void *data, u64 *val)
{
@@ -5107,6 +5161,7 @@ static const struct i915_debugfs_files {
{i915_wedged, i915_wedged_fops},
{i915_max_freq, i915_max_freq_fops},
{i915_min_freq, i915_min_freq_fops},
+ {i915_rps_disable, i915_rps_disable_fops},
{i915_cache_sharing, i915_cache_sharing_fops},
{i915_ring_stop, i915_ring_stop_fops},
{i915_ring_missed_irq, i915_ring_missed_irq_fops},
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 04aa34a..e2a57f0 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1137,6 +1137,8 @@ struct intel_gen6_power_mgmt {
u8 up_threshold; /* Current %busy required to uplock */
u8 down_threshold; /* Current %busy required to downclock */
+ bool rps_disable;
+
int last_adj;
enum { LOW_POWER, BETWEEN, HIGH_POWER } power;
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/2 v2] drm/i915: Allow parsing of variable size child device entries from VBT
On Tue, Aug 04, 2015 at 04:55:52PM +0300, David Weinehall wrote:
VBT version 196 increased the size of common_child_dev_config. The parser
code assumed that the size of this structure would not change.
The modified code now copies the amount needed based on the VBT version,
and emits a debug message if the VBT version is unknown (too new);
since the struct config block won't shrink in newer versions it should
be harmless to copy the maximum known size in such cases, so that's
what we do, but emitting the warning is probably sensible anyway.
In the longer run it might make sense to modify the parser code to
use a version/feature mapping, rather than hardcoding things like this,
but for now the variants are fairly managable.
v2: Stricter size checks
Signed-off-by: David Weinehall david.weineh...@linux.intel.com
Since Chris mentioned that this should fix a regression I applied it to
drm-intel-fixes.
-Daniel
---
drivers/gpu/drm/i915/intel_bios.c | 26 ++
1 file changed, 22 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_bios.c
b/drivers/gpu/drm/i915/intel_bios.c
index 2ff9eb00fdec..8a1f3e1fc598 100644
--- a/drivers/gpu/drm/i915/intel_bios.c
+++ b/drivers/gpu/drm/i915/intel_bios.c
@@ -1015,15 +1015,33 @@ parse_device_mapping(struct drm_i915_private
*dev_priv,
const union child_device_config *p_child;
union child_device_config *child_dev_ptr;
int i, child_device_num, count;
- u16 block_size;
+ u8 expected_size;
+ u16 block_size;
p_defs = find_section(bdb, BDB_GENERAL_DEFINITIONS);
if (!p_defs) {
DRM_DEBUG_KMS(No general definition block is found, no devices
defined.\n);
return;
}
- if (p_defs-child_dev_size sizeof(*p_child)) {
- DRM_ERROR(General definiton block child device size is too
small.\n);
+ if (bdb-version 195) {
+ expected_size = 33;
+ } else if (bdb-version == 195) {
+ expected_size = 37;
+ } else if (bdb-version = 197) {
+ expected_size = 38;
+ } else {
+ expected_size = 38;
+ DRM_DEBUG_DRIVER(Expected child_device_config size for BDB
version %u not known; assuming %u\n, expected_size);
+ }
+
+ if (expected_size sizeof(*p_child)) {
+ DRM_ERROR(child_device_config cannot fit in p_child\n);
+ return;
+ }
+
+ if (p_defs-child_dev_size != expected_size) {
+ DRM_ERROR(Size mismatch; child_device_config size=%u (expected
%u); bdb-version: %u\n,
+ p_defs-child_dev_size, expected_size, bdb-version);
return;
}
/* get the block size of general definitions */
@@ -1070,7 +1088,7 @@ parse_device_mapping(struct drm_i915_private *dev_priv,
child_dev_ptr = dev_priv-vbt.child_dev + count;
count++;
- memcpy(child_dev_ptr, p_child, sizeof(*p_child));
+ memcpy(child_dev_ptr, p_child, p_defs-child_dev_size);
}
return;
}
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [SKL-DMC-BUGFIX 1/5] drm/i915/gen9: Removed byte swapping for csr firmware
On Tue, Aug 04, 2015 at 11:25:40AM +0530, Animesh Manna wrote:
On 8/4/2015 9:16 AM, Nagaraju, Vathsala wrote:
This patch contains the changes to remove the byte swapping logic
introduced with old dmc firmware.
Which version of DMC need reversal logic? Atleast , 4,1.16,1.18 follow the
same format.
Packaging of firmware binary completely changed after api version 1.0, so by
old firmware I want to mean
the initial version before dmc 1.0.
This kind of information really must be included in the commit message.
Very likely someone with old firmware will bisect to this commit, and if
you don't include that people need latest dmc firmware there will be
confusion.
Commit message _must_ be complete and contain everything that was
discussed while reviewing and developing a patch.
I added a note while merging the patch.
-Daniel
-Original Message-
From: Manna, Animesh
Sent: Monday, August 3, 2015 9:56 PM
To: intel-gfx@lists.freedesktop.org
Cc: Manna, Animesh; Vetter, Daniel; Lespiau, Damien; Deak, Imre; Kamath,
Sunil; Nagaraju, Vathsala
Subject: [SKL-DMC-BUGFIX 1/5] drm/i915/gen9: Removed byte swapping for csr
firmware
This patch contains the changes to remove the byte swapping logic introduced
with old dmc firmware.
While debugging PC10 entry issue for skylake found with latest dmc firmware
version 1.18 without byte swapping dmc is working fine and able to enter
PC10.
v1: Initial version.
v2: Corrected firmware size during memcpy(). (Suggested by Sunil)
Cc: Daniel Vetter daniel.vet...@intel.com
Cc: Damien Lespiau damien.lesp...@intel.com
Cc: Imre Deak imre.d...@intel.com
Cc: Sunil Kamath sunil.kam...@intel.com
Signed-off-by: Animesh Manna animesh.ma...@intel.com
Signed-off-by: Vathsala Nagaraju vathsala.nagar...@intel.com
---
drivers/gpu/drm/i915/i915_drv.h | 2 +- drivers/gpu/drm/i915/intel_csr.c
| 16
2 files changed, 5 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h
b/drivers/gpu/drm/i915/i915_drv.h index b94ada9..9d0ee58 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -742,7 +742,7 @@ enum csr_state {
struct intel_csr {
const char *fw_path;
-__be32 *dmc_payload;
+uint32_t *dmc_payload;
uint32_t dmc_fw_size;
uint32_t mmio_count;
uint32_t mmioaddr[8];
diff --git a/drivers/gpu/drm/i915/intel_csr.c
b/drivers/gpu/drm/i915/intel_csr.c
index 6d8a7bf..ba1ae03 100644
--- a/drivers/gpu/drm/i915/intel_csr.c
+++ b/drivers/gpu/drm/i915/intel_csr.c
@@ -244,7 +244,7 @@ void intel_csr_load_status_set(struct drm_i915_private
*dev_priv, void intel_csr_load_program(struct drm_device *dev) {
struct drm_i915_private *dev_priv = dev-dev_private;
-__be32 *payload = dev_priv-csr.dmc_payload;
+u32 *payload = dev_priv-csr.dmc_payload;
uint32_t i, fw_size;
if (!IS_GEN9(dev)) {
@@ -256,7 +256,7 @@ void intel_csr_load_program(struct drm_device *dev)
fw_size = dev_priv-csr.dmc_fw_size;
for (i = 0; i fw_size; i++)
I915_WRITE(CSR_PROGRAM_BASE + i * 4,
-(u32 __force)payload[i]);
+payload[i]);
for (i = 0; i dev_priv-csr.mmio_count; i++) {
I915_WRITE(dev_priv-csr.mmioaddr[i],
@@ -279,7 +279,7 @@ static void finish_csr_load(const struct firmware *fw,
void *context)
char substepping = intel_get_substepping(dev);
uint32_t dmc_offset = CSR_DEFAULT_FW_OFFSET, readcount = 0, nbytes;
uint32_t i;
-__be32 *dmc_payload;
+uint32_t *dmc_payload;
bool fw_loaded = false;
if (!fw) {
@@ -375,15 +375,7 @@ static void finish_csr_load(const struct firmware *fw,
void *context)
}
dmc_payload = csr-dmc_payload;
-for (i = 0; i dmc_header-fw_size; i++) {
-uint32_t *tmp = (u32 *)fw-data[readcount + i * 4];
-/*
- * The firmware payload is an array of 32 bit words stored in
- * little-endian format in the firmware image and programmed
- * as 32 bit big-endian format to memory.
- */
-dmc_payload[i] = cpu_to_be32(*tmp);
-}
+memcpy(dmc_payload, fw-data[readcount], nbytes);
/* load csr program during system boot, as needed for DC states */
intel_csr_load_program(dev);
--
2.0.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [SKL-DMC-BUGFIX 2/5] drm/i915/skl: Making DC6 entry is the last call in suspend flow.
On Mon, Aug 03, 2015 at 09:55:33PM +0530, Animesh Manna wrote:
Mmio register access after dc6/dc5 entry is not allowed when
DC6 power states are enabled according to bspec (bspec-id 0527),
so enabling dc6 as the last call in suspend flow.
v1: Initial version.
v2: commit message updated based on comment from Vathsala.
Cc: Daniel Vetter daniel.vet...@intel.com
Cc: Damien Lespiau damien.lesp...@intel.com
Cc: Imre Deak imre.d...@intel.com
Cc: Sunil Kamath sunil.kam...@intel.com
Signed-off-by: Animesh Manna animesh.ma...@intel.com
Signed-off-by: Vathsala Nagaraju vathsala.nagar...@intel.com
Signed-off-by: Rajneesh Bhardwaj rajneesh.bhard...@intel.com
---
drivers/gpu/drm/i915/i915_drv.c | 12 ++--
drivers/gpu/drm/i915/intel_drv.h| 2 ++
drivers/gpu/drm/i915/intel_runtime_pm.c | 33
-
3 files changed, 16 insertions(+), 31 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 0d6775a..e1d0102 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -1017,14 +1017,11 @@ static int skl_suspend_complete(struct
drm_i915_private *dev_priv)
{
/* Enabling DC6 is not a hard requirement to enter runtime D3 */
- /*
- * This is to ensure that CSR isn't identified as loaded before
- * CSR-loading program is called during runtime-resume.
- */
- intel_csr_load_status_set(dev_priv, FW_UNINITIALIZED);
Seems like an unrelated hunk. Separate patch (in the dmc loader rework
series) or an explanation why we need this.
-
skl_uninit_cdclk(dev_priv);
+ if (intel_csr_load_status_get(dev_priv) == FW_LOADED)
+ skl_enable_dc6(dev_priv);
+
return 0;
}
@@ -1071,6 +1068,9 @@ static int skl_resume_prepare(struct drm_i915_private
*dev_priv)
{
struct drm_device *dev = dev_priv-dev;
+ if (intel_csr_load_status_get(dev_priv) == FW_LOADED)
+ skl_disable_dc6(dev_priv);
+
skl_init_cdclk(dev_priv);
intel_csr_load_program(dev);
diff --git a/drivers/gpu/drm/i915/intel_drv.h
b/drivers/gpu/drm/i915/intel_drv.h
index 47cef0e..06f346f 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -1117,6 +1117,8 @@ void bxt_enable_dc9(struct drm_i915_private *dev_priv);
void bxt_disable_dc9(struct drm_i915_private *dev_priv);
void skl_init_cdclk(struct drm_i915_private *dev_priv);
void skl_uninit_cdclk(struct drm_i915_private *dev_priv);
+void skl_enable_dc6(struct drm_i915_private *dev_priv);
+void skl_disable_dc6(struct drm_i915_private *dev_priv);
void intel_dp_get_m_n(struct intel_crtc *crtc,
struct intel_crtc_state *pipe_config);
void intel_dp_set_m_n(struct intel_crtc *crtc, enum link_m_n_set m_n);
diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c
b/drivers/gpu/drm/i915/intel_runtime_pm.c
index 6393b76..c660245 100644
--- a/drivers/gpu/drm/i915/intel_runtime_pm.c
+++ b/drivers/gpu/drm/i915/intel_runtime_pm.c
@@ -532,7 +532,7 @@ static void assert_can_disable_dc6(struct
drm_i915_private *dev_priv)
DC6 already programmed to be disabled.\n);
}
-static void skl_enable_dc6(struct drm_i915_private *dev_priv)
+void skl_enable_dc6(struct drm_i915_private *dev_priv)
{
uint32_t val;
@@ -549,7 +549,7 @@ static void skl_enable_dc6(struct drm_i915_private
*dev_priv)
POSTING_READ(DC_STATE_EN);
}
-static void skl_disable_dc6(struct drm_i915_private *dev_priv)
+void skl_disable_dc6(struct drm_i915_private *dev_priv)
{
uint32_t val;
Everything above seems to roughly be matching your patch description, but
not perfectly: You talk about suspend flow but also touch resume flow.
But the hunks below are completely unexplained magic afaict. Either this
needs a separate patch or it needs seriously more explanation of what's
going on.
@@ -610,10 +610,10 @@ static void skl_set_power_well(struct drm_i915_private
*dev_priv,
!I915_READ(HSW_PWR_WELL_BIOS),
Invalid for power well status to be enabled,
unless done by the BIOS, \
when request is to disable!\n);
- if ((GEN9_ENABLE_DC5(dev) || SKL_ENABLE_DC6(dev))
- power_well-data == SKL_DISP_PW_2) {
+ if (power_well-data == SKL_DISP_PW_2) {
+ if (GEN9_ENABLE_DC5(dev))
+ gen9_disable_dc5(dev_priv);
if (SKL_ENABLE_DC6(dev)) {
- skl_disable_dc6(dev_priv);
/*
* DDI buffer programming unnecessary
during driver-load/resume
* as it's already done during modeset
initialization then.
@@
Re: [Intel-gfx] [SKL-DMC-BUGFIX 2/5] drm/i915/skl: Making DC6 entry is the last call in suspend flow.
On Tue, Aug 04, 2015 at 04:55:59PM +0530, Sunil Kamath wrote:
On Monday 03 August 2015 09:55 PM, Animesh Manna wrote:
Mmio register access after dc6/dc5 entry is not allowed when
DC6 power states are enabled according to bspec (bspec-id 0527),
so enabling dc6 as the last call in suspend flow.
v1: Initial version.
v2: commit message updated based on comment from Vathsala.
Cc: Daniel Vetter daniel.vet...@intel.com
Cc: Damien Lespiau damien.lesp...@intel.com
Cc: Imre Deak imre.d...@intel.com
Cc: Sunil Kamath sunil.kam...@intel.com
Signed-off-by: Animesh Manna animesh.ma...@intel.com
Signed-off-by: Vathsala Nagaraju vathsala.nagar...@intel.com
Signed-off-by: Rajneesh Bhardwaj rajneesh.bhard...@intel.com
---
drivers/gpu/drm/i915/i915_drv.c | 12 ++--
drivers/gpu/drm/i915/intel_drv.h| 2 ++
drivers/gpu/drm/i915/intel_runtime_pm.c | 33
-
3 files changed, 16 insertions(+), 31 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c
b/drivers/gpu/drm/i915/i915_drv.c
index 0d6775a..e1d0102 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -1017,14 +1017,11 @@ static int skl_suspend_complete(struct
drm_i915_private *dev_priv)
{
/* Enabling DC6 is not a hard requirement to enter runtime D3 */
-/*
- * This is to ensure that CSR isn't identified as loaded before
- * CSR-loading program is called during runtime-resume.
- */
-intel_csr_load_status_set(dev_priv, FW_UNINITIALIZED);
-
skl_uninit_cdclk(dev_priv);
+if (intel_csr_load_status_get(dev_priv) == FW_LOADED)
+skl_enable_dc6(dev_priv);
+
return 0;
}
@@ -1071,6 +1068,9 @@ static int skl_resume_prepare(struct drm_i915_private
*dev_priv)
{
struct drm_device *dev = dev_priv-dev;
+if (intel_csr_load_status_get(dev_priv) == FW_LOADED)
+skl_disable_dc6(dev_priv);
+
skl_init_cdclk(dev_priv);
intel_csr_load_program(dev);
diff --git a/drivers/gpu/drm/i915/intel_drv.h
b/drivers/gpu/drm/i915/intel_drv.h
index 47cef0e..06f346f 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -1117,6 +1117,8 @@ void bxt_enable_dc9(struct drm_i915_private *dev_priv);
void bxt_disable_dc9(struct drm_i915_private *dev_priv);
void skl_init_cdclk(struct drm_i915_private *dev_priv);
void skl_uninit_cdclk(struct drm_i915_private *dev_priv);
+void skl_enable_dc6(struct drm_i915_private *dev_priv);
+void skl_disable_dc6(struct drm_i915_private *dev_priv);
void intel_dp_get_m_n(struct intel_crtc *crtc,
struct intel_crtc_state *pipe_config);
void intel_dp_set_m_n(struct intel_crtc *crtc, enum link_m_n_set m_n);
diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c
b/drivers/gpu/drm/i915/intel_runtime_pm.c
index 6393b76..c660245 100644
--- a/drivers/gpu/drm/i915/intel_runtime_pm.c
+++ b/drivers/gpu/drm/i915/intel_runtime_pm.c
@@ -532,7 +532,7 @@ static void assert_can_disable_dc6(struct
drm_i915_private *dev_priv)
DC6 already programmed to be disabled.\n);
}
-static void skl_enable_dc6(struct drm_i915_private *dev_priv)
+void skl_enable_dc6(struct drm_i915_private *dev_priv)
{
uint32_t val;
@@ -549,7 +549,7 @@ static void skl_enable_dc6(struct drm_i915_private
*dev_priv)
POSTING_READ(DC_STATE_EN);
}
-static void skl_disable_dc6(struct drm_i915_private *dev_priv)
+void skl_disable_dc6(struct drm_i915_private *dev_priv)
{
uint32_t val;
@@ -610,10 +610,10 @@ static void skl_set_power_well(struct drm_i915_private
*dev_priv,
!I915_READ(HSW_PWR_WELL_BIOS),
Invalid for power well status to be enabled,
unless done by the BIOS, \
when request is to disable!\n);
-if ((GEN9_ENABLE_DC5(dev) || SKL_ENABLE_DC6(dev))
-power_well-data == SKL_DISP_PW_2) {
+if (power_well-data == SKL_DISP_PW_2) {
+if (GEN9_ENABLE_DC5(dev))
+gen9_disable_dc5(dev_priv);
if (SKL_ENABLE_DC6(dev)) {
-skl_disable_dc6(dev_priv);
/*
* DDI buffer programming unnecessary
during driver-load/resume
* as it's already done during modeset
initialization then.
@@ -621,8 +621,6 @@ static void skl_set_power_well(struct drm_i915_private
*dev_priv,
*/
if
(!dev_priv-power_domains.initializing)
intel_prepare_ddi(dev);
-} else {
-gen9_disable_dc5(dev_priv);
Re: [Intel-gfx] [SKL-DMC-BUGFIX 3/5] drm/i915/skl: Do not disable cdclk PLL if csr firmware is present.
On Mon, Aug 03, 2015 at 09:55:34PM +0530, Animesh Manna wrote:
While display engine entering into low power state no need to disable
cdclk pll as CSR firmware of dmc will take care. If pll is already
enabled firmware execution sequence will be blocked. This is one
of the criteria for dmc to work properly.
Cc: Daniel Vetter daniel.vet...@intel.com
Cc: Damien Lespiau damien.lesp...@intel.com
Cc: Imre Deak imre.d...@intel.com
Cc: Sunil Kamath sunil.kam...@intel.com
Signed-off-by: Animesh Manna animesh.ma...@intel.com
Signed-off-bt: Vathsala Nagaraju vathsala.nagar...@intel.com
Signed-off-by: Rajneesh Bhardwaj rajneesh.bhard...@intel.com
---
drivers/gpu/drm/i915/intel_display.c | 11 +++
1 file changed, 7 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index af0bcfe..ef2ef4d 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -5675,10 +5675,13 @@ void skl_uninit_cdclk(struct drm_i915_private
*dev_priv)
if (I915_READ(DBUF_CTL) DBUF_POWER_STATE)
DRM_ERROR(DBuf power disable timeout\n);
- /* disable DPLL0 */
- I915_WRITE(LCPLL1_CTL, I915_READ(LCPLL1_CTL) ~LCPLL_PLL_ENABLE);
- if (wait_for(!(I915_READ(LCPLL1_CTL) LCPLL_PLL_LOCK), 1))
- DRM_ERROR(Couldn't disable DPLL0\n);
+ if (dev_priv-csr.dmc_payload) {
+ /* disable DPLL0 */
Imo this needs a proper comment (and the current one is useless since it
just states exactly what the code does and is redundant). What about
/* DMC assumes ownership of LCPLL and will get confused if we
* touch it. */
instead before the if?
-Daniel
+ I915_WRITE(LCPLL1_CTL, I915_READ(LCPLL1_CTL)
+ ~LCPLL_PLL_ENABLE);
+ if (wait_for(!(I915_READ(LCPLL1_CTL) LCPLL_PLL_LOCK), 1))
+ DRM_ERROR(Couldn't disable DPLL0\n);
+ }
intel_display_power_put(dev_priv, POWER_DOMAIN_PLLS);
}
--
2.0.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [SKL-DMC-BUGFIX 4/5] drm/i915/skl: Block disable call for pw1 if dmc firmware is present.
On Mon, Aug 03, 2015 at 09:55:35PM +0530, Animesh Manna wrote:
Another interesting criteria to work dmc as expected is pw1 to be
enabled by driver and dmc will shut it off in its execution
sequence. If already disabled by driver dmc will get confuse and
behave differently than expected found during pc10 entry issue
for skl.
So berfore we disable power-well 1, added check if dmc firmware is
present and driver will not disable power well 1, but for any reason
if firmware is not present of failed to load we can shut off the
power well 1 which will save some power.
As skl is currently fully dependent on dmc to go in lowest possible
power state (dc6) but the same is not applicable for bxt. Display
engine can enter into dc9 without dmc, hence unblocking disable call.
v1: Initial version.
v2: Based on revire commnents from Sunil,
- condition check for pw1 is moved in skl_set_power_well.
There's another patch from Damien/Paulo to do some similar fumbling
between LCPLL and PW1. We probably want to completely take away PW1 from
being controlled by the power wells code and push it all into the rpm code
(where we either disable pw1, pw-misc and lcpll in one go or leave it all
to the dmc firmware).
-Daniel
Cc: Daniel Vetter daniel.vet...@intel.com
Cc: Damien Lespiau damien.lesp...@intel.com
Cc: Imre Deak imre.d...@intel.com
Cc: Sunil Kamath sunil.kam...@intel.com
Signed-off-by: Animesh Manna animesh.ma...@intel.com
Signed-off-by: Vathsala Nagaraju vathsala.nagar...@intel.com
---
drivers/gpu/drm/i915/intel_runtime_pm.c | 12 +---
1 file changed, 9 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c
b/drivers/gpu/drm/i915/intel_runtime_pm.c
index c660245..00cd4ff 100644
--- a/drivers/gpu/drm/i915/intel_runtime_pm.c
+++ b/drivers/gpu/drm/i915/intel_runtime_pm.c
@@ -636,9 +636,15 @@ static void skl_set_power_well(struct drm_i915_private
*dev_priv,
}
} else {
if (enable_requested) {
- I915_WRITE(HSW_PWR_WELL_DRIVER, tmp ~req_mask);
- POSTING_READ(HSW_PWR_WELL_DRIVER);
- DRM_DEBUG_KMS(Disabling %s\n, power_well-name);
+ if (IS_SKYLAKE(dev)
+ (power_well-data == SKL_DISP_PW_1)
+ (intel_csr_load_status_get(dev_priv) ==
FW_LOADED))
+ DRM_DEBUG_KMS(Not Disabling PW1, dmc will
handle\n);
+ else {
+ I915_WRITE(HSW_PWR_WELL_DRIVER, tmp
~req_mask);
+ POSTING_READ(HSW_PWR_WELL_DRIVER);
+ DRM_DEBUG_KMS(Disabling %s\n,
power_well-name);
+ }
if (GEN9_ENABLE_DC5(dev)
power_well-data == SKL_DISP_PW_2)
--
2.0.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v1 1/2] drm/i915:skl: Add WaEnableGapsTsvCreditFix
On Tue, Aug 04, 2015 at 10:01:43AM +0100, Siluvery, Arun wrote:
On 04/08/2015 09:58, Mika Kuoppala wrote:
Ben Widawsky benjamin.widaw...@intel.com writes:
On Mon, Aug 03, 2015 at 08:24:56PM +0100, Arun Siluvery wrote:
Cc: Ben Widawsky benjamin.widaw...@intel.com
Cc: Joonas Lahtinen joonas.lahti...@linux.intel.com
Signed-off-by: Arun Siluvery arun.siluv...@linux.intel.com
---
drivers/gpu/drm/i915/i915_reg.h | 3 +++
drivers/gpu/drm/i915/intel_pm.c | 6 ++
2 files changed, 9 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_reg.h
b/drivers/gpu/drm/i915/i915_reg.h
index 77967ca..8991cd5 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -6849,6 +6849,9 @@ enum skl_disp_power_wells {
#define GEN7_MISCCPCTL (0x9424)
#define GEN7_DOP_CLOCK_GATE_ENABLE (10)
+#define GEN8_GARBCNTL 0xB004
+#define GEN9_GAPS_TSV_CREDIT_DISABLE (17)
+
/* IVYBRIDGE DPF */
#define GEN7_L3CDERRST1 0xB008 /* L3CD Error Status 1 */
#define HSW_L3CDERRST11 0xB208 /* L3CD Error Status
register 1 slice 1 */
diff --git a/drivers/gpu/drm/i915/intel_pm.c
b/drivers/gpu/drm/i915/intel_pm.c
index c23cab6..9152113 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -106,6 +106,12 @@ static void skl_init_clock_gating(struct drm_device
*dev)
/* WaDisableLSQCROPERFforOCL:skl */
I915_WRITE(GEN8_L3SQCREG4, I915_READ(GEN8_L3SQCREG4) |
GEN8_LQSC_RO_PERF_DIS);
+
+ /* WaEnableGapsTsvCreditFix:skl */
+ if (IS_SKYLAKE(dev) (INTEL_REVID(dev) = SKL_REVID_C0)) {
+ I915_WRITE(GEN8_GARBCNTL, (I915_READ(GEN8_GARBCNTL) |
+ GEN9_GAPS_TSV_CREDIT_DISABLE));
+ }
}
static void bxt_init_clock_gating(struct drm_device *dev)
FWIW, the docs make it sound like BIOS should be doing this. Did you verify
we
actually don't have the bit set with more recent BKC?
I have pretty recent BIOS and the bit was not set.
I checked about this, it should be done in driver.
regards
Arun
Tested-by: Ben Widawsky b...@bwidawsk.net
Reviewed-by: Ben Widawsky b...@bwidawsk.net
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=90854
Tested-by: Mika Kuoppala mika.kuopp...@intel.com
Queued for -next, thanks for the patch.
-Daniel
--
Ben Widawsky, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC 7/8] drm/i915: Add support for forwarding execbuffer tags in timestamp sample metadata
On Wed, Aug 05, 2015 at 11:25:43AM +0530, sourab.gu...@intel.com wrote:
@@ -555,10 +558,12 @@ static void forward_one_gen_pmu_sample(struct
drm_i915_private *dev_priv,
struct drm_i915_ts_node_ctx_id *ctx_info;
struct drm_i915_ts_node_ring_id *ring_info;
struct drm_i915_ts_node_pid *pid_info;
+ struct drm_i915_ts_node_tag *tag_info;
struct perf_raw_record raw;
BUILD_BUG_ON((TS_DATA_SIZE != 8) || (CTX_INFO_SIZE != 8) ||
- (RING_INFO_SIZE != 8) || (PID_INFO_SIZE != 8));
+ (RING_INFO_SIZE != 8) || (PID_INFO_SIZE != 8) ||
+ (TAG_INFO_SIZE != 8));
This is much more useful if each clause is independent. The error
message is then unambiguous and it looks neater.
snapshot = dev_priv-gen_pmu.buffer.addr + node-offset;
snapshot_size = TS_DATA_SIZE + CTX_INFO_SIZE;
diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h
index 3dcc862..db91098 100644
--- a/include/uapi/drm/i915_drm.h
+++ b/include/uapi/drm/i915_drm.h
@@ -104,7 +104,8 @@ struct drm_i915_gen_pmu_attr {
__u32 size;
__u32 sample_ring:1,
sample_pid:1,
- __reserved_1:30;
+ sample_tag:1,
+ __reserved_1:29;
Start each bitfield entry on its own line with __u32;
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC 1/8] drm/i915: Add a new PMU for handling non-OA counter data profiling requests
On Wed, Aug 05, 2015 at 11:25:37AM +0530, sourab.gu...@intel.com wrote:
+static void gen_buffer_destroy(struct drm_i915_private *i915)
+{
+ mutex_lock(i915-dev-struct_mutex);
+ vunmap(i915-gen_pmu.buffer.addr);
+ i915_gem_object_ggtt_unpin(i915-gen_pmu.buffer.obj);
+ drm_gem_object_unreference(i915-gen_pmu.buffer.obj-base);
+ mutex_unlock(i915-dev-struct_mutex);
+
+ spin_lock(i915-gen_pmu.lock);
+ i915-gen_pmu.buffer.obj = NULL;
+ i915-gen_pmu.buffer.gtt_offset = 0;
+ i915-gen_pmu.buffer.addr = NULL;
+ spin_unlock(i915-gen_pmu.lock);
This ordering looks scary. At the very least it deserves a comment to
explain why it is safe.
So what stops a second event being created while the first is being
destroyed? I presume the perf events are exclusive? Or a refcounted
singleton?
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC 5/8] drm/i915: Add support for forwarding ring id in sample metadata through perf
On Wed, Aug 05, 2015 at 11:25:41AM +0530, sourab.gu...@intel.com wrote:
@@ -542,18 +548,27 @@ static void forward_one_gen_pmu_sample(struct
drm_i915_private *dev_priv,
struct perf_sample_data data;
struct perf_event *event = dev_priv-gen_pmu.exclusive_event;
int snapshot_size;
- u8 *snapshot;
+ u8 *snapshot, *current_ptr;
struct drm_i915_ts_node_ctx_id *ctx_info;
+ struct drm_i915_ts_node_ring_id *ring_info;
struct perf_raw_record raw;
- BUILD_BUG_ON(TS_DATA_SIZE != 8);
- BUILD_BUG_ON(CTX_INFO_SIZE != 8);
+ BUILD_BUG_ON((TS_DATA_SIZE != 8) || (CTX_INFO_SIZE != 8) ||
+ (RING_INFO_SIZE != 8));
snapshot = dev_priv-gen_pmu.buffer.addr + node-offset;
snapshot_size = TS_DATA_SIZE + CTX_INFO_SIZE;
ctx_info = (struct drm_i915_ts_node_ctx_id *)(snapshot + TS_DATA_SIZE);
ctx_info-ctx_id = node-ctx_id;
+ current_ptr = snapshot + snapshot_size;
+
+ if (dev_priv-gen_pmu.sample_info_flags I915_GEN_PMU_SAMPLE_RING) {
+ ring_info = (struct drm_i915_ts_node_ring_id *)current_ptr;
+ ring_info-ring = node-ring;
Stylewise I would be move familar with current_ptr = ring_info + 1, and
make current_ptr void*. snapshot_size is then redundant.
+ snapshot_size += RING_INFO_SIZE;
+ current_ptr = snapshot + snapshot_size;
+ }
--
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC 7/8] drm/i915: Add support for forwarding execbuffer tags in timestamp sample metadata
On Wed, Aug 05, 2015 at 10:17:55AM +0100, Chris Wilson wrote:
On Wed, Aug 05, 2015 at 11:25:43AM +0530, sourab.gu...@intel.com wrote:
@@ -555,10 +558,12 @@ static void forward_one_gen_pmu_sample(struct
drm_i915_private *dev_priv,
struct drm_i915_ts_node_ctx_id *ctx_info;
struct drm_i915_ts_node_ring_id *ring_info;
struct drm_i915_ts_node_pid *pid_info;
+ struct drm_i915_ts_node_tag *tag_info;
struct perf_raw_record raw;
BUILD_BUG_ON((TS_DATA_SIZE != 8) || (CTX_INFO_SIZE != 8) ||
- (RING_INFO_SIZE != 8) || (PID_INFO_SIZE != 8));
+ (RING_INFO_SIZE != 8) || (PID_INFO_SIZE != 8) ||
+ (TAG_INFO_SIZE != 8));
This is much more useful if each clause is independent. The error
message is then unambiguous and it looks neater.
snapshot = dev_priv-gen_pmu.buffer.addr + node-offset;
snapshot_size = TS_DATA_SIZE + CTX_INFO_SIZE;
diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h
index 3dcc862..db91098 100644
--- a/include/uapi/drm/i915_drm.h
+++ b/include/uapi/drm/i915_drm.h
@@ -104,7 +104,8 @@ struct drm_i915_gen_pmu_attr {
__u32 size;
__u32 sample_ring:1,
sample_pid:1,
- __reserved_1:30;
+ sample_tag:1,
+ __reserved_1:29;
Start each bitfield entry on its own line with __u32;
also no bitfields in uapi headers.
-Daniel
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC 4/8] drm/i915: Insert commands for capturing timestamps in the ring
On Wed, Aug 05, 2015 at 11:25:40AM +0530, sourab.gu...@intel.com wrote: From: Sourab Gupta sourab.gu...@intel.com This patch adds the routines through which one can insert commands in the ringbuf for capturing timestamps, which are used to insert these commands around the batchbuffer. While inserting the commands, we keep a reference of associated request. This will be released when we are forwarding the samples to userspace (or when the event is being destroyed). Also, an active reference of the destination buffer is taken here, so that we can be assured that the buffer is freed up only after GPU is done with it, even if the local reference of the buffer is released. v2: Changes (as suggested by Chris): - Passing in 'request' struct for emit report function - Removed multiple calls to i915_gem_obj_to_ggtt(). Keeping hold of pinned vma from start and using when required. - Better nomenclature, and error handling. @@ -919,6 +993,7 @@ static int init_gen_pmu_buffer(struct perf_event *event) dev_priv-gen_pmu.buffer.obj = bo; dev_priv-gen_pmu.buffer.gtt_offset = i915_gem_obj_ggtt_offset(bo); + dev_priv-gen_pmu.buffer.vma = i915_gem_obj_to_ggtt(bo); dev_priv-gen_pmu.buffer.addr = vmap_oa_buffer(bo); INIT_LIST_HEAD(dev_priv-gen_pmu.node_list); Still calling i915_gem_obj_to_ggtt(bo) twice! With pmu_buffer.vma you can drop pmu_buffer.gtt_offset and never be confused again. -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC 1/8] drm/i915: Add a new PMU for handling non-OA counter data profiling requests
On Wed, Aug 05, 2015 at 11:25:37AM +0530, sourab.gu...@intel.com wrote: From: Sourab Gupta sourab.gu...@intel.com The current perf PMU driver is specific for collection of OA counter statistics (which may be done in a periodic or asynchronous way). Since this enables us (and limits us) to render ring, we have no means for collection of data pertaining to other rings. To overcome this limitation, we need to have a new PMU driver which enables data collection for other rings also (in a non-OA specific mode). This patch adds a new perf PMU to i915 device private, for handling profiling requests for non-OA counter data.This data may encompass timestamps, mmio register values, etc. for the relevant ring. The new perf PMU will serve these purposes, without constraining itself to type of data being dumped (which may restrict the user to specific ring like in case of OA counters). The patch introduces this PMU driver alongwith its associated callbacks. Signed-off-by: Sourab Gupta sourab.gu...@intel.com --- drivers/gpu/drm/i915/i915_dma.c | 2 + drivers/gpu/drm/i915/i915_drv.h | 19 drivers/gpu/drm/i915/i915_oa_perf.c | 215 You have to admit it is a bit odd for the object to be called i915_oa_pmu/i915_gen_pmu and the file i915_oa_perf.c -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC 1/8] drm/i915: Add a new PMU for handling non-OA counter data profiling requests
On Wed, 2015-08-05 at 09:22 +, Chris Wilson wrote:
On Wed, Aug 05, 2015 at 11:25:37AM +0530, sourab.gu...@intel.com wrote:
+static void gen_buffer_destroy(struct drm_i915_private *i915)
+{
+ mutex_lock(i915-dev-struct_mutex);
+ vunmap(i915-gen_pmu.buffer.addr);
+ i915_gem_object_ggtt_unpin(i915-gen_pmu.buffer.obj);
+ drm_gem_object_unreference(i915-gen_pmu.buffer.obj-base);
+ mutex_unlock(i915-dev-struct_mutex);
+
+ spin_lock(i915-gen_pmu.lock);
+ i915-gen_pmu.buffer.obj = NULL;
+ i915-gen_pmu.buffer.gtt_offset = 0;
+ i915-gen_pmu.buffer.addr = NULL;
+ spin_unlock(i915-gen_pmu.lock);
This ordering looks scary. At the very least it deserves a comment to
explain why it is safe.
So what stops a second event being created while the first is being
destroyed? I presume the perf events are exclusive? Or a refcounted
singleton?
-Chris
Hi Chris,
Yes, the perf events are exclusive. This patch doesn't handle the
problem of exclusion fully. I intended to handle this problem in the
later patch in the series:
http://lists.freedesktop.org/archives/intel-gfx/2015-August/072959.html
If you check here, a new event init checks whether obj is NULL (while
holding the spinlock), to see whether it is exclusive.
This is taken care of during the event destroy work fn, which assigns
obj to NULL (while holding spinlock), after it is done with everything.
Regards,
Sourab
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC 1/8] drm/i915: Add a new PMU for handling non-OA counter data profiling requests
On Wed, 2015-08-05 at 09:38 +, Chris Wilson wrote: On Wed, Aug 05, 2015 at 11:25:37AM +0530, sourab.gu...@intel.com wrote: From: Sourab Gupta sourab.gu...@intel.com The current perf PMU driver is specific for collection of OA counter statistics (which may be done in a periodic or asynchronous way). Since this enables us (and limits us) to render ring, we have no means for collection of data pertaining to other rings. To overcome this limitation, we need to have a new PMU driver which enables data collection for other rings also (in a non-OA specific mode). This patch adds a new perf PMU to i915 device private, for handling profiling requests for non-OA counter data.This data may encompass timestamps, mmio register values, etc. for the relevant ring. The new perf PMU will serve these purposes, without constraining itself to type of data being dumped (which may restrict the user to specific ring like in case of OA counters). The patch introduces this PMU driver alongwith its associated callbacks. Signed-off-by: Sourab Gupta sourab.gu...@intel.com --- drivers/gpu/drm/i915/i915_dma.c | 2 + drivers/gpu/drm/i915/i915_drv.h | 19 drivers/gpu/drm/i915/i915_oa_perf.c | 215 You have to admit it is a bit odd for the object to be called i915_oa_pmu/i915_gen_pmu and the file i915_oa_perf.c -Chris Well, yes.. If the nomenclature of i915_gen_pmu is agreed upon, I can have a new file named as i915_gen_pmu.c which will hold the routines for this pmu, leaving oa pmu stuff behind in i915_oa_pmu.c ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC 1/8] drm/i915: Add a new PMU for handling non-OA counter data profiling requests
On Wed, 2015-08-05 at 15:17 +0530, sourab gupta wrote: On Wed, 2015-08-05 at 09:38 +, Chris Wilson wrote: On Wed, Aug 05, 2015 at 11:25:37AM +0530, sourab.gu...@intel.com wrote: From: Sourab Gupta sourab.gu...@intel.com The current perf PMU driver is specific for collection of OA counter statistics (which may be done in a periodic or asynchronous way). Since this enables us (and limits us) to render ring, we have no means for collection of data pertaining to other rings. To overcome this limitation, we need to have a new PMU driver which enables data collection for other rings also (in a non-OA specific mode). This patch adds a new perf PMU to i915 device private, for handling profiling requests for non-OA counter data.This data may encompass timestamps, mmio register values, etc. for the relevant ring. The new perf PMU will serve these purposes, without constraining itself to type of data being dumped (which may restrict the user to specific ring like in case of OA counters). The patch introduces this PMU driver alongwith its associated callbacks. Signed-off-by: Sourab Gupta sourab.gu...@intel.com --- drivers/gpu/drm/i915/i915_dma.c | 2 + drivers/gpu/drm/i915/i915_drv.h | 19 drivers/gpu/drm/i915/i915_oa_perf.c | 215 You have to admit it is a bit odd for the object to be called i915_oa_pmu/i915_gen_pmu and the file i915_oa_perf.c -Chris Well, yes.. If the nomenclature of i915_gen_pmu is agreed upon, I can have a new file named as i915_gen_pmu.c which will hold the routines for this pmu, leaving oa pmu stuff behind in i915_oa_pmu.c Sorry, I meant to say 'oa pmu stuff behind in i915_oa_perf.c'. Does i915_gen_pmu.c sound fine? ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/bxt: WA for swapped HPD pins in A stepping
On Mon, 2015-07-27 at 11:02 +0530, Sonika Jindal wrote:
WA for BXT A0/A1, where DDIB's HPD pin is swapped to DDIA, so enabling
DDIA HPD pin in place of DDIB.
v2: For DP, irq_port is used to determine the encoder instead of
hpd_pin and removing the edp HPD logic because port A HPD is not
present(Imre)
v3: Rebased on top of Imre's patchset for enabling HPD on PORT A.
Added hpd_pin swapping for intel_dp_init_connector, setting encoder
for PORT_A as per the WA in irq_port (Imre)
v4: Dont enable interrupt for edp, also reframe the description (Siva)
Signed-off-by: Sonika Jindal sonika.jin...@intel.com
This patch is a new version of 2/2 of your patchset at
http://lists.freedesktop.org/archives/intel-gfx/2015-July/071580.html
so this should've been sent either as a reply to the individual v1 patch
there, or just by resending the whole patchset. For now you could just
resend the whole patchset. Also please add the version info to the
subject with git format-patch --subject-prefix.
---
drivers/gpu/drm/i915/intel_ddi.c | 11 ++-
drivers/gpu/drm/i915/intel_dp.c |4
drivers/gpu/drm/i915/intel_hdmi.c |9 -
3 files changed, 22 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_ddi.c
b/drivers/gpu/drm/i915/intel_ddi.c
index e2c6f73..8d7ffe0 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -3225,7 +3225,16 @@ void intel_ddi_init(struct drm_device *dev, enum port
port)
goto err;
intel_dig_port-hpd_pulse = intel_dp_hpd_pulse;
- dev_priv-hotplug.irq_port[port] = intel_dig_port;
+ /*
+ * On BXT A0/A1, sw needs to activate DDIA HPD logic and
+ * interrupts to check the external panel connection.
+ */
+ if (IS_BROXTON(dev_priv) (INTEL_REVID(dev) BXT_REVID_B0)
+ port == PORT_B)
+ dev_priv-hotplug.irq_port[PORT_A] = intel_dig_port;
+ /* Dont enable interrupts for edp*/
+ else if (port != PORT_A)
+ dev_priv-hotplug.irq_port[port] = intel_dig_port;
Not enabling HPD on eDP is not a BXT specific change (even though it's
disabled now everywhere), so that part should be a separate patch and
ordered before patch 1/2. Also this isn't the proper place to disable
HPD handling; as long as the corresponding intel_encoder-hpd_pin is set
the relevant interrupt will get unmasked and hotplug_work will be
called. See bxt_hpd_irq_setup() and intel_hpd_irq_handler().
}
/* In theory we don't need the encoder-type check, but leave it just in
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index fcc64e5..71679ef 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -5785,9 +5785,13 @@ intel_dp_init_connector(struct intel_digital_port
*intel_dig_port,
switch (port) {
case PORT_A:
intel_encoder-hpd_pin = HPD_PORT_A;
+ if (IS_BROXTON(dev_priv) (INTEL_REVID(dev) BXT_REVID_B0))
+ intel_encoder-hpd_pin = HPD_PORT_C;
break;
case PORT_B:
intel_encoder-hpd_pin = HPD_PORT_B;
+ if (IS_BROXTON(dev_priv) (INTEL_REVID(dev) BXT_REVID_B0))
+ intel_encoder-hpd_pin = HPD_PORT_A;
break;
case PORT_C:
intel_encoder-hpd_pin = HPD_PORT_C;
diff --git a/drivers/gpu/drm/i915/intel_hdmi.c
b/drivers/gpu/drm/i915/intel_hdmi.c
index 70bad5b..94fa716 100644
--- a/drivers/gpu/drm/i915/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/intel_hdmi.c
@@ -1973,7 +1973,14 @@ void intel_hdmi_init_connector(struct
intel_digital_port *intel_dig_port,
intel_hdmi-ddc_bus = GMBUS_PIN_1_BXT;
else
intel_hdmi-ddc_bus = GMBUS_PIN_DPB;
- intel_encoder-hpd_pin = HPD_PORT_B;
+ /*
+ * On BXT A0/A1, sw needs to activate DDIA HPD logic and
+ * interrupts to check the external panel connection.
+ */
+ if (IS_BROXTON(dev_priv) (INTEL_REVID(dev) BXT_REVID_B0))
+ intel_encoder-hpd_pin = HPD_PORT_A;
+ else
+ intel_encoder-hpd_pin = HPD_PORT_B;
break;
case PORT_C:
if (IS_BROXTON(dev_priv))
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC 4/8] drm/i915: Insert commands for capturing timestamps in the ring
On Wed, 2015-08-05 at 09:30 +, Chris Wilson wrote: On Wed, Aug 05, 2015 at 11:25:40AM +0530, sourab.gu...@intel.com wrote: From: Sourab Gupta sourab.gu...@intel.com This patch adds the routines through which one can insert commands in the ringbuf for capturing timestamps, which are used to insert these commands around the batchbuffer. While inserting the commands, we keep a reference of associated request. This will be released when we are forwarding the samples to userspace (or when the event is being destroyed). Also, an active reference of the destination buffer is taken here, so that we can be assured that the buffer is freed up only after GPU is done with it, even if the local reference of the buffer is released. v2: Changes (as suggested by Chris): - Passing in 'request' struct for emit report function - Removed multiple calls to i915_gem_obj_to_ggtt(). Keeping hold of pinned vma from start and using when required. - Better nomenclature, and error handling. @@ -919,6 +993,7 @@ static int init_gen_pmu_buffer(struct perf_event *event) dev_priv-gen_pmu.buffer.obj = bo; dev_priv-gen_pmu.buffer.gtt_offset = i915_gem_obj_ggtt_offset(bo); + dev_priv-gen_pmu.buffer.vma = i915_gem_obj_to_ggtt(bo); dev_priv-gen_pmu.buffer.addr = vmap_oa_buffer(bo); INIT_LIST_HEAD(dev_priv-gen_pmu.node_list); Still calling i915_gem_obj_to_ggtt(bo) twice! With pmu_buffer.vma you can drop pmu_buffer.gtt_offset and never be confused again. -Chris Sorry, I'll have the one pertaining to gtt offset removed, and derive the gtt offset field from the vma only. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC 2/8] drm/i915: Add mechanism for forwarding the timestamp data through perf
On Wed, Aug 05, 2015 at 11:25:38AM +0530, sourab.gu...@intel.com wrote:
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 66f9ee9..08235582 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1676,6 +1676,13 @@ struct i915_oa_rcs_node {
u32 tag;
};
+struct i915_gen_pmu_node {
+ struct list_head head;
This not the head of the list, but a node.
+ struct drm_i915_gem_request *req;
Use request since this is a less often used member name and brevity
isn't saving thousands of keystrokes.
+ u32 offset;
+ u32 ctx_id;
+};
+static int i915_gen_pmu_wait_gpu(struct drm_i915_private *dev_priv)
+{
+ struct i915_gen_pmu_node *last_entry = NULL;
+ int ret;
+
+ /*
+ * Wait for the last scheduled request to complete. This would
+ * implicitly wait for the prior submitted requests. The refcount
+ * of the requests is not decremented here.
+ */
+ spin_lock(dev_priv-gen_pmu.lock);
+
+ if (!list_empty(dev_priv-gen_pmu.node_list)) {
+ last_entry = list_last_entry(dev_priv-gen_pmu.node_list,
+ struct i915_gen_pmu_node, head);
+ }
+ spin_unlock(dev_priv-gen_pmu.lock);
Because you issue requests on all rings that are not actually
serialised, the order of writes and retirements are also not serialised,
i.e. this does not do a complete wait for all activity on the object.
static void forward_gen_pmu_snapshots(struct drm_i915_private *dev_priv)
{
- WARN_ON(!dev_priv-gen_pmu.buffer.addr);
+ struct i915_gen_pmu_node *entry, *next;
+ LIST_HEAD(deferred_list_free);
+ int ret;
- /* TODO: routine for forwarding snapshots to userspace */
+ list_for_each_entry_safe
+ (entry, next, dev_priv-gen_pmu.node_list, head) {
+ if (!i915_gem_request_completed(entry-req, true))
+ break;
Again the list is not actually in retirement order since you combine
multiple rings into one list.
These problems magically disappear with a list per-ring and a page
per-ring. You also need to be more careful with overwriting unflushed
entries. A dynamic approach to page allocation overcomes that.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC 1/8] drm/i915: Add a new PMU for handling non-OA counter data profiling requests
On Wed, Aug 05, 2015 at 09:45:28AM +, Gupta, Sourab wrote: On Wed, 2015-08-05 at 09:38 +, Chris Wilson wrote: On Wed, Aug 05, 2015 at 11:25:37AM +0530, sourab.gu...@intel.com wrote: From: Sourab Gupta sourab.gu...@intel.com The current perf PMU driver is specific for collection of OA counter statistics (which may be done in a periodic or asynchronous way). Since this enables us (and limits us) to render ring, we have no means for collection of data pertaining to other rings. To overcome this limitation, we need to have a new PMU driver which enables data collection for other rings also (in a non-OA specific mode). This patch adds a new perf PMU to i915 device private, for handling profiling requests for non-OA counter data.This data may encompass timestamps, mmio register values, etc. for the relevant ring. The new perf PMU will serve these purposes, without constraining itself to type of data being dumped (which may restrict the user to specific ring like in case of OA counters). The patch introduces this PMU driver alongwith its associated callbacks. Signed-off-by: Sourab Gupta sourab.gu...@intel.com --- drivers/gpu/drm/i915/i915_dma.c | 2 + drivers/gpu/drm/i915/i915_drv.h | 19 drivers/gpu/drm/i915/i915_oa_perf.c | 215 You have to admit it is a bit odd for the object to be called i915_oa_pmu/i915_gen_pmu and the file i915_oa_perf.c -Chris Well, yes.. If the nomenclature of i915_gen_pmu is agreed upon, I can have a new file named as i915_gen_pmu.c which will hold the routines for this pmu, leaving oa pmu stuff behind in i915_oa_pmu.c Or just i915_pmu.c if we share a lot of the routines and i915_gen_pmu, i915_oa_pmu themselves are more or less the perf_event interface. -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 3/3] drm/i915: Check live status before reading edid
On Wed, 2015-07-15 at 09:25 +0530, Jindal, Sonika wrote:
On 7/14/2015 7:59 PM, Imre Deak wrote:
On ti, 2015-07-14 at 17:21 +0530, Sonika Jindal wrote:
Adding this for SKL onwards.
v2: Adding checks for VLV/CHV as well. Reusing old ibx and g4x functions
to check digital port status. Adding a separate function to get bxt live
status (Daniel)
Signed-off-by: Sonika Jindal sonika.jin...@intel.com
---
drivers/gpu/drm/i915/intel_dp.c |4 ++--
drivers/gpu/drm/i915/intel_drv.h |2 ++
drivers/gpu/drm/i915/intel_hdmi.c | 43
+
3 files changed, 43 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c
b/drivers/gpu/drm/i915/intel_dp.c
index 4ebfc3a..7b54b9d 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -4443,8 +4443,8 @@ ironlake_dp_detect(struct intel_dp *intel_dp)
return intel_dp_detect_dpcd(intel_dp);
}
-static int g4x_digital_port_connected(struct drm_device *dev,
- struct intel_digital_port
*intel_dig_port)
+int g4x_digital_port_connected(struct drm_device *dev,
+ struct intel_digital_port *intel_dig_port)
{
struct drm_i915_private *dev_priv = dev-dev_private;
uint32_t bit;
diff --git a/drivers/gpu/drm/i915/intel_drv.h
b/drivers/gpu/drm/i915/intel_drv.h
index a47fbc3..30c8dd6 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -1187,6 +1187,8 @@ void intel_edp_drrs_disable(struct intel_dp
*intel_dp);
void intel_edp_drrs_invalidate(struct drm_device *dev,
unsigned frontbuffer_bits);
void intel_edp_drrs_flush(struct drm_device *dev, unsigned
frontbuffer_bits);
+int g4x_digital_port_connected(struct drm_device *dev,
+ struct intel_digital_port *intel_dig_port);
/* intel_dp_mst.c */
int intel_dp_mst_encoder_init(struct intel_digital_port *intel_dig_port,
int conn_id);
diff --git a/drivers/gpu/drm/i915/intel_hdmi.c
b/drivers/gpu/drm/i915/intel_hdmi.c
index c4b82ce..402be54 100644
--- a/drivers/gpu/drm/i915/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/intel_hdmi.c
@@ -1300,6 +1300,40 @@ intel_hdmi_unset_edid(struct drm_connector
*connector)
to_intel_connector(connector)-detect_edid = NULL;
}
+static bool bxt_port_connected(struct drm_i915_private *dev_priv,
+ struct intel_digital_port *port)
+{
+ u32 temp = I915_READ(GEN8_DE_PORT_ISR);
+
+ /* TODO: Add bxt A0/A1 wa related to hpd pin swap */
This doesn't seem to work on my BXT A1 RVP. For me GEN8_DE_PORT_ISR
reads all 0 even while an HDMI monitor is plugged to port B.
This is really strange, I checked on atleast 3 different A1 boards and 3
different monitors (also on two different branches) and I see 0x0 as
0x8 after the HPD swap patch when monitor is connected and it is 0 when
no hdmi monitor is present.
Do you think something to do with the board config?
Upgrading my BIOS from version W25 to W29 has solved this issue,
GEN8_DE_PORT_ISR bit 3 is set now correctly whenever the monitor is
connected. My guess is that some GPIO/PIN configuration change done by
the BIOS has fixed this, although I haven't found the reason by looking
at the PAD_CFG register contents and BIOS release notes.
+ switch (port-port) {
+ case PORT_B:
+ return temp BXT_DE_PORT_HP_DDIB;
+
+ case PORT_C:
+ return temp BXT_DE_PORT_HP_DDIC;
+
+ default:
+ return false;
+
+ }
+}
+
+static bool intel_hdmi_live_status(struct intel_digital_port
*intel_dig_port)
+{
+ struct drm_device *dev = intel_dig_port-base.base.dev;
+ struct drm_i915_private *dev_priv = to_i915(dev);
+
+ if (IS_VALLEYVIEW(dev))
+ return g4x_digital_port_connected(dev, intel_dig_port);
+ else if (IS_SKYLAKE(dev))
+ return ibx_digital_port_connected(dev_priv, intel_dig_port);
+ else if (IS_BROXTON(dev))
+ return bxt_port_connected(dev_priv, intel_dig_port);
+
+ return true;
+}
+
static bool
intel_hdmi_set_edid(struct drm_connector *connector)
{
@@ -1308,15 +1342,16 @@ intel_hdmi_set_edid(struct drm_connector
*connector)
struct intel_encoder *intel_encoder =
hdmi_to_dig_port(intel_hdmi)-base;
enum intel_display_power_domain power_domain;
- struct edid *edid;
+ struct edid *edid = NULL;
bool connected = false;
power_domain = intel_display_port_power_domain(intel_encoder);
intel_display_power_get(dev_priv, power_domain);
- edid = drm_get_edid(connector,
- intel_gmbus_get_adapter(dev_priv,
- intel_hdmi-ddc_bus));
+ if (intel_hdmi_live_status(hdmi_to_dig_port(intel_hdmi)))
+ edid = drm_get_edid(connector,
+
Re: [Intel-gfx] [RFC 8/8] drm/i915: Support for retrieving MMIO register values alongwith timestamps through perf
On Wed, Aug 05, 2015 at 11:25:44AM +0530, sourab.gu...@intel.com wrote: From: Sourab Gupta sourab.gu...@intel.com This patch adds support for retrieving MMIO register values alongwith timestamps and forwarding them to userspace through perf. The userspace can request upto 8 MMIO register values to be dumped. The addresses of upto 8 MMIO registers can be passed through perf attr config. The registers are checked against a whitelist before passing them on. The commands to dump the values of these MMIO registers are then inserted into the ring alongwith commands to dump the timestamps. The values reported to userspace are deltas across batches right? We don't expose the global value to an unprivileged user? It would be nice to clarify that in perf_init so that the reviewer is aware that the issue of unprivileged information leak is addressed (or at least reminded that the register values do not leak!). -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/bxt: WA for swapped HPD pins in A stepping
On 8/5/2015 3:23 PM, Imre Deak wrote:
On Mon, 2015-07-27 at 11:02 +0530, Sonika Jindal wrote:
WA for BXT A0/A1, where DDIB's HPD pin is swapped to DDIA, so enabling
DDIA HPD pin in place of DDIB.
v2: For DP, irq_port is used to determine the encoder instead of
hpd_pin and removing the edp HPD logic because port A HPD is not
present(Imre)
v3: Rebased on top of Imre's patchset for enabling HPD on PORT A.
Added hpd_pin swapping for intel_dp_init_connector, setting encoder
for PORT_A as per the WA in irq_port (Imre)
v4: Dont enable interrupt for edp, also reframe the description (Siva)
Signed-off-by: Sonika Jindal sonika.jin...@intel.com
This patch is a new version of 2/2 of your patchset at
http://lists.freedesktop.org/archives/intel-gfx/2015-July/071580.html
so this should've been sent either as a reply to the individual v1 patch
there, or just by resending the whole patchset. For now you could just
resend the whole patchset. Also please add the version info to the
subject with git format-patch --subject-prefix.
---
drivers/gpu/drm/i915/intel_ddi.c | 11 ++-
drivers/gpu/drm/i915/intel_dp.c |4
drivers/gpu/drm/i915/intel_hdmi.c |9 -
3 files changed, 22 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index e2c6f73..8d7ffe0 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -3225,7 +3225,16 @@ void intel_ddi_init(struct drm_device *dev, enum port
port)
goto err;
intel_dig_port-hpd_pulse = intel_dp_hpd_pulse;
- dev_priv-hotplug.irq_port[port] = intel_dig_port;
+ /*
+* On BXT A0/A1, sw needs to activate DDIA HPD logic and
+* interrupts to check the external panel connection.
+*/
+ if (IS_BROXTON(dev_priv) (INTEL_REVID(dev) BXT_REVID_B0)
+ port == PORT_B)
+ dev_priv-hotplug.irq_port[PORT_A] = intel_dig_port;
+ /* Dont enable interrupts for edp*/
+ else if (port != PORT_A)
+ dev_priv-hotplug.irq_port[port] = intel_dig_port;
Not enabling HPD on eDP is not a BXT specific change (even though it's
disabled now everywhere), so that part should be a separate patch and
ordered before patch 1/2. Also this isn't the proper place to disable
HPD handling; as long as the corresponding intel_encoder-hpd_pin is set
the relevant interrupt will get unmasked and hotplug_work will be
called. See bxt_hpd_irq_setup() and intel_hpd_irq_handler().
hmm , ok Sonika, please remove HPD_PORT_A being set for PORT_A. here
else if can
be modified to simple else
}
/* In theory we don't need the encoder-type check, but leave it just in
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index fcc64e5..71679ef 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -5785,9 +5785,13 @@ intel_dp_init_connector(struct intel_digital_port
*intel_dig_port,
switch (port) {
case PORT_A:
intel_encoder-hpd_pin = HPD_PORT_A;
+ if (IS_BROXTON(dev_priv) (INTEL_REVID(dev) BXT_REVID_B0))
+ intel_encoder-hpd_pin = HPD_PORT_C;
break;
case PORT_B:
intel_encoder-hpd_pin = HPD_PORT_B;
+ if (IS_BROXTON(dev_priv) (INTEL_REVID(dev) BXT_REVID_B0))
+ intel_encoder-hpd_pin = HPD_PORT_A;
break;
case PORT_C:
intel_encoder-hpd_pin = HPD_PORT_C;
diff --git a/drivers/gpu/drm/i915/intel_hdmi.c
b/drivers/gpu/drm/i915/intel_hdmi.c
index 70bad5b..94fa716 100644
--- a/drivers/gpu/drm/i915/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/intel_hdmi.c
@@ -1973,7 +1973,14 @@ void intel_hdmi_init_connector(struct intel_digital_port
*intel_dig_port,
intel_hdmi-ddc_bus = GMBUS_PIN_1_BXT;
else
intel_hdmi-ddc_bus = GMBUS_PIN_DPB;
- intel_encoder-hpd_pin = HPD_PORT_B;
+ /*
+* On BXT A0/A1, sw needs to activate DDIA HPD logic and
+* interrupts to check the external panel connection.
+*/
+ if (IS_BROXTON(dev_priv) (INTEL_REVID(dev) BXT_REVID_B0))
+ intel_encoder-hpd_pin = HPD_PORT_A;
+ else
+ intel_encoder-hpd_pin = HPD_PORT_B;
break;
case PORT_C:
if (IS_BROXTON(dev_priv))
--
regards,
Sivakumar
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC 8/8] drm/i915: Support for retrieving MMIO register values alongwith timestamps through perf
On Wed, 2015-08-05 at 10:03 +, Chris Wilson wrote: On Wed, Aug 05, 2015 at 11:25:44AM +0530, sourab.gu...@intel.com wrote: From: Sourab Gupta sourab.gu...@intel.com This patch adds support for retrieving MMIO register values alongwith timestamps and forwarding them to userspace through perf. The userspace can request upto 8 MMIO register values to be dumped. The addresses of upto 8 MMIO registers can be passed through perf attr config. The registers are checked against a whitelist before passing them on. The commands to dump the values of these MMIO registers are then inserted into the ring alongwith commands to dump the timestamps. The values reported to userspace are deltas across batches right? We don't expose the global value to an unprivileged user? It would be nice to clarify that in perf_init so that the reviewer is aware that the issue of unprivileged information leak is addressed (or at least reminded that the register values do not leak!). -Chris Hi Chris, Two things here: 1) Only root is allowed to call event_init for gen pmu. This restriction is there in event_init. (The thought behind this restriction being that we are profiling data across contexts here, so a process wishing to listen to global activity happening in system across all contexts ought to have root priviliges). Is this thought process correct? Should we be supporting non-root users too? 2) Being already a root, do we need to worry about the unauthorized mmio access while exposing these mmio values through the interface? In the current patches, the full mmio register value is dumped to be passed on to userspace (no deltas across batches), provided the register is there in the whitelist. Does the question of unpriviliged information leak arise here(the user being root)? Regards, Sourab ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC 8/8] drm/i915: Support for retrieving MMIO register values alongwith timestamps through perf
On Wed, Aug 05, 2015 at 10:18:50AM +, Gupta, Sourab wrote: On Wed, 2015-08-05 at 10:03 +, Chris Wilson wrote: On Wed, Aug 05, 2015 at 11:25:44AM +0530, sourab.gu...@intel.com wrote: From: Sourab Gupta sourab.gu...@intel.com This patch adds support for retrieving MMIO register values alongwith timestamps and forwarding them to userspace through perf. The userspace can request upto 8 MMIO register values to be dumped. The addresses of upto 8 MMIO registers can be passed through perf attr config. The registers are checked against a whitelist before passing them on. The commands to dump the values of these MMIO registers are then inserted into the ring alongwith commands to dump the timestamps. The values reported to userspace are deltas across batches right? We don't expose the global value to an unprivileged user? It would be nice to clarify that in perf_init so that the reviewer is aware that the issue of unprivileged information leak is addressed (or at least reminded that the register values do not leak!). -Chris Hi Chris, Two things here: 1) Only root is allowed to call event_init for gen pmu. This restriction is there in event_init. (The thought behind this restriction being that we are profiling data across contexts here, so a process wishing to listen to global activity happening in system across all contexts ought to have root priviliges). Is this thought process correct? Should we be supporting non-root users too? That is not clear in this patch, so you need to address such concerns at least in the changelog, and preferrably with a reminder in the whitelist (that these register reads are safe because they are being done from a privileged context only - we then have a red flag in case we lower it). What is the privilege check you are using here exactly? For gen pmu, I want it user accessible. How long does it take to execute my batches is a common developer query. We may even be able to make anonymised information freely available ala top (per-process GPU usage, memory usage, though cgroups/namespacing rules probably apply here). 2) Being already a root, do we need to worry about the unauthorized mmio access while exposing these mmio values through the interface? Yes. See above, the information here can be anonymised and useful for user processes exactly like TIMESTAMP. In the current patches, the full mmio register value is dumped to be passed on to userspace (no deltas across batches), provided the register is there in the whitelist. Does the question of unpriviliged information leak arise here(the user being root)? Not for root. -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v3 03/13] drm/i915: Update atomic state when removing mst connector.
Fully remove the MST connector from the atomic state, and remove the
early returns in check_*_state for MST connectors.
With atomic the state can be made consistent all the time.
Changes since v1:
- Remove the MST check in intel_connector_check_state too.
Signed-off-by: Maarten Lankhorst maarten.lankho...@linux.intel.com
Reviewed-by: Ander Conselvan de Oliveira conselv...@gmail.com
---
drivers/gpu/drm/i915/intel_display.c | 11 -
drivers/gpu/drm/i915/intel_dp_mst.c | 45 +++-
2 files changed, 44 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 7747520bf9f6..dfe4407b0390 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -6370,10 +6370,6 @@ static void intel_connector_check_state(struct
intel_connector *connector)
connector-base.base.id,
connector-base.name);
- /* there is no real hw state for MST connectors */
- if (connector-mst_port)
- return;
-
I915_STATE_WARN(connector-base.dpms == DRM_MODE_DPMS_OFF,
wrong connector dpms state\n);
I915_STATE_WARN(connector-base.encoder != encoder-base,
@@ -12751,13 +12747,6 @@ check_encoder_state(struct drm_device *dev)
encoder-base.crtc,
connector's crtc doesn't match encoder crtc\n);
}
- /*
-* for MST connectors if we unplug the connector is gone
-* away but the encoder is still connected to a crtc
-* until a modeset happens in response to the hotplug.
-*/
- if (!enabled encoder-base.encoder_type ==
DRM_MODE_ENCODER_DPMST)
- continue;
I915_STATE_WARN(!!encoder-base.crtc != enabled,
encoder's enabled state mismatch
diff --git a/drivers/gpu/drm/i915/intel_dp_mst.c
b/drivers/gpu/drm/i915/intel_dp_mst.c
index e3a5864160fa..36bd9394f789 100644
--- a/drivers/gpu/drm/i915/intel_dp_mst.c
+++ b/drivers/gpu/drm/i915/intel_dp_mst.c
@@ -459,6 +459,49 @@ static struct drm_connector
*intel_dp_add_mst_connector(struct drm_dp_mst_topolo
return connector;
}
+static void
+intel_dp_unbind_mst_connector(struct drm_device *dev,
+ struct drm_connector *connector)
+{
+ struct drm_atomic_state *state;
+ struct drm_connector_state *conn_state;
+ struct drm_crtc *crtc = connector-state-crtc;
+ int ret;
+
+ if (!crtc)
+ return;
+
+ state = drm_atomic_state_alloc(dev);
+ if (!state)
+ return;
+
+ state-acquire_ctx = dev-mode_config.acquire_ctx;
+
+ conn_state = drm_atomic_get_connector_state(state, connector);
+ ret = PTR_ERR_OR_ZERO(conn_state);
+ if (!ret)
+ ret = drm_atomic_set_crtc_for_connector(conn_state, NULL);
+
+ if (!ret)
+ ret = drm_atomic_add_affected_connectors(state, crtc);
+
+ if (!ret !drm_atomic_connectors_for_crtc(state, crtc)) {
+ struct drm_crtc_state *crtc_state =
+ drm_atomic_get_existing_crtc_state(state, crtc);
+
+ crtc_state-active = false;
+ ret = drm_atomic_set_mode_for_crtc(crtc_state, NULL);
+ }
+
+ if (!ret)
+ ret = drm_atomic_commit(state);
+
+ if (ret)
+ drm_atomic_state_free(state);
+
+ I915_STATE_WARN_ON(ret);
+}
+
static void intel_dp_destroy_mst_connector(struct drm_dp_mst_topology_mgr *mgr,
struct drm_connector *connector)
{
@@ -466,7 +509,7 @@ static void intel_dp_destroy_mst_connector(struct
drm_dp_mst_topology_mgr *mgr,
struct drm_device *dev = connector-dev;
/* need to nuke the connector */
drm_modeset_lock_all(dev);
- intel_connector_dpms(connector, DRM_MODE_DPMS_OFF);
+ intel_dp_unbind_mst_connector(dev, connector);
drm_modeset_unlock_all(dev);
intel_connector-unregister(intel_connector);
--
2.1.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v3 02/13] drm/i915: Validate the state after an atomic modeset only, and pass the state.
First step in removing dpms and validating atomic state.
There can still be a mismatch in the connector state because the dpms
callbacks are still used, but this can not happen immediately after a modeset.
Signed-off-by: Maarten Lankhorst maarten.lankho...@linux.intel.com
Reviewed-by: Ander Conselvan de Oliveira conselv...@gmail.com
---
drivers/gpu/drm/i915/intel_crt.c | 2 --
drivers/gpu/drm/i915/intel_display.c | 12 ++--
drivers/gpu/drm/i915/intel_drv.h | 1 -
drivers/gpu/drm/i915/intel_dvo.c | 2 --
drivers/gpu/drm/i915/intel_sdvo.c| 2 --
5 files changed, 6 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_crt.c b/drivers/gpu/drm/i915/intel_crt.c
index 5d78c1feec81..9eba3dd5b434 100644
--- a/drivers/gpu/drm/i915/intel_crt.c
+++ b/drivers/gpu/drm/i915/intel_crt.c
@@ -280,8 +280,6 @@ static int intel_crt_dpms(struct drm_connector *connector,
int mode)
intel_crtc_update_dpms(crtc);
}
- intel_modeset_check_state(connector-dev);
-
return 0;
}
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index dfe4407b0390..77b4da7e698c 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -6440,8 +6440,6 @@ int intel_connector_dpms(struct drm_connector *connector,
int mode)
if (connector-encoder)
intel_encoder_dpms(to_intel_encoder(connector-encoder), mode);
- intel_modeset_check_state(connector-dev);
-
return 0;
}
@@ -12900,8 +12898,9 @@ check_shared_dpll_state(struct drm_device *dev)
}
}
-void
-intel_modeset_check_state(struct drm_device *dev)
+static void
+intel_modeset_check_state(struct drm_device *dev,
+ struct drm_atomic_state *old_state)
{
check_wm_state(dev);
check_connector_state(dev);
@@ -13290,10 +13289,11 @@ static int intel_atomic_commit(struct drm_device *dev,
drm_atomic_helper_wait_for_vblanks(dev, state);
drm_atomic_helper_cleanup_planes(dev, state);
- drm_atomic_state_free(state);
if (any_ms)
- intel_modeset_check_state(dev);
+ intel_modeset_check_state(dev, state);
+
+ drm_atomic_state_free(state);
return 0;
}
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 320c9e6bd848..0da4236dc85a 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -999,7 +999,6 @@ int intel_connector_init(struct intel_connector *);
struct intel_connector *intel_connector_alloc(void);
int intel_connector_dpms(struct drm_connector *, int mode);
bool intel_connector_get_hw_state(struct intel_connector *connector);
-void intel_modeset_check_state(struct drm_device *dev);
bool ibx_digital_port_connected(struct drm_i915_private *dev_priv,
struct intel_digital_port *port);
void intel_connector_attach_encoder(struct intel_connector *connector,
diff --git a/drivers/gpu/drm/i915/intel_dvo.c b/drivers/gpu/drm/i915/intel_dvo.c
index fd5e522abebb..600f7fb855d8 100644
--- a/drivers/gpu/drm/i915/intel_dvo.c
+++ b/drivers/gpu/drm/i915/intel_dvo.c
@@ -237,8 +237,6 @@ static int intel_dvo_dpms(struct drm_connector *connector,
int mode)
intel_crtc_update_dpms(crtc);
}
- intel_modeset_check_state(connector-dev);
-
return 0;
}
diff --git a/drivers/gpu/drm/i915/intel_sdvo.c
b/drivers/gpu/drm/i915/intel_sdvo.c
index 2c435a79d4da..8911e0e417ee 100644
--- a/drivers/gpu/drm/i915/intel_sdvo.c
+++ b/drivers/gpu/drm/i915/intel_sdvo.c
@@ -1550,8 +1550,6 @@ static int intel_sdvo_dpms(struct drm_connector
*connector, int mode)
intel_sdvo_set_active_outputs(intel_sdvo,
intel_sdvo-attached_output);
}
- intel_modeset_check_state(connector-dev);
-
return 0;
}
--
2.1.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v3 12/13] drm/i915: Only update mode related state if a modeset happened.
The rest will be a noop anyway, since without modeset there will be
no updated dplls and no modeset state to update.
Signed-off-by: Maarten Lankhorst maarten.lankho...@linux.intel.com
---
drivers/gpu/drm/i915/intel_display.c | 30 +++---
1 file changed, 7 insertions(+), 23 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 1fd8b7dec7da..aa444cbc2262 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -12181,33 +12181,15 @@ fail:
return ret;
}
-static bool intel_crtc_in_use(struct drm_crtc *crtc)
-{
- struct drm_encoder *encoder;
- struct drm_device *dev = crtc-dev;
-
- list_for_each_entry(encoder, dev-mode_config.encoder_list, head)
- if (encoder-crtc == crtc)
- return true;
-
- return false;
-}
-
static void
-intel_modeset_update_state(struct drm_atomic_state *state)
+intel_modeset_update_crtc_state(struct drm_atomic_state *state)
{
struct drm_crtc *crtc;
struct drm_crtc_state *crtc_state;
int i;
- intel_shared_dpll_commit(state);
-
- drm_atomic_helper_update_legacy_modeset_state(state-dev, state);
-
/* Double check state. */
for_each_crtc_in_state(state, crtc, crtc_state, i) {
- WARN_ON(crtc-state-enable != intel_crtc_in_use(crtc));
-
to_intel_crtc(crtc)-config = to_intel_crtc_state(crtc-state);
/* Update hwmode for vblank functions */
@@ -13110,12 +13092,14 @@ static int intel_atomic_commit(struct drm_device *dev,
/* Only after disabling all output pipelines that will be changed can we
* update the the output configuration. */
- intel_modeset_update_state(state);
+ intel_modeset_update_crtc_state(state);
- /* The state has been swaped above, so state actually contains the
-* old state now. */
- if (any_ms)
+ if (any_ms) {
+ intel_shared_dpll_commit(state);
+
+ drm_atomic_helper_update_legacy_modeset_state(state-dev,
state);
modeset_update_crtc_power_domains(state);
+ }
/* Now enable the clocks, plane, pipe, and connectors that we set up. */
for_each_crtc_in_state(state, crtc, crtc_state, i) {
--
2.1.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v3 07/13] drm/i915: Make crtc checking use the atomic state, v2.
Instead of allocating pipe_config on the stack use the old
crtc_state, it's only going to freed from this point on.
All crtc' are now only checked once during modeset,
because false positives can happen with encoders after
dpms changes and to limit the amount of errors for 1 failure.
Changes since v1:
- crtc_state - old_crtc_state
- state - old_state
Signed-off-by: Maarten Lankhorst maarten.lankho...@linux.intel.com
Reviewed-by: Ander Conselvan de Oliveira conselv...@gmail.com
---
drivers/gpu/drm/i915/intel_display.c | 118 +--
1 file changed, 56 insertions(+), 62 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 129931f3013e..4babecd1c99f 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -11829,7 +11829,7 @@ static int intel_crtc_atomic_check(struct drm_crtc
*crtc,
struct intel_crtc_state *pipe_config =
to_intel_crtc_state(crtc_state);
struct drm_atomic_state *state = crtc_state-state;
- int ret, idx = crtc-base.id;
+ int ret;
bool mode_changed = needs_modeset(crtc_state);
if (mode_changed !check_encoder_cloning(state, intel_crtc)) {
@@ -11837,10 +11837,6 @@ static int intel_crtc_atomic_check(struct drm_crtc
*crtc,
return -EINVAL;
}
- I915_STATE_WARN(crtc-state-active != intel_crtc-active,
- [CRTC:%i] mismatch between state-active(%i) and
crtc-active(%i)\n,
- idx, crtc-state-active, intel_crtc-active);
-
if (mode_changed !crtc_state-active)
intel_crtc-atomic.update_wm_post = true;
@@ -12722,19 +12718,16 @@ check_encoder_state(struct drm_device *dev)
for_each_intel_encoder(dev, encoder) {
bool enabled = false;
- bool active = false;
- enum pipe pipe, tracked_pipe;
+ enum pipe pipe;
DRM_DEBUG_KMS([ENCODER:%d:%s]\n,
encoder-base.base.id,
encoder-base.name);
for_each_intel_connector(dev, connector) {
- if (connector-base.encoder != encoder-base)
+ if (connector-base.state-best_encoder !=
encoder-base)
continue;
enabled = true;
- if (connector-base.dpms != DRM_MODE_DPMS_OFF)
- active = true;
I915_STATE_WARN(connector-base.state-crtc !=
encoder-base.crtc,
@@ -12745,85 +12738,86 @@ check_encoder_state(struct drm_device *dev)
encoder's enabled state mismatch
(expected %i, found %i)\n,
!!encoder-base.crtc, enabled);
- I915_STATE_WARN(active !encoder-base.crtc,
-active encoder with no crtc\n);
-
- active = encoder-get_hw_state(encoder, pipe);
if (!encoder-base.crtc) {
- I915_STATE_WARN(active,
-encoder detached but not turned off.\n);
+ bool active;
- continue;
+ active = encoder-get_hw_state(encoder, pipe);
+ I915_STATE_WARN(active,
+encoder detached but still enabled on pipe %c.\n,
+pipe_name(pipe));
}
-
- I915_STATE_WARN(active != encoder-base.crtc-state-active,
-encoder's hw state doesn't match sw tracking
-(expected %i, found %i)\n,
-encoder-base.crtc-state-active, active);
-
-
- tracked_pipe = to_intel_crtc(encoder-base.crtc)-pipe;
- I915_STATE_WARN(active pipe != tracked_pipe,
-active encoder's pipe doesn't match
-(expected %i, found %i)\n,
-tracked_pipe, pipe);
-
}
}
static void
-check_crtc_state(struct drm_device *dev)
+check_crtc_state(struct drm_device *dev, struct drm_atomic_state *old_state)
{
struct drm_i915_private *dev_priv = dev-dev_private;
- struct intel_crtc *crtc;
struct intel_encoder *encoder;
- struct intel_crtc_state pipe_config;
+ struct drm_crtc_state *old_crtc_state;
+ struct drm_crtc *crtc;
+ int i;
- for_each_intel_crtc(dev, crtc) {
+ for_each_crtc_in_state(old_state, crtc, old_crtc_state, i) {
+ struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
+ struct intel_crtc_state *pipe_config, *sw_config;
bool active;
- memset(pipe_config, 0, sizeof(pipe_config));
+ if (!needs_modeset(crtc-state))
+ continue;
- DRM_DEBUG_KMS([CRTC:%d]\n,
-
[Intel-gfx] [PATCH v3 01/13] drm/i915: Make the force_thru workaround atomic, v2.
Set connectors_changed to force a modeset if the panel fitter's force
enabled on eDP.
Changes since v1:
- Use connectors_changed instead of active_changed because it's a
routing update.
Signed-off-by: Maarten Lankhorst maarten.lankho...@linux.intel.com
---
drivers/gpu/drm/i915/i915_debugfs.c | 82 +++-
drivers/gpu/drm/i915/intel_display.c | 3 ++
2 files changed, 27 insertions(+), 58 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index 23a69307e12e..d1c643a82267 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -3645,74 +3645,40 @@ static int ilk_pipe_crc_ctl_reg(enum
intel_pipe_crc_source *source,
return 0;
}
-static void hsw_trans_edp_pipe_A_crc_wa(struct drm_device *dev)
+static void hsw_trans_edp_pipe_A_crc_wa(struct drm_device *dev, bool enable)
{
struct drm_i915_private *dev_priv = dev-dev_private;
struct intel_crtc *crtc =
to_intel_crtc(dev_priv-pipe_to_crtc_mapping[PIPE_A]);
struct intel_crtc_state *pipe_config;
+ struct drm_atomic_state *state;
+ int ret = 0;
drm_modeset_lock_all(dev);
- pipe_config = to_intel_crtc_state(crtc-base.state);
-
- /*
-* If we use the eDP transcoder we need to make sure that we don't
-* bypass the pfit, since otherwise the pipe CRC source won't work. Only
-* relevant on hsw with pipe A when using the always-on power well
-* routing.
-*/
- if (pipe_config-cpu_transcoder == TRANSCODER_EDP
- !pipe_config-pch_pfit.enabled) {
- bool active = pipe_config-base.active;
-
- if (active) {
- intel_crtc_control(crtc-base, false);
- pipe_config = to_intel_crtc_state(crtc-base.state);
- }
-
- pipe_config-pch_pfit.force_thru = true;
-
- intel_display_power_get(dev_priv,
- POWER_DOMAIN_PIPE_PANEL_FITTER(PIPE_A));
-
- if (active)
- intel_crtc_control(crtc-base, true);
+ state = drm_atomic_state_alloc(dev);
+ if (!state) {
+ ret = -ENOMEM;
+ goto out;
}
- drm_modeset_unlock_all(dev);
-}
-static void hsw_undo_trans_edp_pipe_A_crc_wa(struct drm_device *dev)
-{
- struct drm_i915_private *dev_priv = dev-dev_private;
- struct intel_crtc *crtc =
- to_intel_crtc(dev_priv-pipe_to_crtc_mapping[PIPE_A]);
- struct intel_crtc_state *pipe_config;
-
- drm_modeset_lock_all(dev);
- /*
-* If we use the eDP transcoder we need to make sure that we don't
-* bypass the pfit, since otherwise the pipe CRC source won't work. Only
-* relevant on hsw with pipe A when using the always-on power well
-* routing.
-*/
- pipe_config = to_intel_crtc_state(crtc-base.state);
- if (pipe_config-pch_pfit.force_thru) {
- bool active = pipe_config-base.active;
-
- if (active) {
- intel_crtc_control(crtc-base, false);
- pipe_config = to_intel_crtc_state(crtc-base.state);
- }
-
- pipe_config-pch_pfit.force_thru = false;
+ state-acquire_ctx = drm_modeset_legacy_acquire_ctx(crtc-base);
+ pipe_config = intel_atomic_get_crtc_state(state, crtc);
+ if (IS_ERR(pipe_config)) {
+ ret = PTR_ERR(pipe_config);
+ goto out;
+ }
- intel_display_power_put(dev_priv,
- POWER_DOMAIN_PIPE_PANEL_FITTER(PIPE_A));
+ pipe_config-pch_pfit.force_thru = enable;
+ if (pipe_config-cpu_transcoder == TRANSCODER_EDP
+ pipe_config-pch_pfit.enabled != enable)
+ pipe_config-base.connectors_changed = true;
- if (active)
- intel_crtc_control(crtc-base, true);
- }
+ ret = drm_atomic_commit(state);
+out:
drm_modeset_unlock_all(dev);
+ WARN(ret, Toggling workaround to %i returns %i\n, enable, ret);
+ if (ret)
+ drm_atomic_state_free(state);
}
static int ivb_pipe_crc_ctl_reg(struct drm_device *dev,
@@ -3732,7 +3698,7 @@ static int ivb_pipe_crc_ctl_reg(struct drm_device *dev,
break;
case INTEL_PIPE_CRC_SOURCE_PF:
if (IS_HASWELL(dev) pipe == PIPE_A)
- hsw_trans_edp_pipe_A_crc_wa(dev);
+ hsw_trans_edp_pipe_A_crc_wa(dev, true);
*val = PIPE_CRC_ENABLE | PIPE_CRC_SOURCE_PF_IVB;
break;
@@ -3844,7 +3810,7 @@ static int pipe_crc_set_source(struct drm_device *dev,
enum pipe pipe,
else if (IS_VALLEYVIEW(dev))
vlv_undo_pipe_scramble_reset(dev, pipe);
else if
[Intel-gfx] [PATCH v3 11/13] drm/i915: Remove connectors_active.
There are no more users, byebye!
Signed-off-by: Maarten Lankhorst maarten.lankho...@linux.intel.com
Reviewed-by: Ander Conselvan de Oliveira conselv...@gmail.com
---
drivers/gpu/drm/i915/intel_display.c | 37 +---
drivers/gpu/drm/i915/intel_drv.h | 1 -
2 files changed, 1 insertion(+), 37 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index ff0a22f223e6..1fd8b7dec7da 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -12196,27 +12196,12 @@ static bool intel_crtc_in_use(struct drm_crtc *crtc)
static void
intel_modeset_update_state(struct drm_atomic_state *state)
{
- struct drm_device *dev = state-dev;
- struct intel_encoder *intel_encoder;
struct drm_crtc *crtc;
struct drm_crtc_state *crtc_state;
- struct drm_connector *connector;
int i;
intel_shared_dpll_commit(state);
- for_each_intel_encoder(dev, intel_encoder) {
- if (!intel_encoder-base.crtc)
- continue;
-
- crtc = intel_encoder-base.crtc;
- crtc_state = drm_atomic_get_existing_crtc_state(state, crtc);
- if (!crtc_state || !needs_modeset(crtc-state))
- continue;
-
- intel_encoder-connectors_active = false;
- }
-
drm_atomic_helper_update_legacy_modeset_state(state-dev, state);
/* Double check state. */
@@ -12231,21 +12216,6 @@ intel_modeset_update_state(struct drm_atomic_state
*state)
else
crtc-hwmode.crtc_clock = 0;
}
-
- list_for_each_entry(connector, dev-mode_config.connector_list, head) {
- if (!connector-encoder || !connector-encoder-crtc)
- continue;
-
- crtc = connector-encoder-crtc;
- crtc_state = drm_atomic_get_existing_crtc_state(state, crtc);
- if (!crtc_state || !needs_modeset(crtc-state))
- continue;
-
- if (crtc-state-active) {
- intel_encoder = to_intel_encoder(connector-encoder);
- intel_encoder-connectors_active = true;
- }
- }
}
static bool intel_fuzzy_clock_check(int clock1, int clock2)
@@ -14966,10 +14936,8 @@ static void intel_sanitize_crtc(struct intel_crtc
*crtc)
* actually up, hence no need to break them. */
WARN_ON(crtc-active);
- for_each_encoder_on_crtc(dev, crtc-base, encoder) {
- WARN_ON(encoder-connectors_active);
+ for_each_encoder_on_crtc(dev, crtc-base, encoder)
encoder-base.crtc = NULL;
- }
}
if (crtc-active || HAS_GMCH_DISPLAY(dev)) {
@@ -15028,7 +14996,6 @@ static void intel_sanitize_encoder(struct intel_encoder
*encoder)
encoder-post_disable(encoder);
}
encoder-base.crtc = NULL;
- encoder-connectors_active = false;
/* Inconsistent output/port/pipe state happens presumably due to
* a bug in one of the get_hw_state functions. Or someplace else
@@ -15190,7 +15157,6 @@ static void intel_modeset_readout_hw_state(struct
drm_device *dev)
encoder-base.crtc = NULL;
}
- encoder-connectors_active = false;
DRM_DEBUG_KMS([ENCODER:%d:%s] hw state readout: %s, pipe %c\n,
encoder-base.base.id,
encoder-base.name,
@@ -15201,7 +15167,6 @@ static void intel_modeset_readout_hw_state(struct
drm_device *dev)
for_each_intel_connector(dev, connector) {
if (connector-get_hw_state(connector)) {
connector-base.dpms = DRM_MODE_DPMS_ON;
- connector-encoder-connectors_active = true;
connector-base.encoder = connector-encoder-base;
} else {
connector-base.dpms = DRM_MODE_DPMS_OFF;
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 62073d2f83fa..c30bbb22381b 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -133,7 +133,6 @@ struct intel_encoder {
enum intel_output_type type;
unsigned int cloneable;
- bool connectors_active;
void (*hot_plug)(struct intel_encoder *);
bool (*compute_config)(struct intel_encoder *,
struct intel_crtc_state *);
--
2.1.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v3 06/13] drm/i915: Remove connectors_active from state checking.
Connectors are updated atomically now, so the only interaction
with the encoder is through base.crtc.
If it's NULL the encoder's not part of any crtc, and if it's
not NULL then active should be equal to crtc_state-active.
Signed-off-by: Maarten Lankhorst maarten.lankho...@linux.intel.com
Reviewed-by: Ander Conselvan de Oliveira conselv...@gmail.com
---
drivers/gpu/drm/i915/intel_display.c | 21 ++---
1 file changed, 10 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 7f4c8df86555..129931f3013e 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -12729,9 +12729,6 @@ check_encoder_state(struct drm_device *dev)
encoder-base.base.id,
encoder-base.name);
- I915_STATE_WARN(encoder-connectors_active
!encoder-base.crtc,
-encoder's active_connectors set, but no crtc\n);
-
for_each_intel_connector(dev, connector) {
if (connector-base.encoder != encoder-base)
continue;
@@ -12751,18 +12748,20 @@ check_encoder_state(struct drm_device *dev)
I915_STATE_WARN(active !encoder-base.crtc,
active encoder with no crtc\n);
- I915_STATE_WARN(encoder-connectors_active != active,
-encoder's computed active state doesn't match tracked
active state
-(expected %i, found %i)\n, active,
encoder-connectors_active);
-
active = encoder-get_hw_state(encoder, pipe);
- I915_STATE_WARN(active != encoder-connectors_active,
+
+ if (!encoder-base.crtc) {
+ I915_STATE_WARN(active,
+encoder detached but not turned off.\n);
+
+ continue;
+ }
+
+ I915_STATE_WARN(active != encoder-base.crtc-state-active,
encoder's hw state doesn't match sw tracking
(expected %i, found %i)\n,
-encoder-connectors_active, active);
+encoder-base.crtc-state-active, active);
- if (!encoder-base.crtc)
- continue;
tracked_pipe = to_intel_crtc(encoder-base.crtc)-pipe;
I915_STATE_WARN(active pipe != tracked_pipe,
--
2.1.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v3 05/13] drm/i915: Remove some unneeded checks from check_crtc_state.
This is handled by the atomic core now, no need to check this for ourself.
Signed-off-by: Maarten Lankhorst maarten.lankho...@linux.intel.com
Reviewed-by: Ander Conselvan de Oliveira conselv...@gmail.com
---
drivers/gpu/drm/i915/intel_display.c | 19 +--
1 file changed, 1 insertion(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 876071ad4681..7f4c8df86555 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -12782,8 +12782,7 @@ check_crtc_state(struct drm_device *dev)
struct intel_crtc_state pipe_config;
for_each_intel_crtc(dev, crtc) {
- bool enabled = false;
- bool active = false;
+ bool active;
memset(pipe_config, 0, sizeof(pipe_config));
@@ -12793,22 +12792,6 @@ check_crtc_state(struct drm_device *dev)
I915_STATE_WARN(crtc-active !crtc-base.state-enable,
active crtc, but not enabled in sw tracking\n);
- for_each_intel_encoder(dev, encoder) {
- if (encoder-base.crtc != crtc-base)
- continue;
- enabled = true;
- if (encoder-connectors_active)
- active = true;
- }
-
- I915_STATE_WARN(active != crtc-active,
-crtc's computed active state doesn't match tracked active
state
-(expected %i, found %i)\n, active, crtc-active);
- I915_STATE_WARN(enabled != crtc-base.state-enable,
-crtc's computed enabled state doesn't match tracked
enabled state
-(expected %i, found %i)\n, enabled,
- crtc-base.state-enable);
-
active = dev_priv-display.get_pipe_config(crtc,
pipe_config);
--
2.1.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v3 10/13] drm/i915: Remove connectors_active from intel_dp.c, v2.
Now that everything's atomic, checking encoder-base.crtc is enough. This function doesn't have the locks to dereference crtc-state, but stealing an encoder bound to any crtc is probably enough reason to warn. Changes since v1: - Commit message. Cc: Ville Syrjälä ville.syrj...@linux.intel.com Signed-off-by: Maarten Lankhorst maarten.lankho...@linux.intel.com Reviewed-by: Ander Conselvan de Oliveira conselv...@gmail.com --- drivers/gpu/drm/i915/intel_dp.c | 7 ++- 1 file changed, 2 insertions(+), 5 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c index 3c243dee72c2..da347a8996a6 100644 --- a/drivers/gpu/drm/i915/intel_dp.c +++ b/drivers/gpu/drm/i915/intel_dp.c @@ -2624,7 +2624,7 @@ static void vlv_steal_power_sequencer(struct drm_device *dev, DRM_DEBUG_KMS(stealing pipe %c power sequencer from port %c\n, pipe_name(pipe), port_name(port)); - WARN(encoder-connectors_active, + WARN(encoder-base.crtc, stealing pipe %c power sequencer from active eDP port %c\n, pipe_name(pipe), port_name(port)); @@ -4241,10 +4241,7 @@ intel_dp_check_link_status(struct intel_dp *intel_dp) WARN_ON(!drm_modeset_is_locked(dev-mode_config.connection_mutex)); - if (!intel_encoder-connectors_active) - return; - - if (WARN_ON(!intel_encoder-base.crtc)) + if (!intel_encoder-base.crtc) return; if (!to_intel_crtc(intel_encoder-base.crtc)-active) -- 2.1.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v3 13/13] drm/i915: Handle return value in intel_pin_and_fence_fb_obj, v2.
-EDEADLK has special meaning in atomic, but get_fence may call
i915_find_fence_reg which can return -EDEADLK.
This has special meaning in the atomic world, so convert the error
to -EBUSY for this case.
Changes since v1:
- Add comment in the code.
Signed-off-by: Maarten Lankhorst maarten.lankho...@linux.intel.com
---
drivers/gpu/drm/i915/intel_display.c | 13 -
1 file changed, 12 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index aa444cbc2262..df237ad4a780 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -2395,7 +2395,18 @@ intel_pin_and_fence_fb_obj(struct drm_plane *plane,
* a fence as the cost is not that onerous.
*/
ret = i915_gem_object_get_fence(obj);
- if (ret)
+ if (ret == -EDEADLK) {
+ /*
+* -EDEADLK means there are no free fences
+* no pending flips.
+*
+* This is propagated to atomic, but it uses
+* -EDEADLK to force a locking recovery, so
+* change the returned error to -EBUSY.
+*/
+ ret = -EBUSY;
+ goto err_unpin;
+ } else if (ret)
goto err_unpin;
i915_gem_object_pin_fence(obj);
--
2.1.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v3 00/13] DPMS updates and atomic state checking.
Mixed bag of fixes for -next now that the first merge happened. Patch series deals with getting rid of intel DPMS handling and making the state checker atomic. The state checker is now atomic and only checks the affected crtc's, encoders and connectors. This is just a resend with all the fixes done after v2. Maarten Lankhorst (13): drm/i915: Make the force_thru workaround atomic, v2. drm/i915: Validate the state after an atomic modeset only, and pass the state. drm/i915: Update atomic state when removing mst connector. drm/i915: Convert connector checking to atomic, v2. drm/i915: Remove some unneeded checks from check_crtc_state. drm/i915: Remove connectors_active from state checking. drm/i915: Make crtc checking use the atomic state, v2. drm/i915: Get rid of dpms handling. drm/i915: Remove connectors_active from sanitization, v2. drm/i915: Remove connectors_active from intel_dp.c, v2. drm/i915: Remove connectors_active. drm/i915: Only update mode related state if a modeset happened. drm/i915: Handle return value in intel_pin_and_fence_fb_obj, v2. drivers/gpu/drm/i915/i915_debugfs.c | 82 ++- drivers/gpu/drm/i915/intel_crt.c | 51 + drivers/gpu/drm/i915/intel_display.c | 426 +++ drivers/gpu/drm/i915/intel_dp.c | 9 +- drivers/gpu/drm/i915/intel_dp_mst.c | 47 +++- drivers/gpu/drm/i915/intel_drv.h | 5 - drivers/gpu/drm/i915/intel_dsi.c | 2 +- drivers/gpu/drm/i915/intel_dvo.c | 48 +--- drivers/gpu/drm/i915/intel_hdmi.c| 2 +- drivers/gpu/drm/i915/intel_lvds.c| 2 +- drivers/gpu/drm/i915/intel_sdvo.c| 49 +--- drivers/gpu/drm/i915/intel_tv.c | 2 +- 12 files changed, 213 insertions(+), 512 deletions(-) -- 2.1.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v3 09/13] drm/i915: Remove connectors_active from sanitization, v2.
connectors_active will be removed, so just calculate this instead.
Changes since v1:
- Look for the right pointer in intel_sanitize_encoder.
Signed-off-by: Maarten Lankhorst maarten.lankho...@linux.intel.com
Reviewed-by: Ander Conselvan de Oliveira conselv...@gmail.com
---
drivers/gpu/drm/i915/intel_display.c | 17 ++---
1 file changed, 14 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 4837d14a5f8e..ff0a22f223e6 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -14936,8 +14936,10 @@ static void intel_sanitize_crtc(struct intel_crtc
*crtc)
/* Adjust the state of the output pipe according to whether we
* have active connectors/encoders. */
enable = false;
- for_each_encoder_on_crtc(dev, crtc-base, encoder)
- enable |= encoder-connectors_active;
+ for_each_encoder_on_crtc(dev, crtc-base, encoder) {
+ enable = true;
+ break;
+ }
if (!enable)
intel_crtc_disable_noatomic(crtc-base);
@@ -14993,6 +14995,7 @@ static void intel_sanitize_encoder(struct intel_encoder
*encoder)
{
struct intel_connector *connector;
struct drm_device *dev = encoder-base.dev;
+ bool active = false;
/* We need to check both for a crtc link (meaning that the
* encoder is active and trying to read from a pipe) and the
@@ -15000,7 +15003,15 @@ static void intel_sanitize_encoder(struct
intel_encoder *encoder)
bool has_active_crtc = encoder-base.crtc
to_intel_crtc(encoder-base.crtc)-active;
- if (encoder-connectors_active !has_active_crtc) {
+ for_each_intel_connector(dev, connector) {
+ if (connector-base.encoder != encoder-base)
+ continue;
+
+ active = true;
+ break;
+ }
+
+ if (active !has_active_crtc) {
DRM_DEBUG_KMS([ENCODER:%d:%s] has active connectors but no
active pipe!\n,
encoder-base.base.id,
encoder-base.name);
--
2.1.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v3 04/13] drm/i915: Convert connector checking to atomic, v2.
Right now dpms callbacks can still fiddle with the connector state,
but it can only turn connectors off.
This is remediated by only checking crtc-state-active when the
connector is active, and ignore crtc-state-active when the
connector is off.
connectors_active is no longer checked, and will be removed later
in this series together with dpms.
Another check for !encoder-crtc is performed by check_encoder_state
too, so it can be removed.
Changes since v1:
- Add commit message.
- rename state to old_state.
- Move deletion of mst_port check to mst patch.
Signed-off-by: Maarten Lankhorst maarten.lankho...@linux.intel.com
Reviewed-by: Ander Conselvan de Oliveira conselv...@gmail.com
---
drivers/gpu/drm/i915/intel_display.c | 66 +---
1 file changed, 32 insertions(+), 34 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 77b4da7e698c..876071ad4681 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -6360,38 +6360,33 @@ static void intel_encoder_dpms(struct intel_encoder
*encoder, int mode)
* internal consistency). */
static void intel_connector_check_state(struct intel_connector *connector)
{
- if (connector-get_hw_state(connector)) {
- struct intel_encoder *encoder = connector-encoder;
- struct drm_crtc *crtc;
- bool encoder_enabled;
- enum pipe pipe;
+ struct drm_crtc *crtc = connector-base.state-crtc;
- DRM_DEBUG_KMS([CONNECTOR:%d:%s]\n,
- connector-base.base.id,
- connector-base.name);
+ DRM_DEBUG_KMS([CONNECTOR:%d:%s]\n,
+ connector-base.base.id,
+ connector-base.name);
- I915_STATE_WARN(connector-base.dpms == DRM_MODE_DPMS_OFF,
-wrong connector dpms state\n);
- I915_STATE_WARN(connector-base.encoder != encoder-base,
-active connector not linked to encoder\n);
+ if (connector-get_hw_state(connector)) {
+ struct drm_encoder *encoder = connector-encoder-base;
+ struct drm_connector_state *conn_state = connector-base.state;
- if (encoder) {
- I915_STATE_WARN(!encoder-connectors_active,
-encoder-connectors_active not set\n);
+ I915_STATE_WARN(!crtc,
+connector enabled without attached crtc\n);
- encoder_enabled = encoder-get_hw_state(encoder, pipe);
- I915_STATE_WARN(!encoder_enabled, encoder not
enabled\n);
- if (I915_STATE_WARN_ON(!encoder-base.crtc))
- return;
+ if (!crtc)
+ return;
- crtc = encoder-base.crtc;
+ I915_STATE_WARN(!crtc-state-active,
+ connector is active, but attached crtc isn't\n);
- I915_STATE_WARN(!crtc-state-enable,
- crtc not enabled\n);
- I915_STATE_WARN(!to_intel_crtc(crtc)-active, crtc not
active\n);
- I915_STATE_WARN(pipe != to_intel_crtc(crtc)-pipe,
-encoder active on the wrong pipe\n);
- }
+ I915_STATE_WARN(conn_state-best_encoder != encoder,
+ atomic encoder doesn't match attached encoder\n);
+
+ I915_STATE_WARN(conn_state-crtc != encoder-crtc,
+ attached encoder crtc differs from connector crtc\n);
+ } else {
+ I915_STATE_WARN(!crtc connector-base.state-best_encoder,
+ best encoder set without crtc!\n);
}
}
@@ -12699,20 +12694,23 @@ static void check_wm_state(struct drm_device *dev)
}
static void
-check_connector_state(struct drm_device *dev)
+check_connector_state(struct drm_device *dev,
+ struct drm_atomic_state *old_state)
{
- struct intel_connector *connector;
+ struct drm_connector_state *old_conn_state;
+ struct drm_connector *connector;
+ int i;
- for_each_intel_connector(dev, connector) {
- struct drm_encoder *encoder = connector-base.encoder;
- struct drm_connector_state *state = connector-base.state;
+ for_each_connector_in_state(old_state, connector, old_conn_state, i) {
+ struct drm_encoder *encoder = connector-encoder;
+ struct drm_connector_state *state = connector-state;
/* This also checks the encoder/connector hw state with the
* -get_hw_state callbacks. */
- intel_connector_check_state(connector);
+ intel_connector_check_state(to_intel_connector(connector));
[Intel-gfx] drm/i915: Postpone plane readout until after encoder readout, v2.
From: Patrik Jakobsson patrik.jakobs...@linux.intel.com
When reading out hw state for planes we disable inactive planes which in
turn triggers an update of the watermarks. The update depends on the
crtc_clock being set which is done when reading out encoders. Thus
postpone the plane readout until after encoder readout.
This prevents a warning in skl_compute_linetime_wm() where pixel_rate
becomes 0 when crtc_clock is 0.
Changes since v1:
- Set all modes after all state is read out. (Maarten)
References: https://bugs.freedesktop.org/show_bug.cgi?id=91428
Signed-off-by: Patrik Jakobsson patrik.jakobs...@linux.intel.com
Signed-off-by: Maarten Lankhorst maarten.lankho...@linux.intel.com
---
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index df237ad4a780..85d52158d476 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -15042,27 +15042,25 @@ static bool primary_get_hw_state(struct intel_crtc
*crtc)
return !!(I915_READ(DSPCNTR(crtc-plane)) DISPLAY_PLANE_ENABLE);
}
-static void readout_plane_state(struct intel_crtc *crtc,
- struct intel_crtc_state *crtc_state)
+static void intel_sanitize_plane(struct intel_plane *plane)
{
- struct intel_plane *p;
struct intel_plane_state *plane_state;
- bool active = crtc_state-base.active;
+ struct intel_crtc *crtc;
- for_each_intel_plane(crtc-base.dev, p) {
- if (crtc-pipe != p-pipe)
- continue;
+ plane_state = to_intel_plane_state(plane-base.state);
- plane_state = to_intel_plane_state(p-base.state);
+ if (!plane_state-base.crtc)
+ return;
- if (p-base.type == DRM_PLANE_TYPE_PRIMARY)
- plane_state-visible = primary_get_hw_state(crtc);
- else {
- if (active)
- p-disable_plane(p-base, crtc-base);
+ crtc = to_intel_crtc(plane_state-base.crtc);
- plane_state-visible = false;
- }
+ if (plane-base.type == DRM_PLANE_TYPE_PRIMARY) {
+ plane_state-visible = primary_get_hw_state(crtc);
+ } else {
+ if (crtc-base.state-active)
+ plane-disable_plane(plane-base, crtc-base);
+
+ plane_state-visible = false;
}
}
@@ -15086,35 +15084,6 @@ static void intel_modeset_readout_hw_state(struct
drm_device *dev)
crtc-base.state-active = crtc-active;
crtc-base.enabled = crtc-active;
- memset(crtc-base.mode, 0, sizeof(crtc-base.mode));
- if (crtc-base.state-active) {
- intel_mode_from_pipe_config(crtc-base.mode,
crtc-config);
-
intel_mode_from_pipe_config(crtc-base.state-adjusted_mode, crtc-config);
- WARN_ON(drm_atomic_set_mode_for_crtc(crtc-base.state,
crtc-base.mode));
-
- /*
-* The initial mode needs to be set in order to keep
-* the atomic core happy. It wants a valid mode if the
-* crtc's enabled, so we do the above call.
-*
-* At this point some state updated by the connectors
-* in their -detect() callback has not run yet, so
-* no recalculation can be done yet.
-*
-* Even if we could do a recalculation and modeset
-* right now it would cause a double modeset if
-* fbdev or userspace chooses a different initial mode.
-*
-* If that happens, someone indicated they wanted a
-* mode change, which means it's safe to do a full
-* recalculation.
-*/
- crtc-base.state-mode.private_flags =
I915_MODE_FLAG_INHERITED;
- }
-
- crtc-base.hwmode = crtc-config-base.adjusted_mode;
- readout_plane_state(crtc,
to_intel_crtc_state(crtc-base.state));
-
DRM_DEBUG_KMS([CRTC:%d] hw state readout: %s\n,
crtc-base.base.id,
crtc-active ? enabled : disabled);
@@ -15184,6 +15153,7 @@ intel_modeset_setup_hw_state(struct drm_device *dev)
enum pipe pipe;
struct intel_crtc *crtc;
struct intel_encoder *encoder;
+ struct intel_plane *plane;
int i;
intel_modeset_readout_hw_state(dev);
@@ -15195,6 +15165,40 @@ intel_modeset_setup_hw_state(struct drm_device *dev)
for_each_pipe(dev_priv, pipe) {
crtc = to_intel_crtc(dev_priv-pipe_to_crtc_mapping[pipe]);
+ crtc-base.hwmode = crtc-config-base.adjusted_mode;
Re: [Intel-gfx] [RFC 7/9] drm/i915: Interrupt driven fences
Op 05-08-15 om 10:05 schreef Daniel Vetter: On Mon, Aug 03, 2015 at 10:20:29AM +0100, Tvrtko Ursulin wrote: On 07/27/2015 03:00 PM, Daniel Vetter wrote: On Mon, Jul 27, 2015 at 02:20:43PM +0100, Tvrtko Ursulin wrote: On 07/17/2015 03:31 PM, john.c.harri...@intel.com wrote: From: John Harrison john.c.harri...@intel.com The intended usage model for struct fence is that the signalled status should be set on demand rather than polled. That is, there should not be a need for a 'signaled' function to be called everytime the status is queried. Instead, 'something' should be done to enable a signal callback from the hardware which will update the state directly. In the case of requests, this is the seqno update interrupt. The idea is that this callback will only be enabled on demand when something actually tries to wait on the fence. This change removes the polling test and replaces it with the callback scheme. Each fence is added to a 'please poke me' list at the start of i915_add_request(). The interrupt handler then scans through the 'poke me' list when a new seqno pops out and signals any matching fence/request. The fence is then removed from the list so the entire request stack does not need to be scanned every time. Note that the fence is added to the list before the commands to generate the seqno interrupt are added to the ring. Thus the sequence is guaranteed to be race free if the interrupt is already enabled. Note that the interrupt is only enabled on demand (i.e. when __wait_request() is called). Thus there is still a potential race when enabling the interrupt as the request may already have completed. However, this is simply solved by calling the interrupt processing code immediately after enabling the interrupt and thereby checking for already completed requests. Lastly, the ring clean up code has the possibility to cancel outstanding requests (e.g. because TDR has reset the ring). These requests will never get signalled and so must be removed from the signal list manually. This is done by setting a 'cancelled' flag and then calling the regular notify/retire code path rather than attempting to duplicate the list manipulatation and clean up code in multiple places. This also avoid any race condition where the cancellation request might occur after/during the completion interrupt actually arriving. v2: Updated to take advantage of the request unreference no longer requiring the mutex lock. For: VIZ-5190 Signed-off-by: John Harrison john.c.harri...@intel.com --- [snip] @@ -1382,6 +1387,10 @@ static void i915_gem_request_retire(struct drm_i915_gem_request *request) list_del_init(request-list); i915_gem_request_remove_from_client(request); + /* In case the request is still in the signal pending list */ + if (!list_empty(request-signal_list)) + request-cancelled = true; + Another thing I did not see implemented is the sync_fence error state. This is more about the Android part, but related to this canceled flag so I am commenting here. I thought when TDR kicks in and we set request-cancelled to true, there should be a code path which somehow makes sync_fence-status negative. As it is, because fence_signal will not be called on canceled, I thought waiters will wait until timeout, rather than being woken up and return error status. For this to work you would somehow need to make sync_fence-status go negative. With normal fence completion it goes from 1 - 0, via the completion callback. I did not immediately see how to make it go negative using the existing API. I think back when we did struct fence we decided that we won't care yet about forwarding error state since doing that across drivers if you have a chain of fences looked complicated. And no one had any clear idea about what kind of semantics we really want. If we want this we'd need to add it, but probably better to do that as a follow-up (usual caveat about open-source userspace and demonstration vehicles apply and all that). Hm, I am not sure but it feels to me not having an error state is a problem. Without it userspace can just keep waiting and waiting upon a fence even though the driver has discarded that workload and never plans to resubmit it. Am I missing something? fences still must complete eventually, they simply won't tell you whether the gpu died before completing the fence or not. Which is in line with gl spec for fences and arb_robustness - inquiring about gpu hangs is done through sideband apis. Actually you can tell. Set fence-status before signalling. ~Maarten ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC 1/8] drm/i915: Add a new PMU for handling non-OA counter data profiling requests
On Wed, Aug 05, 2015 at 09:49:39AM +, Gupta, Sourab wrote: On Wed, 2015-08-05 at 15:17 +0530, sourab gupta wrote: On Wed, 2015-08-05 at 09:38 +, Chris Wilson wrote: On Wed, Aug 05, 2015 at 11:25:37AM +0530, sourab.gu...@intel.com wrote: From: Sourab Gupta sourab.gu...@intel.com The current perf PMU driver is specific for collection of OA counter statistics (which may be done in a periodic or asynchronous way). Since this enables us (and limits us) to render ring, we have no means for collection of data pertaining to other rings. To overcome this limitation, we need to have a new PMU driver which enables data collection for other rings also (in a non-OA specific mode). This patch adds a new perf PMU to i915 device private, for handling profiling requests for non-OA counter data.This data may encompass timestamps, mmio register values, etc. for the relevant ring. The new perf PMU will serve these purposes, without constraining itself to type of data being dumped (which may restrict the user to specific ring like in case of OA counters). The patch introduces this PMU driver alongwith its associated callbacks. Signed-off-by: Sourab Gupta sourab.gu...@intel.com --- drivers/gpu/drm/i915/i915_dma.c | 2 + drivers/gpu/drm/i915/i915_drv.h | 19 drivers/gpu/drm/i915/i915_oa_perf.c | 215 You have to admit it is a bit odd for the object to be called i915_oa_pmu/i915_gen_pmu and the file i915_oa_perf.c -Chris Well, yes.. If the nomenclature of i915_gen_pmu is agreed upon, I can have a new file named as i915_gen_pmu.c which will hold the routines for this pmu, leaving oa pmu stuff behind in i915_oa_pmu.c Sorry, I meant to say 'oa pmu stuff behind in i915_oa_perf.c'. Does i915_gen_pmu.c sound fine? Aiui, there is some common code with i915_oa_perf and a fair amount of perf_event boilerplate. At the moment, I'm leaning towards just i915_pmu.c for both (and if need be i915_pmu_gen.c i915_pmu_oa.c if and only if splitting the boilerplate away helps maintainablity). -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/atomic: Call ww_acquire_done after check phase is complete
We want to make sure that no one tries to acquire more locks and states, and ww mutexes provide debug facilities for that. So use them. Cc: Rob Clark robdcl...@gmail.com Cc: Maarten Lankhorst maarten.lankho...@linux.intel.com Signed-off-by: Daniel Vetter daniel.vet...@intel.com --- drivers/gpu/drm/drm_atomic.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c index 422183e7ee7d..5ea609f270ea 100644 --- a/drivers/gpu/drm/drm_atomic.c +++ b/drivers/gpu/drm/drm_atomic.c @@ -1268,6 +1268,8 @@ int drm_atomic_check_only(struct drm_atomic_state *state) } } + ww_acquire_done(state-acquire_ctx-ww_ctx); + return ret; } EXPORT_SYMBOL(drm_atomic_check_only); -- 2.5.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/skl: Bypass debug message if scalers are not requested
On 05/04/2015 03:29 PM, Daniel Vetter wrote: On Fri, Apr 24, 2015 at 06:07:05PM +, Konduru, Chandra wrote: -Original Message- From: Konduru, Chandra Sent: Friday, April 24, 2015 10:53 AM To: 'Tvrtko Ursulin'; Intel-gfx@lists.freedesktop.org Cc: Ursulin, Tvrtko Subject: RE: [PATCH] drm/i915/skl: Bypass debug message if scalers are not requested -Original Message- From: Tvrtko Ursulin [mailto:tvrtko.ursu...@linux.intel.com] Sent: Friday, April 24, 2015 9:34 AM To: Konduru, Chandra; Intel-gfx@lists.freedesktop.org Cc: Ursulin, Tvrtko Subject: Re: [PATCH] drm/i915/skl: Bypass debug message if scalers are not requested On 04/24/2015 05:30 PM, Konduru, Chandra wrote: -Original Message- From: Tvrtko Ursulin [mailto:tvrtko.ursu...@linux.intel.com] Sent: Friday, April 24, 2015 9:08 AM To: Intel-gfx@lists.freedesktop.org Cc: Ursulin, Tvrtko; Konduru, Chandra Subject: [PATCH] drm/i915/skl: Bypass debug message if scalers are not requested From: Tvrtko Ursulin tvrtko.ursu...@intel.com Signed-off-by: Tvrtko Ursulin tvrtko.ursu...@intel.com Cc: Chandra Konduru chandra.kond...@intel.com --- Up for discussion I suppose, but like it is, with typical drm.debug = 0xe, it logs one line per cursor movement while the log would otherwise be quiet. --- drivers/gpu/drm/i915/intel_atomic.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/gpu/drm/i915/intel_atomic.c b/drivers/gpu/drm/i915/intel_atomic.c index 3c4b7cd..7284c6d 100644 --- a/drivers/gpu/drm/i915/intel_atomic.c +++ b/drivers/gpu/drm/i915/intel_atomic.c @@ -302,6 +302,9 @@ int intel_atomic_setup_scalers(struct drm_device *dev, scaler_state = crtc_state-scaler_state; drm_state = crtc_state-base.state; + if (!scaler_state-scaler_users) + return 0; This will cause issue because scalers will never get freed if they are in use before and no more required now. I put the debug print to help debug variety of state related issues while we are in development, but perhaps debug print can be deleted. Doesn't the loop below skip everything anyway when no bits are set in scaler_state-scaler_users ? Oh, that's right, ignore my prev comment (with updated scaler design above shouldn't cause issues). By the way, can you pls run kms_panel_fit and kms_plane_scaling to make sure they pass and there are no related warnings or errors in kernel log? For kms_plane_scaling, pls apply two pending patches that aren't merged: v5 [PATCH 13/14] drm/i915: skylake primary plane scaling using shared scalers v5 [PATCH 14/14] drm/i915: skylake sprite plane scaling using shared scalers One more: This change address logs when no scaler is required, but might comeback when a scaler is active (panel fitting or plane scaling is enabled). I don't know general policy in these kind of situations, but perhaps debug print can be deleted. Atomic is really complicated, but doing fully diagnostics for each frame is also way too noisy. For that reason we've add a DRM_DEBUG_ATOMIC which can be used for all these state tracking debug lines. We didn't do anything here and I just noticed kernel is still too spammy with regards to this issue. Should we just merge my patch? Still looks completely safe to me... Regards, Tvrtko ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH i-g-t] kms_rotation_crc: Test 90 and 270 degree rotation in sequence
From: Tvrtko Ursulin tvrtko.ursu...@intel.com
Sounds like a useful thing to test going straight from 90 to 270 degrees,
without resetting to no rotation in between.
Signed-off-by: Tvrtko Ursulin tvrtko.ursu...@intel.com
---
tests/kms_rotation_crc.c | 42 ++
1 file changed, 42 insertions(+)
diff --git a/tests/kms_rotation_crc.c b/tests/kms_rotation_crc.c
index 3fd77c42b803..5e32eb6911b2 100644
--- a/tests/kms_rotation_crc.c
+++ b/tests/kms_rotation_crc.c
@@ -36,8 +36,10 @@ typedef struct {
struct igt_fb fb;
struct igt_fb fb_modeset;
igt_crc_t ref_crc;
+ igt_crc_t ref_crc2;
igt_pipe_crc_t *pipe_crc;
igt_rotation_t rotation;
+ igt_rotation_t rotation2;
int pos_x;
int pos_y;
unsigned int w, h;
@@ -174,6 +176,12 @@ static void prepare_crtc(data_t *data, igt_output_t
*output, enum pipe pipe,
commit_crtc(data, output, plane);
igt_pipe_crc_collect_crc(data-pipe_crc, data-ref_crc);
+ if (data-rotation2 != IGT_ROTATION_0) {
+ paint_squares(data, mode, data-rotation2, plane);
+ commit_crtc(data, output, plane);
+ igt_pipe_crc_collect_crc(data-pipe_crc, data-ref_crc2);
+ }
+
/*
* Step 2: prepare the plane with an non-rotated fb let the hw
* rotate it.
@@ -249,6 +257,21 @@ static void test_plane_rotation(data_t *data, enum
igt_plane plane_type)
crc_output);
}
+ if (data-rotation2 != IGT_ROTATION_0) {
+ igt_plane_set_rotation(plane, data-rotation2);
+ ret = igt_display_try_commit2(display, commit);
+ if (data-override_fmt ||
+ data-override_tiling) {
+ igt_assert(ret == -EINVAL);
+ } else {
+ igt_assert(ret == 0);
+ igt_pipe_crc_collect_crc(data-pipe_crc,
+crc_output);
+ igt_assert_crc_equal(data-ref_crc2,
+crc_output);
+ }
+ }
+
/*
* check the rotation state has been reset when the VT
* mode is restored
@@ -284,7 +307,10 @@ igt_main
igt_require_pipe_crc();
igt_display_init(data.display, data.gfx_fd);
+
+ data.rotation2 = IGT_ROTATION_0;
}
+
igt_subtest_f(primary-rotation-180) {
data.rotation = IGT_ROTATION_180;
test_plane_rotation(data, IGT_PLANE_PRIMARY);
@@ -312,9 +338,17 @@ igt_main
test_plane_rotation(data, IGT_PLANE_PRIMARY);
}
+ igt_subtest_f(primary-rotation-90-270) {
+ igt_require(gen = 9);
+ data.rotation = IGT_ROTATION_90;
+ data.rotation2 = IGT_ROTATION_270;
+ test_plane_rotation(data, IGT_PLANE_PRIMARY);
+ }
+
igt_subtest_f(sprite-rotation-90) {
igt_require(gen = 9);
data.rotation = IGT_ROTATION_90;
+ data.rotation2 = IGT_ROTATION_0;
test_plane_rotation(data, IGT_PLANE_2);
}
@@ -324,9 +358,17 @@ igt_main
test_plane_rotation(data, IGT_PLANE_2);
}
+ igt_subtest_f(sprite-rotation-90-270) {
+ igt_require(gen = 9);
+ data.rotation = IGT_ROTATION_90;
+ data.rotation2 = IGT_ROTATION_270;
+ test_plane_rotation(data, IGT_PLANE_2);
+ }
+
igt_subtest_f(sprite-rotation-90-pos-100-0) {
igt_require(gen = 9);
data.rotation = IGT_ROTATION_90;
+ data.rotation2 = IGT_ROTATION_0;
data.pos_x = 100,
data.pos_y = 0;
test_plane_rotation(data, IGT_PLANE_2);
--
2.4.6
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/skl: Bypass debug message if scalers are not requested
On Wed, Aug 05, 2015 at 02:20:17PM +0100, Tvrtko Ursulin wrote: On 05/04/2015 03:29 PM, Daniel Vetter wrote: On Fri, Apr 24, 2015 at 06:07:05PM +, Konduru, Chandra wrote: -Original Message- From: Konduru, Chandra Sent: Friday, April 24, 2015 10:53 AM To: 'Tvrtko Ursulin'; Intel-gfx@lists.freedesktop.org Cc: Ursulin, Tvrtko Subject: RE: [PATCH] drm/i915/skl: Bypass debug message if scalers are not requested -Original Message- From: Tvrtko Ursulin [mailto:tvrtko.ursu...@linux.intel.com] Sent: Friday, April 24, 2015 9:34 AM To: Konduru, Chandra; Intel-gfx@lists.freedesktop.org Cc: Ursulin, Tvrtko Subject: Re: [PATCH] drm/i915/skl: Bypass debug message if scalers are not requested On 04/24/2015 05:30 PM, Konduru, Chandra wrote: -Original Message- From: Tvrtko Ursulin [mailto:tvrtko.ursu...@linux.intel.com] Sent: Friday, April 24, 2015 9:08 AM To: Intel-gfx@lists.freedesktop.org Cc: Ursulin, Tvrtko; Konduru, Chandra Subject: [PATCH] drm/i915/skl: Bypass debug message if scalers are not requested From: Tvrtko Ursulin tvrtko.ursu...@intel.com Signed-off-by: Tvrtko Ursulin tvrtko.ursu...@intel.com Cc: Chandra Konduru chandra.kond...@intel.com --- Up for discussion I suppose, but like it is, with typical drm.debug = 0xe, it logs one line per cursor movement while the log would otherwise be quiet. --- drivers/gpu/drm/i915/intel_atomic.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/gpu/drm/i915/intel_atomic.c b/drivers/gpu/drm/i915/intel_atomic.c index 3c4b7cd..7284c6d 100644 --- a/drivers/gpu/drm/i915/intel_atomic.c +++ b/drivers/gpu/drm/i915/intel_atomic.c @@ -302,6 +302,9 @@ int intel_atomic_setup_scalers(struct drm_device *dev, scaler_state = crtc_state-scaler_state; drm_state = crtc_state-base.state; + if (!scaler_state-scaler_users) + return 0; This will cause issue because scalers will never get freed if they are in use before and no more required now. I put the debug print to help debug variety of state related issues while we are in development, but perhaps debug print can be deleted. Doesn't the loop below skip everything anyway when no bits are set in scaler_state-scaler_users ? Oh, that's right, ignore my prev comment (with updated scaler design above shouldn't cause issues). By the way, can you pls run kms_panel_fit and kms_plane_scaling to make sure they pass and there are no related warnings or errors in kernel log? For kms_plane_scaling, pls apply two pending patches that aren't merged: v5 [PATCH 13/14] drm/i915: skylake primary plane scaling using shared scalers v5 [PATCH 14/14] drm/i915: skylake sprite plane scaling using shared scalers One more: This change address logs when no scaler is required, but might comeback when a scaler is active (panel fitting or plane scaling is enabled). I don't know general policy in these kind of situations, but perhaps debug print can be deleted. Atomic is really complicated, but doing fully diagnostics for each frame is also way too noisy. For that reason we've add a DRM_DEBUG_ATOMIC which can be used for all these state tracking debug lines. We didn't do anything here and I just noticed kernel is still too spammy with regards to this issue. Should we just merge my patch? Still looks completely safe to me... doesn't seem to apply any more:( -Daniel Regards, Tvrtko -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC 7/8] drm/i915: Add support for forwarding execbuffer tags in timestamp sample metadata
On Wed, Aug 5, 2015 at 10:29 AM, Daniel Vetter dan...@ffwll.ch wrote:
On Wed, Aug 05, 2015 at 10:17:55AM +0100, Chris Wilson wrote:
On Wed, Aug 05, 2015 at 11:25:43AM +0530, sourab.gu...@intel.com wrote:
@@ -555,10 +558,12 @@ static void forward_one_gen_pmu_sample(struct
drm_i915_private *dev_priv,
struct drm_i915_ts_node_ctx_id *ctx_info;
struct drm_i915_ts_node_ring_id *ring_info;
struct drm_i915_ts_node_pid *pid_info;
+ struct drm_i915_ts_node_tag *tag_info;
struct perf_raw_record raw;
BUILD_BUG_ON((TS_DATA_SIZE != 8) || (CTX_INFO_SIZE != 8) ||
- (RING_INFO_SIZE != 8) || (PID_INFO_SIZE != 8));
+ (RING_INFO_SIZE != 8) || (PID_INFO_SIZE != 8) ||
+ (TAG_INFO_SIZE != 8));
This is much more useful if each clause is independent. The error
message is then unambiguous and it looks neater.
snapshot = dev_priv-gen_pmu.buffer.addr + node-offset;
snapshot_size = TS_DATA_SIZE + CTX_INFO_SIZE;
diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h
index 3dcc862..db91098 100644
--- a/include/uapi/drm/i915_drm.h
+++ b/include/uapi/drm/i915_drm.h
@@ -104,7 +104,8 @@ struct drm_i915_gen_pmu_attr {
__u32 size;
__u32 sample_ring:1,
sample_pid:1,
- __reserved_1:30;
+ sample_tag:1,
+ __reserved_1:29;
Start each bitfield entry on its own line with __u32;
also no bitfields in uapi headers.
-Daniel
Ah, I had previously asked Sourab to pack the bitfields into the same
u64. I think we only get into undefined ABI territory if we have
multiple sequential bitfields in the structure where the compiler can
choose to combine them in some undefined way?
This follows the same pattern for bitfields seen in struct perf_event_attr.
I'm not sure we'll need lots of flags in our case though so perhaps it
would be fine to avoid the use of bitfields altogether here.
- Robert
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3 01/13] drm/i915: Make the force_thru workaround atomic, v2.
On Wed, Aug 05, 2015 at 12:36:59PM +0200, Maarten Lankhorst wrote:
Set connectors_changed to force a modeset if the panel fitter's force
enabled on eDP.
Changes since v1:
- Use connectors_changed instead of active_changed because it's a
routing update.
Signed-off-by: Maarten Lankhorst maarten.lankho...@linux.intel.com
Queued for -next, thanks for the patch. I can't merge more since I need to
backmerge topic/drm-misc first and that still suffers from arm driver
breakage.
-Daniel
---
drivers/gpu/drm/i915/i915_debugfs.c | 82
+++-
drivers/gpu/drm/i915/intel_display.c | 3 ++
2 files changed, 27 insertions(+), 58 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index 23a69307e12e..d1c643a82267 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -3645,74 +3645,40 @@ static int ilk_pipe_crc_ctl_reg(enum
intel_pipe_crc_source *source,
return 0;
}
-static void hsw_trans_edp_pipe_A_crc_wa(struct drm_device *dev)
+static void hsw_trans_edp_pipe_A_crc_wa(struct drm_device *dev, bool enable)
{
struct drm_i915_private *dev_priv = dev-dev_private;
struct intel_crtc *crtc =
to_intel_crtc(dev_priv-pipe_to_crtc_mapping[PIPE_A]);
struct intel_crtc_state *pipe_config;
+ struct drm_atomic_state *state;
+ int ret = 0;
drm_modeset_lock_all(dev);
- pipe_config = to_intel_crtc_state(crtc-base.state);
-
- /*
- * If we use the eDP transcoder we need to make sure that we don't
- * bypass the pfit, since otherwise the pipe CRC source won't work. Only
- * relevant on hsw with pipe A when using the always-on power well
- * routing.
- */
- if (pipe_config-cpu_transcoder == TRANSCODER_EDP
- !pipe_config-pch_pfit.enabled) {
- bool active = pipe_config-base.active;
-
- if (active) {
- intel_crtc_control(crtc-base, false);
- pipe_config = to_intel_crtc_state(crtc-base.state);
- }
-
- pipe_config-pch_pfit.force_thru = true;
-
- intel_display_power_get(dev_priv,
- POWER_DOMAIN_PIPE_PANEL_FITTER(PIPE_A));
-
- if (active)
- intel_crtc_control(crtc-base, true);
+ state = drm_atomic_state_alloc(dev);
+ if (!state) {
+ ret = -ENOMEM;
+ goto out;
}
- drm_modeset_unlock_all(dev);
-}
-static void hsw_undo_trans_edp_pipe_A_crc_wa(struct drm_device *dev)
-{
- struct drm_i915_private *dev_priv = dev-dev_private;
- struct intel_crtc *crtc =
- to_intel_crtc(dev_priv-pipe_to_crtc_mapping[PIPE_A]);
- struct intel_crtc_state *pipe_config;
-
- drm_modeset_lock_all(dev);
- /*
- * If we use the eDP transcoder we need to make sure that we don't
- * bypass the pfit, since otherwise the pipe CRC source won't work. Only
- * relevant on hsw with pipe A when using the always-on power well
- * routing.
- */
- pipe_config = to_intel_crtc_state(crtc-base.state);
- if (pipe_config-pch_pfit.force_thru) {
- bool active = pipe_config-base.active;
-
- if (active) {
- intel_crtc_control(crtc-base, false);
- pipe_config = to_intel_crtc_state(crtc-base.state);
- }
-
- pipe_config-pch_pfit.force_thru = false;
+ state-acquire_ctx = drm_modeset_legacy_acquire_ctx(crtc-base);
+ pipe_config = intel_atomic_get_crtc_state(state, crtc);
+ if (IS_ERR(pipe_config)) {
+ ret = PTR_ERR(pipe_config);
+ goto out;
+ }
- intel_display_power_put(dev_priv,
- POWER_DOMAIN_PIPE_PANEL_FITTER(PIPE_A));
+ pipe_config-pch_pfit.force_thru = enable;
+ if (pipe_config-cpu_transcoder == TRANSCODER_EDP
+ pipe_config-pch_pfit.enabled != enable)
+ pipe_config-base.connectors_changed = true;
- if (active)
- intel_crtc_control(crtc-base, true);
- }
+ ret = drm_atomic_commit(state);
+out:
drm_modeset_unlock_all(dev);
+ WARN(ret, Toggling workaround to %i returns %i\n, enable, ret);
+ if (ret)
+ drm_atomic_state_free(state);
}
static int ivb_pipe_crc_ctl_reg(struct drm_device *dev,
@@ -3732,7 +3698,7 @@ static int ivb_pipe_crc_ctl_reg(struct drm_device *dev,
break;
case INTEL_PIPE_CRC_SOURCE_PF:
if (IS_HASWELL(dev) pipe == PIPE_A)
- hsw_trans_edp_pipe_A_crc_wa(dev);
+ hsw_trans_edp_pipe_A_crc_wa(dev, true);
*val = PIPE_CRC_ENABLE | PIPE_CRC_SOURCE_PF_IVB;
break;
@@ -3844,7 +3810,7 @@ static int
Re: [Intel-gfx] [PATCH] drm/i915/skl: Bypass debug message if scalers are not requested
On 08/05/2015 02:58 PM, Daniel Vetter wrote: On Wed, Aug 05, 2015 at 02:20:17PM +0100, Tvrtko Ursulin wrote: On 05/04/2015 03:29 PM, Daniel Vetter wrote: On Fri, Apr 24, 2015 at 06:07:05PM +, Konduru, Chandra wrote: -Original Message- From: Konduru, Chandra Sent: Friday, April 24, 2015 10:53 AM To: 'Tvrtko Ursulin'; Intel-gfx@lists.freedesktop.org Cc: Ursulin, Tvrtko Subject: RE: [PATCH] drm/i915/skl: Bypass debug message if scalers are not requested -Original Message- From: Tvrtko Ursulin [mailto:tvrtko.ursu...@linux.intel.com] Sent: Friday, April 24, 2015 9:34 AM To: Konduru, Chandra; Intel-gfx@lists.freedesktop.org Cc: Ursulin, Tvrtko Subject: Re: [PATCH] drm/i915/skl: Bypass debug message if scalers are not requested On 04/24/2015 05:30 PM, Konduru, Chandra wrote: -Original Message- From: Tvrtko Ursulin [mailto:tvrtko.ursu...@linux.intel.com] Sent: Friday, April 24, 2015 9:08 AM To: Intel-gfx@lists.freedesktop.org Cc: Ursulin, Tvrtko; Konduru, Chandra Subject: [PATCH] drm/i915/skl: Bypass debug message if scalers are not requested From: Tvrtko Ursulin tvrtko.ursu...@intel.com Signed-off-by: Tvrtko Ursulin tvrtko.ursu...@intel.com Cc: Chandra Konduru chandra.kond...@intel.com --- Up for discussion I suppose, but like it is, with typical drm.debug = 0xe, it logs one line per cursor movement while the log would otherwise be quiet. --- drivers/gpu/drm/i915/intel_atomic.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/gpu/drm/i915/intel_atomic.c b/drivers/gpu/drm/i915/intel_atomic.c index 3c4b7cd..7284c6d 100644 --- a/drivers/gpu/drm/i915/intel_atomic.c +++ b/drivers/gpu/drm/i915/intel_atomic.c @@ -302,6 +302,9 @@ int intel_atomic_setup_scalers(struct drm_device *dev, scaler_state = crtc_state-scaler_state; drm_state = crtc_state-base.state; + if (!scaler_state-scaler_users) + return 0; This will cause issue because scalers will never get freed if they are in use before and no more required now. I put the debug print to help debug variety of state related issues while we are in development, but perhaps debug print can be deleted. Doesn't the loop below skip everything anyway when no bits are set in scaler_state-scaler_users ? Oh, that's right, ignore my prev comment (with updated scaler design above shouldn't cause issues). By the way, can you pls run kms_panel_fit and kms_plane_scaling to make sure they pass and there are no related warnings or errors in kernel log? For kms_plane_scaling, pls apply two pending patches that aren't merged: v5 [PATCH 13/14] drm/i915: skylake primary plane scaling using shared scalers v5 [PATCH 14/14] drm/i915: skylake sprite plane scaling using shared scalers One more: This change address logs when no scaler is required, but might comeback when a scaler is active (panel fitting or plane scaling is enabled). I don't know general policy in these kind of situations, but perhaps debug print can be deleted. Atomic is really complicated, but doing fully diagnostics for each frame is also way too noisy. For that reason we've add a DRM_DEBUG_ATOMIC which can be used for all these state tracking debug lines. We didn't do anything here and I just noticed kernel is still too spammy with regards to this issue. Should we just merge my patch? Still looks completely safe to me... doesn't seem to apply any more:( Yeah only some months have passed, who would have thought. :) But I realized that would be only one of the three log lines per cursor update - there is a code path calling skl_detach_scaler two times as well. Looks like this overall, per update: [drm:intel_atomic_setup_scalers] crtc_state = 880074b55c00 need = 0 avail = 2 scaler_users = 0x0 [drm:skl_detach_scaler] CRTC:21 Disabled scaler id 0.0 [drm:skl_detach_scaler] CRTC:21 Disabled scaler id 0.1 I'll rebase this patch for a start. Regards, Tvrtko ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915/skl: Bypass debug message if scalers are not requested
From: Tvrtko Ursulin tvrtko.ursu...@intel.com The loop below does nothing if scaler_users has no bits set so it is safe to bail out early in order to avoid dmesg spam, on for example cursor updates. v2: Commit message and rebase. Signed-off-by: Tvrtko Ursulin tvrtko.ursu...@intel.com Cc: Chandra Konduru chandra.kond...@intel.com Cc: Daniel Vetter daniel.vet...@ffwll.ch --- drivers/gpu/drm/i915/intel_atomic.c | 4 1 file changed, 4 insertions(+) diff --git a/drivers/gpu/drm/i915/intel_atomic.c b/drivers/gpu/drm/i915/intel_atomic.c index e2531cf59266..523afd21cf87 100644 --- a/drivers/gpu/drm/i915/intel_atomic.c +++ b/drivers/gpu/drm/i915/intel_atomic.c @@ -148,6 +148,10 @@ int intel_atomic_setup_scalers(struct drm_device *dev, int num_scalers_need; int i, j; + + if (scaler_state-scaler_users == 0) + return 0; + num_scalers_need = hweight32(scaler_state-scaler_users); DRM_DEBUG_KMS(crtc_state = %p need = %d avail = %d scaler_users = 0x%x\n, crtc_state, num_scalers_need, intel_crtc-num_scalers, -- 2.4.6 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/skl: Bypass debug message if scalers are not requested
On 08/05/2015 03:12 PM, Tvrtko Ursulin wrote: On 08/05/2015 02:58 PM, Daniel Vetter wrote: On Wed, Aug 05, 2015 at 02:20:17PM +0100, Tvrtko Ursulin wrote: On 05/04/2015 03:29 PM, Daniel Vetter wrote: On Fri, Apr 24, 2015 at 06:07:05PM +, Konduru, Chandra wrote: -Original Message- From: Konduru, Chandra Sent: Friday, April 24, 2015 10:53 AM To: 'Tvrtko Ursulin'; Intel-gfx@lists.freedesktop.org Cc: Ursulin, Tvrtko Subject: RE: [PATCH] drm/i915/skl: Bypass debug message if scalers are not requested -Original Message- From: Tvrtko Ursulin [mailto:tvrtko.ursu...@linux.intel.com] Sent: Friday, April 24, 2015 9:34 AM To: Konduru, Chandra; Intel-gfx@lists.freedesktop.org Cc: Ursulin, Tvrtko Subject: Re: [PATCH] drm/i915/skl: Bypass debug message if scalers are not requested On 04/24/2015 05:30 PM, Konduru, Chandra wrote: -Original Message- From: Tvrtko Ursulin [mailto:tvrtko.ursu...@linux.intel.com] Sent: Friday, April 24, 2015 9:08 AM To: Intel-gfx@lists.freedesktop.org Cc: Ursulin, Tvrtko; Konduru, Chandra Subject: [PATCH] drm/i915/skl: Bypass debug message if scalers are not requested From: Tvrtko Ursulin tvrtko.ursu...@intel.com Signed-off-by: Tvrtko Ursulin tvrtko.ursu...@intel.com Cc: Chandra Konduru chandra.kond...@intel.com --- Up for discussion I suppose, but like it is, with typical drm.debug = 0xe, it logs one line per cursor movement while the log would otherwise be quiet. --- drivers/gpu/drm/i915/intel_atomic.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/gpu/drm/i915/intel_atomic.c b/drivers/gpu/drm/i915/intel_atomic.c index 3c4b7cd..7284c6d 100644 --- a/drivers/gpu/drm/i915/intel_atomic.c +++ b/drivers/gpu/drm/i915/intel_atomic.c @@ -302,6 +302,9 @@ int intel_atomic_setup_scalers(struct drm_device *dev, scaler_state = crtc_state-scaler_state; drm_state = crtc_state-base.state; +if (!scaler_state-scaler_users) +return 0; This will cause issue because scalers will never get freed if they are in use before and no more required now. I put the debug print to help debug variety of state related issues while we are in development, but perhaps debug print can be deleted. Doesn't the loop below skip everything anyway when no bits are set in scaler_state-scaler_users ? Oh, that's right, ignore my prev comment (with updated scaler design above shouldn't cause issues). By the way, can you pls run kms_panel_fit and kms_plane_scaling to make sure they pass and there are no related warnings or errors in kernel log? For kms_plane_scaling, pls apply two pending patches that aren't merged: v5 [PATCH 13/14] drm/i915: skylake primary plane scaling using shared scalers v5 [PATCH 14/14] drm/i915: skylake sprite plane scaling using shared scalers One more: This change address logs when no scaler is required, but might comeback when a scaler is active (panel fitting or plane scaling is enabled). I don't know general policy in these kind of situations, but perhaps debug print can be deleted. Atomic is really complicated, but doing fully diagnostics for each frame is also way too noisy. For that reason we've add a DRM_DEBUG_ATOMIC which can be used for all these state tracking debug lines. We didn't do anything here and I just noticed kernel is still too spammy with regards to this issue. Should we just merge my patch? Still looks completely safe to me... doesn't seem to apply any more:( Yeah only some months have passed, who would have thought. :) But I realized that would be only one of the three log lines per cursor update - there is a code path calling skl_detach_scaler two times as well. Looks like this overall, per update: [drm:intel_atomic_setup_scalers] crtc_state = 880074b55c00 need = 0 avail = 2 scaler_users = 0x0 [drm:skl_detach_scaler] CRTC:21 Disabled scaler id 0.0 [drm:skl_detach_scaler] CRTC:21 Disabled scaler id 0.1 I'll rebase this patch for a start. Sent it as a new thread but forgot v2 in the subject. Other source of spam is probably intel_begin_crtc_commit - skl_detach_scalers. Don't know what the right fix would be there. Looks like it is not tracking transitions in scaler use so it would be able to act and log when something interesting happens, but rather does it every time. I defer to Chandra. :) Regards, Tvrtko ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [drm-intel:for-linux-next 478/478] drivers/gpu/drm/i915/i915_debugfs.c:3672:20: error: 'struct drm_crtc_state' has no member named 'connectors_changed'
tree: git://anongit.freedesktop.org/drm-intel for-linux-next head: 574a8ff34ee3f9353cf5bb6b4bff732387cf03c6 commit: 574a8ff34ee3f9353cf5bb6b4bff732387cf03c6 [478/478] drm/i915: Make the force_thru workaround atomic, v2. config: i386-randconfig-i1-201531 (attached as .config) reproduce: git checkout 574a8ff34ee3f9353cf5bb6b4bff732387cf03c6 # save the attached .config to linux build tree make ARCH=i386 All error/warnings (new ones prefixed by ): drivers/gpu/drm/i915/i915_debugfs.c: In function 'hsw_trans_edp_pipe_A_crc_wa': drivers/gpu/drm/i915/i915_debugfs.c:3672:20: error: 'struct drm_crtc_state' has no member named 'connectors_changed' pipe_config-base.connectors_changed = true; ^ vim +3672 drivers/gpu/drm/i915/i915_debugfs.c 3666 goto out; 3667 } 3668 3669 pipe_config-pch_pfit.force_thru = enable; 3670 if (pipe_config-cpu_transcoder == TRANSCODER_EDP 3671 pipe_config-pch_pfit.enabled != enable) 3672 pipe_config-base.connectors_changed = true; 3673 3674 ret = drm_atomic_commit(state); 3675 out: --- 0-DAY kernel test infrastructureOpen Source Technology Center https://lists.01.org/pipermail/kbuild-all Intel Corporation # # Automatically generated file; DO NOT EDIT. # Linux/i386 4.2.0-rc2 Kernel Configuration # # CONFIG_64BIT is not set CONFIG_X86_32=y CONFIG_X86=y CONFIG_INSTRUCTION_DECODER=y CONFIG_PERF_EVENTS_INTEL_UNCORE=y CONFIG_OUTPUT_FORMAT=elf32-i386 CONFIG_ARCH_DEFCONFIG=arch/x86/configs/i386_defconfig CONFIG_LOCKDEP_SUPPORT=y CONFIG_STACKTRACE_SUPPORT=y CONFIG_HAVE_LATENCYTOP_SUPPORT=y CONFIG_MMU=y CONFIG_NEED_SG_DMA_LENGTH=y CONFIG_GENERIC_ISA_DMA=y CONFIG_GENERIC_BUG=y CONFIG_GENERIC_HWEIGHT=y CONFIG_ARCH_MAY_HAVE_PC_FDC=y CONFIG_RWSEM_XCHGADD_ALGORITHM=y CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_ARCH_HAS_CPU_RELAX=y CONFIG_ARCH_HAS_CACHE_LINE_SIZE=y CONFIG_HAVE_SETUP_PER_CPU_AREA=y CONFIG_NEED_PER_CPU_EMBED_FIRST_CHUNK=y CONFIG_NEED_PER_CPU_PAGE_FIRST_CHUNK=y CONFIG_ARCH_HIBERNATION_POSSIBLE=y CONFIG_ARCH_SUSPEND_POSSIBLE=y CONFIG_ARCH_WANT_HUGE_PMD_SHARE=y CONFIG_ARCH_WANT_GENERAL_HUGETLB=y CONFIG_ARCH_SUPPORTS_OPTIMIZED_INLINING=y CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y CONFIG_X86_32_SMP=y CONFIG_ARCH_HWEIGHT_CFLAGS=-fcall-saved-ecx -fcall-saved-edx CONFIG_ARCH_SUPPORTS_UPROBES=y CONFIG_FIX_EARLYCON_MEM=y CONFIG_PGTABLE_LEVELS=2 CONFIG_DEFCONFIG_LIST=/lib/modules/$UNAME_RELEASE/.config CONFIG_IRQ_WORK=y CONFIG_BUILDTIME_EXTABLE_SORT=y # # General setup # CONFIG_INIT_ENV_ARG_LIMIT=32 CONFIG_CROSS_COMPILE= # CONFIG_COMPILE_TEST is not set CONFIG_LOCALVERSION= CONFIG_LOCALVERSION_AUTO=y CONFIG_HAVE_KERNEL_GZIP=y CONFIG_HAVE_KERNEL_BZIP2=y CONFIG_HAVE_KERNEL_LZMA=y CONFIG_HAVE_KERNEL_XZ=y CONFIG_HAVE_KERNEL_LZO=y CONFIG_HAVE_KERNEL_LZ4=y # CONFIG_KERNEL_GZIP is not set # CONFIG_KERNEL_BZIP2 is not set # CONFIG_KERNEL_LZMA is not set # CONFIG_KERNEL_XZ is not set # CONFIG_KERNEL_LZO is not set CONFIG_KERNEL_LZ4=y CONFIG_DEFAULT_HOSTNAME=(none) CONFIG_SWAP=y CONFIG_SYSVIPC=y # CONFIG_POSIX_MQUEUE is not set # CONFIG_CROSS_MEMORY_ATTACH is not set CONFIG_FHANDLE=y CONFIG_USELIB=y # CONFIG_AUDIT is not set CONFIG_HAVE_ARCH_AUDITSYSCALL=y # # IRQ subsystem # CONFIG_GENERIC_IRQ_PROBE=y CONFIG_GENERIC_IRQ_SHOW=y CONFIG_GENERIC_PENDING_IRQ=y CONFIG_GENERIC_IRQ_CHIP=y CONFIG_IRQ_DOMAIN=y CONFIG_IRQ_DOMAIN_HIERARCHY=y # CONFIG_IRQ_DOMAIN_DEBUG is not set CONFIG_IRQ_FORCED_THREADING=y CONFIG_SPARSE_IRQ=y CONFIG_CLOCKSOURCE_WATCHDOG=y CONFIG_ARCH_CLOCKSOURCE_DATA=y CONFIG_CLOCKSOURCE_VALIDATE_LAST_CYCLE=y CONFIG_GENERIC_TIME_VSYSCALL=y CONFIG_GENERIC_CLOCKEVENTS=y CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y CONFIG_GENERIC_CLOCKEVENTS_MIN_ADJUST=y CONFIG_GENERIC_CMOS_UPDATE=y # # Timers subsystem # CONFIG_TICK_ONESHOT=y CONFIG_NO_HZ_COMMON=y # CONFIG_HZ_PERIODIC is not set CONFIG_NO_HZ_IDLE=y CONFIG_NO_HZ=y CONFIG_HIGH_RES_TIMERS=y # # CPU/Task time and stats accounting # CONFIG_TICK_CPU_ACCOUNTING=y # CONFIG_IRQ_TIME_ACCOUNTING is not set CONFIG_BSD_PROCESS_ACCT=y CONFIG_BSD_PROCESS_ACCT_V3=y # CONFIG_TASKSTATS is not set # # RCU Subsystem # CONFIG_TREE_RCU=y CONFIG_RCU_EXPERT=y CONFIG_SRCU=y # CONFIG_TASKS_RCU is not set CONFIG_RCU_STALL_COMMON=y CONFIG_RCU_FANOUT=32 CONFIG_RCU_FANOUT_LEAF=16 CONFIG_RCU_FAST_NO_HZ=y # CONFIG_TREE_RCU_TRACE is not set CONFIG_RCU_KTHREAD_PRIO=0 CONFIG_RCU_NOCB_CPU=y CONFIG_RCU_NOCB_CPU_NONE=y # CONFIG_RCU_NOCB_CPU_ZERO is not set # CONFIG_RCU_NOCB_CPU_ALL is not set # CONFIG_RCU_EXPEDITE_BOOT is not set CONFIG_BUILD_BIN2C=y CONFIG_IKCONFIG=y # CONFIG_IKCONFIG_PROC is not set CONFIG_LOG_BUF_SHIFT=17 CONFIG_LOG_CPU_MAX_BUF_SHIFT=12 CONFIG_HAVE_UNSTABLE_SCHED_CLOCK=y CONFIG_CGROUPS=y CONFIG_CGROUP_DEBUG=y CONFIG_CGROUP_FREEZER=y CONFIG_CGROUP_DEVICE=y CONFIG_CPUSETS=y CONFIG_PROC_PID_CPUSET=y # CONFIG_CGROUP_CPUACCT is not set # CONFIG_MEMCG is not set CONFIG_CGROUP_PERF=y
Re: [Intel-gfx] [RFC 8/8] drm/i915: Support for retrieving MMIO register values alongwith timestamps through perf
On Wed, 2015-08-05 at 10:30 +, Chris Wilson wrote: On Wed, Aug 05, 2015 at 10:18:50AM +, Gupta, Sourab wrote: On Wed, 2015-08-05 at 10:03 +, Chris Wilson wrote: On Wed, Aug 05, 2015 at 11:25:44AM +0530, sourab.gu...@intel.com wrote: From: Sourab Gupta sourab.gu...@intel.com This patch adds support for retrieving MMIO register values alongwith timestamps and forwarding them to userspace through perf. The userspace can request upto 8 MMIO register values to be dumped. The addresses of upto 8 MMIO registers can be passed through perf attr config. The registers are checked against a whitelist before passing them on. The commands to dump the values of these MMIO registers are then inserted into the ring alongwith commands to dump the timestamps. The values reported to userspace are deltas across batches right? We don't expose the global value to an unprivileged user? It would be nice to clarify that in perf_init so that the reviewer is aware that the issue of unprivileged information leak is addressed (or at least reminded that the register values do not leak!). -Chris Hi Chris, Two things here: 1) Only root is allowed to call event_init for gen pmu. This restriction is there in event_init. (The thought behind this restriction being that we are profiling data across contexts here, so a process wishing to listen to global activity happening in system across all contexts ought to have root priviliges). Is this thought process correct? Should we be supporting non-root users too? That is not clear in this patch, so you need to address such concerns at least in the changelog, and preferrably with a reminder in the whitelist (that these register reads are safe because they are being done from a privileged context only - we then have a red flag in case we lower it). What is the privilege check you are using here exactly? In the current patch set, during the gen pmu event_init, I'm checking for root access using the below check: + if (!capable(CAP_SYS_ADMIN)) + return -EACCES; For gen pmu, I want it user accessible. How long does it take to execute my batches is a common developer query. We may even be able to make anonymised information freely available ala top (per-process GPU usage, memory usage, though cgroups/namespacing rules probably apply here). So, aiui the privilige access should be controlled as below: - For gen pmu, no need to restrict only to root processes. This would imply that user processes would now be able to gather timestamps for all the batches (no unpriviliged information leak since timestamps are inherently anonymised) .. - For the collection of mmio register data, we have following options: - If it is a root process, allow access (is whitelist check necessary in this case?). - If not root, one option is to disallow mmio register dump(probably not a preferable option?). - If not root, second option is to allow mmio dump (after checking against the whitelist?). In this case, do we send the mmio register values as they exist or do we anonymise them?. Since my impression was that perf is expected to simply return the dump of mmio registers requested, and throw an access error in case of unpriviliged operation. And if required, how do we anonymise the mmio data? can you let me know your opinion here wrt the above points. And the mechanism to anonymise the mmio data. 2) Being already a root, do we need to worry about the unauthorized mmio access while exposing these mmio values through the interface? Yes. See above, the information here can be anonymised and useful for user processes exactly like TIMESTAMP. In the current patches, the full mmio register value is dumped to be passed on to userspace (no deltas across batches), provided the register is there in the whitelist. Does the question of unpriviliged information leak arise here(the user being root)? Not for root. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Read WM before sanitize_encoder/crtc calls
If we shut down the crtc we might run into WM consistency checks which
fail because we haven't yet read out the WM state. So do that before
we sanitized the state.
This fixes a WARNING in the ilk wm code which assumes that level 0 WM
are always enabled in it's internal tracking. But since we start out
with all 0 in our driver structures the relevant boolean is false when
loading. This regression was introduced in
commit 0b2ae6d72e445b58ae39cfa6ec0b8d3f53ff7a6f
Author: Ville Syrjälä ville.syrj...@linux.intel.com
Date: Wed Oct 9 19:17:55 2013 +0300
drm/i915: Add intel_pipe_wm and prepare for watermark pre-compute
which added the WARN_ON(!r-enabel).
Cc: Theodore Ts'o ty...@mit.edu
Reported-by: Theodore Ts'o ty...@mit.edu
Signed-off-by: Daniel Vetter daniel.vet...@intel.com
---
Re-ping for testing so that I can merge this patch and send a pull to
Linus.
-Daniel
---
drivers/gpu/drm/i915/intel_display.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 30e0f54ba19d..ae07fd0c395c 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -15121,6 +15121,11 @@ void intel_modeset_setup_hw_state(struct drm_device
*dev,
intel_modeset_readout_hw_state(dev);
+ if (IS_GEN9(dev))
+ skl_wm_get_hw_state(dev);
+ else if (HAS_PCH_SPLIT(dev))
+ ilk_wm_get_hw_state(dev);
+
/*
* Now that we have the config, copy it to each CRTC struct
* Note that this could go away if we move to using crtc_config
@@ -15162,11 +15167,6 @@ void intel_modeset_setup_hw_state(struct drm_device
*dev,
pll-on = false;
}
- if (IS_GEN9(dev))
- skl_wm_get_hw_state(dev);
- else if (HAS_PCH_SPLIT(dev))
- ilk_wm_get_hw_state(dev);
-
if (force_restore) {
i915_redisable_vga(dev);
--
2.5.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 2/2] drm/i915:gen9: Add disable gather at set shader w/a
Arun Siluvery arun.siluv...@linux.intel.com writes:
This WA is implemented in init_context as well as WA batch init.
There are also some dependent bits need to be set in other registers
for this to be complete.
v2: behaviour of disable gather at set shader bit can be specified by
two different registers, use a better option (Ben).
For me it looks like there are 2 orthogonal goals for this patch.
I think the actual workaround should be one patch, the resetting
of the set shader bit and the patch named accordingly.
Then the set shader initialization in a different patch,
if there is justification for it (that I have not managed yet
to find).
But lets concentrate on the workaround itself...
Cc: Ben Widawsky benjamin.widaw...@intel.com
Cc: Joonas Lahtinen joonas.lahti...@linux.intel.com
Signed-off-by: Arun Siluvery arun.siluv...@linux.intel.com
---
drivers/gpu/drm/i915/i915_reg.h | 5 +
drivers/gpu/drm/i915/intel_lrc.c| 8
drivers/gpu/drm/i915/intel_ringbuffer.c | 18 ++
3 files changed, 31 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 8991cd5..8719a5a 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -1721,6 +1721,10 @@ enum skl_disp_power_wells {
#define MEM_DISPLAY_TRICKLE_FEED_DISABLE (12) /* 85x only */
#define FW_BLC 0x020d8
#define FW_BLC2 0x020dc
+#define GEN7_RS_CHICKEN 0x20DC
+#define GEN9_RS_CHICKEN_DISABLE_GATHER_AT_SHADER (12)
+#define GEN7_FF_SLICE_CHICKEN10x20E0
+#define GEN9_PER_CTX_DISABLE_GATHER_CONTROL (115)
#define FW_BLC_SELF 0x020e0 /* 915+ only */
#define FW_BLC_SELF_EN_MASK (131)
#define FW_BLC_SELF_FIFO_MASK(116) /* 945 only */
@@ -5836,6 +5840,7 @@ enum skl_disp_power_wells {
# define GEN7_CSC1_RHWO_OPT_DISABLE_IN_RCC ((110) | (126))
# define GEN9_RHWO_OPTIMIZATION_DISABLE (114)
#define COMMON_SLICE_CHICKEN20x7014
+#define GEN9_DISABLE_GATHER_SET_SHADER_SLICE (112)
# define GEN8_CSC2_SBE_VUE_CACHE_CONSERVATIVE(10)
#define HIZ_CHICKEN 0x7018
diff --git a/drivers/gpu/drm/i915/intel_lrc.c
b/drivers/gpu/drm/i915/intel_lrc.c
index 9faad82..d3a03f3 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -1292,6 +1292,14 @@ static int gen9_init_perctx_bb(struct intel_engine_cs
*ring,
struct drm_device *dev = ring-dev;
uint32_t index = wa_ctx_start(wa_ctx, *offset, CACHELINE_DWORDS);
+ /* WA to reset disable gather at set shader slice bit */
I am thinking how we could also alert the reader that this workaround
needs to be revisited when it has been given a name.
By adding WaNoName:skl,bxt along with the comment above?
+ if (IS_SKYLAKE(dev)) {
As Ben noted, documentation is rather sparse. But the reference
to previous problems with this bit being save/restored in wrong order,
we can conclude that this should be for BXT also.
+ wa_ctx_emit(batch, index, MI_LOAD_REGISTER_IMM(1));
+ wa_ctx_emit(batch, index, COMMON_SLICE_CHICKEN2);
+ wa_ctx_emit(batch, index,
+
_MASKED_BIT_DISABLE(GEN9_DISABLE_GATHER_SET_SHADER_SLICE));
+ }
+
The actual value of 'disable set shader' is orthogonal and beyond scope
of this Workaround so the rest should be strip out to different patch.
-Mika
/* WaSetDisablePixMaskCammingAndRhwoInCommonSliceChicken:skl,bxt */
if ((IS_SKYLAKE(dev) (INTEL_REVID(dev) = SKL_REVID_B0)) ||
(IS_BROXTON(dev) (INTEL_REVID(dev) == BXT_REVID_A0))) {
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c
b/drivers/gpu/drm/i915/intel_ringbuffer.c
index dcd1b8f..5e8e5f9 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.c
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
@@ -985,6 +985,17 @@ static int gen9_init_workarounds(struct intel_engine_cs
*ring)
tmp |= HDC_FORCE_CSR_NON_COHERENT_OVR_DISABLE;
WA_SET_BIT_MASKED(HDC_CHICKEN0, tmp);
+ /* WA to gather at set shader - skl,bxt
+ * These are dependent bits need to be set for the WA.
+ */
+ if ((IS_SKYLAKE(dev) INTEL_REVID(dev) SKL_REVID_D0) ||
+ (IS_BROXTON(dev) INTEL_REVID(dev) BXT_REVID_A0)) {
+ WA_SET_BIT_MASKED(GEN7_FF_SLICE_CHICKEN1,
+ GEN9_PER_CTX_DISABLE_GATHER_CONTROL);
+ WA_SET_BIT_MASKED(GEN7_RS_CHICKEN,
+ GEN9_RS_CHICKEN_DISABLE_GATHER_AT_SHADER);
+ }
+
return 0;
}
@@ -1068,6 +1079,13 @@ static int skl_init_workarounds(struct intel_engine_cs
*ring)
HDC_FENCE_DEST_SLM_DISABLE |
HDC_BARRIER_PERFORMANCE_DISABLE);
+ /* WA to Disable gather at set shader - skl
+ * This bit needs to be reset in Per
[Intel-gfx] [PATCH] drm/i915/skl: Only disable scalers once
From: Tvrtko Ursulin tvrtko.ursu...@intel.com
Only disable scalers once when transitioning from enabled state.
Avoids a lot of log noise as a side effect.
Signed-off-by: Tvrtko Ursulin tvrtko.ursu...@intel.com
Cc: Chandra Konduru chandra.kond...@intel.com
---
Compile tested only due momentary lack of suitable hardware for testing!!!
---
drivers/gpu/drm/i915/intel_display.c | 12
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 83dadb4796a4..b7541a9b5223 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -2954,16 +2954,19 @@ static void skl_detach_scaler(struct intel_crtc
*intel_crtc, int id)
/*
* This function detaches (aka. unbinds) unused scalers in hardware
*/
-static void skl_detach_scalers(struct intel_crtc *intel_crtc)
+static void skl_detach_scalers(struct intel_crtc *intel_crtc,
+ struct intel_crtc_state *old_intel_crtc_state)
{
- struct intel_crtc_scaler_state *scaler_state;
+ struct intel_crtc_scaler_state *scaler_state, *old_scaler_state;
int i;
scaler_state = intel_crtc-config-scaler_state;
+ old_scaler_state = old_intel_crtc_state-scaler_state;
/* loop through and disable scalers that aren't in use */
for (i = 0; i intel_crtc-num_scalers; i++) {
- if (!scaler_state-scalers[i].in_use)
+ if (!scaler_state-scalers[i].in_use
+ old_scaler_state-scalers[i].in_use)
skl_detach_scaler(intel_crtc, i);
}
}
@@ -13665,7 +13668,8 @@ static void intel_begin_crtc_commit(struct drm_crtc
*crtc,
intel_pipe_update_start(intel_crtc,
intel_crtc-start_vbl_count);
if (!needs_modeset(crtc-state) INTEL_INFO(dev)-gen = 9)
- skl_detach_scalers(intel_crtc);
+ skl_detach_scalers(intel_crtc,
+ to_intel_crtc_state(old_crtc_state));
}
static void intel_finish_crtc_commit(struct drm_crtc *crtc,
--
2.4.6
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/atomic: Call ww_acquire_done after check phase is complete
On Wed, Aug 5, 2015 at 4:57 PM, Maarten Lankhorst maarten.lankho...@linux.intel.com wrote: Op 05-08-15 om 15:08 schreef Daniel Vetter: We want to make sure that no one tries to acquire more locks and states, and ww mutexes provide debug facilities for that. So use them. Cc: Rob Clark robdcl...@gmail.com Cc: Maarten Lankhorst maarten.lankho...@linux.intel.com Signed-off-by: Daniel Vetter daniel.vet...@intel.com --- drivers/gpu/drm/drm_atomic.c | 2 ++ 1 file changed, 2 insertions(+) I like the idea, played with the thought myself, but I think it might need to be slightly less strict for transitional drivers. What would blow up? This should only be called fairly late in the transition when most of the atomic handling is correctly done. And i915 is probably the most extreme example of a conversion, so if it works out for us I think everyone else should be fine too. Generally drivers only started to do fancy stuff with get_*_state once converted to atomic to start exploiting it, not before the transition is completed. i915 is different since we have a lot of our own modeset code ... -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/atomic: Call ww_acquire_done after check phase is complete
Hey, Op 05-08-15 om 15:08 schreef Daniel Vetter: We want to make sure that no one tries to acquire more locks and states, and ww mutexes provide debug facilities for that. So use them. Cc: Rob Clark robdcl...@gmail.com Cc: Maarten Lankhorst maarten.lankho...@linux.intel.com Signed-off-by: Daniel Vetter daniel.vet...@intel.com --- drivers/gpu/drm/drm_atomic.c | 2 ++ 1 file changed, 2 insertions(+) I like the idea, played with the thought myself, but I think it might need to be slightly less strict for transitional drivers. ~Maarten diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c index 422183e7ee7d..5ea609f270ea 100644 --- a/drivers/gpu/drm/drm_atomic.c +++ b/drivers/gpu/drm/drm_atomic.c @@ -1268,6 +1268,8 @@ int drm_atomic_check_only(struct drm_atomic_state *state) } } + ww_acquire_done(state-acquire_ctx-ww_ctx); + return ret; } EXPORT_SYMBOL(drm_atomic_check_only); ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/skl: Bypass debug message if scalers are not requested
On 08/05/2015 03:19 PM, Tvrtko Ursulin wrote: [snip] Atomic is really complicated, but doing fully diagnostics for each frame is also way too noisy. For that reason we've add a DRM_DEBUG_ATOMIC which can be used for all these state tracking debug lines. We didn't do anything here and I just noticed kernel is still too spammy with regards to this issue. Should we just merge my patch? Still looks completely safe to me... doesn't seem to apply any more:( Yeah only some months have passed, who would have thought. :) But I realized that would be only one of the three log lines per cursor update - there is a code path calling skl_detach_scaler two times as well. Looks like this overall, per update: [drm:intel_atomic_setup_scalers] crtc_state = 880074b55c00 need = 0 avail = 2 scaler_users = 0x0 [drm:skl_detach_scaler] CRTC:21 Disabled scaler id 0.0 [drm:skl_detach_scaler] CRTC:21 Disabled scaler id 0.1 I'll rebase this patch for a start. Sent it as a new thread but forgot v2 in the subject. Other source of spam is probably intel_begin_crtc_commit - skl_detach_scalers. Don't know what the right fix would be there. Looks like it is not tracking transitions in scaler use so it would be able to act and log when something interesting happens, but rather does it every time. I defer to Chandra. :) Ok I've sent something named [PATCH] drm/i915/skl: Only disable scalers once. It was only compile tested due my current lack of suitable hardware for testing. And I don't pretend to be confident in the world of atomic states etc. so it may well be completely wrong. So either scrutinize it a lot please, or let it be a motivator to come up with a proper fix of your own. :) Regards, Tvrtko ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 2/2] drm/i915:gen9: Add disable gather at set shader w/a
On 05/08/2015 15:45, Mika Kuoppala wrote:
Arun Siluvery arun.siluv...@linux.intel.com writes:
This WA is implemented in init_context as well as WA batch init.
There are also some dependent bits need to be set in other registers
for this to be complete.
v2: behaviour of disable gather at set shader bit can be specified by
two different registers, use a better option (Ben).
For me it looks like there are 2 orthogonal goals for this patch.
I think the actual workaround should be one patch, the resetting
of the set shader bit and the patch named accordingly.
Then the set shader initialization in a different patch,
if there is justification for it (that I have not managed yet
to find).
I agree it needs to be split into two patches.
But lets concentrate on the workaround itself...
Cc: Ben Widawsky benjamin.widaw...@intel.com
Cc: Joonas Lahtinen joonas.lahti...@linux.intel.com
Signed-off-by: Arun Siluvery arun.siluv...@linux.intel.com
---
drivers/gpu/drm/i915/i915_reg.h | 5 +
drivers/gpu/drm/i915/intel_lrc.c| 8
drivers/gpu/drm/i915/intel_ringbuffer.c | 18 ++
3 files changed, 31 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 8991cd5..8719a5a 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -1721,6 +1721,10 @@ enum skl_disp_power_wells {
#define MEM_DISPLAY_TRICKLE_FEED_DISABLE (12) /* 85x only */
#define FW_BLC0x020d8
#define FW_BLC2 0x020dc
+#define GEN7_RS_CHICKEN 0x20DC
+#define GEN9_RS_CHICKEN_DISABLE_GATHER_AT_SHADER (12)
+#define GEN7_FF_SLICE_CHICKEN10x20E0
+#define GEN9_PER_CTX_DISABLE_GATHER_CONTROL (115)
#define FW_BLC_SELF 0x020e0 /* 915+ only */
#define FW_BLC_SELF_EN_MASK (131)
#define FW_BLC_SELF_FIFO_MASK(116) /* 945 only */
@@ -5836,6 +5840,7 @@ enum skl_disp_power_wells {
# define GEN7_CSC1_RHWO_OPT_DISABLE_IN_RCC((110) | (126))
# define GEN9_RHWO_OPTIMIZATION_DISABLE (114)
#define COMMON_SLICE_CHICKEN2 0x7014
+#define GEN9_DISABLE_GATHER_SET_SHADER_SLICE (112)
# define GEN8_CSC2_SBE_VUE_CACHE_CONSERVATIVE (10)
#define HIZ_CHICKEN 0x7018
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 9faad82..d3a03f3 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -1292,6 +1292,14 @@ static int gen9_init_perctx_bb(struct intel_engine_cs
*ring,
struct drm_device *dev = ring-dev;
uint32_t index = wa_ctx_start(wa_ctx, *offset, CACHELINE_DWORDS);
+ /* WA to reset disable gather at set shader slice bit */
I am thinking how we could also alert the reader that this workaround
needs to be revisited when it has been given a name.
By adding WaNoName:skl,bxt along with the comment above?
+ if (IS_SKYLAKE(dev)) {
As Ben noted, documentation is rather sparse. But the reference
to previous problems with this bit being save/restored in wrong order,
we can conclude that this should be for BXT also.
+ wa_ctx_emit(batch, index, MI_LOAD_REGISTER_IMM(1));
+ wa_ctx_emit(batch, index, COMMON_SLICE_CHICKEN2);
+ wa_ctx_emit(batch, index,
+
_MASKED_BIT_DISABLE(GEN9_DISABLE_GATHER_SET_SHADER_SLICE));
+ }
+
The actual value of 'disable set shader' is orthogonal and beyond scope
of this Workaround so the rest should be strip out to different patch.
As you mentioned on irc we first need to know whether we need to disable
the set shader or not (set ox7014[12:12] to 1), because the WA only
talks about resetting this bit in per ctx batch.
The following bits can be ignore if there is not need to set that bit in
the first place.
with reference to gem_ringfill, on my system it only completes without
any hang if I add this patch completely but on some system this patch
doesn't seem to be necessary.
regards
Arun
-Mika
/* WaSetDisablePixMaskCammingAndRhwoInCommonSliceChicken:skl,bxt */
if ((IS_SKYLAKE(dev) (INTEL_REVID(dev) = SKL_REVID_B0)) ||
(IS_BROXTON(dev) (INTEL_REVID(dev) == BXT_REVID_A0))) {
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c
b/drivers/gpu/drm/i915/intel_ringbuffer.c
index dcd1b8f..5e8e5f9 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.c
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
@@ -985,6 +985,17 @@ static int gen9_init_workarounds(struct intel_engine_cs
*ring)
tmp |= HDC_FORCE_CSR_NON_COHERENT_OVR_DISABLE;
WA_SET_BIT_MASKED(HDC_CHICKEN0, tmp);
+ /* WA to gather at set shader - skl,bxt
+* These are dependent bits need to be set for the WA.
+*/
+ if ((IS_SKYLAKE(dev) INTEL_REVID(dev) SKL_REVID_D0) ||
+ (IS_BROXTON(dev) INTEL_REVID(dev) BXT_REVID_A0)) {
+ WA_SET_BIT_MASKED(GEN7_FF_SLICE_CHICKEN1,
Re: [Intel-gfx] [RFC 7/8] drm/i915: Add support for forwarding execbuffer tags in timestamp sample metadata
On Wed, Aug 05, 2015 at 02:59:03PM +0100, Robert Bragg wrote:
On Wed, Aug 5, 2015 at 10:29 AM, Daniel Vetter dan...@ffwll.ch wrote:
On Wed, Aug 05, 2015 at 10:17:55AM +0100, Chris Wilson wrote:
On Wed, Aug 05, 2015 at 11:25:43AM +0530, sourab.gu...@intel.com wrote:
@@ -555,10 +558,12 @@ static void forward_one_gen_pmu_sample(struct
drm_i915_private *dev_priv,
struct drm_i915_ts_node_ctx_id *ctx_info;
struct drm_i915_ts_node_ring_id *ring_info;
struct drm_i915_ts_node_pid *pid_info;
+ struct drm_i915_ts_node_tag *tag_info;
struct perf_raw_record raw;
BUILD_BUG_ON((TS_DATA_SIZE != 8) || (CTX_INFO_SIZE != 8) ||
- (RING_INFO_SIZE != 8) || (PID_INFO_SIZE != 8));
+ (RING_INFO_SIZE != 8) || (PID_INFO_SIZE != 8) ||
+ (TAG_INFO_SIZE != 8));
This is much more useful if each clause is independent. The error
message is then unambiguous and it looks neater.
snapshot = dev_priv-gen_pmu.buffer.addr + node-offset;
snapshot_size = TS_DATA_SIZE + CTX_INFO_SIZE;
diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h
index 3dcc862..db91098 100644
--- a/include/uapi/drm/i915_drm.h
+++ b/include/uapi/drm/i915_drm.h
@@ -104,7 +104,8 @@ struct drm_i915_gen_pmu_attr {
__u32 size;
__u32 sample_ring:1,
sample_pid:1,
- __reserved_1:30;
+ sample_tag:1,
+ __reserved_1:29;
Start each bitfield entry on its own line with __u32;
also no bitfields in uapi headers.
-Daniel
Ah, I had previously asked Sourab to pack the bitfields into the same
u64. I think we only get into undefined ABI territory if we have
multiple sequential bitfields in the structure where the compiler can
choose to combine them in some undefined way?
This follows the same pattern for bitfields seen in struct perf_event_attr.
I'm not sure we'll need lots of flags in our case though so perhaps it
would be fine to avoid the use of bitfields altogether here.
It might be uapi cargo culting, but I'm just not sure ;-) The other
problem with bitfields is that it's fickle properly size the reserved
fields, and we need those to correctly reject unused flags. Otherwise
userspace might but garbage in there and extendability is out the window.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v6 02/19] drm/i915/gen8: Make pdp allocation more dynamic
On Wed, Jul 29, 2015 at 05:23:46PM +0100, Michel Thierry wrote:
This transitional patch doesn't do much for the existing code. However,
it should make upcoming patches to use the full 48b address space a bit
easier.
commit message should also mention how exactly it's more dynamic and why
exactly that's useful ... It's ofc possible to infer that from the
context, but that won't be the case any more if you look at the patch
alone (with git blame or after a bisect). Please follow up with a few
words so I can add them to the commit message.
-Daniel
v2: Renamed pdp_free to be similar to pd/pt (unmap_and_free_pdp).
v3: To facilitate testing, 48b mode will be available on Broadwell and
GEN9+, when i915.enable_ppgtt = 3.
v4: Rebase after s/page_tables/page_table/, added extra information
about 4-level page table formats and use IS_ENABLED macro.
v5: Check CONFIG_X86_64 instead of CONFIG_64BIT.
v6: Rebase after Mika's ppgtt cleanup / scratch merge patch series, and
follow
his nomenclature in pdp functions (there is no alloc_pdp yet).
v7: Rebase after merged version of Mika's ppgtt cleanup patch series.
v8: Rebase after final merged version of Mika's ppgtt/scratch patches.
v9: Introduce PML4 (and 48-bit checks) until next patch (Akash).
v10: Also use test_bit to detect when pd/pt are already allocated (Akash)
Cc: Akash Goel akash.g...@intel.com
Signed-off-by: Ben Widawsky b...@bwidawsk.net
Signed-off-by: Michel Thierry michel.thie...@intel.com (v2+)
---
drivers/gpu/drm/i915/i915_gem_gtt.c | 86
+
drivers/gpu/drm/i915/i915_gem_gtt.h | 17 +---
2 files changed, 80 insertions(+), 23 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index 189572d..28f3227 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -522,6 +522,43 @@ static void gen8_initialize_pd(struct i915_address_space
*vm,
fill_px(vm-dev, pd, scratch_pde);
}
+static int __pdp_init(struct drm_device *dev,
+ struct i915_page_directory_pointer *pdp)
+{
+ size_t pdpes = I915_PDPES_PER_PDP(dev);
+
+ pdp-used_pdpes = kcalloc(BITS_TO_LONGS(pdpes),
+ sizeof(unsigned long),
+ GFP_KERNEL);
+ if (!pdp-used_pdpes)
+ return -ENOMEM;
+
+ pdp-page_directory = kcalloc(pdpes, sizeof(*pdp-page_directory),
+ GFP_KERNEL);
+ if (!pdp-page_directory) {
+ kfree(pdp-used_pdpes);
+ /* the PDP might be the statically allocated top level. Keep it
+ * as clean as possible */
+ pdp-used_pdpes = NULL;
+ return -ENOMEM;
+ }
+
+ return 0;
+}
+
+static void __pdp_fini(struct i915_page_directory_pointer *pdp)
+{
+ kfree(pdp-used_pdpes);
+ kfree(pdp-page_directory);
+ pdp-page_directory = NULL;
+}
+
+static void free_pdp(struct drm_device *dev,
+ struct i915_page_directory_pointer *pdp)
+{
+ __pdp_fini(pdp);
+}
+
/* Broadwell Page Directory Pointer Descriptors */
static int gen8_write_pdp(struct drm_i915_gem_request *req,
unsigned entry,
@@ -720,7 +757,8 @@ static void gen8_ppgtt_cleanup(struct i915_address_space
*vm)
container_of(vm, struct i915_hw_ppgtt, base);
int i;
- for_each_set_bit(i, ppgtt-pdp.used_pdpes, GEN8_LEGACY_PDPES) {
+ for_each_set_bit(i, ppgtt-pdp.used_pdpes,
+ I915_PDPES_PER_PDP(ppgtt-base.dev)) {
if (WARN_ON(!ppgtt-pdp.page_directory[i]))
continue;
@@ -729,6 +767,7 @@ static void gen8_ppgtt_cleanup(struct i915_address_space
*vm)
free_pd(ppgtt-base.dev, ppgtt-pdp.page_directory[i]);
}
+ free_pdp(ppgtt-base.dev, ppgtt-pdp);
gen8_free_scratch(vm);
}
@@ -763,7 +802,7 @@ static int gen8_ppgtt_alloc_pagetabs(struct i915_hw_ppgtt
*ppgtt,
gen8_for_each_pde(pt, pd, start, length, temp, pde) {
/* Don't reallocate page tables */
- if (pt) {
+ if (test_bit(pde, pd-used_pdes)) {
/* Scratch is never allocated this way */
WARN_ON(pt == ppgtt-base.scratch_pt);
continue;
@@ -820,11 +859,12 @@ static int gen8_ppgtt_alloc_page_directories(struct
i915_hw_ppgtt *ppgtt,
struct i915_page_directory *pd;
uint64_t temp;
uint32_t pdpe;
+ uint32_t pdpes = I915_PDPES_PER_PDP(dev);
- WARN_ON(!bitmap_empty(new_pds, GEN8_LEGACY_PDPES));
+ WARN_ON(!bitmap_empty(new_pds, pdpes));
gen8_for_each_pdpe(pd, pdp, start, length, temp, pdpe) {
- if (pd)
+ if (test_bit(pdpe, pdp-used_pdpes))
continue;
pd = alloc_pd(dev);
@@ -839,18 +879,19
Re: [Intel-gfx] [PATCH 1/2 v2] drm/i915: Allow parsing of variable size child device entries from VBT
On Wed, Aug 05, 2015 at 10:59:00AM +0200, Daniel Vetter wrote: On Tue, Aug 04, 2015 at 04:55:52PM +0300, David Weinehall wrote: VBT version 196 increased the size of common_child_dev_config. The parser code assumed that the size of this structure would not change. The modified code now copies the amount needed based on the VBT version, and emits a debug message if the VBT version is unknown (too new); since the struct config block won't shrink in newer versions it should be harmless to copy the maximum known size in such cases, so that's what we do, but emitting the warning is probably sensible anyway. In the longer run it might make sense to modify the parser code to use a version/feature mapping, rather than hardcoding things like this, but for now the variants are fairly managable. v2: Stricter size checks Signed-off-by: David Weinehall david.weineh...@linux.intel.com Since Chris mentioned that this should fix a regression I applied it to drm-intel-fixes. Great! Will you merge the other patch in the series to the nightly build? Regards, David ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v7 03/19] drm/i915/gen8: Abstract PDP usage
On Fri, Jul 31, 2015 at 09:41:11AM +0530, Goel, Akash wrote:
Reviewed the patch it looks fine.
Reviewed-by: Akash Goel akash.g...@intel.com
Just an aside is not required in your tag here and actually breaks it
as a proper mail address - if needed should only wrap the name, but
must not include the mail address itself.
-Daniel
On 7/30/2015 3:32 PM, Michel Thierry wrote:
Up until now, ppgtt-pdp has always been the root of our page tables.
Legacy 32b addresses acted like it had 1 PDP with 4 PDPEs.
In preparation for 4 level page tables, we need to stop using ppgtt-pdp
directly unless we know it's what we want. The future structure will use
ppgtt-pml4 for the top level, and the pdp is just one of the entries
being pointed to by a pml4e. The temporal pdp local variable will be
removed once the rest of the 4-level code lands.
Also, start passing the vm pointer to the alloc functions, instead of
ppgtt.
v2: Updated after dynamic page allocation changes.
v3: Rebase after s/page_tables/page_table/.
v4: Rebase after changes in Dynamic page table allocations patch.
v5: Rebase after Mika's ppgtt cleanup / scratch merge patch series.
v6: Rebase after final merged version of Mika's ppgtt/scratch patches.
v7: Keep pagetable map in-line (and avoid unnecessary for_each_pde
loops), remove redundant ppgtt pointer in _alloc_pagetabs (Akash)
v8: Fix text indentation in _alloc_pagetabs/page_directories (Chris)
v9: Defer gen8_alloc_va_range_4lvl definition until 4lvl is implemented,
clean-up gen8_ppgtt_cleanup [pun intended] (Akash).
v10: Clean-up commit message (Akash).
Cc: Akash Goel akash.g...@intel.com
Signed-off-by: Ben Widawsky b...@bwidawsk.net
Signed-off-by: Michel Thierry michel.thie...@intel.com (v2+)
---
drivers/gpu/drm/i915/i915_gem_gtt.c | 84
+++--
1 file changed, 44 insertions(+), 40 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index 28f3227..bd56979 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -607,6 +607,7 @@ static void gen8_ppgtt_clear_range(struct
i915_address_space *vm,
{
struct i915_hw_ppgtt *ppgtt =
container_of(vm, struct i915_hw_ppgtt, base);
+struct i915_page_directory_pointer *pdp = ppgtt-pdp; /* FIXME: 48b */
gen8_pte_t *pt_vaddr, scratch_pte;
unsigned pdpe = start GEN8_PDPE_SHIFT GEN8_PDPE_MASK;
unsigned pde = start GEN8_PDE_SHIFT GEN8_PDE_MASK;
@@ -621,10 +622,10 @@ static void gen8_ppgtt_clear_range(struct
i915_address_space *vm,
struct i915_page_directory *pd;
struct i915_page_table *pt;
-if (WARN_ON(!ppgtt-pdp.page_directory[pdpe]))
+if (WARN_ON(!pdp-page_directory[pdpe]))
break;
-pd = ppgtt-pdp.page_directory[pdpe];
+pd = pdp-page_directory[pdpe];
if (WARN_ON(!pd-page_table[pde]))
break;
@@ -662,6 +663,7 @@ static void gen8_ppgtt_insert_entries(struct
i915_address_space *vm,
{
struct i915_hw_ppgtt *ppgtt =
container_of(vm, struct i915_hw_ppgtt, base);
+struct i915_page_directory_pointer *pdp = ppgtt-pdp; /* FIXME: 48b */
gen8_pte_t *pt_vaddr;
unsigned pdpe = start GEN8_PDPE_SHIFT GEN8_PDPE_MASK;
unsigned pde = start GEN8_PDE_SHIFT GEN8_PDE_MASK;
@@ -675,7 +677,7 @@ static void gen8_ppgtt_insert_entries(struct
i915_address_space *vm,
break;
if (pt_vaddr == NULL) {
-struct i915_page_directory *pd =
ppgtt-pdp.page_directory[pdpe];
+struct i915_page_directory *pd =
pdp-page_directory[pdpe];
struct i915_page_table *pt = pd-page_table[pde];
pt_vaddr = kmap_px(pt);
}
@@ -755,28 +757,29 @@ static void gen8_ppgtt_cleanup(struct
i915_address_space *vm)
{
struct i915_hw_ppgtt *ppgtt =
container_of(vm, struct i915_hw_ppgtt, base);
+struct i915_page_directory_pointer *pdp = ppgtt-pdp; /* FIXME: 48b */
+struct drm_device *dev = ppgtt-base.dev;
int i;
-for_each_set_bit(i, ppgtt-pdp.used_pdpes,
- I915_PDPES_PER_PDP(ppgtt-base.dev)) {
-if (WARN_ON(!ppgtt-pdp.page_directory[i]))
+for_each_set_bit(i, pdp-used_pdpes, I915_PDPES_PER_PDP(dev)) {
+if (WARN_ON(!pdp-page_directory[i]))
continue;
-gen8_free_page_tables(ppgtt-base.dev,
- ppgtt-pdp.page_directory[i]);
-free_pd(ppgtt-base.dev, ppgtt-pdp.page_directory[i]);
+gen8_free_page_tables(dev, pdp-page_directory[i]);
+free_pd(dev, pdp-page_directory[i]);
}
-free_pdp(ppgtt-base.dev, ppgtt-pdp);
+free_pdp(dev, pdp);
+
gen8_free_scratch(vm);
}
/**
Re: [Intel-gfx] [PATCH v9 10/19] drm/i915/gen8: Add 4 level support in insert_entries and clear_range
On Mon, Aug 03, 2015 at 09:53:27AM +0100, Michel Thierry wrote:
When 48b is enabled, gen8_ppgtt_insert_entries needs to read the Page Map
Level 4 (PML4), before it selects which Page Directory Pointer (PDP)
it will write to.
Similarly, gen8_ppgtt_clear_range needs to get the correct PDP/PD range.
This patch was inspired by Ben's Depend exclusively on map and
unmap_vma.
v2: Rebase after s/page_tables/page_table/.
v3: Remove unnecessary pdpe loop in gen8_ppgtt_clear_range_4lvl and use
clamp_pdp in gen8_ppgtt_insert_entries (Akash).
v4: Merge gen8_ppgtt_clear_range_4lvl into gen8_ppgtt_clear_range to
maintain symmetry with gen8_ppgtt_insert_entries (Akash).
v5: Do not mix pages and bytes in insert_entries (Akash).
v6: Prevent overflow in sg_nents PAGE_SHIFT, when inserting 4GB at
once.
v7: Rebase after Mika's ppgtt cleanup / scratch merge patch series.
Use gen8_px_index functions, and remove unnecessary number of pages
parameter in insert_pte_entries.
v8: Change gen8_ppgtt_clear_pte_range to stop at PDP boundary, instead of
adding and extra clamp function; remove unnecessary pdp_start/pdp_len
variables (Akash).
v9: pages-orig_nents instead of sg_nents(pages-sgl) to get the
length (Akash).
v10: Remove pdp warning check ingen8_ppgtt_insert_pte_entries until this
commit (Akash).
Reviewed-by: Akash Goel akash.g...@intel.com (v9)
Cc: Akash Goel akash.g...@intel.com
Signed-off-by: Michel Thierry michel.thie...@intel.com
---
drivers/gpu/drm/i915/i915_gem_gtt.c | 52
+
1 file changed, 36 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index 31fc672..d5ae5de 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -681,9 +681,9 @@ static void gen8_ppgtt_clear_pte_range(struct
i915_address_space *vm,
struct i915_hw_ppgtt *ppgtt =
container_of(vm, struct i915_hw_ppgtt, base);
gen8_pte_t *pt_vaddr;
- unsigned pdpe = start GEN8_PDPE_SHIFT GEN8_PDPE_MASK;
- unsigned pde = start GEN8_PDE_SHIFT GEN8_PDE_MASK;
- unsigned pte = start GEN8_PTE_SHIFT GEN8_PTE_MASK;
+ unsigned pdpe = gen8_pdpe_index(start);
+ unsigned pde = gen8_pde_index(start);
+ unsigned pte = gen8_pte_index(start);
unsigned num_entries = length PAGE_SHIFT;
unsigned last_pte, i;
@@ -722,7 +722,8 @@ static void gen8_ppgtt_clear_pte_range(struct
i915_address_space *vm,
pte = 0;
if (++pde == I915_PDES) {
- pdpe++;
+ if (++pdpe == I915_PDPES_PER_PDP(vm-dev))
+ break;
pde = 0;
}
}
@@ -735,12 +736,21 @@ static void gen8_ppgtt_clear_range(struct
i915_address_space *vm,
{
struct i915_hw_ppgtt *ppgtt =
container_of(vm, struct i915_hw_ppgtt, base);
- struct i915_page_directory_pointer *pdp = ppgtt-pdp; /* FIXME: 48b */
-
gen8_pte_t scratch_pte = gen8_pte_encode(px_dma(vm-scratch_page),
I915_CACHE_LLC, use_scratch);
- gen8_ppgtt_clear_pte_range(vm, pdp, start, length, scratch_pte);
+ if (!USES_FULL_48BIT_PPGTT(vm-dev)) {
Hm, this isn't pretty, and looking through earlier patches you have a lot
of if (48BIT) functions right at the topmost level where we have vfuncs,
e.g. gen8_ppgtt_cleanup. Imo much better to just do a
gen8_legacy_ppgtt_cleanup and gen8_4lvl_ppgtt_cleanup. Yeah means we
duplicate the call to free_scracth but really that's meh - we committed to
that abstraction so let's use it.
But reworking all the patches to get rid of all the 48bit ifs and
exploiting the vfunc abstraction we have will be a bit of work, so I'll
keep merging and sign you up for that follow-up task. The usual design
when we have vfuncs should be:
- do per-platform vfuncs everywhere you need a split
- for functionality shared between different vfuncs extract common helper
functions and call them from both places.
E.g. for this case here I think we need a new 4lvl insert_entries
function which calls the existing one in a loop, and a 3lvl inser_entries
function which calls the existing one for the single legacy pdp. Make 2
copies of this and pull out the if to the top-level of each, then
simplify.
If we have abstraction in the form of vfuncs _and_ pile in lots of ifs at
low level then we pay both the price for the abstraction and the price for
tightly nit code, i.e. both downsides without an upside.
Anway, I expect follow-up work here ;-)
Thanks, Daniel
+ gen8_ppgtt_clear_pte_range(vm, ppgtt-pdp, start, length,
+scratch_pte);
+ } else {
+ uint64_t templ4, pml4e;
+ struct i915_page_directory_pointer *pdp;
+
+ gen8_for_each_pml4e(pdp, ppgtt-pml4, start, length,
Re: [Intel-gfx] [PATCH v6 02/19] drm/i915/gen8: Make pdp allocation more dynamic
On 8/5/2015 4:31 PM, Daniel Vetter wrote: On Wed, Jul 29, 2015 at 05:23:46PM +0100, Michel Thierry wrote: This transitional patch doesn't do much for the existing code. However, it should make upcoming patches to use the full 48b address space a bit easier. commit message should also mention how exactly it's more dynamic and why exactly that's useful ... It's ofc possible to infer that from the context, but that won't be the case any more if you look at the patch alone (with git blame or after a bisect). Please follow up with a few words so I can add them to the commit message. -Daniel Hi Daniel, Agree the description is vague. Here's the updated commit message, let me know what you think (and if you want a new patch): drm/i915/gen8: Make pdp allocation more dynamic This transitional patch doesn't do much for the existing code. However, it should make upcoming patches to use the full 48b address space a bit easier. 32-bit ppgtt uses just 4 PDPs, while 48-bit ppgtt will have up-to 512; this patch prepares the existing functions to query the right number of pdps at run-time. This also means that used_pdpes should also be allocated during ppgtt_init, as the bitmap size will depend on the ppgtt address range selected. v2: Renamed pdp_free to be similar to pd/pt (unmap_and_free_pdp). v3: To facilitate testing, 48b mode will be available on Broadwell and GEN9+, when i915.enable_ppgtt = 3. v4: Rebase after s/page_tables/page_table/, added extra information about 4-level page table formats and use IS_ENABLED macro. v5: Check CONFIG_X86_64 instead of CONFIG_64BIT. v6: Rebase after Mika's ppgtt cleanup / scratch merge patch series, and follow his nomenclature in pdp functions (there is no alloc_pdp yet). v7: Rebase after merged version of Mika's ppgtt cleanup patch series. v8: Rebase after final merged version of Mika's ppgtt/scratch patches. v9: Introduce PML4 (and 48-bit checks) until next patch (Akash). v10: Also use test_bit to detect when pd/pt are already allocated (Akash) v11: Cc: Akash Goel akash.g...@intel.com Signed-off-by: Ben Widawsky b...@bwidawsk.net Signed-off-by: Michel Thierry michel.thie...@intel.com (v2+) ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v6 02/19] drm/i915/gen8: Make pdp allocation more dynamic
On 8/5/2015 4:49 PM, Michel Thierry wrote: On 8/5/2015 4:31 PM, Daniel Vetter wrote: On Wed, Jul 29, 2015 at 05:23:46PM +0100, Michel Thierry wrote: v8: Rebase after final merged version of Mika's ppgtt/scratch patches. v9: Introduce PML4 (and 48-bit checks) until next patch (Akash). v10: Also use test_bit to detect when pd/pt are already allocated (Akash) v11: Press _sent_ too fast, v11: Expand commit message (Daniel). Cc: Akash Goel akash.g...@intel.com Signed-off-by: Ben Widawsky b...@bwidawsk.net Signed-off-by: Michel Thierry michel.thie...@intel.com (v2+) ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v6 17/19] drm/i915: Wa32bitGeneralStateOffset Wa32bitInstructionBaseOffset
On Wed, Jul 29, 2015 at 05:24:01PM +0100, Michel Thierry wrote:
There are some allocations that must be only referenced by 32-bit
offsets. To limit the chances of having the first 4GB already full,
objects not requiring this workaround use DRM_MM_SEARCH_BELOW/
DRM_MM_CREATE_TOP flags
In specific, any resource used with flat/heapless (0x-0xf000)
General State Heap (GSH) or Instruction State Heap (ISH) must be in a
32-bit range, because the General State Offset and Instruction State
Offset are limited to 32-bits.
Objects must have EXEC_OBJECT_SUPPORTS_48B_ADDRESS flag to indicate if
they can be allocated above the 32-bit address range. To limit the
chances of having the first 4GB already full, objects will use
DRM_MM_SEARCH_BELOW + DRM_MM_CREATE_TOP flags when possible.
v2: Changed flag logic from neeeds_32b, to supports_48b.
v3: Moved 48-bit support flag back to exec_object. (Chris, Daniel)
v4: Split pin flags into PIN_ZONE_4G and PIN_HIGH; update PIN_OFFSET_MASK
to use last PIN_ defined instead of hard-coded value; use correct limit
check in eb_vma_misplaced. (Chris)
v5: Don't touch PIN_OFFSET_MASK and update workaround comment (Chris)
v6: Apply pin-high for ggtt too (Chris)
v7: Handle simultaneous pin-high and pin-mappable end correctly (Akash)
Fix check for entries currently using +4GB addresses, use min_t and
other polish in object_bind_to_vm (Chris)
Cc: Chris Wilson ch...@chris-wilson.co.uk
Cc: Akash Goel akash.g...@intel.com
Reviewed-by: Chris Wilson ch...@chris-wilson.co.uk (v4)
Signed-off-by: Michel Thierry michel.thie...@intel.com
For the record, where can I find the mesa patches for this? I think for
simple things like this a References: line point to the relevant UMD
patches in mailing-list archives would be great.
-Daniel
---
drivers/gpu/drm/i915/i915_drv.h| 2 ++
drivers/gpu/drm/i915/i915_gem.c| 25 +++--
drivers/gpu/drm/i915/i915_gem_execbuffer.c | 13 +
include/uapi/drm/i915_drm.h| 3 ++-
4 files changed, 36 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index ed2fbcd..c344805 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2775,6 +2775,8 @@ void i915_gem_vma_destroy(struct i915_vma *vma);
#define PIN_OFFSET_BIAS (13)
#define PIN_USER (14)
#define PIN_UPDATE (15)
+#define PIN_ZONE_4G (16)
+#define PIN_HIGH (17)
#define PIN_OFFSET_MASK (~4095)
int __must_check
i915_gem_object_pin(struct drm_i915_gem_object *obj,
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 80f5d97..e1ca63f 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -3349,11 +3349,9 @@ i915_gem_object_bind_to_vm(struct drm_i915_gem_object
*obj,
struct drm_device *dev = obj-base.dev;
struct drm_i915_private *dev_priv = dev-dev_private;
u32 fence_alignment, unfenced_alignment;
+ u32 search_flag, alloc_flag;
+ u64 start, end;
u64 size, fence_size;
- u64 start =
- flags PIN_OFFSET_BIAS ? flags PIN_OFFSET_MASK : 0;
- u64 end =
- flags PIN_MAPPABLE ? dev_priv-gtt.mappable_end : vm-total;
struct i915_vma *vma;
int ret;
@@ -3393,6 +3391,13 @@ i915_gem_object_bind_to_vm(struct drm_i915_gem_object
*obj,
size = flags PIN_MAPPABLE ? fence_size : obj-base.size;
}
+ start = flags PIN_OFFSET_BIAS ? flags PIN_OFFSET_MASK : 0;
+ end = vm-total;
+ if (flags PIN_MAPPABLE)
+ end = min_t(u64, end, dev_priv-gtt.mappable_end);
+ if (flags PIN_ZONE_4G)
+ end = min_t(u64, end, (1ULL 32));
+
if (alignment == 0)
alignment = flags PIN_MAPPABLE ? fence_alignment :
unfenced_alignment;
@@ -3428,13 +3433,21 @@ i915_gem_object_bind_to_vm(struct drm_i915_gem_object
*obj,
if (IS_ERR(vma))
goto err_unpin;
+ if (flags PIN_HIGH) {
+ search_flag = DRM_MM_SEARCH_BELOW;
+ alloc_flag = DRM_MM_CREATE_TOP;
+ } else {
+ search_flag = DRM_MM_SEARCH_DEFAULT;
+ alloc_flag = DRM_MM_CREATE_DEFAULT;
+ }
+
search_free:
ret = drm_mm_insert_node_in_range_generic(vm-mm, vma-node,
size, alignment,
obj-cache_level,
start, end,
- DRM_MM_SEARCH_DEFAULT,
- DRM_MM_CREATE_DEFAULT);
+ search_flag,
+ alloc_flag);
if (ret) {
ret =
Re: [Intel-gfx] [PATCH i-g-t] benchmarks/Android.mk, tools/Android.mk: Fix android build error
On 04/08/15 09:56, Morton, Derek J wrote:
Bump.
Can this be merged? It only affects android and addresses an issue causing igt
to fail to build at all on android.
//Derek
-Original Message-
From: Morton, Derek J
Sent: Monday, July 27, 2015 11:31 AM
To: intel-gfx@lists.freedesktop.org
Cc: Wood, Thomas; Gore, Tim; Morton, Derek J
Subject: [PATCH i-g-t] benchmarks/Android.mk, tools/Android.mk: Fix android
build error
Recently added tools / benckmarks have the same module name as existing tests.
Android does not allow duplicate modules. This patch appends _benchmark and
_tool to the module names used when building benckmarks and tools to prevent
clashes with tests of the same name.
Signed-off-by: Derek Morton derek.j.mor...@intel.com
---
benchmarks/Android.mk | 2 +-
tools/Android.mk | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/benchmarks/Android.mk b/benchmarks/Android.mk index
14fc0a7..da11c44 100644
--- a/benchmarks/Android.mk
+++ b/benchmarks/Android.mk
@@ -17,7 +17,7 @@ define add_benchmark
# Excessive complaining for established cases. Rely on the Linux version
warnings.
LOCAL_CFLAGS += -Wno-sign-compare
-LOCAL_MODULE := $1
+LOCAL_MODULE := $1_benchmark
This will append _benchmark also to modules which already have it in
the name (e.g. gem_userptr_benchmark). I'd go with:
ifneq (,$(findstring benchmark,$1))
LOCAL_MODULE := $1
else
LOCAL_MODULE := $1_benchmark
endif
Daniele
LOCAL_MODULE_TAGS := optional
LOCAL_STATIC_LIBRARIES := libintel_gpu_tools diff --git a/tools/Android.mk b/tools/Android.mk index 6617f28..0a196e4 100644
--- a/tools/Android.mk
+++ b/tools/Android.mk
@@ -25,7 +25,7 @@ define add_tool
LOCAL_C_INCLUDES = $(LOCAL_PATH)/../lib
LOCAL_C_INCLUDES += ${ANDROID_BUILD_TOP}/external/PRIVATE/drm/include/drm
-LOCAL_MODULE := $1
+LOCAL_MODULE := $1_tool
LOCAL_MODULE_TAGS := optional
LOCAL_STATIC_LIBRARIES := libintel_gpu_tools
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v6 15/19] drm/i915: batch_obj vm offset must be u64
On Wed, Jul 29, 2015 at 05:23:59PM +0100, Michel Thierry wrote:
Otherwise it can overflow in 48-bit mode, and cause an incorrect
exec_start.
Before commit 5f19e2bffa63a91cd4ac1adcec648e14a44277ce (drm/i915: Merged
the many do_execbuf() parameters into a structure), it was already an u64.
Signed-off-by: Michel Thierry michel.thie...@intel.com
So we have a few more u64, but the i915_gem_obj_offset is still unsigned
long. Am I missing a patch?
-Daniel
---
drivers/gpu/drm/i915/i915_drv.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 33926d9..ed2fbcd 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1674,7 +1674,7 @@ struct i915_execbuffer_params {
struct drm_file *file;
uint32_tdispatch_flags;
uint32_targs_batch_start_offset;
- uint32_tbatch_obj_vm_offset;
+ uint64_tbatch_obj_vm_offset;
struct intel_engine_cs *ring;
struct drm_i915_gem_object *batch_obj;
struct intel_context*ctx;
--
2.4.5
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v9 10/19] drm/i915/gen8: Add 4 level support in insert_entries and clear_range
On 8/5/2015 4:46 PM, Daniel Vetter wrote:
On Mon, Aug 03, 2015 at 09:53:27AM +0100, Michel Thierry wrote:
@@ -735,12 +736,21 @@ static void gen8_ppgtt_clear_range(struct
i915_address_space *vm,
{
struct i915_hw_ppgtt *ppgtt =
container_of(vm, struct i915_hw_ppgtt, base);
- struct i915_page_directory_pointer *pdp = ppgtt-pdp; /* FIXME: 48b */
-
gen8_pte_t scratch_pte = gen8_pte_encode(px_dma(vm-scratch_page),
I915_CACHE_LLC, use_scratch);
- gen8_ppgtt_clear_pte_range(vm, pdp, start, length, scratch_pte);
+ if (!USES_FULL_48BIT_PPGTT(vm-dev)) {
Hm, this isn't pretty, and looking through earlier patches you have a lot
of if (48BIT) functions right at the topmost level where we have vfuncs,
e.g. gen8_ppgtt_cleanup. Imo much better to just do a
gen8_legacy_ppgtt_cleanup and gen8_4lvl_ppgtt_cleanup. Yeah means we
duplicate the call to free_scracth but really that's meh - we committed to
that abstraction so let's use it.
But reworking all the patches to get rid of all the 48bit ifs and
exploiting the vfunc abstraction we have will be a bit of work, so I'll
keep merging and sign you up for that follow-up task. The usual design
when we have vfuncs should be:
- do per-platform vfuncs everywhere you need a split
- for functionality shared between different vfuncs extract common helper
functions and call them from both places.
E.g. for this case here I think we need a new 4lvl insert_entries
function which calls the existing one in a loop, and a 3lvl inser_entries
function which calls the existing one for the single legacy pdp. Make 2
copies of this and pull out the if to the top-level of each, then
simplify.
If we have abstraction in the form of vfuncs _and_ pile in lots of ifs at
low level then we pay both the price for the abstraction and the price for
tightly nit code, i.e. both downsides without an upside.
Anway, I expect follow-up work here ;-)
Thanks, Daniel
Yes, all the main functions (alloc, clear, cleanup, dump, insert) have
if (USES_FULL_48BIT_PPGTT)
pml4 function
else
pdp function
I'll make a patch to set the correct ones as vfuncs in gen8_ppgtt_init.
-Michel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v6 15/19] drm/i915: batch_obj vm offset must be u64
On 8/5/2015 5:01 PM, Daniel Vetter wrote: On Wed, Jul 29, 2015 at 05:23:59PM +0100, Michel Thierry wrote: Otherwise it can overflow in 48-bit mode, and cause an incorrect exec_start. Before commit 5f19e2bffa63a91cd4ac1adcec648e14a44277ce (drm/i915: Merged the many do_execbuf() parameters into a structure), it was already an u64. Signed-off-by: Michel Thierry michel.thie...@intel.com So we have a few more u64, but the i915_gem_obj_offset is still unsigned long. Am I missing a patch? http://news.gmane.org/find-root.php?message_id=1437063498-31930-1-git-send-email-michel.thie...@intel.com Which I need to re-send with the comments I got. Thanks for remind me. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v6 17/19] drm/i915: Wa32bitGeneralStateOffset Wa32bitInstructionBaseOffset
On 8/5/2015 4:58 PM, Daniel Vetter wrote: On Wed, Jul 29, 2015 at 05:24:01PM +0100, Michel Thierry wrote: There are some allocations that must be only referenced by 32-bit offsets. To limit the chances of having the first 4GB already full, objects not requiring this workaround use DRM_MM_SEARCH_BELOW/ DRM_MM_CREATE_TOP flags In specific, any resource used with flat/heapless (0x-0xf000) General State Heap (GSH) or Instruction State Heap (ISH) must be in a 32-bit range, because the General State Offset and Instruction State Offset are limited to 32-bits. Objects must have EXEC_OBJECT_SUPPORTS_48B_ADDRESS flag to indicate if they can be allocated above the 32-bit address range. To limit the chances of having the first 4GB already full, objects will use DRM_MM_SEARCH_BELOW + DRM_MM_CREATE_TOP flags when possible. v2: Changed flag logic from neeeds_32b, to supports_48b. v3: Moved 48-bit support flag back to exec_object. (Chris, Daniel) v4: Split pin flags into PIN_ZONE_4G and PIN_HIGH; update PIN_OFFSET_MASK to use last PIN_ defined instead of hard-coded value; use correct limit check in eb_vma_misplaced. (Chris) v5: Don't touch PIN_OFFSET_MASK and update workaround comment (Chris) v6: Apply pin-high for ggtt too (Chris) v7: Handle simultaneous pin-high and pin-mappable end correctly (Akash) Fix check for entries currently using +4GB addresses, use min_t and other polish in object_bind_to_vm (Chris) Cc: Chris Wilson ch...@chris-wilson.co.uk Cc: Akash Goel akash.g...@intel.com Reviewed-by: Chris Wilson ch...@chris-wilson.co.uk (v4) Signed-off-by: Michel Thierry michel.thie...@intel.com For the record, where can I find the mesa patches for this? I think for simple things like this a References: line point to the relevant UMD patches in mailing-list archives would be great. -Daniel Here they are, References: http://lists.freedesktop.org/archives/dri-devel/2015-July/085501.html and http://lists.freedesktop.org/archives/mesa-dev/2015-July/088003.html The name for the macro will be OUT_RELOC64_INSIDE_4G, as suggested by Chris. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC 7/8] drm/i915: Add support for forwarding execbuffer tags in timestamp sample metadata
On Wed, Aug 5, 2015 at 4:25 PM, Daniel Vetter dan...@ffwll.ch wrote:
On Wed, Aug 05, 2015 at 02:59:03PM +0100, Robert Bragg wrote:
On Wed, Aug 5, 2015 at 10:29 AM, Daniel Vetter dan...@ffwll.ch wrote:
On Wed, Aug 05, 2015 at 10:17:55AM +0100, Chris Wilson wrote:
On Wed, Aug 05, 2015 at 11:25:43AM +0530, sourab.gu...@intel.com wrote:
@@ -555,10 +558,12 @@ static void forward_one_gen_pmu_sample(struct
drm_i915_private *dev_priv,
struct drm_i915_ts_node_ctx_id *ctx_info;
struct drm_i915_ts_node_ring_id *ring_info;
struct drm_i915_ts_node_pid *pid_info;
+ struct drm_i915_ts_node_tag *tag_info;
struct perf_raw_record raw;
BUILD_BUG_ON((TS_DATA_SIZE != 8) || (CTX_INFO_SIZE != 8) ||
- (RING_INFO_SIZE != 8) || (PID_INFO_SIZE != 8));
+ (RING_INFO_SIZE != 8) || (PID_INFO_SIZE != 8) ||
+ (TAG_INFO_SIZE != 8));
This is much more useful if each clause is independent. The error
message is then unambiguous and it looks neater.
snapshot = dev_priv-gen_pmu.buffer.addr + node-offset;
snapshot_size = TS_DATA_SIZE + CTX_INFO_SIZE;
diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h
index 3dcc862..db91098 100644
--- a/include/uapi/drm/i915_drm.h
+++ b/include/uapi/drm/i915_drm.h
@@ -104,7 +104,8 @@ struct drm_i915_gen_pmu_attr {
__u32 size;
__u32 sample_ring:1,
sample_pid:1,
- __reserved_1:30;
+ sample_tag:1,
+ __reserved_1:29;
Start each bitfield entry on its own line with __u32;
also no bitfields in uapi headers.
-Daniel
Ah, I had previously asked Sourab to pack the bitfields into the same
u64. I think we only get into undefined ABI territory if we have
multiple sequential bitfields in the structure where the compiler can
choose to combine them in some undefined way?
This follows the same pattern for bitfields seen in struct perf_event_attr.
I'm not sure we'll need lots of flags in our case though so perhaps it
would be fine to avoid the use of bitfields altogether here.
It might be uapi cargo culting, but I'm just not sure ;-) The other
problem with bitfields is that it's fickle properly size the reserved
fields, and we need those to correctly reject unused flags. Otherwise
userspace might but garbage in there and extendability is out the window.
In my latest branch (sorry I haven't sent out a recent RFC myself as
I'm hoping to update public Gen Observability docs before I do that) I
ended up slightly generalizing and exporting perf_copy_attr() in
kernel/events/core.c to use the same tested code to help with this.
Core perf's approach to versioning + extending the attributes
structure seems pretty decent.
That said though regarding unused/reserved fields I realise now I did
miss an important check within the i915_oa code that core perf has
which is to explicitly return -EINVAL if __reserved_1 != 0.
Maybe that should be taken as a case in point.
- Robert
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH igt] tests/gem_mmap_wc: don't fail if the Kernel is too old for the getparam flag
Just don't check the drmIoctl() return code: the if (val) should be
enough to prevent any problems.
v2: Don't SKIP, just proceed (Chris).
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=89739
Cc: Chris Wilson ch...@chris-wilson.co.uk
Signed-off-by: Paulo Zanoni paulo.r.zan...@intel.com
---
tests/gem_mmap_wc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tests/gem_mmap_wc.c b/tests/gem_mmap_wc.c
index 6e43465..0a5326e 100644
--- a/tests/gem_mmap_wc.c
+++ b/tests/gem_mmap_wc.c
@@ -104,7 +104,7 @@ test_invalid_flags(int fd)
gp.value = val;
/* Do we have the new mmap_ioctl? */
- do_ioctl(fd, DRM_IOCTL_I915_GETPARAM, gp);
+ drmIoctl(fd, DRM_IOCTL_I915_GETPARAM, gp);
if (val = 1) {
/*
--
2.4.6
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/atomic: Call ww_acquire_done after check phase is complete
Op 05-08-15 om 17:03 schreef Daniel Vetter:
On Wed, Aug 5, 2015 at 4:57 PM, Maarten Lankhorst
maarten.lankho...@linux.intel.com wrote:
Op 05-08-15 om 15:08 schreef Daniel Vetter:
We want to make sure that no one tries to acquire more locks and
states, and ww mutexes provide debug facilities for that. So use them.
Cc: Rob Clark robdcl...@gmail.com
Cc: Maarten Lankhorst maarten.lankho...@linux.intel.com
Signed-off-by: Daniel Vetter daniel.vet...@intel.com
---
drivers/gpu/drm/drm_atomic.c | 2 ++
1 file changed, 2 insertions(+)
I like the idea, played with the thought myself, but I think it might need
to be slightly less strict for transitional drivers.
What would blow up? This should only be called fairly late in the
transition when most of the atomic handling is correctly done. And
i915 is probably the most extreme example of a conversion, so if it
works out for us I think everyone else should be fine too.
Might blow up with transitional helpers, though not 100% sure if it would.
Also if atomic_check returns -EDEADLK you would still say acquire_done, that
will definitely blow up in legitimate cases..
If it doesn't blow up transitional helpers and you fix the -EDEADLK, acked-by.
:-)
Generally drivers only started to do fancy stuff with get_*_state once
converted to atomic to start exploiting it, not before the transition
is completed. i915 is different since we have a lot of our own modeset
Should we electrify drm_atomic_get_{*}_state too, to force everyone to use the
get_existing_state versions?
~Maarten
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] tools/null_state/gen9: Send atleast one valid component in VF state
On Wed, Aug 05, 2015 at 11:13:46AM +0300, Mika Kuoppala wrote: Ben Widawsky benjamin.widaw...@intel.com writes: On Fri, Jul 31, 2015 at 04:27:07PM +0100, Arun Siluvery wrote: A programming restriction exists for this instruction, atleast one component of one valid vertex element must be enabled. Cc: Ben Widawsky benjamin.widaw...@intel.com Cc: Chris Wilson ch...@chris-wilson.co.uk Signed-off-by: Arun Siluvery arun.siluv...@linux.intel.com --- tools/null_state_gen/intel_renderstate_gen9.c | 7 ++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/tools/null_state_gen/intel_renderstate_gen9.c b/tools/null_state_gen/intel_renderstate_gen9.c index 6f808f8..b3766ea 100644 --- a/tools/null_state_gen/intel_renderstate_gen9.c +++ b/tools/null_state_gen/intel_renderstate_gen9.c @@ -440,7 +440,12 @@ int gen9_setup_null_render_state(struct intel_batchbuffer *batch) /* Vertex buffers */ gen8_emit_vertex_buffers(batch); gen8_emit_vertex_elements(batch); - OUT_CMD(GEN9_3DSTATE_COMPONENT_PACKING, 5); + + OUT_BATCH(GEN9_3DSTATE_COMPONENT_PACKING | 3); + OUT_BATCH(1); + OUT_BATCH(0); + OUT_BATCH(0); + OUT_BATCH(0); OUT_BATCH(GEN6_3DSTATE_VF_STATISTICS | 1 /* Enable */); Like I said on IRC, I don't think this does anything unless you set bit 9 of 3DSTATE_VF.0. Also, I believe you should be setting 0xf, not 1 since you'd want to use all 4 components. So I'm not really sure what we're aiming to do. If you make it 0xf, and add a comment about how this command doesn't do anything because we're not setting up 3DSTATE_VF packing, it's: Reviewed-by: Ben Widawsky b...@bwidawsk.net I'm still more in favor of dropping the command altogether, that too would be: Reviewed-by: Ben Widawsky b...@bwidawsk.net We are trying here just to satisfy the minimum requirements the bspec states. Right, except I am saying at least set minimal state which makes sense. Packing 1 component of the vertex element makes little sense (though doing this at all makes even less sense). The bspec also states that with gen9+, the 3d pipeline state doesn't need to be initialized. We should seek confirmation about this and if it is so, remove the null state for gen9+. That would be super terrific. -Mika -- Ben Widawsky, Intel Open Source Technology Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx -- Ben Widawsky, Intel Open Source Technology Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 3/4] drm/i915: Make turning on/off PW1 and Misc I/O part of the init/fini sequences
2015-08-05 5:30 GMT-03:00 Daniel Vetter dan...@ffwll.ch:
On Thu, Jul 30, 2015 at 06:20:28PM -0300, Paulo Zanoni wrote:
From: Damien Lespiau damien.lesp...@intel.com
Before this patch, we used the intel_display_power_{get,put} functions
to make sure the PW1 and Misc I/O power wells were enabled all the
time while LCPLL was enabled. We called a get() at
intel_ddi_pll_init() when we discovered that LCPLL was enabled, then
we would call put/get at skl_{un,}init_cdclk().
The problem is that skl_uninit_cdclk() is indirectly called by
intel_runtime_suspend(). So it will only release its power well
_after_ we already decided to runtime suspend. But since we only
decide to runtime suspend after all power wells and refcounts are
released, that basically means we will never decide to runtime
suspend.
So what this patch does to fix that problem is move the PW1 + Misc I/O
power well handling out of the runtime PM mechanism: instead of
calling intel_display_power_{get_put} - functions that touch the
refcount -, we'll call the low level intel_power_well_{en,dis}able,
which don't change the refcount. This way, it is now possible for the
refcount to actually reach zero, and we'll now start runtime
suspending/resuming.
v2 (from Paulo):
- Write a commit message since the original patch left it empty.
- Rebase after the intel_power_well_{en,dis}able rename.
- Use lookup_power_well() instead of hardcoded indexes.
Testcase: igt/pm_rpm/rte (and every other rpm test)
Signed-off-by: Damien Lespiau damien.lesp...@intel.com
Reviewed-by: Paulo Zanoni paulo.r.zan...@intel.com
Signed-off-by: Paulo Zanoni paulo.r.zan...@intel.com
This is imo too much of a hack. If we go with this then we should either
completely remove the pw1 and misc pw from the power well code and just
directly call the relevant functions.
What do you mean by the relevant functions? Notice that the patch
already moved us outside of the power domains framework, but not the
power wells framework, since those are actual power wells. I'm still
trying to fully understand what you wanted here.
Or we fix up the ordering and stop lcpll before dropping pw1, which
probably means that skl dp aux and gmbus need to adjust their divisors for
every transaction since those change when lcpll changes.
I don't really have clue about which is the right option, but it seems
like dmc will take control of pw1pw-misc anyway, so probably we don't
need to manage them explicitly on skl anyway.
-Daniel
---
drivers/gpu/drm/i915/intel_ddi.c| 2 --
drivers/gpu/drm/i915/intel_display.c| 5 +++--
drivers/gpu/drm/i915/intel_drv.h| 2 ++
drivers/gpu/drm/i915/intel_runtime_pm.c | 29 +
4 files changed, 34 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_ddi.c
b/drivers/gpu/drm/i915/intel_ddi.c
index 9a40bfb..e629ad3 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -2931,8 +2931,6 @@ void intel_ddi_pll_init(struct drm_device *dev)
dev_priv-skl_boot_cdclk = cdclk_freq;
if (!(I915_READ(LCPLL1_CTL) LCPLL_PLL_ENABLE))
DRM_ERROR(LCPLL1 is disabled\n);
- else
- intel_display_power_get(dev_priv, POWER_DOMAIN_PLLS);
} else if (IS_BROXTON(dev)) {
broxton_init_cdclk(dev);
broxton_ddi_phy_init(dev);
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 43b0f17..34cbe4a 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -5680,7 +5680,8 @@ void skl_uninit_cdclk(struct drm_i915_private
*dev_priv)
if (wait_for(!(I915_READ(LCPLL1_CTL) LCPLL_PLL_LOCK), 1))
DRM_ERROR(Couldn't disable DPLL0\n);
- intel_display_power_put(dev_priv, POWER_DOMAIN_PLLS);
+ /* disable PG1 and Misc I/O */
+ skl_pw1_misc_io_fini(dev_priv);
}
void skl_init_cdclk(struct drm_i915_private *dev_priv)
@@ -5693,7 +5694,7 @@ void skl_init_cdclk(struct drm_i915_private *dev_priv)
I915_WRITE(HSW_NDE_RSTWRN_OPT, val | RESET_PCH_HANDSHAKE_ENABLE);
/* enable PG1 and Misc I/O */
- intel_display_power_get(dev_priv, POWER_DOMAIN_PLLS);
+ skl_pw1_misc_io_init(dev_priv);
/* DPLL0 already enabed !? */
if (I915_READ(LCPLL1_CTL) LCPLL_PLL_ENABLE) {
diff --git a/drivers/gpu/drm/i915/intel_drv.h
b/drivers/gpu/drm/i915/intel_drv.h
index 320c9e6..10e8a2f 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -1325,6 +1325,8 @@ void intel_psr_single_frame_update(struct drm_device
*dev,
int intel_power_domains_init(struct drm_i915_private *);
void intel_power_domains_fini(struct drm_i915_private *);
void intel_power_domains_init_hw(struct drm_i915_private *dev_priv);
+void skl_pw1_misc_io_init(struct drm_i915_private *dev_priv);
+void
