Re: [Intel-gfx] [PATCH v3] drm/i915: Add parsing support for new MIPI blocks in VBT
On Mon, Apr 14, 2014 at 11:00:34AM +0530, Shobhit Kumar wrote:
The parser extracts the config block(#52) and sequence(#53) data
and store in private data structures.
v2: Address review comments by Jani
- adjust code for the structure changes for bdb_mipi_config
- add boundry and buffer overflow checks as suggested
- use kmemdup instead of kmalloc and memcpy
v3: More strict check while parsing VBT
- Ensure that at anytime we do not go beyond sequence block
while parsing
- On unknown element fail the whole parsing
v4: Style changes and spell check mostly as suggested by Jani
Signed-off-by: Shobhit Kumar shobhit.ku...@intel.com
Reviewed-by: Jani Nikula jani.nik...@intel.com
I didn't spot Jani's r-b tag in earlier mails, was that done off-list?
-Daniel
---
drivers/gpu/drm/i915/i915_drv.h | 6 ++
drivers/gpu/drm/i915/intel_bios.c | 204
+-
drivers/gpu/drm/i915/intel_bios.h | 31 ++
3 files changed, 236 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 85e362f..1b763aa 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1170,6 +1170,12 @@ struct intel_vbt_data {
/* MIPI DSI */
struct {
u16 panel_id;
+ struct mipi_config *config;
+ struct mipi_pps_data *pps;
+ u8 seq_version;
+ u32 size;
+ u8 *data;
+ u8 *sequence[MIPI_SEQ_MAX];
} dsi;
int crt_ddc_pin;
diff --git a/drivers/gpu/drm/i915/intel_bios.c
b/drivers/gpu/drm/i915/intel_bios.c
index 862ca04..917f5bb 100644
--- a/drivers/gpu/drm/i915/intel_bios.c
+++ b/drivers/gpu/drm/i915/intel_bios.c
@@ -636,19 +636,213 @@ parse_edp(struct drm_i915_private *dev_priv, struct
bdb_header *bdb)
}
}
+static u8 *goto_next_sequence(u8 *data, int *size)
+{
+ u16 len;
+ int tmp = *size;
+
+ if (--tmp 0)
+ return NULL;
+
+ /* goto first element */
+ data++;
+ while (1) {
+ switch (*data) {
+ case MIPI_SEQ_ELEM_SEND_PKT:
+ /*
+ * skip by this element payload size
+ * skip elem id, command flag and data type
+ */
+ if ((tmp = tmp - 5) 0)
+ return NULL;
+
+ data += 3;
+ len = *((u16 *)data);
+
+ if ((tmp = tmp - len) 0)
+ return NULL;
+
+ /* skip by len */
+ data = data + 2 + len;
+ break;
+ case MIPI_SEQ_ELEM_DELAY:
+ /* skip by elem id, and delay is 4 bytes */
+ if ((tmp = tmp - 5) 0)
+ return NULL;
+
+ data += 5;
+ break;
+ case MIPI_SEQ_ELEM_GPIO:
+ if ((tmp = tmp - 3) 0)
+ return NULL;
+
+ data += 3;
+ break;
+ default:
+ DRM_ERROR(Unknown element\n);
+ return NULL;
+ }
+
+ /* end of sequence ? */
+ if (*data == 0)
+ break;
+ }
+
+ /* goto next sequence or end of block byte */
+ if (--tmp 0)
+ return NULL;
+
+ data++;
+
+ /* update amount of data left for the sequence block to be parsed */
+ *size = tmp;
+ return data;
+}
+
static void
parse_mipi(struct drm_i915_private *dev_priv, struct bdb_header *bdb)
{
- struct bdb_mipi *mipi;
+ struct bdb_mipi_config *start;
+ struct bdb_mipi_sequence *sequence;
+ struct mipi_config *config;
+ struct mipi_pps_data *pps;
+ u8 *data, *seq_data;
+ int i, panel_id, seq_size;
+ u16 block_size;
+
+ /* Initialize this to undefined indicating no generic MIPI support */
+ dev_priv-vbt.dsi.panel_id = MIPI_DSI_UNDEFINED_PANEL_ID;
+
+ /* Block #40 is already parsed and panel_fixed_mode is
+ * stored in dev_priv-lfp_lvds_vbt_mode
+ * resuse this when needed
+ */
- mipi = find_section(bdb, BDB_MIPI_CONFIG);
- if (!mipi) {
- DRM_DEBUG_KMS(No MIPI BDB found);
+ /* Parse #52 for panel index used from panel_type already
+ * parsed
+ */
+ start = find_section(bdb, BDB_MIPI_CONFIG);
+ if (!start) {
+ DRM_DEBUG_KMS(No MIPI config BDB found);
return;
}
- /* XXX: add more info */
+ DRM_DEBUG_DRIVER(Found MIPI Config block, panel index = %d\n,
+ panel_type);
+
+ /*
+ * get hold of the correct configuration
Re: [Intel-gfx] [PATCH I-g-t 2/2] tests: Add dummy_reloc test case based on multi drm_fd to test CPU-GPU sync under multi BSD rings
On Mon, Apr 14, 2014 at 12:19:58PM +0800, Zhao Yakui wrote:
The Broadwell GT3 machine has two independent BSD rings in kernel driver while
it is transparent to the user-space driver. In such case it needs to check
the CPU-GPU sync for the second BSD ring. Multi drm_fd can assure that the
second BSD ring has the opportunity to dispatch the GPU command.
Signed-off-by: Zhao Yakui yakui.z...@intel.com
---
tests/Makefile.sources|1 +
tests/gem_dummy_reloc_multi_bsd.c | 258
+
I've meant that you add a new subtest to the existing gem_dummy_reloc
test. With your patch here we essentially duplicate all the tests for the
other rings.
2 files changed, 259 insertions(+)
create mode 100644 tests/gem_dummy_reloc_multi_bsd.c
diff --git a/tests/Makefile.sources b/tests/Makefile.sources
index 254a5c5..98f277f 100644
--- a/tests/Makefile.sources
+++ b/tests/Makefile.sources
@@ -105,6 +105,7 @@ TESTS_progs = \
gem_ring_sync_copy \
gem_ring_sync_loop \
gem_multi_bsd_sync_loop \
+ gem_dummy_reloc_multi_bsd \
Tests with subtests must be added to the TESTS_progs_M variable, otherwise
piglit won't be able to enumerate the subtests. That's just an fyi for the
next testcase, like I've said here it's imo better to just add a new
subtest.
Also you've forgotten to update .gitignore, when building with your patch
git status shows some not-added binaries.
-Daniel
gem_seqno_wrap \
gem_set_tiling_vs_gtt \
gem_set_tiling_vs_pwrite \
diff --git a/tests/gem_dummy_reloc_multi_bsd.c
b/tests/gem_dummy_reloc_multi_bsd.c
new file mode 100644
index 000..ef8213e
--- /dev/null
+++ b/tests/gem_dummy_reloc_multi_bsd.c
@@ -0,0 +1,258 @@
+/*
+ * Copyright © 2014 Intel Corporation
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the Software),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
DEALINGS
+ * IN THE SOFTWARE.
+ *
+ * Authors:
+ *Daniel Vetter daniel.vet...@ffwll.ch (based on
gem_dummy_reloc_loop*.c)
+ *Zhao Yakui yakui.z...@intel.com
+ *
+ */
+
+#include stdlib.h
+#include stdio.h
+#include string.h
+#include fcntl.h
+#include inttypes.h
+#include errno.h
+#include sys/stat.h
+#include sys/time.h
+#include drm.h
+#include ioctl_wrappers.h
+#include drmtest.h
+#include intel_bufmgr.h
+#include intel_batchbuffer.h
+#include intel_io.h
+#include i830_reg.h
+#include intel_chipset.h
+
+#define LOCAL_I915_EXEC_VEBOX (40)
+
+static drm_intel_bufmgr *bufmgr;
+struct intel_batchbuffer *batch;
+static drm_intel_bo *target_buffer;
+
+#define NUM_FD 50
+
+static int mfd[NUM_FD];
+static drm_intel_bufmgr *mbufmgr[NUM_FD];
+static struct intel_batchbuffer *mbatch[NUM_FD];
+static drm_intel_bo *mbuffer[NUM_FD];
+
+
+/*
+ * Testcase: Basic check of ring-cpu sync using a dummy reloc under
multi-fd
+ *
+ * The last test (that randomly switches the ring) seems to be pretty
effective
+ * at hitting the missed irq bug that's worked around with the HWSTAM irq
write.
+ */
+
+
+#define MI_COND_BATCH_BUFFER_END (0x3623 | 1)
+#define MI_DO_COMPARE(121)
+static void
+dummy_reloc_loop(int ring)
+{
+ int i;
+ srandom(0xdeadbeef);
+
+ for (i = 0; i 0x10; i++) {
+ int mindex = random() % NUM_FD;
+
+ batch = mbatch[mindex];
+ if (ring == I915_EXEC_RENDER) {
+ BEGIN_BATCH(4);
+ OUT_BATCH(MI_COND_BATCH_BUFFER_END | MI_DO_COMPARE);
+ OUT_BATCH(0x); /* compare dword */
+ OUT_RELOC(mbuffer[mindex], I915_GEM_DOMAIN_RENDER,
+ I915_GEM_DOMAIN_RENDER, 0);
+ OUT_BATCH(MI_NOOP);
+ ADVANCE_BATCH();
+ } else {
+ BEGIN_BATCH(4);
+ OUT_BATCH(MI_FLUSH_DW | 1);
+
Re: [Intel-gfx] [PATCH V2 1/6] drm/i915: Split the BDW device definition to prepare for dual BSD rings on BDW GT3
On Mon, Apr 14, 2014 at 12:21:39PM +0800, Zhao Yakui wrote:
V1-V2: Follow Daniel's comment to consider the stolen check for BDW in
kernel/early-quirks.c
Small style nit: We usually put the patch changelog at the end of the
commit message. That way the core commit message is clearly separated from
the per-patch changelog. In rare cases there's some confusion otherwise.
No need to resend just for that.
-Daniel
Based on the hardware spec, the BDW GT3 has the different configuration
with the BDW GT1/GT2. So split the BDW device info definition.
This is to do the preparation for adding the Dual BSD rings on BDW GT3
machine.
Signed-off-by: Zhao Yakui yakui.z...@intel.com
---
drivers/gpu/drm/i915/i915_drv.c | 26 --
include/drm/i915_pciids.h | 22 +-
2 files changed, 41 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 5d8250f..17fbbe5 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -279,6 +279,26 @@ static const struct intel_device_info
intel_broadwell_m_info = {
GEN_DEFAULT_PIPEOFFSETS,
};
+static const struct intel_device_info intel_broadwell_gt3d_info = {
+ .gen = 8, .num_pipes = 3,
+ .need_gfx_hws = 1, .has_hotplug = 1,
+ .ring_mask = RENDER_RING | BSD_RING | BLT_RING | VEBOX_RING,
+ .has_llc = 1,
+ .has_ddi = 1,
+ .has_fbc = 1,
+ GEN_DEFAULT_PIPEOFFSETS,
+};
+
+static const struct intel_device_info intel_broadwell_gt3m_info = {
+ .gen = 8, .is_mobile = 1, .num_pipes = 3,
+ .need_gfx_hws = 1, .has_hotplug = 1,
+ .ring_mask = RENDER_RING | BSD_RING | BLT_RING | VEBOX_RING,
+ .has_llc = 1,
+ .has_ddi = 1,
+ .has_fbc = 1,
+ GEN_DEFAULT_PIPEOFFSETS,
+};
+
/*
* Make sure any device matches here are from most specific to most
* general. For example, since the Quanta match is based on the subsystem
@@ -311,8 +331,10 @@ static const struct intel_device_info
intel_broadwell_m_info = {
INTEL_HSW_M_IDS(intel_haswell_m_info), \
INTEL_VLV_M_IDS(intel_valleyview_m_info), \
INTEL_VLV_D_IDS(intel_valleyview_d_info), \
- INTEL_BDW_M_IDS(intel_broadwell_m_info), \
- INTEL_BDW_D_IDS(intel_broadwell_d_info)
+ INTEL_BDW_GT12M_IDS(intel_broadwell_m_info), \
+ INTEL_BDW_GT12D_IDS(intel_broadwell_d_info), \
+ INTEL_BDW_GT3M_IDS(intel_broadwell_gt3m_info), \
+ INTEL_BDW_GT3D_IDS(intel_broadwell_gt3d_info)
static const struct pci_device_id pciidlist[] = {/* aka */
INTEL_PCI_IDS,
diff --git a/include/drm/i915_pciids.h b/include/drm/i915_pciids.h
index 940ece4..24f3cad 100644
--- a/include/drm/i915_pciids.h
+++ b/include/drm/i915_pciids.h
@@ -223,14 +223,26 @@
_INTEL_BDW_D(gt, 0x160A, info), /* Server */ \
_INTEL_BDW_D(gt, 0x160D, info) /* Workstation */
-#define INTEL_BDW_M_IDS(info) \
+#define INTEL_BDW_GT12M_IDS(info) \
_INTEL_BDW_M_IDS(1, info), \
- _INTEL_BDW_M_IDS(2, info), \
- _INTEL_BDW_M_IDS(3, info)
+ _INTEL_BDW_M_IDS(2, info)
-#define INTEL_BDW_D_IDS(info) \
+#define INTEL_BDW_GT12D_IDS(info) \
_INTEL_BDW_D_IDS(1, info), \
- _INTEL_BDW_D_IDS(2, info), \
+ _INTEL_BDW_D_IDS(2, info)
+
+#define INTEL_BDW_GT3M_IDS(info) \
+ _INTEL_BDW_M_IDS(3, info)
+
+#define INTEL_BDW_GT3D_IDS(info) \
_INTEL_BDW_D_IDS(3, info)
+#define INTEL_BDW_M_IDS(info) \
+ INTEL_BDW_GT12M_IDS(info), \
+ INTEL_BDW_GT3M_IDS(info)
+
+#define INTEL_BDW_D_IDS(info) \
+ INTEL_BDW_GT12D_IDS(info), \
+ INTEL_BDW_GT3D_IDS(info)
+
#endif /* _I915_PCIIDS_H */
--
1.7.10.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH V2 1/6] drm/i915: Split the BDW device definition to prepare for dual BSD rings on BDW GT3
On Mon, 2014-04-14 at 01:09 -0600, Daniel Vetter wrote:
On Mon, Apr 14, 2014 at 12:21:39PM +0800, Zhao Yakui wrote:
V1-V2: Follow Daniel's comment to consider the stolen check for BDW in
kernel/early-quirks.c
Small style nit: We usually put the patch changelog at the end of the
commit message. That way the core commit message is clearly separated from
the per-patch changelog. In rare cases there's some confusion otherwise.
No need to resend just for that.
Thanks for your advice.
I will pay attention to the style nit next time.
Thanks.
Yakui
-Daniel
Based on the hardware spec, the BDW GT3 has the different configuration
with the BDW GT1/GT2. So split the BDW device info definition.
This is to do the preparation for adding the Dual BSD rings on BDW GT3
machine.
Signed-off-by: Zhao Yakui yakui.z...@intel.com
---
drivers/gpu/drm/i915/i915_drv.c | 26 --
include/drm/i915_pciids.h | 22 +-
2 files changed, 41 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c
b/drivers/gpu/drm/i915/i915_drv.c
index 5d8250f..17fbbe5 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -279,6 +279,26 @@ static const struct intel_device_info
intel_broadwell_m_info = {
GEN_DEFAULT_PIPEOFFSETS,
};
+static const struct intel_device_info intel_broadwell_gt3d_info = {
+ .gen = 8, .num_pipes = 3,
+ .need_gfx_hws = 1, .has_hotplug = 1,
+ .ring_mask = RENDER_RING | BSD_RING | BLT_RING | VEBOX_RING,
+ .has_llc = 1,
+ .has_ddi = 1,
+ .has_fbc = 1,
+ GEN_DEFAULT_PIPEOFFSETS,
+};
+
+static const struct intel_device_info intel_broadwell_gt3m_info = {
+ .gen = 8, .is_mobile = 1, .num_pipes = 3,
+ .need_gfx_hws = 1, .has_hotplug = 1,
+ .ring_mask = RENDER_RING | BSD_RING | BLT_RING | VEBOX_RING,
+ .has_llc = 1,
+ .has_ddi = 1,
+ .has_fbc = 1,
+ GEN_DEFAULT_PIPEOFFSETS,
+};
+
/*
* Make sure any device matches here are from most specific to most
* general. For example, since the Quanta match is based on the subsystem
@@ -311,8 +331,10 @@ static const struct intel_device_info
intel_broadwell_m_info = {
INTEL_HSW_M_IDS(intel_haswell_m_info), \
INTEL_VLV_M_IDS(intel_valleyview_m_info), \
INTEL_VLV_D_IDS(intel_valleyview_d_info), \
- INTEL_BDW_M_IDS(intel_broadwell_m_info), \
- INTEL_BDW_D_IDS(intel_broadwell_d_info)
+ INTEL_BDW_GT12M_IDS(intel_broadwell_m_info), \
+ INTEL_BDW_GT12D_IDS(intel_broadwell_d_info), \
+ INTEL_BDW_GT3M_IDS(intel_broadwell_gt3m_info), \
+ INTEL_BDW_GT3D_IDS(intel_broadwell_gt3d_info)
static const struct pci_device_id pciidlist[] = { /* aka */
INTEL_PCI_IDS,
diff --git a/include/drm/i915_pciids.h b/include/drm/i915_pciids.h
index 940ece4..24f3cad 100644
--- a/include/drm/i915_pciids.h
+++ b/include/drm/i915_pciids.h
@@ -223,14 +223,26 @@
_INTEL_BDW_D(gt, 0x160A, info), /* Server */ \
_INTEL_BDW_D(gt, 0x160D, info) /* Workstation */
-#define INTEL_BDW_M_IDS(info) \
+#define INTEL_BDW_GT12M_IDS(info) \
_INTEL_BDW_M_IDS(1, info), \
- _INTEL_BDW_M_IDS(2, info), \
- _INTEL_BDW_M_IDS(3, info)
+ _INTEL_BDW_M_IDS(2, info)
-#define INTEL_BDW_D_IDS(info) \
+#define INTEL_BDW_GT12D_IDS(info) \
_INTEL_BDW_D_IDS(1, info), \
- _INTEL_BDW_D_IDS(2, info), \
+ _INTEL_BDW_D_IDS(2, info)
+
+#define INTEL_BDW_GT3M_IDS(info) \
+ _INTEL_BDW_M_IDS(3, info)
+
+#define INTEL_BDW_GT3D_IDS(info) \
_INTEL_BDW_D_IDS(3, info)
+#define INTEL_BDW_M_IDS(info) \
+ INTEL_BDW_GT12M_IDS(info), \
+ INTEL_BDW_GT3M_IDS(info)
+
+#define INTEL_BDW_D_IDS(info) \
+ INTEL_BDW_GT12D_IDS(info), \
+ INTEL_BDW_GT3D_IDS(info)
+
#endif /* _I915_PCIIDS_H */
--
1.7.10.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 V2 6/6] drm/i915:Use the coarse ping-pong mechanism based on drm fd to dispatch the BSD command on BDW GT3
On Mon, Apr 14, 2014 at 12:21:44PM +0800, Zhao Yakui wrote:
V1-V2: Follow Daniel's comment and use the simple ping-pong mechanism.
This is only to add the support of dual BSD rings on BDW GT3 machine.
The further optimization will be considered in another patch set.
The BDW GT3 has two independent BSD rings, which can be used to process the
video commands. To be simpler, it is transparent to user-space driver/middle.
Instead the kernel driver will decide which ring is to dispatch the BSD video
command.
As every BSD ring is powerful, it is enough to dispatch the BSD video command
based on the drm fd. In such case it can play back video stream while encoding
another video stream. The coarse ping-pong mechanism is used to determine
which BSD ring is used to dispatch the BSD video command.
Signed-off-by: Zhao Yakui yakui.z...@intel.com
---
drivers/gpu/drm/i915/i915_dma.c|3 +++
drivers/gpu/drm/i915/i915_drv.h|3 +++
drivers/gpu/drm/i915/i915_gem_execbuffer.c | 37
+++-
3 files changed, 42 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
index 0b38f88..4d27cf4 100644
--- a/drivers/gpu/drm/i915/i915_dma.c
+++ b/drivers/gpu/drm/i915/i915_dma.c
@@ -1572,6 +1572,7 @@ int i915_driver_load(struct drm_device *dev, unsigned
long flags)
spin_lock_init(dev_priv-backlight_lock);
spin_lock_init(dev_priv-uncore.lock);
spin_lock_init(dev_priv-mm.object_stat_lock);
+ atomic_set(dev_priv-bsd_cmd_counter, 0);
mutex_init(dev_priv-dpio_lock);
mutex_init(dev_priv-modeset_restore_lock);
@@ -1929,6 +1930,8 @@ void i915_driver_postclose(struct drm_device *dev,
struct drm_file *file)
{
struct drm_i915_file_private *file_priv = file-driver_priv;
+ if (file_priv file_priv-bsd_ring)
+ file_priv-bsd_ring = NULL;
kfree(file_priv);
}
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index ac5598c3..68e8166 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1466,6 +1466,8 @@ struct drm_i915_private {
struct i915_dri1_state dri1;
/* Old ums support infrastructure, same warning applies. */
struct i915_ums_state ums;
+ /* the lock for dispatch video commands on two BSD rings */
+ atomic_t bsd_cmd_counter;
You're still using atomic_t for no real good reason.
gen8_dispatch_bsd_ring is always called with the dev-struct_mutex lock
held, so there's really no reason for it.
-Daniel
};
static inline struct drm_i915_private *to_i915(const struct drm_device *dev)
@@ -1673,6 +1675,7 @@ struct drm_i915_file_private {
struct i915_hw_context *private_default_ctx;
atomic_t rps_wait_boost;
+ struct intel_ring_buffer *bsd_ring;
};
/*
diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
index 341ec68..720ef17 100644
--- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
@@ -999,6 +999,34 @@ i915_reset_gen7_sol_offsets(struct drm_device *dev,
return 0;
}
+/**
+ * Find one BSD ring to dispatch the corresponding BSD command.
+ * The Ring ID is returned.
+ */
+static int gen8_dispatch_bsd_ring(struct drm_device *dev,
+ struct drm_file *file)
+{
+ struct drm_i915_private *dev_priv = dev-dev_private;
+ struct drm_i915_file_private *file_priv = file-driver_priv;
+
+ /* Check whether the file_priv is using one ring */
+ if (file_priv-bsd_ring)
+ return file_priv-bsd_ring-id;
+ else {
+ /* If no, use the ping-pong mechanism to select one ring */
+ int counter, ring_id;
+ smp_mb__before_atomic_inc();
+ counter = atomic_inc_return(dev_priv-bsd_cmd_counter);
+ if (counter % 2 == 0)
+ ring_id = VCS;
+ else
+ ring_id = VCS2;
+
+ file_priv-bsd_ring = dev_priv-ring[ring_id];
+ return ring_id;
+ }
+}
+
static int
i915_gem_do_execbuffer(struct drm_device *dev, void *data,
struct drm_file *file,
@@ -1043,7 +1071,14 @@ i915_gem_do_execbuffer(struct drm_device *dev, void
*data,
if ((args-flags I915_EXEC_RING_MASK) == I915_EXEC_DEFAULT)
ring = dev_priv-ring[RCS];
- else
+ else if ((args-flags I915_EXEC_RING_MASK) == I915_EXEC_BSD) {
+ if (HAS_BSD2(dev)) {
+ int ring_id;
+ ring_id = gen8_dispatch_bsd_ring(dev, file);
+ ring = dev_priv-ring[ring_id];
+ } else
+ ring = dev_priv-ring[VCS];
+ } else
ring = dev_priv-ring[(args-flags I915_EXEC_RING_MASK) - 1];
if
Re: [Intel-gfx] [PATCH I-g-t 2/2] tests: Add dummy_reloc test case based on multi drm_fd to test CPU-GPU sync under multi BSD rings
On Mon, 2014-04-14 at 01:06 -0600, Daniel Vetter wrote:
On Mon, Apr 14, 2014 at 12:19:58PM +0800, Zhao Yakui wrote:
The Broadwell GT3 machine has two independent BSD rings in kernel driver
while
it is transparent to the user-space driver. In such case it needs to check
the CPU-GPU sync for the second BSD ring. Multi drm_fd can assure that the
second BSD ring has the opportunity to dispatch the GPU command.
Signed-off-by: Zhao Yakui yakui.z...@intel.com
---
tests/Makefile.sources|1 +
tests/gem_dummy_reloc_multi_bsd.c | 258
+
I've meant that you add a new subtest to the existing gem_dummy_reloc
test. With your patch here we essentially duplicate all the tests for the
other rings.
2 files changed, 259 insertions(+)
create mode 100644 tests/gem_dummy_reloc_multi_bsd.c
diff --git a/tests/Makefile.sources b/tests/Makefile.sources
index 254a5c5..98f277f 100644
--- a/tests/Makefile.sources
+++ b/tests/Makefile.sources
@@ -105,6 +105,7 @@ TESTS_progs = \
gem_ring_sync_copy \
gem_ring_sync_loop \
gem_multi_bsd_sync_loop \
+ gem_dummy_reloc_multi_bsd \
Tests with subtests must be added to the TESTS_progs_M variable, otherwise
piglit won't be able to enumerate the subtests. That's just an fyi for the
next testcase, like I've said here it's imo better to just add a new
subtest.
Thanks for the rules about how to add the test with subtests.(Sorry that
I don't know this rule)
OK. I will follow your comment to add it as subtests.
Thanks.
Yakui
Also you've forgotten to update .gitignore, when building with your patch
git status shows some not-added binaries.
-Daniel
gem_seqno_wrap \
gem_set_tiling_vs_gtt \
gem_set_tiling_vs_pwrite \
diff --git a/tests/gem_dummy_reloc_multi_bsd.c
b/tests/gem_dummy_reloc_multi_bsd.c
new file mode 100644
index 000..ef8213e
--- /dev/null
+++ b/tests/gem_dummy_reloc_multi_bsd.c
@@ -0,0 +1,258 @@
+/*
+ * Copyright © 2014 Intel Corporation
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the
Software),
+ * to deal in the Software without restriction, including without
limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the
next
+ * paragraph) shall be included in all copies or substantial portions of
the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND, EXPRESS
OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR
OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
DEALINGS
+ * IN THE SOFTWARE.
+ *
+ * Authors:
+ *Daniel Vetter daniel.vet...@ffwll.ch (based on
gem_dummy_reloc_loop*.c)
+ *Zhao Yakui yakui.z...@intel.com
+ *
+ */
+
+#include stdlib.h
+#include stdio.h
+#include string.h
+#include fcntl.h
+#include inttypes.h
+#include errno.h
+#include sys/stat.h
+#include sys/time.h
+#include drm.h
+#include ioctl_wrappers.h
+#include drmtest.h
+#include intel_bufmgr.h
+#include intel_batchbuffer.h
+#include intel_io.h
+#include i830_reg.h
+#include intel_chipset.h
+
+#define LOCAL_I915_EXEC_VEBOX (40)
+
+static drm_intel_bufmgr *bufmgr;
+struct intel_batchbuffer *batch;
+static drm_intel_bo *target_buffer;
+
+#define NUM_FD 50
+
+static int mfd[NUM_FD];
+static drm_intel_bufmgr *mbufmgr[NUM_FD];
+static struct intel_batchbuffer *mbatch[NUM_FD];
+static drm_intel_bo *mbuffer[NUM_FD];
+
+
+/*
+ * Testcase: Basic check of ring-cpu sync using a dummy reloc under
multi-fd
+ *
+ * The last test (that randomly switches the ring) seems to be pretty
effective
+ * at hitting the missed irq bug that's worked around with the HWSTAM irq
write.
+ */
+
+
+#define MI_COND_BATCH_BUFFER_END (0x3623 | 1)
+#define MI_DO_COMPARE (121)
+static void
+dummy_reloc_loop(int ring)
+{
+ int i;
+ srandom(0xdeadbeef);
+
+ for (i = 0; i 0x10; i++) {
+ int mindex = random() % NUM_FD;
+
+ batch = mbatch[mindex];
+ if (ring == I915_EXEC_RENDER) {
+ BEGIN_BATCH(4);
+ OUT_BATCH(MI_COND_BATCH_BUFFER_END | MI_DO_COMPARE);
+ OUT_BATCH(0x); /* compare dword */
+
Re: [Intel-gfx] Power saving using Display port HPD
Hi,
Finally I did it. Interested parties can find it below. If anybody has
better ways to do it please suggest.
1) Revert the commit 77961eb984c7e5394bd29cc7be2ab0bf0cc7e7b1.
With this commit DP hotplug events are not coming after doing xset dpms
force off
commit bfcbf45b5b458ebdc38118ca67279a1cd90e085d
Author: Arun Chandran achand...@mvista.com
Date: Fri Apr 11 16:16:32 2014 +0530
Revert drm/i915: power domains: add vlv power wells
This reverts commit 77961eb984c7e5394bd29cc7be2ab0bf0cc7e7b1.
2) Modify the code to inject uvents when DP cable is removed/inserted
#
diff --git a/drivers/gpu/drm/i915/i915_irq.c
b/drivers/gpu/drm/i915/i915_irq.c
index 4069703..84b3251 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -987,6 +987,12 @@ static bool intel_hpd_irq_event(struct drm_device *dev,
*/
#define I915_REENABLE_HOTPLUG_DELAY (2*60*1000)
+static int hpd_status;
+static struct intel_dp *intel_attached_dp(struct drm_connector *connector)
+{
+ return enc_to_intel_dp(intel_attached_encoder(connector)-base);
+}
+
static void i915_hotplug_work_func(struct work_struct *work)
{
struct drm_i915_private *dev_priv =
@@ -994,6 +1000,7 @@ static void i915_hotplug_work_func(struct work_struct
*work)
struct drm_device *dev = dev_priv-dev;
struct drm_mode_config *mode_config = dev-mode_config;
struct intel_connector *intel_connector;
+ struct intel_dp *intel_dp;
struct intel_encoder *intel_encoder;
struct drm_connector *connector;
unsigned long irqflags;
@@ -1045,6 +1052,15 @@ static void i915_hotplug_work_func(struct
work_struct *work)
list_for_each_entry(connector, mode_config-connector_list, head) {
intel_connector = to_intel_connector(connector);
intel_encoder = intel_connector-encoder;
+ if (connector-connector_type == DRM_MODE_CONNECTOR_eDP) {
+ DRM_DEBUG_KMS(arun edp %x\n, hpd_status);
+ intel_dp = intel_attached_dp(connector);
+
+ if (hpd_status (1 28))
+ kobject_uevent(intel_dp-aux.ddc.dev.kobj,
KOBJ_ADD);
+ else
+ kobject_uevent(intel_dp-aux.ddc.dev.kobj,
KOBJ_REMOVE);
+ }
if (hpd_event_bits (1 intel_encoder-hpd_pin)) {
if (intel_encoder-hot_plug)
intel_encoder-hot_plug(intel_encoder);
@@ -1639,11 +1655,14 @@ static void valleyview_pipestat_irq_handler(struct
drm_device *dev, u32 iir)
gmbus_irq_handler(dev);
}
+
static void i9xx_hpd_irq_handler(struct drm_device *dev)
{
struct drm_i915_private *dev_priv = dev-dev_private;
u32 hotplug_status = I915_READ(PORT_HOTPLUG_STAT);
+ hpd_status = hotplug_status;
+
if (IS_G4X(dev)) {
u32 hotplug_trigger = hotplug_status
HOTPLUG_INT_STATUS_G4X;
##
3) Add a udev rule
arun@arun-valley-view:~$ cat /etc/udev/rules.d/95-dpmonitor-hotplug.rules
KERNEL==i2c-7, SUBSYSTEM==i2c, ATTR{name}==DPDDC-C,
RUN+=/usr/local/bin/hpd.sh
4) Finally the script doing on/off
arun@arun-valley-view:~$ cat /usr/local/bin/hpd.sh
#! /bin/bash
export XAUTHORITY=/home/arun/.Xauthority
export DISPLAY=:0
echo ^ /tmp/hpd.log
echo `date` /tmp/hpd.log
if [ $ACTION == add ] ; then
echo Powering on /tmp/hpd.log
xset dpms force on
fi
if [ $ACTION == remove ] ; then
echo Powering off /tmp/hpd.log
sleep 1; xset dpms force off
fi
Regards,
Arun C
On Thu, Apr 10, 2014 at 3:58 PM, Arun Chandran achand...@mvista.com wrote:
Hi,
On Thu, Apr 10, 2014 at 12:54 PM, Daniel Vetter dan...@ffwll.ch wrote:
On Thu, Apr 10, 2014 at 12:06:15PM +0530, Arun Chandran wrote:
I have connected only a DP monitor on Bayley Bay platform and booting
ubuntu 13.10 with the kernel
http://cgit.freedesktop.org/drm-intel/log/?h=drm-intel-fixes.
I am experimenting with the HPD feature of display port with debug
messages enabled. (drm.debug=0xe).
When I plug in/out DP cable I am able to see the below kernel messages
and ubuntu desktop is displayed on the DP monitor
##
root@arun-valley-view:~# uname -a
Linux arun-valley-view 3.14.0-00528-g67e9d82 #34 SMP PREEMPT Wed Apr 9
18:48:30 IST 2014 i686 i686 i686 GNU/Linux
root@arun-valley-view:~# dmesg -c
[ 1028.506188] [drm:intel_hpd_irq_handler] hotplug event received,
stat 0x0010
[ 1028.506217] [drm:intel_hpd_irq_handler] Received HPD interrupt on
PIN 5 - cnt: 0
[ 1028.513858] [drm:i915_hotplug_work_func] running encoder hotplug
functions
[ 1028.513880] [drm:i915_hotplug_work_func] Connector eDP-1 (pin 5)
received hotplug event.
[ 1028.513896] [drm:i915_hotplug_work_func] Connector
Re: [Intel-gfx] Power saving using Display port HPD
On Mon, Apr 14, 2014 at 9:43 AM, Arun Chandran achand...@mvista.com wrote: 1) Revert the commit 77961eb984c7e5394bd29cc7be2ab0bf0cc7e7b1. With this commit DP hotplug events are not coming after doing xset dpms force off commit bfcbf45b5b458ebdc38118ca67279a1cd90e085d Author: Arun Chandran achand...@mvista.com Date: Fri Apr 11 16:16:32 2014 +0530 Revert drm/i915: power domains: add vlv power wells This reverts commit 77961eb984c7e5394bd29cc7be2ab0bf0cc7e7b1. So this breaks DP hotplug detection? Imre? -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 I-g-t 2/2] tests: Add dummy_reloc test case based on multi drm_fd to test CPU-GPU sync under multi BSD rings
On Mon, 2014-04-14 at 01:06 -0600, Daniel Vetter wrote:
On Mon, Apr 14, 2014 at 12:19:58PM +0800, Zhao Yakui wrote:
The Broadwell GT3 machine has two independent BSD rings in kernel driver
while
it is transparent to the user-space driver. In such case it needs to check
the CPU-GPU sync for the second BSD ring. Multi drm_fd can assure that the
second BSD ring has the opportunity to dispatch the GPU command.
Signed-off-by: Zhao Yakui yakui.z...@intel.com
---
tests/Makefile.sources|1 +
tests/gem_dummy_reloc_multi_bsd.c | 258
+
I've meant that you add a new subtest to the existing gem_dummy_reloc
test. With your patch here we essentially duplicate all the tests for the
other rings.
2 files changed, 259 insertions(+)
create mode 100644 tests/gem_dummy_reloc_multi_bsd.c
diff --git a/tests/Makefile.sources b/tests/Makefile.sources
index 254a5c5..98f277f 100644
--- a/tests/Makefile.sources
+++ b/tests/Makefile.sources
@@ -105,6 +105,7 @@ TESTS_progs = \
gem_ring_sync_copy \
gem_ring_sync_loop \
gem_multi_bsd_sync_loop \
+ gem_dummy_reloc_multi_bsd \
Tests with subtests must be added to the TESTS_progs_M variable, otherwise
piglit won't be able to enumerate the subtests. That's just an fyi for the
next testcase, like I've said here it's imo better to just add a new
subtest.
Thanks for the rules about how to add the test with subtests.(Sorry that
I don't know this rule)
OK. I will follow your comment to add it as subtests.
Also you've forgotten to update .gitignore, when building with your patch
git status shows some not-added binaries.
BTW: How do I update the .gitigonre?
In my test I usually use the following step to create the corresponding
patches before sending and never update the .gitignore.
a. use quilt tool to create it
b. use git am to apply the corresponding patch on the working tree
c. use git format-patch to get the corresponding patches that can
be sent by using git-send-email
Appreciate your helps.
Thanks.
Yakui
-Daniel
gem_seqno_wrap \
gem_set_tiling_vs_gtt \
gem_set_tiling_vs_pwrite \
diff --git a/tests/gem_dummy_reloc_multi_bsd.c
b/tests/gem_dummy_reloc_multi_bsd.c
new file mode 100644
index 000..ef8213e
--- /dev/null
+++ b/tests/gem_dummy_reloc_multi_bsd.c
@@ -0,0 +1,258 @@
+/*
+ * Copyright © 2014 Intel Corporation
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the
Software),
+ * to deal in the Software without restriction, including without
limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the
next
+ * paragraph) shall be included in all copies or substantial portions of
the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND, EXPRESS
OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR
OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
DEALINGS
+ * IN THE SOFTWARE.
+ *
+ * Authors:
+ *Daniel Vetter daniel.vet...@ffwll.ch (based on
gem_dummy_reloc_loop*.c)
+ *Zhao Yakui yakui.z...@intel.com
+ *
+ */
+
+#include stdlib.h
+#include stdio.h
+#include string.h
+#include fcntl.h
+#include inttypes.h
+#include errno.h
+#include sys/stat.h
+#include sys/time.h
+#include drm.h
+#include ioctl_wrappers.h
+#include drmtest.h
+#include intel_bufmgr.h
+#include intel_batchbuffer.h
+#include intel_io.h
+#include i830_reg.h
+#include intel_chipset.h
+
+#define LOCAL_I915_EXEC_VEBOX (40)
+
+static drm_intel_bufmgr *bufmgr;
+struct intel_batchbuffer *batch;
+static drm_intel_bo *target_buffer;
+
+#define NUM_FD 50
+
+static int mfd[NUM_FD];
+static drm_intel_bufmgr *mbufmgr[NUM_FD];
+static struct intel_batchbuffer *mbatch[NUM_FD];
+static drm_intel_bo *mbuffer[NUM_FD];
+
+
+/*
+ * Testcase: Basic check of ring-cpu sync using a dummy reloc under
multi-fd
+ *
+ * The last test (that randomly switches the ring) seems to be pretty
effective
+ * at hitting the missed irq bug that's worked around with the HWSTAM irq
write.
+ */
+
+
+#define MI_COND_BATCH_BUFFER_END (0x3623 | 1)
+#define MI_DO_COMPARE (121)
+static void
+dummy_reloc_loop(int ring)
+{
+
Re: [Intel-gfx] [PATCH v3] drm/i915: Add parsing support for new MIPI blocks in VBT
On 4/14/2014 12:32 PM, Daniel Vetter wrote: On Mon, Apr 14, 2014 at 11:00:34AM +0530, Shobhit Kumar wrote: The parser extracts the config block(#52) and sequence(#53) data and store in private data structures. v2: Address review comments by Jani - adjust code for the structure changes for bdb_mipi_config - add boundry and buffer overflow checks as suggested - use kmemdup instead of kmalloc and memcpy v3: More strict check while parsing VBT - Ensure that at anytime we do not go beyond sequence block while parsing - On unknown element fail the whole parsing v4: Style changes and spell check mostly as suggested by Jani Signed-off-by: Shobhit Kumar shobhit.ku...@intel.com Reviewed-by: Jani Nikula jani.nik...@intel.com I didn't spot Jani's r-b tag in earlier mails, was that done off-list? Yeah, was reviewed along with the other DSI patchset you merged, sorry about that. But then some patches needed internal review while they were being approved for up-streaming to save time. And this one was related to the other panel driver patches which I published today so got stuck with them. Sorry about that. Regards Shobhit ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH I-g-t 2/2] tests: Add dummy_reloc test case based on multi drm_fd to test CPU-GPU sync under multi BSD rings
On Mon, Apr 14, 2014 at 9:32 AM, Zhao Yakui yakui.z...@intel.com wrote: BTW: How do I update the .gitigonre? In my test I usually use the following step to create the corresponding patches before sending and never update the .gitignore. a. use quilt tool to create it b. use git am to apply the corresponding patch on the working tree c. use git format-patch to get the corresponding patches that can be sent by using git-send-email It's a normal file in the corresponding directory. You can just edit it and add it to the patch. -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 V2 6/6] drm/i915:Use the coarse ping-pong mechanism based on drm fd to dispatch the BSD command on BDW GT3
On Mon, 2014-04-14 at 01:22 -0600, Daniel Vetter wrote:
On Mon, Apr 14, 2014 at 12:21:44PM +0800, Zhao Yakui wrote:
V1-V2: Follow Daniel's comment and use the simple ping-pong mechanism.
This is only to add the support of dual BSD rings on BDW GT3 machine.
The further optimization will be considered in another patch set.
The BDW GT3 has two independent BSD rings, which can be used to process the
video commands. To be simpler, it is transparent to user-space
driver/middle.
Instead the kernel driver will decide which ring is to dispatch the BSD
video
command.
As every BSD ring is powerful, it is enough to dispatch the BSD video
command
based on the drm fd. In such case it can play back video stream while
encoding
another video stream. The coarse ping-pong mechanism is used to determine
which BSD ring is used to dispatch the BSD video command.
Signed-off-by: Zhao Yakui yakui.z...@intel.com
---
drivers/gpu/drm/i915/i915_dma.c|3 +++
drivers/gpu/drm/i915/i915_drv.h|3 +++
drivers/gpu/drm/i915/i915_gem_execbuffer.c | 37
+++-
3 files changed, 42 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_dma.c
b/drivers/gpu/drm/i915/i915_dma.c
index 0b38f88..4d27cf4 100644
--- a/drivers/gpu/drm/i915/i915_dma.c
+++ b/drivers/gpu/drm/i915/i915_dma.c
@@ -1572,6 +1572,7 @@ int i915_driver_load(struct drm_device *dev, unsigned
long flags)
spin_lock_init(dev_priv-backlight_lock);
spin_lock_init(dev_priv-uncore.lock);
spin_lock_init(dev_priv-mm.object_stat_lock);
+ atomic_set(dev_priv-bsd_cmd_counter, 0);
mutex_init(dev_priv-dpio_lock);
mutex_init(dev_priv-modeset_restore_lock);
@@ -1929,6 +1930,8 @@ void i915_driver_postclose(struct drm_device *dev,
struct drm_file *file)
{
struct drm_i915_file_private *file_priv = file-driver_priv;
+ if (file_priv file_priv-bsd_ring)
+ file_priv-bsd_ring = NULL;
kfree(file_priv);
}
diff --git a/drivers/gpu/drm/i915/i915_drv.h
b/drivers/gpu/drm/i915/i915_drv.h
index ac5598c3..68e8166 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1466,6 +1466,8 @@ struct drm_i915_private {
struct i915_dri1_state dri1;
/* Old ums support infrastructure, same warning applies. */
struct i915_ums_state ums;
+ /* the lock for dispatch video commands on two BSD rings */
+ atomic_t bsd_cmd_counter;
You're still using atomic_t for no real good reason.
gen8_dispatch_bsd_ring is always called with the dev-struct_mutex lock
held, so there's really no reason for it.
If the struct_mutex is used in the gen8_dispatch_bsd_ring, I can remove
the atomic_t.
It seems that the struct_mutex is a big lock and it is used very
frequently(i915_gem.c, i915_dma.c and so on). In my point it is a little
heavier than the atomic_t if one counter is increased and returned.
If you think that the mutex is better than atomic, I will follow your
advice.
Thanks.
Yakui
-Daniel
};
static inline struct drm_i915_private *to_i915(const struct drm_device
*dev)
@@ -1673,6 +1675,7 @@ struct drm_i915_file_private {
struct i915_hw_context *private_default_ctx;
atomic_t rps_wait_boost;
+ struct intel_ring_buffer *bsd_ring;
};
/*
diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
index 341ec68..720ef17 100644
--- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
@@ -999,6 +999,34 @@ i915_reset_gen7_sol_offsets(struct drm_device *dev,
return 0;
}
+/**
+ * Find one BSD ring to dispatch the corresponding BSD command.
+ * The Ring ID is returned.
+ */
+static int gen8_dispatch_bsd_ring(struct drm_device *dev,
+ struct drm_file *file)
+{
+ struct drm_i915_private *dev_priv = dev-dev_private;
+ struct drm_i915_file_private *file_priv = file-driver_priv;
+
+ /* Check whether the file_priv is using one ring */
+ if (file_priv-bsd_ring)
+ return file_priv-bsd_ring-id;
+ else {
+ /* If no, use the ping-pong mechanism to select one ring */
+ int counter, ring_id;
+ smp_mb__before_atomic_inc();
+ counter = atomic_inc_return(dev_priv-bsd_cmd_counter);
+ if (counter % 2 == 0)
+ ring_id = VCS;
+ else
+ ring_id = VCS2;
+
+ file_priv-bsd_ring = dev_priv-ring[ring_id];
+ return ring_id;
+ }
+}
+
static int
i915_gem_do_execbuffer(struct drm_device *dev, void *data,
struct drm_file *file,
@@ -1043,7 +1071,14 @@ i915_gem_do_execbuffer(struct drm_device *dev, void
*data,
if ((args-flags I915_EXEC_RING_MASK) ==
Re: [Intel-gfx] [PATCH I-g-t 2/2] tests: Add dummy_reloc test case based on multi drm_fd to test CPU-GPU sync under multi BSD rings
On Mon, 2014-04-14 at 01:55 -0600, Daniel Vetter wrote: On Mon, Apr 14, 2014 at 9:32 AM, Zhao Yakui yakui.z...@intel.com wrote: BTW: How do I update the .gitigonre? In my test I usually use the following step to create the corresponding patches before sending and never update the .gitignore. a. use quilt tool to create it b. use git am to apply the corresponding patch on the working tree c. use git format-patch to get the corresponding patches that can be sent by using git-send-email It's a normal file in the corresponding directory. You can just edit it and add it to the patch. Thanks. Yakui -Daniel ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] Power saving using Display port HPD
On Mon, 2014-04-14 at 09:47 +0200, Daniel Vetter wrote: On Mon, Apr 14, 2014 at 9:43 AM, Arun Chandran achand...@mvista.com wrote: 1) Revert the commit 77961eb984c7e5394bd29cc7be2ab0bf0cc7e7b1. With this commit DP hotplug events are not coming after doing xset dpms force off commit bfcbf45b5b458ebdc38118ca67279a1cd90e085d Author: Arun Chandran achand...@mvista.com Date: Fri Apr 11 16:16:32 2014 +0530 Revert drm/i915: power domains: add vlv power wells This reverts commit 77961eb984c7e5394bd29cc7be2ab0bf0cc7e7b1. So this breaks DP hotplug detection? Imre? Yes, unfortunately. I made this clear in my patchset [1] and it was also discussed on IRC. If there isn't any (e)DP,HDMI pipe active we power down the DPIO HW block responsible normally for DP and HDMI hotplug detection. There is one possible solution: the pin that is used for HPD detection can be used either normally in the above way, where it's controlled by the DPIO block, or as a GPIO where it's controlled by the GPIO HW block which is on even if we power down the DPIO. So during power down periods we could reconfigure that pin to work as a GPIO and treat any interrupts arriving it as an HPD event. I haven't had yet time to investigate this. Another way is to turn on polling while powered down. This would also make VGA hotplug work, for which we don't have a GPIO alternative as above. [1] http://lists.freedesktop.org/archives/intel-gfx/2014-February/040232.html signature.asc Description: This is a digitally signed message part ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH V2 6/6] drm/i915:Use the coarse ping-pong mechanism based on drm fd to dispatch the BSD command on BDW GT3
On Mon, Apr 14, 2014 at 04:05:19PM +0800, Zhao Yakui wrote: On Mon, 2014-04-14 at 01:22 -0600, Daniel Vetter wrote: You're still using atomic_t for no real good reason. gen8_dispatch_bsd_ring is always called with the dev-struct_mutex lock held, so there's really no reason for it. If the struct_mutex is used in the gen8_dispatch_bsd_ring, I can remove the atomic_t. It seems that the struct_mutex is a big lock and it is used very frequently(i915_gem.c, i915_dma.c and so on). In my point it is a little heavier than the atomic_t if one counter is increased and returned. If you think that the mutex is better than atomic, I will follow your advice. You are already holding the struct_mutex whenever we touch the ring and execbuffer. Even in a fine-grained world, there will still be a mutex around all operations that touch the rings. -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] [ 3.14.0-12041-g75ff24f ] regression: drm warning
2014-04-09 12:08 GMT+02:00 Jörg Otte jrg.o...@gmail.com: Kernel 3.14.0-12041-g75ff24f from 9.4.2014 introduces the following on the console (driver is i915): [drm:ivb_err_int_handler] *ERROR* Pipe B FIFO underrun [drm:cpt_serr_int_handler] *ERROR* PCH transcoder A FIFO underrun [drm:cpt_serr_int_handler] *ERROR* PCH transcoder B FIFO underrun In syslog I find: [ cut here ] WARNING: CPU: 1 PID: 1 at /data/kernel/linux/drivers/gpu/drm/drm_mm.c:211 0xb22a70fa() no hole found for node 0x0 + 0x30 CPU: 1 PID: 1 Comm: swapper/0 Not tainted 3.14.0-12041-g75ff24f #45 Hardware name: FUJITSU LIFEBOOK AH532/FJNBB1C, BIOS Version 1.09 05/22/2012 b2967138 b262ae5d 8802160d5a58 b20391ad 880214994000 0030 880214952800 b2039255 b2967190 Call Trace: [b262ae5d] ? 0xb262ae5d [b20391ad] ? 0xb20391ad [b2039255] ? 0xb2039255 [b22a70fa] ? 0xb22a70fa [b22d4b11] ? 0xb22d4b11 [b2300f92] ? 0xb2300f92 [b232af7b] ? 0xb232af7b [b232f675] ? 0xb232f675 [b21fa38c] ? 0xb21fa38c [b232ec04] ? 0xb232ec04 [b2622997] ? 0xb2622997 [b232ee62] ? 0xb232ee62 [b22a6a5b] ? 0xb22a6a5b [b22a3994] ? 0xb22a3994 [b22a5a38] ? 0xb22a5a38 [b221a019] ? 0xb221a019 [b23327b8] ? 0xb23327b8 [b2332a03] ? 0xb2332a03 [b2332970] ? 0xb2332970 [b2330c45] ? 0xb2330c45 [b2331534] ? 0xb2331534 [b2332fce] ? 0xb2332fce [b2aa2cc5] ? 0xb2aa2cc5 [b2a7fe45] ? 0xb2a7fe45 [b2052100] ? 0xb2052100 [b2a7ffe2] ? 0xb2a7ffe2 [b2a7f79e] ? 0xb2a7f79e [b2624d20] ? 0xb2624d20 [b2624d29] ? 0xb2624d29 [b263223c] ? 0xb263223c [b2624d20] ? 0xb2624d20 ---[ end trace 0d3f14b61bc31dab ]--- This does not happen in 3.14.0-11030-ga7963eb from 8.4.2014 and never before. Suppose merge 12024 e9f37d3 Merge branch 'drm-next' of git://people.freedesktop.org/~airlied/linux produces this problem. cc to more people.. Jörg ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH V2 6/6] drm/i915:Use the coarse ping-pong mechanism based on drm fd to dispatch the BSD command on BDW GT3
On Mon, 2014-04-14 at 02:19 -0600, Chris Wilson wrote: On Mon, Apr 14, 2014 at 04:05:19PM +0800, Zhao Yakui wrote: On Mon, 2014-04-14 at 01:22 -0600, Daniel Vetter wrote: You're still using atomic_t for no real good reason. gen8_dispatch_bsd_ring is always called with the dev-struct_mutex lock held, so there's really no reason for it. If the struct_mutex is used in the gen8_dispatch_bsd_ring, I can remove the atomic_t. It seems that the struct_mutex is a big lock and it is used very frequently(i915_gem.c, i915_dma.c and so on). In my point it is a little heavier than the atomic_t if one counter is increased and returned. If you think that the mutex is better than atomic, I will follow your advice. You are already holding the struct_mutex whenever we touch the ring and execbuffer. Even in a fine-grained world, there will still be a mutex around all operations that touch the rings. Hi, Chris I understand your concern. From the source code the struct_mutex will be held when trying to do the buffer relocation and dispatch the command in one ring. But my code is only to select one BSD ring. In such case the atomic_t usage is enough and it is unnecessary to hold the struct_mutex. If you also think that the struct_mutex is better, I can update the code to use the struct_mutex. Thanks. Yakui -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3] drm/i915: Add parsing support for new MIPI blocks in VBT
On Mon, Apr 14, 2014 at 01:24:43PM +0530, Kumar, Shobhit wrote: On 4/14/2014 12:32 PM, Daniel Vetter wrote: On Mon, Apr 14, 2014 at 11:00:34AM +0530, Shobhit Kumar wrote: The parser extracts the config block(#52) and sequence(#53) data and store in private data structures. v2: Address review comments by Jani - adjust code for the structure changes for bdb_mipi_config - add boundry and buffer overflow checks as suggested - use kmemdup instead of kmalloc and memcpy v3: More strict check while parsing VBT - Ensure that at anytime we do not go beyond sequence block while parsing - On unknown element fail the whole parsing v4: Style changes and spell check mostly as suggested by Jani Signed-off-by: Shobhit Kumar shobhit.ku...@intel.com Reviewed-by: Jani Nikula jani.nik...@intel.com I didn't spot Jani's r-b tag in earlier mails, was that done off-list? Yeah, was reviewed along with the other DSI patchset you merged, sorry about that. But then some patches needed internal review while they were being approved for up-streaming to save time. And this one was related to the other panel driver patches which I published today so got stuck with them. Sorry about that. Ok, pulled it in. checkpatch complained a few times about assignments in if conditions, and I tend to agree. Can you please follow up with a cleanup patch? Also it looks like assignment operators could be used. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Increase WM memory latency values on SNB with high pixel clock
On Mon, Mar 31, 2014 at 06:29:51PM +, Robert Navarro wrote: Runyan, Arthur J arthur.j.runyan at intel.com writes: Please check the DRAM configuration for the systems that fail. The higher latency is more likely with higher tRFC which is mainly found with 8 Gbit components. What other information do we need to get this included? The DRAM config, is this something that I have to/should check? How do I get this information to you? If decode-dimms works on your machine it might print out potentially interesting stuff. It doesn't seem to work on most of my machines. It does work on the x220 I have here though, so I'm assuming it should work on your x220 too. decode-dimms comes from the i2c-tools package. Here's what I get on mine: # modprobe i2c-i801 # modprobe eeprom # decode-dimms # decode-dimms version 6231 (2014-02-20 10:54:34 +0100) Memory Serial Presence Detect Decoder By Philip Edelbrock, Christian Zuckschwerdt, Burkart Lingner, Jean Delvare, Trent Piepho and others Decoding EEPROM: /sys/bus/i2c/drivers/eeprom/0-0050 Guessing DIMM is in bank 1 ---=== SPD EEPROM Information ===--- EEPROM CRC of bytes 0-116 OK (0xFC7B) # of bytes written to SDRAM EEPROM 176 Total number of bytes in EEPROM 256 Fundamental Memory type DDR3 SDRAM Module Type SO-DIMM ---=== Memory Characteristics ===--- Fine time base 1.000 ps Medium time base0.125 ns Maximum module speed1333 MHz (PC3-10600) Size4096 MB Banks x Rows x Columns x Bits 8 x 15 x 10 x 64 Ranks 2 SDRAM Device Width 8 bits Bus Width Extension 0 bits tCL-tRCD-tRP-tRAS 9-9-9-24 Supported CAS Latencies (tCL) 9T, 8T, 7T, 6T, 5T ---=== Timing Parameters ===--- Minimum Write Recovery time (tWR) 15.000 ns Minimum Row Active to Row Active Delay (tRRD) 6.000 ns Minimum Active to Auto-Refresh Delay (tRC) 49.125 ns Minimum Recovery Delay (tRFC) 160.000 ns Minimum Write to Read CMD Delay (tWTR) 7.500 ns Minimum Read to Pre-charge CMD Delay (tRTP) 7.500 ns Minimum Four Activate Window Delay (tFAW) 30.000 ns ---=== Optional Features ===--- Operable voltages 1.5V RZQ/6 supported?Yes RZQ/7 supported?Yes DLL-Off Mode supported? Yes Operating temperature range 0-95 degrees C Refresh Rate in extended temp range 1X Auto Self-Refresh? No On-Die Thermal Sensor readout? No Partial Array Self-Refresh? No Thermal Sensor Accuracy Not implemented SDRAM Device Type Standard Monolithic ---=== Physical Characteristics ===--- Module Height (mm) 30 Module Thickness (mm) 2 front, 2 back Module Width (mm) 67.6 Module Reference Card F ---=== Manufacturer Data ===--- Module Manufacturer Samsung DRAM Manufacturer Samsung Manufacturing Location Code 0x03 Manufacturing Date 2012-W04 Assembly Serial Number 0x009B48F1 Part Number M471B5273DH0-CH9 Number of SDRAM DIMMs detected and decoded: 1 Just for figuring out what tRFC is I think the following would do it: # intel_reg_read 0x144298 0x144698 0x144a98 0x145d10 0x145e04 These are from the machines I have lying around on my desk: // dell xps (snb) # ./intel_reg_read 0x144298 0x144698 0x144a98 0x145d10 0x145e04 0x144298 : 0x5A6B1450 0x144698 : 0x5A6B1450 0x144A98 : 0x0 0x145D10 : 0x16040307 0x145E04 : 0x5 // x220 (snb) # ./intel_reg_read 0x144298 0x144698 0x144a98 0x145d10 0x145e04 0x144298 : 0x5A6B1450 0x144698 : 0x46B41004 0x144A98 : 0x0 0x145D10 : 0x16040307 0x145E04 : 0x5 // some ivb desktop # ./intel_reg_read 0x144298 0x144698 0x144a98 0x145d10 0x145e04 0x144298 : 0x5A6B1450 0x144698 : 0x5A6B1450 0x144A98 : 0x0 0x145D10 : 0x2010040C 0x145E04 : 0x5 So on for most things I get an answer of tRFC=107, which means 160ns if my math is any good. And that matches the SPD info from decode-dimms on the x220. The second channel for the x220 has something different but it actually looks like the reset value for the register which makes sense since decode-dimms says it only has one DIMM. No idea if my tRFC is particularly low or high. The latency values are quite different between the
[Intel-gfx] [PATCH v5 2/6] drm/i915/vlv: Added a rendering specific Hw WA 'WaSendDummy3dPrimitveAfterSetContext'
From: Akash Goel akash.g...@intel.com
This workaround is needed on VLV for the HW context feature.
It is used after adding the mi_set_context command in ring buffer
for Hw context switch. As per the spec
The software must send a pipe_control with a CS stall and a post sync
operation and then a dummy DRAW after every MI_SET_CONTEXT and after any
PIPELINE_SELECT that is enabling 3D mode.
Tested only for vlv.
v2: Modified the WA comment. (Ville)
v3: Added the vlv identifier with the WA name
v4: Check removed for scratch page initialization. (Chris/Daniel)
v5: Refactored based on latest codebase. Also WA added for full Gen7.
Signed-off-by: Sourab Gupta sourab.gu...@intel.com
Signed-off-by: Akash Goel akash.g...@intel.com
---
drivers/gpu/drm/i915/i915_gem_context.c | 55 +++--
drivers/gpu/drm/i915/i915_reg.h | 1 +
drivers/gpu/drm/i915/intel_ringbuffer.c | 9 ++
drivers/gpu/drm/i915/intel_ringbuffer.h | 1 +
4 files changed, 64 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_context.c
b/drivers/gpu/drm/i915/i915_gem_context.c
index f77b4c1..b6d2a67 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/i915_gem_context.c
@@ -545,6 +545,47 @@ i915_gem_context_get(struct drm_i915_file_private
*file_priv, u32 id)
return ctx;
}
+static inline void
+mi_set_context_dummy3d_prim_wa(struct intel_ring_buffer *ring)
+{
+ u32 scratch_addr;
+ u32 flags = 0;
+
+ /* Actual scratch location is at 128 bytes offset */
+ scratch_addr = intel_get_pipe_control_scratch_addr(ring) + 128;
+
+ /*
+* WaSendDummy3dPrimitveAfterSetContext:ivb,vlv
+* Software must send a pipe_control with a CS stall
+* and a post sync operation and then a dummy DRAW after
+* every MI_SET_CONTEXT and after any PIPELINE_SELECT that
+* is enabling 3D mode. A dummy draw is a 3DPRIMITIVE command
+* with Indirect Parameter Enable set to 0, UAV Coherency
+* Required set to 0, Predicate Enable set to 0,
+* End Offset Enable set to 0, and Vertex Count Per Instance
+* set to 0, All other parameters are a don't care.
+*/
+
+ /*
+* Add a pipe control with CS Stall and postsync op
+* before dummy 3D_PRIMITIVE
+*/
+ flags |= PIPE_CONTROL_QW_WRITE | PIPE_CONTROL_CS_STALL;
+ intel_ring_emit(ring, GFX_OP_PIPE_CONTROL(4));
+ intel_ring_emit(ring, flags);
+ intel_ring_emit(ring, scratch_addr | PIPE_CONTROL_GLOBAL_GTT);
+ intel_ring_emit(ring, 0);
+
+ /* Add a dummy 3D_PRIMITVE */
+ intel_ring_emit(ring, GFX_OP_3DPRIMITIVE);
+ intel_ring_emit(ring, 4); /* PrimTopoType*/
+ intel_ring_emit(ring, 0); /* VertexCountPerInstance */
+ intel_ring_emit(ring, 0); /* StartVertexLocation */
+ intel_ring_emit(ring, 0); /* InstanceCount */
+ intel_ring_emit(ring, 0); /* StartInstanceLocation */
+ intel_ring_emit(ring, 0); /* BaseVertexLocation */
+}
+
static inline int
mi_set_context(struct intel_ring_buffer *ring,
struct i915_hw_context *new_context,
@@ -563,7 +604,10 @@ mi_set_context(struct intel_ring_buffer *ring,
return ret;
}
- ret = intel_ring_begin(ring, 6);
+ if (INTEL_INFO(ring-dev)-gen == 7)
+ ret = intel_ring_begin(ring, 6+4+8);
+ else
+ ret = intel_ring_begin(ring, 6);
if (ret)
return ret;
@@ -586,8 +630,15 @@ mi_set_context(struct intel_ring_buffer *ring,
*/
intel_ring_emit(ring, MI_NOOP);
+ /* WaSendDummy3dPrimitveAfterSetContext:ivb,vlv */
if (INTEL_INFO(ring-dev)-gen = 7)
- intel_ring_emit(ring, MI_ARB_ON_OFF | MI_ARB_ENABLE);
+ if (INTEL_INFO(ring-dev)-gen == 7) {
+ mi_set_context_dummy3d_prim_wa(ring);
+ intel_ring_emit(ring, MI_ARB_ON_OFF | MI_ARB_ENABLE);
+ intel_ring_emit(ring, MI_NOOP);
+ } else
+ intel_ring_emit(ring, MI_ARB_ON_OFF | MI_ARB_ENABLE);
+
else
intel_ring_emit(ring, MI_NOOP);
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 8f84555..1128527 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -355,6 +355,7 @@
#define PIPE_CONTROL_STALL_AT_SCOREBOARD (11)
#define PIPE_CONTROL_DEPTH_CACHE_FLUSH (10)
#define PIPE_CONTROL_GLOBAL_GTT (12) /* in addr dword */
+#define GFX_OP_3DPRIMITIVE ((0x329)|(0x327)|(0x324)|(7-2))
/*
* Commands used only by the command parser
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c
b/drivers/gpu/drm/i915/intel_ringbuffer.c
index eb3dd26..834411b 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.c
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
@@ -585,6 +585,15 @@ err:
return
Re: [Intel-gfx] [PATCH 3/6] drm/i915: Add support for stealing purgable stolen pages
On Fri, 2014-04-11 at 08:55 +, Daniel Vetter wrote: On Thu, Apr 10, 2014 at 10:12:39AM +, Gupta, Sourab wrote: On Wed, 2014-04-09 at 13:06 +, Daniel Vetter wrote: On Tue, Apr 08, 2014 at 06:53:03AM +, Gupta, Sourab wrote: On Tue, 2014-04-08 at 06:45 +, Chris Wilson wrote: On Tue, Apr 08, 2014 at 04:32:02AM +, Gupta, Sourab wrote: Hi Rodrigo, In this patch, while freeing the purgeable stolen object, the memory node also has to be freed, so as to make space for new object. We need to call drm_mm_remove_node while freeing obj. The below modification patch was floated earlier for this purpose: http://lists.freedesktop.org/archives/intel-gfx/2014-March/041282.html Right, I have a v2 locally with the fix you identified. -Chris Ok, Thanks Chris. I'd really prefer if someone would pick up all the stolen/create2_ioctl/whatever patches, pack them up into a polished series, add the testcases and submit this all for review and merging. Otherwise this will linger forever and we'll get nowhere. Chris seems swamped with other stuff, so Sourab could you please take a look at this? Please check with your manager that you have sufficient bandwidth to pull this through. I'll be on vacation from next week, so I'll be able to gauge this better after coming back. Nevertheless, I have some questions regarding the expectation of userspace code changes required for these patches (i.e. libdrm changes and igt testcases) 1) For libdrm , I am assuming, a counterpart of drm_intel_gem_bo_alloc_tiled() function would call the create2 ioctl and take in the parameters needed. Should the caching of objects from libdrm need to take care of both the placement domains seperately (as in different sets of bo buckets)? Should libdrm be transparent to all the combinations of different parameters being passed by user or should the prohibited combinations be disallowed from libdrm side? I'm not sure whether we need a cache implemented in libdrm. Since stolen objects are fairly special it's probably easier to just have a simple linear cache tailor-made in the respective UMD. So just exposing create2_ioctl should be good enough. 2) For the igt, since we have a lot of parameters exposed to user, the number of subtests required may be huge and still they may not test out everything. So, Is the expectation here to have exhaustive test cases for all the parameters (tiling/cache/domain/madvise/offset etc.) going in as input to the create2 ioctl? For eg. let us say we are going to check the render copy operation of src and dest bo's. Do we need to provide all possible combinations of different (create2 ioctl) input parameters to these src and dest bo's and then run the render copy test for all these combinations. Any guiding pointers from your side as to how we may go about the igt testcases? At a high-level there's two parts for igt tests: - First is functional tests, where we try to make sure that the feature actually works. I.e. allocate some stolen memory and then do something with it, making sure that data access for the gpu and similar things work. For this we just want some reasonable base coverage so that when we hit a bug somewhere it's easy to extend the testcase to cover that bug with a specific subtest. - Then there's interface testing. kernel/userspace is a trust barrier, so we need to make sure that evil userspace can't make the kernel crash with some crazy invalid combination of flags or operations (like create a stolen object and then try to mmap it). Since this is security relevant and also since we can't ever change established userspace ABI I want full coverage of all cases. But this is just about detecting abuse correctly, no functional tests here. For details see my two blog posts on the topic: http://blog.ffwll.ch/2013/11/botching-up-ioctls.html http://blog.ffwll.ch/2013/11/testing-requirements-for-drmi915.html Cheers, Daniel Thanks Daniel, We'll take care of the above points for libdrm changes and igt. Regards, Sourab ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3] drm/i915: Add parsing support for new MIPI blocks in VBT
On 4/14/2014 2:35 PM, Daniel Vetter wrote: On Mon, Apr 14, 2014 at 01:24:43PM +0530, Kumar, Shobhit wrote: On 4/14/2014 12:32 PM, Daniel Vetter wrote: On Mon, Apr 14, 2014 at 11:00:34AM +0530, Shobhit Kumar wrote: The parser extracts the config block(#52) and sequence(#53) data and store in private data structures. v2: Address review comments by Jani - adjust code for the structure changes for bdb_mipi_config - add boundry and buffer overflow checks as suggested - use kmemdup instead of kmalloc and memcpy v3: More strict check while parsing VBT - Ensure that at anytime we do not go beyond sequence block while parsing - On unknown element fail the whole parsing v4: Style changes and spell check mostly as suggested by Jani Signed-off-by: Shobhit Kumar shobhit.ku...@intel.com Reviewed-by: Jani Nikula jani.nik...@intel.com I didn't spot Jani's r-b tag in earlier mails, was that done off-list? Yeah, was reviewed along with the other DSI patchset you merged, sorry about that. But then some patches needed internal review while they were being approved for up-streaming to save time. And this one was related to the other panel driver patches which I published today so got stuck with them. Sorry about that. Ok, pulled it in. checkpatch complained a few times about assignments in if conditions, and I tend to agree. Can you please follow up with a cleanup patch? Also it looks like assignment operators could be used. -Daniel Ok. Thanks. I should have run checkpatch. Will fix and push a cleanup patch. Regards Shobhit ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2] tests/gem_error_capture: Initial testcase for error state capture/dump
+ FILE *file;
+ int debug_fd;
+ char *line = NULL;
+ size_t line_size = 0;
+ char *dashes = NULL;
+ char *ring_name = NULL;
+ int bb_matched = 0;
+ uint32_t gtt_offset;
+ char expected_line[32];
+ int req_matched = 0;
+ int requests;
+ uint32_t seqno, tail;
+ long jiffies;
+ int ringbuf_matched = 0;
+ unsigned int offset, command, expected_addr = 0;
+ int i, items;
+ bool bb_ok = false, req_ok = false, ringbuf_ok = false;
Most of these are only of use in local scope.
ACK, will change.
+ debug_fd = igt_debugfs_open(i915_error_state, O_RDONLY);
+ igt_assert(debug_fd = 0);
+ file = fdopen(debug_fd, r);
+
+ while (getline(line, line_size, file) 0) {
+ dashes = strstr(line, ---);
+ if (!dashes)
+ continue;
+
+ ring_name = realloc(ring_name, dashes - line);
+ strncpy(ring_name, line, dashes - line);
+ ring_name[dashes - line - 1] = '\0';
+
+ bb_matched = sscanf(dashes, --- gtt_offset = 0x%08x\n,
+ gtt_offset);
+ if (bb_matched == 1) {
+ igt_assert(strstr(ring_name, expected_ring_name));
+ igt_assert(gtt_offset == expected_offset);
+
+ for (i = 0; i sizeof(batch) / 4; i++) {
+ igt_assert(getline(line, line_size, file)
0);
+ snprintf(expected_line, sizeof(expected_line),
%08x : %08x,
+ 4*i, batch[i]);
+ igt_assert(strstr(line, expected_line));
+ }
+ bb_ok = true;
+ continue;
+ }
+
+ req_matched = sscanf(dashes, --- %d requests\n,
+ requests);
+ if (req_matched == 1) {
+ igt_assert(strstr(ring_name, expected_ring_name));
+ igt_assert(requests == 1);
Bad assumption. You could still have the request from
gem_quiescent_gpu() which may not have been retired before the error
triggers.
H... but I make a first valid gem_execbuf()+gem_sync() before the one that
actually hangs. Shouldn´t that make sure that all previous requests have been
retired?
+
+ igt_assert(getline(line, line_size, file) 0);
+ items = sscanf(line, seqno 0x%08x, emitted %ld, tail
0x%08x\n,
+ seqno, jiffies, tail);
+ igt_assert(items == 3);
Bad. I may change the format. s/may/will/
I still need to make sure I got a valid tail, so I need to know the format and
fail if don´t understand it. Or do you want me to use a different tail, maybe
the ringbuffer one?
+ req_ok = true;
+ continue;
+ }
+
+ ringbuf_matched = sscanf(dashes, --- ringbuffer = 0x%08x\n,
+ gtt_offset);
+ if (ringbuf_matched == 1) {
+ if (!strstr(ring_name, expected_ring_name))
+ continue;
+ igt_assert(req_ok);
+
+ for (i = 0; i tail / 4; i++) {
+ igt_assert(getline(line, line_size, file)
0);
+ items = sscanf(line, %08x : %08x\n,
+ offset, command);
+ igt_assert(items == 2);
+ if ((command 0x1F80) ==
MI_BATCH_BUFFER_START) {
+ igt_assert(getline(line, line_size,
file) 0);
+ items = sscanf(line, %08x : %08x\n,
+ offset,
expected_addr);
+ igt_assert(items == 2);
+ i++;
+ }
+ }
+ igt_assert(expected_addr == expected_offset);
Bad. Some gen encode flags into the BB start address.
ACK, will change.
+ ringbuf_ok = true;
+ continue;
+ }
+
+ if (bb_ok req_ok ringbuf_ok)
+ break;
+ }
+ igt_assert(bb_ok req_ok ringbuf_ok);
+
+ free(line);
+ free(ring_name);
+ close(debug_fd);
+}
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2] tests/gem_error_capture: Initial testcase for error state capture/dump
On Mon, Apr 14, 2014 at 10:01:12AM +, Mateo Lozano, Oscar wrote:
+ requests);
+ if (req_matched == 1) {
+ igt_assert(strstr(ring_name, expected_ring_name));
+ igt_assert(requests == 1);
Bad assumption. You could still have the request from
gem_quiescent_gpu() which may not have been retired before the error
triggers.
H... but I make a first valid gem_execbuf()+gem_sync() before the one
that actually hangs. Shouldn´t that make sure that all previous requests have
been retired?
No, I would not make that assumption about kernel behaviour. The only
thing that it will guarantee is that the last request with that handle
is retired. (In other words, forthcoming bug fixes already break this
assumption.)
+
+ igt_assert(getline(line, line_size, file) 0);
+ items = sscanf(line, seqno 0x%08x, emitted %ld, tail
0x%08x\n,
+ seqno, jiffies, tail);
+ igt_assert(items == 3);
Bad. I may change the format. s/may/will/
I still need to make sure I got a valid tail, so I need to know the format
and fail if don´t understand it. Or do you want me to use a different tail,
maybe the ringbuffer one?
I didn't spot where you used tail. Care to elaborate? I may be able to
suggest an alternative, or we may either code this more defensively or
make the kernel emission easier to use and hopefully more informative
for debugging.
-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 v2 6/6] drm/i915/vlv: Modifying WA 'WaDisableL3Bank2xClockGate for vlv
On Tue, 2014-04-01 at 10:53 +0530, sourab gupta wrote: On Tue, 2014-03-25 at 12:23 +0530, sourab gupta wrote: On Mon, 2014-03-24 at 17:56 +, Lespiau, Damien wrote: On Mon, Mar 24, 2014 at 11:00:07PM +0530, sourab.gu...@intel.com wrote: From: Akash Goel akash.g...@intel.com For disabling L3 clock gating we need to set bit 25 of MMIO register 940c. Earlier this was being done by just writing 1 into bit 25 and resetting all other bits. This patch modifies the routine to read-modify-write of the register, so that the values of other bits are not destroyed. v2: Modifying the comments and the patch commit message (Chris) This patch commit message lacks the most important information: which bit are we setting back to 0 and we shouldn't, and why is that important? We do direct writes to other registers in that function (for instance (MI_ARB_VLV just below). Hi Damien, The reset value of the register is 0x00F80003. Therefore, if we directly set only bit 25 to 1, without caring about other bits, the following reg bits will be affected (bits 1:0, bits 23:19). This doesn't seem to be the case with other regs where we are writing directly (MI_ARB_VLV ) whose default value is 0. So, by this commit we're just trying to set only the bit which we really want to change. Regards, Sourab Hi Damien, Please provide your comments on the above explanation. I'll add more information to the commit message regarding the same, if it is okay. Thanks, Sourab Hi Damien, Waiting for feedback on the patch and the explanation. Can you please let us know if the explained reason is good enough for the patch to be considered. If so, it can be added to the commit message. Regards, Sourab ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2] tests/gem_error_capture: Initial testcase for error state capture/dump
+ requests);
+ if (req_matched == 1) {
+ igt_assert(strstr(ring_name,
expected_ring_name));
+ igt_assert(requests == 1);
Bad assumption. You could still have the request from
gem_quiescent_gpu() which may not have been retired before the error
triggers.
H... but I make a first valid gem_execbuf()+gem_sync() before the
one that actually hangs. Shouldn´t that make sure that all previous requests
have been retired?
No, I would not make that assumption about kernel behaviour. The only thing
that it will guarantee is that the last request with that handle is retired.
(In
other words, forthcoming bug fixes already break this
assumption.)
Ok, then I´ll check all the reported requests (can I at least assume that the
one I am interested in will be the last one? request_list seems to be FIFO...).
+
+ igt_assert(getline(line, line_size, file)
0);
+ items = sscanf(line, seqno 0x%08x, emitted
%ld, tail
0x%08x\n,
+ seqno, jiffies, tail);
+ igt_assert(items == 3);
Bad. I may change the format. s/may/will/
I still need to make sure I got a valid tail, so I need to know the format
and
fail if don´t understand it. Or do you want me to use a different tail, maybe
the
ringbuffer one?
I didn't spot where you used tail. Care to elaborate? I may be able to
suggest an
alternative, or we may either code this more defensively or make the kernel
emission easier to use and hopefully more informative for debugging.
I´m using the request tail to traverse the ring buffer, make sure there is a
MI_BB_START and then our object´s address shortly before that tail. I could use
ring-tail, or I could skip this check altogether (after all, I´m already
checking that the GPU was executing a Batch Buffer, and that the BB had my
magic number on it).
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2] tests/gem_error_capture: Initial testcase for error state capture/dump
On Mon, Apr 14, 2014 at 10:23:20AM +, Mateo Lozano, Oscar wrote:
+ requests);
+ if (req_matched == 1) {
+ igt_assert(strstr(ring_name,
expected_ring_name));
+ igt_assert(requests == 1);
Bad assumption. You could still have the request from
gem_quiescent_gpu() which may not have been retired before the error
triggers.
H... but I make a first valid gem_execbuf()+gem_sync() before the
one that actually hangs. Shouldn´t that make sure that all previous requests
have been retired?
No, I would not make that assumption about kernel behaviour. The only thing
that it will guarantee is that the last request with that handle is
retired. (In
other words, forthcoming bug fixes already break this
assumption.)
Ok, then I´ll check all the reported requests (can I at least assume that the
one I am interested in will be the last one? request_list seems to be
FIFO...).
In general, even that may be dangerous. (But less so if can be sure that
is no batchbuffer injection from the testsuite, and that there are no
other clients, or that the kernel doesn't start having to do its own
w/a.)
+
+ igt_assert(getline(line, line_size, file)
0);
+ items = sscanf(line, seqno 0x%08x, emitted
%ld, tail
0x%08x\n,
+ seqno, jiffies, tail);
+ igt_assert(items == 3);
Bad. I may change the format. s/may/will/
I still need to make sure I got a valid tail, so I need to know the
format and
fail if don´t understand it. Or do you want me to use a different tail,
maybe the
ringbuffer one?
I didn't spot where you used tail. Care to elaborate? I may be able to
suggest an
alternative, or we may either code this more defensively or make the kernel
emission easier to use and hopefully more informative for debugging.
I´m using the request tail to traverse the ring buffer, make sure there is a
MI_BB_START and then our object´s address shortly before that tail. I could
use ring-tail, or I could skip this check altogether (after all, I´m already
checking that the GPU was executing a Batch Buffer, and that the BB had my
magic number on it).
I would add a little more smarts to both the kernel and error-decode.
In the kernel, we can print the guilty request, which you can then use
to confirm that it is yours. That seems to me to be a stronger
validation of gem_error_capture, and a useful bit of information from
hangstats that we do not expose currently.
-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 v2] tests/gem_error_capture: Initial testcase for error state capture/dump
I would add a little more smarts to both the kernel and error-decode. In the kernel, we can print the guilty request, which you can then use to confirm that it is yours. That seems to me to be a stronger validation of gem_error_capture, and a useful bit of information from hangstats that we do not expose currently. That sounds good. I have to add a number of other things to i915_gpu_error as part of the Execlists code, so I´ll add a --- guilty request as well and resubmit this test together with the series. Thanks, Oscar ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] REGRESSION 3.14 i915 warning mouse cursor vanishing
Was using my machine normally, then my mouse cursor vanished. After switching to a VT and back to X11, my cursor came back. But I did notice a nasty trace in dmesg (below). I have a few options specified on my command line related to i915, but these worked fine through 3.13.9: i915.lvds_downclock=1 i915.i915_enable_rc6=7 i915.i915_enable_fbc=1 System is a Lenovo ThinkPad S1 Yoga. lspci: $ sudo lspci -nn 00:00.0 Host bridge [0600]: Intel Corporation Haswell-ULT DRAM Controller [8086:0a04] (rev 0b) 00:02.0 VGA compatible controller [0300]: Intel Corporation Haswell-ULT Integrated Graphics Controller [8086:0a16] (rev 0b) 00:03.0 Audio device [0403]: Intel Corporation Device [8086:0a0c] (rev 0b) 00:14.0 USB controller [0c03]: Intel Corporation Lynx Point-LP USB xHCI HC [8086:9c31] (rev 04) 00:16.0 Communication controller [0780]: Intel Corporation Lynx Point-LP HECI #0 [8086:9c3a] (rev 04) 00:1b.0 Audio device [0403]: Intel Corporation Lynx Point-LP HD Audio Controller [8086:9c20] (rev 04) 00:1c.0 PCI bridge [0604]: Intel Corporation Lynx Point-LP PCI Express Root Port 1 [8086:9c10] (rev e4) 00:1c.2 PCI bridge [0604]: Intel Corporation Lynx Point-LP PCI Express Root Port 3 [8086:9c14] (rev e4) 00:1c.3 PCI bridge [0604]: Intel Corporation Lynx Point-LP PCI Express Root Port 4 [8086:9c16] (rev e4) 00:1d.0 USB controller [0c03]: Intel Corporation Lynx Point-LP USB EHCI #1 [8086:9c26] (rev 04) 00:1f.0 ISA bridge [0601]: Intel Corporation Lynx Point-LP LPC Controller [8086:9c43] (rev 04) 00:1f.2 SATA controller [0106]: Intel Corporation Lynx Point-LP SATA Controller 1 [AHCI mode] [8086:9c03] (rev 04) 00:1f.3 SMBus [0c05]: Intel Corporation Lynx Point-LP SMBus Controller [8086:9c22] (rev 04) 04:00.0 Network controller [0280]: Intel Corporation Wireless 7260 [8086:08b2] (rev 73) 05:00.0 Unassigned class [ff00]: Realtek Semiconductor Co., Ltd. Device [10ec:5227] (rev 01) Let me know what other information would be helpful. I could do a bisection if needed, but I'm hoping the stack traces below trigger an aha moment in somebody. Here's the trace: [ 1703.305960] [ cut here ] [ 1703.305982] WARNING: CPU: 2 PID: 351 at drivers/gpu/drm/i915/intel_uncore.c:453 vlv_flisdsi_write+0x1ea9/0x2ed0 [i915]() [ 1703.305983] Device suspended [ 1703.305984] Modules linked in: usb_storage fuse ctr ccm bnep tun wacom hid_sensor_accel_3d hid_sensor_magn_3d hid_sensor_gyro_3d hid_sensor_als hid_sensor_trigger industrialio_triggered_buffer kfifo_buf hid_sensor_iio_common industrialio hid_sensor_hub joydev hid_multitouch usbhid btusb hid bluetooth 6lowpan_iphc arc4 nls_cp437 vfat fat iwlmvm snd_hda_codec_hdmi x86_pkg_temp_thermal mac80211 intel_powerclamp coretemp iTCO_wdt kvm_intel iTCO_vendor_support kvm crct10dif_pclmul crc32_pclmul crc32c_intel ghash_clmulni_intel aesni_intel aes_x86_64 lrw gf128mul glue_helper ablk_helper cryptd microcode snd_hda_codec_conexant snd_hda_codec_generic wmi iwlwifi psmouse serio_raw i2c_i801 cfg80211 thermal snd_hda_intel tpm_tis tpm snd_hda_codec snd_hwdep snd_pcm thinkpad_acpi nvram battery ac snd_timer intel_smartconnect [ 1703.306011] evdev snd lpc_ich soundcore mfd_core processor usbip_host(C) usbip_core(C) efivarfs ext4 crc16 mbcache jbd2 sd_mod crc_t10dif crct10dif_common ahci libahci xhci_hcd libata ehci_pci ehci_hcd scsi_mod usbcore usb_common i915 video intel_gtt i2c_algo_bit drm_kms_helper drm i2c_core e1000e ptp pps_core ipmi_poweroff ipmi_msghandler button [ 1703.306028] CPU: 2 PID: 351 Comm: X Tainted: G C 3.14.0-1-ec2 #1 [ 1703.306029] Hardware name: LENOVO 20CDCTO1WW/20CDCTO1WW, BIOS GQET34WW (1.14 ) 02/26/2014 [ 1703.306030] 0009 88021f283d50 814ea57f 88021f283d98 [ 1703.306032] 88021f283d88 810653dd 8800d2748000 0004400c [ 1703.306034] 8800d2748028 8800d2748020 74002529 88021f283de8 [ 1703.306036] Call Trace: [ 1703.306037] IRQ [814ea57f] dump_stack+0x45/0x56 [ 1703.306044] [810653dd] warn_slowpath_common+0x7d/0xa0 [ 1703.306046] [8106544c] warn_slowpath_fmt+0x4c/0x50 [ 1703.306050] [810a501d] ? enqueue_task_fair+0x43d/0x550 [ 1703.306055] [a0135d59] vlv_flisdsi_write+0x1ea9/0x2ed0 [i915] [ 1703.306060] [a0136530] vlv_flisdsi_write+0x2680/0x2ed0 [i915] [ 1703.306065] [a00d3a3a] i915_queue_hangcheck+0x129a/0x2f20 [i915] [ 1703.306068] [81099a5c] ? try_to_wake_up+0x28c/0x2a0 [ 1703.306070] [810c1572] handle_irq_event_percpu+0x62/0x1f0 [ 1703.306072] [810c173d] handle_irq_event+0x3d/0x60 [ 1703.306074] [810c44c8] handle_edge_irq+0x108/0x140 [ 1703.306078] [81016b3e] handle_irq+0x1e/0x40 [ 1703.306081] [814fba8f] do_IRQ+0x4f/0xe0 [ 1703.306084] [814f0b2d] common_interrupt+0x6d/0x6d [
[Intel-gfx] [PATCH 0/2] Enable PM Interrupts for BDW
From: Deepak S deepa...@intel.com Added patch to enable PM Interrupts Ben Widawsky (1): drm/i915/bdw: Implement a basic PM interrupt handler Deepak S (1): drm/i915: Enable PM Interrupts target via Display Interface. drivers/gpu/drm/i915/i915_irq.c | 81 +--- drivers/gpu/drm/i915/i915_reg.h | 2 + drivers/gpu/drm/i915/intel_drv.h | 3 +- drivers/gpu/drm/i915/intel_pm.c | 40 +++- 4 files changed, 118 insertions(+), 8 deletions(-) -- 1.8.5.2 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/2] drm/i915/bdw: Implement a basic PM interrupt handler
From: Ben Widawsky benjamin.widaw...@intel.com
Almost all of it is reusable from the existing code. The primary
difference is we need to do even less in the interrupt handler, since
interrupts are not shared in the same way.
The patch is mostly a copy-paste of the existing snb+ code, with updates
to the relevant parts requiring changes to the interrupt handling. As
such it /should/ be relatively trivial. It's highly likely that I missed
some places where I need a gen8 version of the PM interrupts, but it has
become invisible to me by now.
This patch could probably be split into adding the new functions,
followed by actually handling the interrupts. Since the code is
currently disabled (and broken) I think the patch stands better by
itself.
v2: Move the commit about not touching the ringbuffer interrupt to the
snb_* function where it belongs (Rodrigo)
v3: Rebased on Paulo's runtime PM changes
v4: Not well validated, but rebase on
commit 730488b2eddded4497f63f70867b1256cd9e117c
Author: Paulo Zanoni paulo.r.zan...@intel.com
Date: Fri Mar 7 20:12:32 2014 -0300
drm/i915: kill dev_priv-pm.regsave
v5: Rebased on latest code base. (Deepak)
Signed-off-by: Ben Widawsky b...@bwidawsk.net
Conflicts:
drivers/gpu/drm/i915/i915_irq.c
---
drivers/gpu/drm/i915/i915_irq.c | 81 +---
drivers/gpu/drm/i915/i915_reg.h | 1 +
drivers/gpu/drm/i915/intel_drv.h | 3 +-
drivers/gpu/drm/i915/intel_pm.c | 38 ++-
4 files changed, 115 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 7a4d3ae..96c459a 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -248,6 +248,50 @@ static bool ivb_can_enable_err_int(struct drm_device *dev)
return true;
}
+/**
+ * bdw_update_pm_irq - update GT interrupt 2
+ * @dev_priv: driver private
+ * @interrupt_mask: mask of interrupt bits to update
+ * @enabled_irq_mask: mask of interrupt bits to enable
+ *
+ * Copied from the snb function, updated with relevant register offsets
+ */
+static void bdw_update_pm_irq(struct drm_i915_private *dev_priv,
+ uint32_t interrupt_mask,
+ uint32_t enabled_irq_mask)
+{
+ uint32_t new_val;
+
+ assert_spin_locked(dev_priv-irq_lock);
+
+ if (dev_priv-pm.irqs_disabled) {
+ WARN(1, IRQs disabled\n);
+ return;
+ }
+
+ new_val = dev_priv-pm_irq_mask;
+ new_val = ~interrupt_mask;
+ new_val |= (~enabled_irq_mask interrupt_mask);
+
+ if (new_val != dev_priv-pm_irq_mask) {
+ dev_priv-pm_irq_mask = new_val;
+ I915_WRITE(GEN8_GT_IMR(2), I915_READ(GEN8_GT_IMR(2)) |
+ dev_priv-pm_irq_mask);
+ POSTING_READ(GEN8_GT_IMR(2));
+ }
+}
+
+void bdw_enable_pm_irq(struct drm_i915_private *dev_priv, uint32_t mask)
+{
+ bdw_update_pm_irq(dev_priv, mask, mask);
+}
+
+void bdw_disable_pm_irq(struct drm_i915_private *dev_priv, uint32_t mask)
+{
+ bdw_update_pm_irq(dev_priv, mask, 0);
+}
+
+
static bool cpt_can_enable_serr_int(struct drm_device *dev)
{
struct drm_i915_private *dev_priv = dev-dev_private;
@@ -1126,13 +1170,17 @@ static void gen6_pm_rps_work(struct work_struct *work)
spin_lock_irq(dev_priv-irq_lock);
pm_iir = dev_priv-rps.pm_iir;
dev_priv-rps.pm_iir = 0;
- /* Make sure not to corrupt PMIMR state used by ringbuffer code */
- snb_enable_pm_irq(dev_priv, dev_priv-pm_rps_events);
+ if (IS_BROADWELL(dev_priv-dev))
+ bdw_enable_pm_irq(dev_priv, dev_priv-pm_rps_events);
+ else {
+ /* Make sure not to corrupt PMIMR state used by ringbuffer */
+ snb_enable_pm_irq(dev_priv, dev_priv-pm_rps_events);
+ /* Make sure we didn't queue anything we're not going to
+* process. */
+ WARN_ON(pm_iir ~dev_priv-pm_rps_events);
+ }
spin_unlock_irq(dev_priv-irq_lock);
- /* Make sure we didn't queue anything we're not going to process. */
- WARN_ON(pm_iir ~dev_priv-pm_rps_events);
-
if ((pm_iir dev_priv-pm_rps_events) == 0)
return;
@@ -1324,6 +1372,19 @@ static void snb_gt_irq_handler(struct drm_device *dev,
ivybridge_parity_error_irq_handler(dev, gt_iir);
}
+static void gen8_rps_irq_handler(struct drm_i915_private *dev_priv, u32 pm_iir)
+{
+ if ((pm_iir dev_priv-pm_rps_events) == 0)
+ return;
+
+ spin_lock(dev_priv-irq_lock);
+ dev_priv-rps.pm_iir |= pm_iir dev_priv-pm_rps_events;
+ bdw_disable_pm_irq(dev_priv, pm_iir dev_priv-pm_rps_events);
+ spin_unlock(dev_priv-irq_lock);
+
+ queue_work(dev_priv-wq, dev_priv-rps.work);
+}
+
static irqreturn_t gen8_gt_irq_handler(struct drm_device *dev,
[Intel-gfx] [PATCH 2/2] drm/i915: Enable PM Interrupts target via Display Interface.
From: Deepak S deepa...@intel.com
In BDW, Apart from unmasking up/down threshold interrupts. we need
to umask bit 32 of PM_INTRMASK to route interrupts to target via Display
Interface.
Signed-off-by: Deepak S deepa...@intel.com
---
drivers/gpu/drm/i915/i915_reg.h | 1 +
drivers/gpu/drm/i915/intel_pm.c | 2 ++
2 files changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index c2dd436..8c7841b 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -5105,6 +5105,7 @@ enum punit_power_well {
#define GEN6_RC6p_THRESHOLD0xA0BC
#define GEN6_RC6pp_THRESHOLD 0xA0C0
#define GEN6_PMINTRMSK 0xA168
+#define GEN8_PMINTR_REDIRECT_TO_NON_DISP 0x7FFF
#define GEN6_PMISR 0x44020
#define GEN6_PMIMR 0x44024 /* rps_lock */
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 27b64ab..6b123cd 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -3066,6 +3066,8 @@ static u32 gen6_rps_pm_mask(struct drm_i915_private
*dev_priv, u8 val)
if (INTEL_INFO(dev_priv-dev)-gen = 7 !IS_HASWELL(dev_priv-dev))
mask |= GEN6_PM_RP_UP_EI_EXPIRED;
+ mask = GEN8_PMINTR_REDIRECT_TO_NON_DISP;
+
return ~mask;
}
--
1.8.5.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 00/25] vlv: add support for RPM
For a description of this patchset see the previous cover letter [1]. Tested on HSW (non-ULT), VLV with igt/kms_flip and pm_pc8. v2: - addressed comments about getting the proper runtime PM references in debugfs (Daniel, Paulo, Ville) - disable RPM if RC6 is disabled for all platforms, not just VLV (Daniel) - refactored the runtime PM callbacks pulling platform independent teardown/re-init code to the generic runtime suspend/resume callbacks (Daniel) - fixed a couple of issues I bumped into while checking the RC6/RPS and the GPU reset error capturing path [1] http://lists.freedesktop.org/archives/intel-gfx/2014-April/043208.html Imre Deak (25): drm/i915: vlv: clean up GTLC wake control/status register macros drm/i915: vlv: clear master interrupt flag when disabling interrupts drm/i915: vlv: add RC6 residency counters drm/i915: fix the RC6 status debug print drm/i915: remove the i915_dpio debugfs entry drm/i915: get a runtime PM ref for debugfs entries where needed drm/i915: move getting struct_mutex lower in the callstack during GPU reset drm/i915: get a runtime PM ref for the deferred GT powersave enabling drm/i915: get a runtime PM ref for the deferred GPU reset work drm/i915: gen2: move error capture of IER to its correct place drm/i915: add missing error capturing of the PIPESTAT reg drm/i915: vlv: check port power domain instead of only D0 for eDP VDD on drm/i915: fix unbalanced GT powersave enable / disable calls drm/i915: sanitize enable_rc6 option drm/i915: disable runtime PM if RC6 is disabled drm/i915: make runtime PM interrupt enable/disable platform independent drm/i915: factor out gen6_update_ring_freq drm/i915: make runtime PM swizzling/ring_freq init platform independent drm/i915: reinit GT power save during resume drm/i915: vlv: setup RPS min/max frequencies once during init time drm/i915: vlv: factor out vlv_force_gfx_clock drm/i915: vlv: increase timeout when forcing on the GFX clock drm/i915: add various missing GTI/Gunit register definitions drm/i915: propagate the error code from runtime PM callbacks drm/i915: vlv: add runtime PM support drivers/gpu/drm/i915/i915_debugfs.c | 63 ++--- drivers/gpu/drm/i915/i915_dma.c | 8 +- drivers/gpu/drm/i915/i915_drv.c | 452 +++--- drivers/gpu/drm/i915/i915_drv.h | 64 - drivers/gpu/drm/i915/i915_gem.c | 5 +- drivers/gpu/drm/i915/i915_gpu_error.c | 11 +- drivers/gpu/drm/i915/i915_irq.c | 23 +- drivers/gpu/drm/i915/i915_reg.h | 56 - drivers/gpu/drm/i915/i915_sysfs.c | 4 + drivers/gpu/drm/i915/intel_display.c | 9 +- drivers/gpu/drm/i915/intel_dp.c | 6 +- drivers/gpu/drm/i915/intel_drv.h | 2 + drivers/gpu/drm/i915/intel_pm.c | 185 ++ 13 files changed, 737 insertions(+), 151 deletions(-) -- 1.8.4 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 01/25] drm/i915: vlv: clean up GTLC wake control/status register macros
These will be needed by the upcoming VLV RPM helpers.
Signed-off-by: Imre Deak imre.d...@intel.com
---
drivers/gpu/drm/i915/i915_gem.c | 5 +++--
drivers/gpu/drm/i915/i915_reg.h | 10 --
2 files changed, 11 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 8f5ffab..af8493a 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -4459,8 +4459,9 @@ int i915_gem_init(struct drm_device *dev)
if (IS_VALLEYVIEW(dev)) {
/* VLVA0 (potential hack), BIOS isn't actually waking us */
- I915_WRITE(VLV_GTLC_WAKE_CTRL, 1);
- if (wait_for((I915_READ(VLV_GTLC_PW_STATUS) 1) == 1, 10))
+ I915_WRITE(VLV_GTLC_WAKE_CTRL, VLV_GTLC_ALLOWWAKEREQ);
+ if (wait_for((I915_READ(VLV_GTLC_PW_STATUS)
+ VLV_GTLC_ALLOWWAKEACK), 10))
DRM_DEBUG_DRIVER(allow wake ack timed out\n);
}
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 8f84555..ee768f0 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -4996,9 +4996,15 @@ enum punit_power_well {
#define FORCEWAKE_ACK_HSW 0x130044
#define FORCEWAKE_ACK 0x130090
#define VLV_GTLC_WAKE_CTRL0x130090
+#define VLV_GTLC_RENDER_CTX_EXISTS (1 25)
+#define VLV_GTLC_MEDIA_CTX_EXISTS(1 24)
+#define VLV_GTLC_ALLOWWAKEREQ(1 0)
+
#define VLV_GTLC_PW_STATUS0x130094
-#define VLV_GTLC_PW_RENDER_STATUS_MASK 0x80
-#define VLV_GTLC_PW_MEDIA_STATUS_MASK 0x20
+#define VLV_GTLC_ALLOWWAKEACK(1 0)
+#define VLV_GTLC_ALLOWWAKEERR(1 1)
+#define VLV_GTLC_PW_MEDIA_STATUS_MASK(1 5)
+#define VLV_GTLC_PW_RENDER_STATUS_MASK (1 7)
#define FORCEWAKE_MT 0xa188 /* multi-threaded */
#define FORCEWAKE_KERNEL 0x1
#define FORCEWAKE_USER 0x2
--
1.8.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 03/25] drm/i915: vlv: add RC6 residency counters
Signed-off-by: Imre Deak imre.d...@intel.com
---
drivers/gpu/drm/i915/i915_debugfs.c | 5 +
drivers/gpu/drm/i915/i915_reg.h | 3 +++
2 files changed, 8 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index 1e83ae4..02f1b39 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -1261,6 +1261,11 @@ static int vlv_drpc_info(struct seq_file *m)
(I915_READ(VLV_GTLC_PW_STATUS)
VLV_GTLC_PW_MEDIA_STATUS_MASK) ? Up : Down);
+ seq_printf(m, Render RC6 residency since boot: %u\n,
+ I915_READ(VLV_GT_RENDER_RC6));
+ seq_printf(m, Media RC6 residency since boot: %u\n,
+ I915_READ(VLV_GT_MEDIA_RC6));
+
spin_lock_irq(dev_priv-uncore.lock);
fw_rendercount = dev_priv-uncore.fw_rendercount;
fw_mediacount = dev_priv-uncore.fw_mediacount;
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index ee768f0..f183746 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -5136,6 +5136,9 @@ enum punit_power_well {
#define VLV_MEDIA_RC6_COUNT_EN (11)
#define VLV_RENDER_RC6_COUNT_EN (10)
#define GEN6_GT_GFX_RC60x138108
+#define VLV_GT_RENDER_RC6 0x138108
+#define VLV_GT_MEDIA_RC6 0x13810C
+
#define GEN6_GT_GFX_RC6p 0x13810C
#define GEN6_GT_GFX_RC6pp 0x138110
--
1.8.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 04/25] drm/i915: fix the RC6 status debug print
The parsing was incorrect for ILK and VLV.
Signed-off-by: Imre Deak imre.d...@intel.com
---
drivers/gpu/drm/i915/intel_pm.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 75c1c76..4ebb93c 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -3250,6 +3250,12 @@ static void valleyview_disable_rps(struct drm_device
*dev)
static void intel_print_rc6_info(struct drm_device *dev, u32 mode)
{
+ if (IS_VALLEYVIEW(dev)) {
+ if (mode (GEN7_RC_CTL_TO_MODE | GEN6_RC_CTL_EI_MODE(1)))
+ mode = GEN6_RC_CTL_RC6_ENABLE;
+ else
+ mode = 0;
+ }
DRM_INFO(Enabling RC6 states: RC6 %s, RC6p %s, RC6pp %s\n,
(mode GEN6_RC_CTL_RC6_ENABLE) ? on : off,
(mode GEN6_RC_CTL_RC6p_ENABLE) ? on : off,
@@ -3876,7 +3882,7 @@ static void ironlake_enable_rc6(struct drm_device *dev)
I915_WRITE(PWRCTXA, i915_gem_obj_ggtt_offset(dev_priv-ips.pwrctx) |
PWRCTX_EN);
I915_WRITE(RSTDBYCTL, I915_READ(RSTDBYCTL) ~RCX_SW_EXIT);
- intel_print_rc6_info(dev, INTEL_RC6_ENABLE);
+ intel_print_rc6_info(dev, GEN6_RC_CTL_RC6_ENABLE);
}
static unsigned long intel_pxfreq(u32 vidfreq)
--
1.8.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 05/25] drm/i915: remove the i915_dpio debugfs entry
There are igt tools that can read/write the DPIO registers, so having a
debugfs entry for only some of those registers is somewhat arbitrary /
redundant. Remove it.
v2:
- instead of fixing the entry by taking a power domain reference around
the register accesses, remove the entry (Ville)
Signed-off-by: Imre Deak imre.d...@intel.com
---
drivers/gpu/drm/i915/i915_debugfs.c | 48 -
1 file changed, 48 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index 02f1b39..4c785a2 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -1903,53 +1903,6 @@ static int i915_ppgtt_info(struct seq_file *m, void
*data)
return 0;
}
-static int i915_dpio_info(struct seq_file *m, void *data)
-{
- struct drm_info_node *node = (struct drm_info_node *) m-private;
- struct drm_device *dev = node-minor-dev;
- struct drm_i915_private *dev_priv = dev-dev_private;
- int ret;
-
-
- if (!IS_VALLEYVIEW(dev)) {
- seq_puts(m, unsupported\n);
- return 0;
- }
-
- ret = mutex_lock_interruptible(dev_priv-dpio_lock);
- if (ret)
- return ret;
-
- seq_printf(m, DPIO_CTL: 0x%08x\n, I915_READ(DPIO_CTL));
-
- seq_printf(m, DPIO PLL DW3 CH0 : 0x%08x\n,
- vlv_dpio_read(dev_priv, PIPE_A, VLV_PLL_DW3(0)));
- seq_printf(m, DPIO PLL DW3 CH1: 0x%08x\n,
- vlv_dpio_read(dev_priv, PIPE_A, VLV_PLL_DW3(1)));
-
- seq_printf(m, DPIO PLL DW5 CH0: 0x%08x\n,
- vlv_dpio_read(dev_priv, PIPE_A, VLV_PLL_DW5(0)));
- seq_printf(m, DPIO PLL DW5 CH1: 0x%08x\n,
- vlv_dpio_read(dev_priv, PIPE_A, VLV_PLL_DW5(1)));
-
- seq_printf(m, DPIO PLL DW7 CH0: 0x%08x\n,
- vlv_dpio_read(dev_priv, PIPE_A, VLV_PLL_DW7(0)));
- seq_printf(m, DPIO PLL DW7 CH1: 0x%08x\n,
- vlv_dpio_read(dev_priv, PIPE_A, VLV_PLL_DW7(1)));
-
- seq_printf(m, DPIO PLL DW10 CH0: 0x%08x\n,
- vlv_dpio_read(dev_priv, PIPE_A, VLV_PLL_DW10(0)));
- seq_printf(m, DPIO PLL DW10 CH1: 0x%08x\n,
- vlv_dpio_read(dev_priv, PIPE_A, VLV_PLL_DW10(1)));
-
- seq_printf(m, DPIO_FASTCLK_DISABLE: 0x%08x\n,
- vlv_dpio_read(dev_priv, PIPE_A, VLV_CMN_DW0));
-
- mutex_unlock(dev_priv-dpio_lock);
-
- return 0;
-}
-
static int i915_llc(struct seq_file *m, void *data)
{
struct drm_info_node *node = (struct drm_info_node *) m-private;
@@ -3808,7 +3761,6 @@ static const struct drm_info_list i915_debugfs_list[] = {
{i915_gen6_forcewake_count, i915_gen6_forcewake_count_info, 0},
{i915_swizzle_info, i915_swizzle_info, 0},
{i915_ppgtt_info, i915_ppgtt_info, 0},
- {i915_dpio, i915_dpio_info, 0},
{i915_llc, i915_llc, 0},
{i915_edp_psr_status, i915_edp_psr_status, 0},
{i915_sink_crc_eDP1, i915_sink_crc, 0},
--
1.8.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 10/25] drm/i915: gen2: move error capture of IER to its correct place
While checking the error capture path I noticed that this register is
read twice for GEN2, so fix this and also move the read where it's done
for other platforms.
Signed-off-by: Imre Deak imre.d...@intel.com
---
drivers/gpu/drm/i915/i915_gpu_error.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gpu_error.c
b/drivers/gpu/drm/i915/i915_gpu_error.c
index 4865ade..ba79b59 100644
--- a/drivers/gpu/drm/i915/i915_gpu_error.c
+++ b/drivers/gpu/drm/i915/i915_gpu_error.c
@@ -1053,9 +1053,6 @@ static void i915_capture_reg_state(struct
drm_i915_private *dev_priv,
error-gfx_mode = I915_READ(GFX_MODE);
}
- if (IS_GEN2(dev))
- error-ier = I915_READ16(IER);
-
/* 2: Registers which belong to multiple generations */
if (INTEL_INFO(dev)-gen = 7)
error-forcewake = I915_READ(FORCEWAKE_MT);
@@ -1079,7 +1076,10 @@ static void i915_capture_reg_state(struct
drm_i915_private *dev_priv,
if (HAS_PCH_SPLIT(dev))
error-ier = I915_READ(DEIER) | I915_READ(GTIER);
else {
- error-ier = I915_READ(IER);
+ if (IS_GEN2(dev))
+ error-ier = I915_READ16(IER);
+ else
+ error-ier = I915_READ(IER);
for_each_pipe(pipe)
error-pipestat[pipe] = I915_READ(PIPESTAT(pipe));
}
--
1.8.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 07/25] drm/i915: move getting struct_mutex lower in the callstack during GPU reset
Getting struct_mutex around the whole intel_enable_gt_powersave()
function is not necessary, since it's only needed for the ILK path
therein.
This will make intel_enable_gt_powersave() useable on the RPM resume
path for =GEN6 (added in an upcoming patch to reset the RPS state
during RPM resume), where we can't (and need not) get this mutex.
Signed-off-by: Imre Deak imre.d...@intel.com
---
drivers/gpu/drm/i915/i915_drv.c | 5 +
drivers/gpu/drm/i915/intel_pm.c | 2 ++
2 files changed, 3 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 5d8250f..a821608 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -753,11 +753,8 @@ int i915_reset(struct drm_device *dev)
* reset and the re-install of drm irq. Skip for ironlake per
* previous concerns that it doesn't respond well to some forms
* of re-init after reset. */
- if (INTEL_INFO(dev)-gen 5) {
- mutex_lock(dev-struct_mutex);
+ if (INTEL_INFO(dev)-gen 5)
intel_enable_gt_powersave(dev);
- mutex_unlock(dev-struct_mutex);
- }
intel_hpd_init(dev);
} else {
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 4ebb93c..e5b9f08 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -4556,9 +4556,11 @@ void intel_enable_gt_powersave(struct drm_device *dev)
struct drm_i915_private *dev_priv = dev-dev_private;
if (IS_IRONLAKE_M(dev)) {
+ mutex_lock(dev-struct_mutex);
ironlake_enable_drps(dev);
ironlake_enable_rc6(dev);
intel_init_emon(dev);
+ mutex_unlock(dev-struct_mutex);
} else if (IS_GEN6(dev) || IS_GEN7(dev)) {
/*
* PCU communication is slow and this doesn't need to be
--
1.8.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 11/25] drm/i915: add missing error capturing of the PIPESTAT reg
While checking the error capture path I noticed that we lacked the
power domain-on check for PIPESTAT so fix this by moving that to where
the rest of pipe registers are captured.
The move also revealed that we actually don't include this register in
the error report, so fix that too.
Signed-off-by: Imre Deak imre.d...@intel.com
---
drivers/gpu/drm/i915/i915_drv.h | 1 -
drivers/gpu/drm/i915/i915_gpu_error.c | 3 ---
drivers/gpu/drm/i915/intel_display.c | 3 +++
3 files changed, 3 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 7d6acb4..5254f4b 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -325,7 +325,6 @@ struct drm_i915_error_state {
u32 gab_ctl;
u32 gfx_mode;
u32 extra_instdone[I915_NUM_INSTDONE_REG];
- u32 pipestat[I915_MAX_PIPES];
u64 fence[I915_MAX_NUM_FENCES];
struct intel_overlay_error_state *overlay;
struct intel_display_error_state *display;
diff --git a/drivers/gpu/drm/i915/i915_gpu_error.c
b/drivers/gpu/drm/i915/i915_gpu_error.c
index ba79b59..7b5cc08 100644
--- a/drivers/gpu/drm/i915/i915_gpu_error.c
+++ b/drivers/gpu/drm/i915/i915_gpu_error.c
@@ -1028,7 +1028,6 @@ static void i915_capture_reg_state(struct
drm_i915_private *dev_priv,
struct drm_i915_error_state *error)
{
struct drm_device *dev = dev_priv-dev;
- int pipe;
/* General organization
* 1. Registers specific to a single generation
@@ -1080,8 +1079,6 @@ static void i915_capture_reg_state(struct
drm_i915_private *dev_priv,
error-ier = I915_READ16(IER);
else
error-ier = I915_READ(IER);
- for_each_pipe(pipe)
- error-pipestat[pipe] = I915_READ(PIPESTAT(pipe));
}
/* 4: Everything else */
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 1390ab5..4d8d875 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -11925,6 +11925,7 @@ struct intel_display_error_state {
struct intel_pipe_error_state {
bool power_domain_on;
u32 source;
+ u32 stat;
} pipe[I915_MAX_PIPES];
struct intel_plane_error_state {
@@ -12006,6 +12007,7 @@ intel_display_capture_error_state(struct drm_device
*dev)
}
error-pipe[i].source = I915_READ(PIPESRC(i));
+ error-pipe[i].stat = I915_READ(PIPESTAT(i));
}
error-num_transcoders = INTEL_INFO(dev)-num_pipes;
@@ -12056,6 +12058,7 @@ intel_display_print_error_state(struct
drm_i915_error_state_buf *m,
err_printf(m, Power: %s\n,
error-pipe[i].power_domain_on ? on : off);
err_printf(m, SRC: %08x\n, error-pipe[i].source);
+ err_printf(m, STAT: %08x\n, error-pipe[i].stat);
err_printf(m, Plane [%d]:\n, i);
err_printf(m, CNTR: %08x\n, error-plane[i].control);
--
1.8.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 14/25] drm/i915: sanitize enable_rc6 option
Atm, an invalid enable_rc6 module option will be silently ignored, so
emit an info message about it. Doing an early sanitization we can also
reuse intel_enable_rc6() in a follow-up patch to see if RC6 is actually
enabled. Currently the caller would have to filter a non-zero return
value based on the platform we are running on. For example on VLV with
i915.enable_rc6 set to 2, RC6 won't be enabled but atm
intel_enable_rc6() would still return 2 in this case.
Signed-off-by: Imre Deak imre.d...@intel.com
---
drivers/gpu/drm/i915/intel_pm.c | 27 ---
1 file changed, 24 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index a56f6b1..89fe0a7 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -3262,15 +3262,29 @@ static void intel_print_rc6_info(struct drm_device
*dev, u32 mode)
(mode GEN6_RC_CTL_RC6pp_ENABLE) ? on : off);
}
-int intel_enable_rc6(const struct drm_device *dev)
+static int sanitize_rc6_option(const struct drm_device *dev, int enable_rc6)
{
/* No RC6 before Ironlake */
if (INTEL_INFO(dev)-gen 5)
return 0;
/* Respect the kernel parameter if it is set */
- if (i915.enable_rc6 = 0)
- return i915.enable_rc6;
+ if (enable_rc6 = 0) {
+ int mask = 0;
+
+ if (IS_BROADWELL(dev) || IS_HASWELL(dev) ||
+ IS_VALLEYVIEW(dev) || IS_IRONLAKE_M(dev))
+ mask = INTEL_RC6_ENABLE;
+ else if (INTEL_INFO(dev)-gen = 6)
+ mask = INTEL_RC6_ENABLE | INTEL_RC6p_ENABLE |
+ INTEL_RC6pp_ENABLE;
+
+ if ((enable_rc6 mask) != enable_rc6)
+ DRM_INFO(Adjusting RC6 mask to %d (requested %d, valid
%d)\n,
+enable_rc6, enable_rc6 mask, mask);
+
+ return enable_rc6 mask;
+ }
/* Disable RC6 on Ironlake */
if (INTEL_INFO(dev)-gen == 5)
@@ -3282,6 +3296,11 @@ int intel_enable_rc6(const struct drm_device *dev)
return INTEL_RC6_ENABLE;
}
+int intel_enable_rc6(const struct drm_device *dev)
+{
+ return i915.enable_rc6;
+}
+
static void gen6_enable_rps_interrupts(struct drm_device *dev)
{
struct drm_i915_private *dev_priv = dev-dev_private;
@@ -4496,6 +4515,8 @@ static void intel_init_emon(struct drm_device *dev)
void intel_init_gt_powersave(struct drm_device *dev)
{
+ i915.enable_rc6 = sanitize_rc6_option(dev, i915.enable_rc6);
+
if (IS_VALLEYVIEW(dev))
valleyview_setup_pctx(dev);
}
--
1.8.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 06/25] drm/i915: get a runtime PM ref for debugfs entries where needed
These debugfs entries access registers that need the D0 power state so
get an RPM ref for them.
v2:
- for all these entries we only need D0 state, so get only an RPM ref,
not a power domain ref (Daniel, Paulo)
- the dpio entry is not an issue any more as it got removed (Ville)
- restore commit message from v1 (Paulo)
Signed-off-by: Imre Deak imre.d...@intel.com
---
drivers/gpu/drm/i915/i915_debugfs.c | 10 ++
drivers/gpu/drm/i915/i915_sysfs.c | 4
2 files changed, 14 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index 4c785a2..cad175c 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -1239,9 +1239,13 @@ static int vlv_drpc_info(struct seq_file *m)
u32 rpmodectl1, rcctl1;
unsigned fw_rendercount = 0, fw_mediacount = 0;
+ intel_runtime_pm_get(dev_priv);
+
rpmodectl1 = I915_READ(GEN6_RP_CONTROL);
rcctl1 = I915_READ(GEN6_RC_CONTROL);
+ intel_runtime_pm_put(dev_priv);
+
seq_printf(m, Video Turbo Mode: %s\n,
yesno(rpmodectl1 GEN6_RP_MEDIA_TURBO));
seq_printf(m, Turbo enabled: %s\n,
@@ -3257,9 +3261,15 @@ static int
i915_wedged_set(void *data, u64 val)
{
struct drm_device *dev = data;
+ struct drm_i915_private *dev_priv = dev-dev_private;
+
+ intel_runtime_pm_get(dev_priv);
i915_handle_error(dev, val,
Manually setting wedged to %llu, val);
+
+ intel_runtime_pm_put(dev_priv);
+
return 0;
}
diff --git a/drivers/gpu/drm/i915/i915_sysfs.c
b/drivers/gpu/drm/i915/i915_sysfs.c
index 9c57029..3620997 100644
--- a/drivers/gpu/drm/i915/i915_sysfs.c
+++ b/drivers/gpu/drm/i915/i915_sysfs.c
@@ -263,6 +263,8 @@ static ssize_t gt_cur_freq_mhz_show(struct device *kdev,
flush_delayed_work(dev_priv-rps.delayed_resume_work);
+ intel_runtime_pm_get(dev_priv);
+
mutex_lock(dev_priv-rps.hw_lock);
if (IS_VALLEYVIEW(dev_priv-dev)) {
u32 freq;
@@ -273,6 +275,8 @@ static ssize_t gt_cur_freq_mhz_show(struct device *kdev,
}
mutex_unlock(dev_priv-rps.hw_lock);
+ intel_runtime_pm_put(dev_priv);
+
return snprintf(buf, PAGE_SIZE, %d\n, ret);
}
--
1.8.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 12/25] drm/i915: vlv: check port power domain instead of only D0 for eDP VDD on
Some platforms need additional power domains to be on in addition to the
device D0 state to access the panel registers.
Suggested by Daniel.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=76987
Signed-off-by: Imre Deak imre.d...@intel.com
---
drivers/gpu/drm/i915/intel_dp.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index b50b170..d283ce2 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -313,8 +313,12 @@ static bool edp_have_panel_vdd(struct intel_dp *intel_dp)
{
struct drm_device *dev = intel_dp_to_dev(intel_dp);
struct drm_i915_private *dev_priv = dev-dev_private;
+ struct intel_digital_port *intel_dig_port = dp_to_dig_port(intel_dp);
+ struct intel_encoder *intel_encoder = intel_dig_port-base;
+ enum intel_display_power_domain power_domain;
- return !dev_priv-pm.suspended
+ power_domain = intel_display_port_power_domain(intel_encoder);
+ return intel_display_power_enabled(dev_priv, power_domain)
(I915_READ(_pp_ctrl_reg(intel_dp)) EDP_FORCE_VDD) != 0;
}
--
1.8.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 09/25] drm/i915: get a runtime PM ref for the deferred GPU reset work
Atm we can end up in the GPU reset deferred work in D3 state if the last runtime PM reference is dropped between detecting a hang/scheduling the work and executing the work. At least one such case I could trigger is the simulated reset via the i915_wedged debugfs entry. Fix this by disabling RPM before scheduling the work until the end of the work. v2: - Instead of getting/putting the RPM reference in the reset work itself, get it already before scheduling the work. By this we also prevent going to D3 before the work gets to run, in addition to making sure that we run the work itself in D0. (Ville, Daniel) Signed-off-by: Imre Deak imre.d...@intel.com --- drivers/gpu/drm/i915/i915_dma.c | 8 +++- drivers/gpu/drm/i915/i915_irq.c | 21 - 2 files changed, 27 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c index 0b38f88..6398280 100644 --- a/drivers/gpu/drm/i915/i915_dma.c +++ b/drivers/gpu/drm/i915/i915_dma.c @@ -1823,7 +1823,13 @@ int i915_driver_unload(struct drm_device *dev) /* Free error state after interrupts are fully disabled. */ del_timer_sync(dev_priv-gpu_error.hangcheck_timer); - cancel_work_sync(dev_priv-gpu_error.work); + if (!cancel_work_sync(dev_priv-gpu_error.work)) + /* +* The following won't make any difference in the PM state, +* since RPM is disabled already, but do it still for +* consistency. +*/ + intel_runtime_pm_put(dev_priv); i915_destroy_error_state(dev); if (dev-pdev-msi_enabled) diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c index a651d0d..5e079d8 100644 --- a/drivers/gpu/drm/i915/i915_irq.c +++ b/drivers/gpu/drm/i915/i915_irq.c @@ -2210,6 +2210,9 @@ static void i915_error_work_func(struct work_struct *work) */ i915_error_wake_up(dev_priv, true); } + + /* Drop the ref we took when scheduling this work. */ + intel_runtime_pm_put(dev_priv); } static void i915_report_and_clear_eir(struct drm_device *dev) @@ -2353,8 +2356,24 @@ void i915_handle_error(struct drm_device *dev, bool wedged, * state of outstanding pagelips). Hence it must not be run on our own * dev-priv-wq work queue for otherwise the flush_work in the pageflip * code will deadlock. +* +* It's guaranteed that here we are in D0 state, since we can only get +* here via one of the following paths: +* - From an IRQ handler's error detection. - The driver must make +* sure that IRQs are unmasked only while holding an RPM ref. +* - From hang-check due to a blocked request. - The request holds an +* RPM ref, that's only released in i915_gpu_idle() which in turn +* won't be called until the request is finished. +* - From hang-check due to a flip hang. - We have an RPM ref because +* of the active modeset. +* - From debugfs i915_wedged_set(). - The caller takes an explicit +* RPM ref. +* Take here an atomic RPM ref still to make sure that we don't +* re-enter D3 until the error work gets to run and completes the +* reset. */ - schedule_work(dev_priv-gpu_error.work); + if (schedule_work(dev_priv-gpu_error.work)) + intel_runtime_pm_get_noresume(dev_priv); } static void __always_unused i915_pageflip_stall_check(struct drm_device *dev, int pipe) -- 1.8.4 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 13/25] drm/i915: fix unbalanced GT powersave enable / disable calls
Atm, we call intel_gt_powersave_enable() for GEN6 and GEN7 but disable
it for everything starting from GEN6. This is a problem in case of BDW.
Since I don't have a BDW to test if RC6 works properly, just keep it
disabled for now and fix only the disable function.
Signed-off-by: Imre Deak imre.d...@intel.com
---
drivers/gpu/drm/i915/intel_pm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 0e8b263..a56f6b1 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -4516,7 +4516,7 @@ void intel_disable_gt_powersave(struct drm_device *dev)
if (IS_IRONLAKE_M(dev)) {
ironlake_disable_drps(dev);
ironlake_disable_rc6(dev);
- } else if (INTEL_INFO(dev)-gen = 6) {
+ } else if (IS_GEN6(dev) || IS_GEN7(dev)) {
cancel_delayed_work_sync(dev_priv-rps.delayed_resume_work);
cancel_work_sync(dev_priv-rps.work);
mutex_lock(dev_priv-rps.hw_lock);
--
1.8.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 19/25] drm/i915: reinit GT power save during resume
Signed-off-by: Imre Deak imre.d...@intel.com --- drivers/gpu/drm/i915/i915_drv.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c index b87109c..1f88917 100644 --- a/drivers/gpu/drm/i915/i915_drv.c +++ b/drivers/gpu/drm/i915/i915_drv.c @@ -920,6 +920,7 @@ static int intel_runtime_suspend(struct device *device) DRM_DEBUG_KMS(Suspending device\n); intel_runtime_pm_disable_interrupts(dev); + cancel_work_sync(dev_priv-rps.work); if (IS_GEN6(dev)) ; @@ -968,6 +969,7 @@ static int intel_runtime_resume(struct device *device) i915_gem_init_swizzling(dev); gen6_update_ring_freq(dev); + intel_reset_gt_powersave(dev); intel_runtime_pm_restore_interrupts(dev); -- 1.8.4 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 23/25] drm/i915: add various missing GTI/Gunit register definitions
Needed by the VLV S0ix context save/restore helpers.
Signed-off-by: Imre Deak imre.d...@intel.com
---
drivers/gpu/drm/i915/i915_reg.h | 43 -
1 file changed, 42 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index f183746..cba0afd 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -92,6 +92,9 @@
#define GEN6_MBC_SNPCR_LOW (221)
#define GEN6_MBC_SNPCR_MIN (321) /* only 1/16th of the cache is shared */
+#define GEN7_G3DCTL0x9024
+#define GEN7_GSCKGCTL 0x9028
+
#define GEN6_MBCTL 0x0907c
#define GEN6_MBCTL_ENABLE_BOOT_FETCH (1 4)
#define GEN6_MBCTL_CTX_FETCH_NEEDED (1 3)
@@ -785,9 +788,20 @@ enum punit_power_well {
#define RING_MAX_IDLE(base)((base)+0x54)
#define RING_HWS_PGA(base) ((base)+0x80)
#define RING_HWS_PGA_GEN6(base)((base)+0x2080)
-#define ARB_MODE 0x04030
+
+#define GEN7_WR_WATERMARK 0x4028
+#define GEN7_GFX_PRIO_CTRL 0x402C
+#define ARB_MODE 0x4030
#define ARB_MODE_SWIZZLE_SNB (14)
#define ARB_MODE_SWIZZLE_IVB (15)
+#define GEN7_GFX_PEND_TLB0 0x4034
+#define GEN7_GFX_PEND_TLB1 0x4038
+/* L3, CVS, ZTLB, RCC, CASC LRA min, max values */
+#define GEN7_LRA_LIMITS_BASE 0x403C
+#define GEN7_LRA_LIMITS_REG_NUM13
+#define GEN7_MEDIA_MAX_REQ_COUNT 0x4070
+#define GEN7_GFX_MAX_REQ_COUNT 0x4074
+
#define GAMTARBMODE0x04a08
#define ARB_MODE_BWGTLB_DISABLE (19)
#define ARB_MODE_SWIZZLE_BDW (11)
@@ -822,6 +836,9 @@ enum punit_power_well {
#define RING_WAIT_I8XX (10) /* gen2, PRBx_HEAD */
#define RING_WAIT(111) /* gen3+, PRBx_CTL */
#define RING_WAIT_SEMAPHORE (110) /* gen6+ */
+
+#define GEN7_TLB_RD_ADDR 0x4700
+
#if 0
#define PRB0_TAIL 0x02030
#define PRB0_HEAD 0x02034
@@ -948,6 +965,8 @@ enum punit_power_well {
#define VLV_DISPLAY_BASE 0x18
+#define VLV_GU_CTL0(VLV_DISPLAY_BASE + 0x2030)
+#define VLV_GU_CTL1(VLV_DISPLAY_BASE + 0x2034)
#define SCPD0 0x0209c /* 915+ only */
#define IER0x020a0
#define IIR0x020a4
@@ -955,6 +974,7 @@ enum punit_power_well {
#define ISR0x020ac
#define VLV_GUNIT_CLOCK_GATE (VLV_DISPLAY_BASE + 0x2060)
#define GCFG_DIS (18)
+#define VLV_GUNIT_CLOCK_GATE2 (VLV_DISPLAY_BASE + 0x2064)
#define VLV_IIR_RW (VLV_DISPLAY_BASE + 0x2084)
#define VLV_IER(VLV_DISPLAY_BASE + 0x20a0)
#define VLV_IIR(VLV_DISPLAY_BASE + 0x20a4)
@@ -4988,6 +5008,8 @@ enum punit_power_well {
#define EDP_LINK_TRAIN_VOL_EMP_MASK_IVB (0x3f22)
+#define VLV_PMWGICZ 0x1300a4
+
#define FORCEWAKE 0xA18C
#define FORCEWAKE_VLV 0x1300b0
#define FORCEWAKE_ACK_VLV 0x1300b4
@@ -5011,6 +5033,7 @@ enum punit_power_well {
#define FORCEWAKE_MT_ACK 0x130040
#define ECOBUS0xa180
#defineFORCEWAKE_MT_ENABLE (15)
+#define VLV_SPAREG2H 0xA194
#define GTFIFODBG 0x12
#defineGT_FIFO_SBDROPERR (16)
@@ -5040,12 +5063,24 @@ enum punit_power_well {
# define GEN6_RCPBUNIT_CLOCK_GATE_DISABLE (1 12)
# define GEN6_RCCUNIT_CLOCK_GATE_DISABLE (1 11)
+#define GEN7_UCGCTL3 0x9408
+
#define GEN7_UCGCTL4 0x940c
#define GEN7_L3BANK2X_CLOCK_GATE_DISABLE (125)
+#define GEN7_RCGCTL1 0x9410
+#define GEN7_RCGCTL2 0x9414
+#define GEN7_RSTCTL0x9420
+
#define GEN8_UCGCTL6 0x9430
#define GEN8_SDEUNIT_CLOCK_GATE_DISABLE (114)
+#define GEN7_GFXPAUSE 0xA000
+#define GEN7_RPDEUHWTC 0xA080
+#define GEN7_RPDEUC0xA084
+
+#define VLV_PWRDWNUPCTL0xA294
+
#define GEN6_RPNSWREQ 0xA008
#define GEN6_TURBO_DISABLE (131)
#define GEN6_FREQUENCY(x)((x)25)
@@ -5098,6 +5133,7 @@ enum punit_power_well {
#define GEN6_RP_UP_EI 0xA068
#define GEN6_RP_DOWN_EI0xA06C
#define GEN6_RP_IDLE_HYSTERSIS 0xA070
+#define GEN7_RPDEUCSW 0xA088
#define GEN6_RC_STATE 0xA094
#define GEN6_RC1_WAKE_RATE_LIMIT 0xA098
#define GEN6_RC6_WAKE_RATE_LIMIT 0xA09C
@@ -5105,9 +5141,11 @@ enum punit_power_well {
#define GEN6_RC_EVALUATION_INTERVAL0xA0A8
#define GEN6_RC_IDLE_HYSTERSIS 0xA0AC
#define
[Intel-gfx] [PATCH v2 24/25] drm/i915: propagate the error code from runtime PM callbacks
Atm, none of the RPM callbacks can fail, but the next patch adding
RPM support for VLV changes this, so prepare for it.
In case one of these callbacks return error RPM will get permanently
disabled until the error is explicitly cleared. In the future we could
add support for re-enabling it, for example after resetting the HW, but
for now - hopefully - we can live with the simpler solution.
v2:
- propagate the error from the resume callbacks too (Paulo)
Signed-off-by: Imre Deak imre.d...@intel.com
---
drivers/gpu/drm/i915/i915_drv.c | 57 ++---
1 file changed, 42 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 845e1e1..08e210c 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -888,21 +888,27 @@ static int i915_pm_poweroff(struct device *dev)
return i915_drm_freeze(drm_dev);
}
-static void hsw_runtime_suspend(struct drm_i915_private *dev_priv)
+static int hsw_runtime_suspend(struct drm_i915_private *dev_priv)
{
hsw_enable_pc8(dev_priv);
+
+ return 0;
}
-static void snb_runtime_resume(struct drm_i915_private *dev_priv)
+static int snb_runtime_resume(struct drm_i915_private *dev_priv)
{
struct drm_device *dev = dev_priv-dev;
intel_init_pch_refclk(dev);
+
+ return 0;
}
-static void hsw_runtime_resume(struct drm_i915_private *dev_priv)
+static int hsw_runtime_resume(struct drm_i915_private *dev_priv)
{
hsw_disable_pc8(dev_priv);
+
+ return 0;
}
int vlv_force_gfx_clock(struct drm_i915_private *dev_priv, bool force_on)
@@ -947,6 +953,7 @@ static int intel_runtime_suspend(struct device *device)
struct pci_dev *pdev = to_pci_dev(device);
struct drm_device *dev = pci_get_drvdata(pdev);
struct drm_i915_private *dev_priv = dev-dev_private;
+ int ret;
if (WARN_ON_ONCE(!(dev_priv-rps.enabled intel_enable_rc6(dev
return -ENODEV;
@@ -959,12 +966,21 @@ static int intel_runtime_suspend(struct device *device)
intel_runtime_pm_disable_interrupts(dev);
cancel_work_sync(dev_priv-rps.work);
- if (IS_GEN6(dev))
- ;
- else if (IS_HASWELL(dev) || IS_BROADWELL(dev))
- hsw_runtime_suspend(dev_priv);
- else
+ if (IS_GEN6(dev)) {
+ ret = 0;
+ } if (IS_HASWELL(dev) || IS_BROADWELL(dev)) {
+ ret = hsw_runtime_suspend(dev_priv);
+ } else {
+ ret = -ENODEV;
WARN_ON(1);
+ }
+
+ if (ret) {
+ DRM_ERROR(Runtime suspend failed, disabling it (%d)\n, ret);
+ intel_runtime_pm_restore_interrupts(dev);
+
+ return ret;
+ }
i915_gem_release_all_mmaps(dev_priv);
@@ -989,6 +1005,7 @@ static int intel_runtime_resume(struct device *device)
struct pci_dev *pdev = to_pci_dev(device);
struct drm_device *dev = pci_get_drvdata(pdev);
struct drm_i915_private *dev_priv = dev-dev_private;
+ int ret;
WARN_ON(!HAS_RUNTIME_PM(dev));
@@ -997,21 +1014,31 @@ static int intel_runtime_resume(struct device *device)
intel_opregion_notify_adapter(dev, PCI_D0);
dev_priv-pm.suspended = false;
- if (IS_GEN6(dev))
- snb_runtime_resume(dev_priv);
- else if (IS_HASWELL(dev) || IS_BROADWELL(dev))
- hsw_runtime_resume(dev_priv);
- else
+ if (IS_GEN6(dev)) {
+ ret = snb_runtime_resume(dev_priv);
+ } else if (IS_HASWELL(dev) || IS_BROADWELL(dev)) {
+ ret = hsw_runtime_resume(dev_priv);
+ } else {
WARN_ON(1);
+ ret = -ENODEV;
+ }
+ /*
+* No point of rolling back things in case of an error, as the best
+* we can do is to hope that things will still work (and disable RPM).
+*/
i915_gem_init_swizzling(dev);
gen6_update_ring_freq(dev);
intel_reset_gt_powersave(dev);
intel_runtime_pm_restore_interrupts(dev);
- DRM_DEBUG_KMS(Device resumed\n);
- return 0;
+ if (ret)
+ DRM_ERROR(Runtime resume failed, disabling it (%d)\n, ret);
+ else
+ DRM_DEBUG_KMS(Device resumed\n);
+
+ return ret;
}
static const struct dev_pm_ops i915_pm_ops = {
--
1.8.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 20/25] drm/i915: vlv: setup RPS min/max frequencies once during init time
When enabling runtime PM on VLV, GT power save enabling becomes relatively
frequent, so optimize it a bit.
Signed-off-by: Imre Deak imre.d...@intel.com
---
drivers/gpu/drm/i915/intel_pm.c | 66 +
1 file changed, 41 insertions(+), 25 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index f88d64d..bc38213 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -3698,6 +3698,45 @@ static void valleyview_cleanup_pctx(struct drm_device
*dev)
dev_priv-vlv_pctx = NULL;
}
+static void valleyview_init_gt_powersave(struct drm_device *dev)
+{
+ struct drm_i915_private *dev_priv = dev-dev_private;
+
+ valleyview_setup_pctx(dev);
+
+ mutex_lock(dev_priv-rps.hw_lock);
+
+ dev_priv-rps.max_freq = valleyview_rps_max_freq(dev_priv);
+ dev_priv-rps.rp0_freq = dev_priv-rps.max_freq;
+ DRM_DEBUG_DRIVER(max GPU freq: %d MHz (%u)\n,
+vlv_gpu_freq(dev_priv, dev_priv-rps.max_freq),
+dev_priv-rps.max_freq);
+
+ dev_priv-rps.efficient_freq = valleyview_rps_rpe_freq(dev_priv);
+ DRM_DEBUG_DRIVER(RPe GPU freq: %d MHz (%u)\n,
+vlv_gpu_freq(dev_priv, dev_priv-rps.efficient_freq),
+dev_priv-rps.efficient_freq);
+
+ dev_priv-rps.min_freq = valleyview_rps_min_freq(dev_priv);
+ DRM_DEBUG_DRIVER(min GPU freq: %d MHz (%u)\n,
+vlv_gpu_freq(dev_priv, dev_priv-rps.min_freq),
+dev_priv-rps.min_freq);
+
+ /* Preserve min/max settings in case of re-init */
+ if (dev_priv-rps.max_freq_softlimit == 0)
+ dev_priv-rps.max_freq_softlimit = dev_priv-rps.max_freq;
+
+ if (dev_priv-rps.min_freq_softlimit == 0)
+ dev_priv-rps.min_freq_softlimit = dev_priv-rps.min_freq;
+
+ mutex_unlock(dev_priv-rps.hw_lock);
+}
+
+static void valleyview_cleanup_gt_powersave(struct drm_device *dev)
+{
+ valleyview_cleanup_pctx(dev);
+}
+
static void valleyview_enable_rps(struct drm_device *dev)
{
struct drm_i915_private *dev_priv = dev-dev_private;
@@ -3764,29 +3803,6 @@ static void valleyview_enable_rps(struct drm_device *dev)
vlv_gpu_freq(dev_priv, dev_priv-rps.cur_freq),
dev_priv-rps.cur_freq);
- dev_priv-rps.max_freq = valleyview_rps_max_freq(dev_priv);
- dev_priv-rps.rp0_freq = dev_priv-rps.max_freq;
- DRM_DEBUG_DRIVER(max GPU freq: %d MHz (%u)\n,
-vlv_gpu_freq(dev_priv, dev_priv-rps.max_freq),
-dev_priv-rps.max_freq);
-
- dev_priv-rps.efficient_freq = valleyview_rps_rpe_freq(dev_priv);
- DRM_DEBUG_DRIVER(RPe GPU freq: %d MHz (%u)\n,
-vlv_gpu_freq(dev_priv, dev_priv-rps.efficient_freq),
-dev_priv-rps.efficient_freq);
-
- dev_priv-rps.min_freq = valleyview_rps_min_freq(dev_priv);
- DRM_DEBUG_DRIVER(min GPU freq: %d MHz (%u)\n,
-vlv_gpu_freq(dev_priv, dev_priv-rps.min_freq),
-dev_priv-rps.min_freq);
-
- /* Preserve min/max settings in case of re-init */
- if (dev_priv-rps.max_freq_softlimit == 0)
- dev_priv-rps.max_freq_softlimit = dev_priv-rps.max_freq;
-
- if (dev_priv-rps.min_freq_softlimit == 0)
- dev_priv-rps.min_freq_softlimit = dev_priv-rps.min_freq;
-
DRM_DEBUG_DRIVER(setting GPU freq to %d MHz (%u)\n,
vlv_gpu_freq(dev_priv, dev_priv-rps.efficient_freq),
dev_priv-rps.efficient_freq);
@@ -4530,13 +4546,13 @@ void intel_init_gt_powersave(struct drm_device *dev)
i915.enable_rc6 = sanitize_rc6_option(dev, i915.enable_rc6);
if (IS_VALLEYVIEW(dev))
- valleyview_setup_pctx(dev);
+ valleyview_init_gt_powersave(dev);
}
void intel_cleanup_gt_powersave(struct drm_device *dev)
{
if (IS_VALLEYVIEW(dev))
- valleyview_cleanup_pctx(dev);
+ valleyview_cleanup_gt_powersave(dev);
}
void intel_disable_gt_powersave(struct drm_device *dev)
--
1.8.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 17/25] drm/i915: factor out gen6_update_ring_freq
This is needed by the next patch moving the call out from platform
specific RPM callbacks to platform independent code.
No functional change.
Signed-off-by: Imre Deak imre.d...@intel.com
---
drivers/gpu/drm/i915/i915_drv.c | 2 --
drivers/gpu/drm/i915/intel_display.c | 2 --
drivers/gpu/drm/i915/intel_pm.c | 18 +++---
3 files changed, 15 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index f3f9a33..afc31e3 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -899,9 +899,7 @@ static void snb_runtime_resume(struct drm_i915_private
*dev_priv)
intel_init_pch_refclk(dev);
i915_gem_init_swizzling(dev);
- mutex_lock(dev_priv-rps.hw_lock);
gen6_update_ring_freq(dev);
- mutex_unlock(dev_priv-rps.hw_lock);
}
static void hsw_runtime_resume(struct drm_i915_private *dev_priv)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index bda79ec..596ae69 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -7088,9 +7088,7 @@ void hsw_disable_pc8(struct drm_i915_private *dev_priv)
intel_prepare_ddi(dev);
i915_gem_init_swizzling(dev);
- mutex_lock(dev_priv-rps.hw_lock);
gen6_update_ring_freq(dev);
- mutex_unlock(dev_priv-rps.hw_lock);
}
static void snb_modeset_global_resources(struct drm_device *dev)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 3068f51..f88d64d 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -3522,7 +3522,7 @@ static void gen6_enable_rps(struct drm_device *dev)
gen6_gt_force_wake_put(dev_priv, FORCEWAKE_ALL);
}
-void gen6_update_ring_freq(struct drm_device *dev)
+static void __gen6_update_ring_freq(struct drm_device *dev)
{
struct drm_i915_private *dev_priv = dev-dev_private;
int min_freq = 15;
@@ -3592,6 +3592,18 @@ void gen6_update_ring_freq(struct drm_device *dev)
}
}
+void gen6_update_ring_freq(struct drm_device *dev)
+{
+ struct drm_i915_private *dev_priv = dev-dev_private;
+
+ if (!(INTEL_INFO(dev)-gen = 6 !IS_VALLEYVIEW(dev)))
+ return;
+
+ mutex_lock(dev_priv-rps.hw_lock);
+ __gen6_update_ring_freq(dev);
+ mutex_unlock(dev_priv-rps.hw_lock);
+}
+
int valleyview_rps_max_freq(struct drm_i915_private *dev_priv)
{
u32 val, rp0;
@@ -4563,10 +4575,10 @@ static void intel_gen6_powersave_work(struct
work_struct *work)
valleyview_enable_rps(dev);
} else if (IS_BROADWELL(dev)) {
gen8_enable_rps(dev);
- gen6_update_ring_freq(dev);
+ __gen6_update_ring_freq(dev);
} else {
gen6_enable_rps(dev);
- gen6_update_ring_freq(dev);
+ __gen6_update_ring_freq(dev);
}
dev_priv-rps.enabled = true;
mutex_unlock(dev_priv-rps.hw_lock);
--
1.8.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 25/25] drm/i915: vlv: add runtime PM support
Add runtime PM support for VLV, but leave it disabled. The next patch
enables it.
The suspend/resume sequence used is based on [1] and [2]. In practice we
depend on the GT RC6 mechanism to save the HW context depending on the
render and media power wells. By the time we run the runtime suspend
callback the display side is also off and the HW context for that is
managed by the display power domain framework.
Besides the above there are Gunit registers that depend on a system-wide
power well. This power well goes off once the device enters any of the
S0i[R123] states. To handle this scenario, save/restore these Gunit
registers. Note that this is not the complete register set dictated by
[2], to remove some overhead, registers that are known not to be used are
ignored. Also some registers are fully setup by initialization functions
called during resume, these are not saved either. The list of registers
can be further reduced, see the TODO note in the code.
[1] VLV_gfx_clocking_PM_reset_y12w21d3 / Driver D3 entry/exit
[2] VLV2_S0IXRegs
Signed-off-by: Imre Deak imre.d...@intel.com
---
drivers/gpu/drm/i915/i915_drv.c | 327
drivers/gpu/drm/i915/i915_drv.h | 62
2 files changed, 389 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 08e210c..bc206dd 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -911,6 +911,198 @@ static int hsw_runtime_resume(struct drm_i915_private
*dev_priv)
return 0;
}
+/*
+ * Save all Gunit registers that may be lost after a D3 and a subsequent
+ * S0i[R123] transition. The list of registers needing a save/restore is
+ * defined in the VLV2_S0IXRegs document. This documents marks all Gunit
+ * registers in the following way:
+ * - Driver: saved/restored by the driver
+ * - Punit : saved/restored by the Punit firmware
+ * - No, w/o marking: no need to save/restore, since the register is R/O or
+ *used internally by the HW in a way that doesn't depend
+ *keeping the content across a suspend/resume.
+ * - Debug : used for debugging
+ *
+ * We save/restore all registers marked with 'Driver', with the following
+ * exceptions:
+ * - Registers out of use, including also registers marked with 'Debug'.
+ * These have no effect on the driver's operation, so we don't save/restore
+ * them to reduce the overhead.
+ * - Registers that are fully setup by an initialization function called from
+ * the resume path. For example many clock gating and RPS/RC6 registers.
+ * - Registers that provide the right functionality with their reset defaults.
+ *
+ * TODO: Except for registers that based on the above 3 criteria can be safely
+ * ignored, we save/restore all others, practically treating the HW context as
+ * a black-box for the driver. Further investigation is needed to reduce the
+ * saved/restored registers even further, by following the same 3 criteria.
+ */
+static void vlv_save_gunit_s0ix_state(struct drm_i915_private *dev_priv)
+{
+ struct vlv_s0ix_state *s = dev_priv-vlv_s0ix_state;
+ int i;
+
+ /* GAM 0x4000-0x4770 */
+ s-wr_watermark = I915_READ(GEN7_WR_WATERMARK);
+ s-gfx_prio_ctrl= I915_READ(GEN7_GFX_PRIO_CTRL);
+ s-arb_mode = I915_READ(ARB_MODE);
+ s-gfx_pend_tlb0= I915_READ(GEN7_GFX_PEND_TLB0);
+ s-gfx_pend_tlb1= I915_READ(GEN7_GFX_PEND_TLB1);
+
+ for (i = 0; i ARRAY_SIZE(s-lra_limits); i++)
+ s-lra_limits[i] = I915_READ(GEN7_LRA_LIMITS_BASE + i * 4);
+
+ s-media_max_req_count = I915_READ(GEN7_MEDIA_MAX_REQ_COUNT);
+ s-gfx_max_req_count= I915_READ(GEN7_MEDIA_MAX_REQ_COUNT);
+
+ s-render_hwsp = I915_READ(RENDER_HWS_PGA_GEN7);
+ s-ecochk = I915_READ(GAM_ECOCHK);
+ s-bsd_hwsp = I915_READ(BSD_HWS_PGA_GEN7);
+ s-blt_hwsp = I915_READ(BLT_HWS_PGA_GEN7);
+
+ s-tlb_rd_addr = I915_READ(GEN7_TLB_RD_ADDR);
+
+ /* MBC 0x9024-0x91D0, 0x8500 */
+ s-g3dctl = I915_READ(GEN7_G3DCTL);
+ s-gsckgctl = I915_READ(GEN7_GSCKGCTL);
+ s-mbctl= I915_READ(GEN6_MBCTL);
+
+ /* GCP 0x9400-0x9424, 0x8100-0x810C */
+ s-ucgctl1 = I915_READ(GEN6_UCGCTL1);
+ s-ucgctl3 = I915_READ(GEN7_UCGCTL3);
+ s-rcgctl1 = I915_READ(GEN7_RCGCTL1);
+ s-rcgctl2 = I915_READ(GEN7_RCGCTL2);
+ s-rstctl = I915_READ(GEN7_RSTCTL);
+ s-misccpctl= I915_READ(GEN7_MISCCPCTL);
+
+ /* GPM 0xA000-0xAA84, 0x8000-0x80FC */
+ s-gfxpause = I915_READ(GEN7_GFXPAUSE);
+ s-rpdeuhwtc= I915_READ(GEN7_RPDEUHWTC);
+ s-rpdeuc = I915_READ(GEN7_RPDEUC);
+ s-ecobus = I915_READ(ECOBUS);
+
[Intel-gfx] [PATCH v2 22/25] drm/i915: vlv: increase timeout when forcing on the GFX clock
I've seen latencies up to 15msec, so increase the timeout to 20msec.
Signed-off-by: Imre Deak imre.d...@intel.com
---
drivers/gpu/drm/i915/i915_drv.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 0609f77..845e1e1 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -916,7 +916,7 @@ int vlv_force_gfx_clock(struct drm_i915_private *dev_priv,
bool force_on)
#define COND (I915_READ(VLV_GTLC_SURVIVABILITY_REG) VLV_GFX_CLK_STATUS_BIT)
/* Wait for a previous force on/off to settle */
if (force_on) {
- err = wait_for(!COND, 5);
+ err = wait_for(!COND, 20);
if (err) {
DRM_ERROR(timeout waiting for GFX clock force-off
(%08x)\n,
I915_READ(VLV_GTLC_SURVIVABILITY_REG));
@@ -933,7 +933,7 @@ int vlv_force_gfx_clock(struct drm_i915_private *dev_priv,
bool force_on)
if (!force_on)
return 0;
- err = wait_for(COND, 5);
+ err = wait_for(COND, 20);
if (err)
DRM_ERROR(timeout waiting for GFX clock force-on (%08x)\n,
I915_READ(VLV_GTLC_SURVIVABILITY_REG));
--
1.8.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 16/25] drm/i915: make runtime PM interrupt enable/disable platform independent
We need to disable the interrupts for all platforms, so make the helpers
for this platform independent and call them from them platform
independent runtime suspend/resume callbacks.
On HSW/BDW this will move interrupt disabling/re-enabling at the
beginning/end of runtime suspend/resume respectively, but I don't see
any reason why this would cause a problem there. In any case this seems
to be the correct thing to do even on those platforms.
Signed-off-by: Imre Deak imre.d...@intel.com
---
drivers/gpu/drm/i915/i915_drv.c | 14 +-
drivers/gpu/drm/i915/intel_display.c | 2 --
2 files changed, 5 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 43980c9..f3f9a33 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -888,13 +888,6 @@ static int i915_pm_poweroff(struct device *dev)
return i915_drm_freeze(drm_dev);
}
-static void snb_runtime_suspend(struct drm_i915_private *dev_priv)
-{
- struct drm_device *dev = dev_priv-dev;
-
- intel_runtime_pm_disable_interrupts(dev);
-}
-
static void hsw_runtime_suspend(struct drm_i915_private *dev_priv)
{
hsw_enable_pc8(dev_priv);
@@ -904,7 +897,6 @@ static void snb_runtime_resume(struct drm_i915_private
*dev_priv)
{
struct drm_device *dev = dev_priv-dev;
- intel_runtime_pm_restore_interrupts(dev);
intel_init_pch_refclk(dev);
i915_gem_init_swizzling(dev);
mutex_lock(dev_priv-rps.hw_lock);
@@ -931,8 +923,10 @@ static int intel_runtime_suspend(struct device *device)
DRM_DEBUG_KMS(Suspending device\n);
+ intel_runtime_pm_disable_interrupts(dev);
+
if (IS_GEN6(dev))
- snb_runtime_suspend(dev_priv);
+ ;
else if (IS_HASWELL(dev) || IS_BROADWELL(dev))
hsw_runtime_suspend(dev_priv);
else
@@ -976,6 +970,8 @@ static int intel_runtime_resume(struct device *device)
else
WARN_ON(1);
+ intel_runtime_pm_restore_interrupts(dev);
+
DRM_DEBUG_KMS(Device resumed\n);
return 0;
}
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 4d8d875..bda79ec 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -7067,7 +7067,6 @@ void hsw_enable_pc8(struct drm_i915_private *dev_priv)
}
lpt_disable_clkout_dp(dev);
- intel_runtime_pm_disable_interrupts(dev);
hsw_disable_lcpll(dev_priv, true, true);
}
@@ -7079,7 +7078,6 @@ void hsw_disable_pc8(struct drm_i915_private *dev_priv)
DRM_DEBUG_KMS(Disabling package C8+\n);
hsw_restore_lcpll(dev_priv);
- intel_runtime_pm_restore_interrupts(dev);
lpt_init_pch_refclk(dev);
if (dev_priv-pch_id == INTEL_PCH_LPT_LP_DEVICE_ID_TYPE) {
--
1.8.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 15/25] drm/i915: disable runtime PM if RC6 is disabled
On VLV we depend on RC6 to save the GT render and media HW context
before going to the D3 state via RPM, so as a preparation for the
VLV RPM support (added in an upcoming patch) disable RPM if RC6 is
disabled.
There is probably a similar dependency on other platforms too, so for
safety require RC6 for those too. For these platforms (SNB, HSW, BDW)
this is then a possible fix.
v2:
- require RC6 for all RPM platforms, not just for VLV (Paulo, Daniel)
Signed-off-by: Imre Deak imre.d...@intel.com
---
drivers/gpu/drm/i915/i915_drv.c | 2 +-
drivers/gpu/drm/i915/intel_pm.c | 12
2 files changed, 13 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index a20d2d1..43980c9 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -923,7 +923,7 @@ static int intel_runtime_suspend(struct device *device)
struct drm_device *dev = pci_get_drvdata(pdev);
struct drm_i915_private *dev_priv = dev-dev_private;
- if (WARN_ON_ONCE(!dev_priv-rps.enabled))
+ if (WARN_ON_ONCE(!(dev_priv-rps.enabled intel_enable_rc6(dev
return -ENODEV;
WARN_ON(!HAS_RUNTIME_PM(dev));
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 89fe0a7..3068f51 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -6098,6 +6098,15 @@ void intel_init_runtime_pm(struct drm_i915_private
*dev_priv)
pm_runtime_set_active(device);
+ /*
+* RPM depends on RC6 to save restore the GT HW context, so make RC6 a
+* requirement.
+*/
+ if (!intel_enable_rc6(dev)) {
+ DRM_INFO(RC6 disabled, disabling runtime PM support\n);
+ return;
+ }
+
pm_runtime_set_autosuspend_delay(device, 1); /* 10s */
pm_runtime_mark_last_busy(device);
pm_runtime_use_autosuspend(device);
@@ -6113,6 +6122,9 @@ void intel_fini_runtime_pm(struct drm_i915_private
*dev_priv)
if (!HAS_RUNTIME_PM(dev))
return;
+ if (!intel_enable_rc6(dev))
+ return;
+
/* Make sure we're not suspended first. */
pm_runtime_get_sync(device);
pm_runtime_disable(device);
--
1.8.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 21/25] drm/i915: vlv: factor out vlv_force_gfx_clock
This will be needed by the VLV runtime PM helpers too, so factor it out.
Signed-off-by: Imre Deak imre.d...@intel.com
---
drivers/gpu/drm/i915/i915_drv.c | 37 +
drivers/gpu/drm/i915/i915_drv.h | 1 +
drivers/gpu/drm/i915/intel_pm.c | 16 ++--
3 files changed, 40 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 1f88917..0609f77 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -905,6 +905,43 @@ static void hsw_runtime_resume(struct drm_i915_private
*dev_priv)
hsw_disable_pc8(dev_priv);
}
+int vlv_force_gfx_clock(struct drm_i915_private *dev_priv, bool force_on)
+{
+ u32 val;
+ int err;
+
+ val = I915_READ(VLV_GTLC_SURVIVABILITY_REG);
+ WARN_ON(!!(val VLV_GFX_CLK_FORCE_ON_BIT) == force_on);
+
+#define COND (I915_READ(VLV_GTLC_SURVIVABILITY_REG) VLV_GFX_CLK_STATUS_BIT)
+ /* Wait for a previous force on/off to settle */
+ if (force_on) {
+ err = wait_for(!COND, 5);
+ if (err) {
+ DRM_ERROR(timeout waiting for GFX clock force-off
(%08x)\n,
+ I915_READ(VLV_GTLC_SURVIVABILITY_REG));
+ return err;
+ }
+ }
+
+ val = I915_READ(VLV_GTLC_SURVIVABILITY_REG);
+ val = ~VLV_GFX_CLK_FORCE_ON_BIT;
+ if (force_on)
+ val |= VLV_GFX_CLK_FORCE_ON_BIT;
+ I915_WRITE(VLV_GTLC_SURVIVABILITY_REG, val);
+
+ if (!force_on)
+ return 0;
+
+ err = wait_for(COND, 5);
+ if (err)
+ DRM_ERROR(timeout waiting for GFX clock force-on (%08x)\n,
+ I915_READ(VLV_GTLC_SURVIVABILITY_REG));
+
+ return err;
+#undef COND
+}
+
static int intel_runtime_suspend(struct device *device)
{
struct pci_dev *pdev = to_pci_dev(device);
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 5254f4b..3cac434 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1968,6 +1968,7 @@ extern unsigned long i915_chipset_val(struct
drm_i915_private *dev_priv);
extern unsigned long i915_mch_val(struct drm_i915_private *dev_priv);
extern unsigned long i915_gfx_val(struct drm_i915_private *dev_priv);
extern void i915_update_gfx_val(struct drm_i915_private *dev_priv);
+int vlv_force_gfx_clock(struct drm_i915_private *dev_priv, bool on);
extern void intel_console_resume(struct work_struct *work);
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index bc38213..5a61075 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -3129,16 +3129,7 @@ static void vlv_set_rps_idle(struct drm_i915_private
*dev_priv)
/* Mask turbo interrupt so that they will not come in between */
I915_WRITE(GEN6_PMINTRMSK, 0x);
- /* Bring up the Gfx clock */
- I915_WRITE(VLV_GTLC_SURVIVABILITY_REG,
- I915_READ(VLV_GTLC_SURVIVABILITY_REG) |
- VLV_GFX_CLK_FORCE_ON_BIT);
-
- if (wait_for(((VLV_GFX_CLK_STATUS_BIT
- I915_READ(VLV_GTLC_SURVIVABILITY_REG)) != 0), 5)) {
- DRM_ERROR(GFX_CLK_ON request timed out\n);
- return;
- }
+ vlv_force_gfx_clock(dev_priv, true);
dev_priv-rps.cur_freq = dev_priv-rps.min_freq_softlimit;
@@ -3149,10 +3140,7 @@ static void vlv_set_rps_idle(struct drm_i915_private
*dev_priv)
GENFREQSTATUS) == 0, 5))
DRM_ERROR(timed out waiting for Punit\n);
- /* Release the Gfx clock */
- I915_WRITE(VLV_GTLC_SURVIVABILITY_REG,
- I915_READ(VLV_GTLC_SURVIVABILITY_REG)
- ~VLV_GFX_CLK_FORCE_ON_BIT);
+ vlv_force_gfx_clock(dev_priv, false);
I915_WRITE(GEN6_PMINTRMSK,
gen6_rps_pm_mask(dev_priv, dev_priv-rps.cur_freq));
--
1.8.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 08/25] drm/i915: get a runtime PM ref for the deferred GT powersave enabling
At least on VLV but probably on other platforms too we depend on RC6
being enabled for RPM, so disable RPM until the delayed RC6 enabling
completes.
v2:
- explain the reason for the _noresume version of RPM get (Daniel)
- use the simpler 'if (schedule_work()) rpm_get();' instead of
'if (!cancel_work_sync()) rpm_get(); schedule_work();'
Signed-off-by: Imre Deak imre.d...@intel.com
---
drivers/gpu/drm/i915/i915_drv.c | 5 -
drivers/gpu/drm/i915/intel_drv.h | 2 ++
drivers/gpu/drm/i915/intel_pm.c | 34 --
3 files changed, 38 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index a821608..a20d2d1 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -754,7 +754,7 @@ int i915_reset(struct drm_device *dev)
* previous concerns that it doesn't respond well to some forms
* of re-init after reset. */
if (INTEL_INFO(dev)-gen 5)
- intel_enable_gt_powersave(dev);
+ intel_reset_gt_powersave(dev);
intel_hpd_init(dev);
} else {
@@ -923,6 +923,9 @@ static int intel_runtime_suspend(struct device *device)
struct drm_device *dev = pci_get_drvdata(pdev);
struct drm_i915_private *dev_priv = dev-dev_private;
+ if (WARN_ON_ONCE(!dev_priv-rps.enabled))
+ return -ENODEV;
+
WARN_ON(!HAS_RUNTIME_PM(dev));
assert_force_wake_inactive(dev_priv);
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index c551472..618d05a 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -924,6 +924,7 @@ void intel_init_gt_powersave(struct drm_device *dev);
void intel_cleanup_gt_powersave(struct drm_device *dev);
void intel_enable_gt_powersave(struct drm_device *dev);
void intel_disable_gt_powersave(struct drm_device *dev);
+void intel_reset_gt_powersave(struct drm_device *dev);
void ironlake_teardown_rc6(struct drm_device *dev);
void gen6_update_ring_freq(struct drm_device *dev);
void gen6_rps_idle(struct drm_i915_private *dev_priv);
@@ -931,6 +932,7 @@ void gen6_rps_boost(struct drm_i915_private *dev_priv);
void intel_aux_display_runtime_get(struct drm_i915_private *dev_priv);
void intel_aux_display_runtime_put(struct drm_i915_private *dev_priv);
void intel_runtime_pm_get(struct drm_i915_private *dev_priv);
+void intel_runtime_pm_get_noresume(struct drm_i915_private *dev_priv);
void intel_runtime_pm_put(struct drm_i915_private *dev_priv);
void intel_init_runtime_pm(struct drm_i915_private *dev_priv);
void intel_fini_runtime_pm(struct drm_i915_private *dev_priv);
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index e5b9f08..0e8b263 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -4549,6 +4549,8 @@ static void intel_gen6_powersave_work(struct work_struct
*work)
}
dev_priv-rps.enabled = true;
mutex_unlock(dev_priv-rps.hw_lock);
+
+ intel_runtime_pm_put(dev_priv);
}
void intel_enable_gt_powersave(struct drm_device *dev)
@@ -4566,12 +4568,28 @@ void intel_enable_gt_powersave(struct drm_device *dev)
* PCU communication is slow and this doesn't need to be
* done at any specific time, so do this out of our fast path
* to make resume and init faster.
+*
+* We depend on the HW RC6 power context save/restore
+* mechanism when entering D3 through runtime PM suspend. So
+* disable RPM until RPS/RC6 is properly setup. We can only
+* get here via the driver load/system resume/runtime resume
+* paths, so the _noresume version is enough (and in case of
+* runtime resume it's necessary).
*/
- schedule_delayed_work(dev_priv-rps.delayed_resume_work,
- round_jiffies_up_relative(HZ));
+ if (schedule_delayed_work(dev_priv-rps.delayed_resume_work,
+ round_jiffies_up_relative(HZ)))
+ intel_runtime_pm_get_noresume(dev_priv);
}
}
+void intel_reset_gt_powersave(struct drm_device *dev)
+{
+ struct drm_i915_private *dev_priv = dev-dev_private;
+
+ dev_priv-rps.enabled = false;
+ intel_enable_gt_powersave(dev);
+}
+
static void ibx_init_clock_gating(struct drm_device *dev)
{
struct drm_i915_private *dev_priv = dev-dev_private;
@@ -6025,6 +6043,18 @@ void intel_runtime_pm_get(struct drm_i915_private
*dev_priv)
WARN(dev_priv-pm.suspended, Device still suspended.\n);
}
+void intel_runtime_pm_get_noresume(struct drm_i915_private *dev_priv)
+{
+ struct drm_device *dev = dev_priv-dev;
+ struct device *device = dev-pdev-dev;
+
+ if
[Intel-gfx] [PATCH v2 18/25] drm/i915: make runtime PM swizzling/ring_freq init platform independent
We need to re-init sizzling on all platforms so move it to the platform independent runtime resume callback. The ring frequency reinit is also needed everywhere except on VLV, but gen6_update_ring_freq() will be a noop on VLV, so we can move this function too to platform independent code. Signed-off-by: Imre Deak imre.d...@intel.com --- drivers/gpu/drm/i915/i915_drv.c | 5 +++-- drivers/gpu/drm/i915/intel_display.c | 2 -- 2 files changed, 3 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c index afc31e3..b87109c 100644 --- a/drivers/gpu/drm/i915/i915_drv.c +++ b/drivers/gpu/drm/i915/i915_drv.c @@ -898,8 +898,6 @@ static void snb_runtime_resume(struct drm_i915_private *dev_priv) struct drm_device *dev = dev_priv-dev; intel_init_pch_refclk(dev); - i915_gem_init_swizzling(dev); - gen6_update_ring_freq(dev); } static void hsw_runtime_resume(struct drm_i915_private *dev_priv) @@ -968,6 +966,9 @@ static int intel_runtime_resume(struct device *device) else WARN_ON(1); + i915_gem_init_swizzling(dev); + gen6_update_ring_freq(dev); + intel_runtime_pm_restore_interrupts(dev); DRM_DEBUG_KMS(Device resumed\n); diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c index 596ae69..3e7ad14 100644 --- a/drivers/gpu/drm/i915/intel_display.c +++ b/drivers/gpu/drm/i915/intel_display.c @@ -7087,8 +7087,6 @@ void hsw_disable_pc8(struct drm_i915_private *dev_priv) } intel_prepare_ddi(dev); - i915_gem_init_swizzling(dev); - gen6_update_ring_freq(dev); } static void snb_modeset_global_resources(struct drm_device *dev) -- 1.8.4 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/2] drm/i915: Set up SDVO encoder type only at detect
Depending on the SDVO output_flags SDVO may have multiple connectors.
These are all initialized in intel_sdvo_output_setup(). The connector
that is initialized later will override the encoder_type that has been
set up by an earlier connector type initialization. Eventually the
one that comes last wins.
Eventually when intel_sdvo_detect() is called the active connector is
determined.
Delay encoder type initialization until the active connector is known
and set it to the type that corresponds to this connector.
Signed-off-by: Egbert Eich e...@suse.de
---
drivers/gpu/drm/i915/intel_sdvo.c | 23 ++-
1 file changed, 18 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_sdvo.c
b/drivers/gpu/drm/i915/intel_sdvo.c
index d27155a..5043f16 100644
--- a/drivers/gpu/drm/i915/intel_sdvo.c
+++ b/drivers/gpu/drm/i915/intel_sdvo.c
@@ -154,6 +154,9 @@ struct intel_sdvo_connector {
/* Mark the type of connector */
uint16_t output_flag;
+ /* store encoder type for convenience */
+ int encoder_type;
+
enum hdmi_force_audio force_audio;
/* This contains all current supported TV format */
@@ -1746,6 +1749,7 @@ intel_sdvo_detect(struct drm_connector *connector, bool
force)
if (response == 0)
return connector_status_disconnected;
+ intel_sdvo-base.base.encoder_type = intel_sdvo_connector-encoder_type;
intel_sdvo-attached_output = response;
intel_sdvo-has_hdmi_monitor = false;
@@ -2489,7 +2493,9 @@ intel_sdvo_dvi_init(struct intel_sdvo *intel_sdvo, int
device)
} else {
intel_connector-polled = DRM_CONNECTOR_POLL_CONNECT |
DRM_CONNECTOR_POLL_DISCONNECT;
}
- encoder-encoder_type = DRM_MODE_ENCODER_TMDS;
+ /* delay encoder_type setting until detection */
+ intel_sdvo_connector-encoder_type = DRM_MODE_ENCODER_TMDS;
+ encoder-encoder_type = DRM_MODE_ENCODER_NONE;
connector-connector_type = DRM_MODE_CONNECTOR_DVID;
if (intel_sdvo_is_hdmi_connector(intel_sdvo, device)) {
@@ -2524,7 +2530,9 @@ intel_sdvo_tv_init(struct intel_sdvo *intel_sdvo, int
type)
intel_connector = intel_sdvo_connector-base;
connector = intel_connector-base;
- encoder-encoder_type = DRM_MODE_ENCODER_TVDAC;
+ /* delay encoder_type setting until detection */
+ intel_sdvo_connector-encoder_type = DRM_MODE_ENCODER_TVDAC;
+ encoder-encoder_type = DRM_MODE_ENCODER_NONE;
connector-connector_type = DRM_MODE_CONNECTOR_SVIDEO;
intel_sdvo-controlled_output |= type;
@@ -2568,7 +2576,9 @@ intel_sdvo_analog_init(struct intel_sdvo *intel_sdvo, int
device)
intel_connector = intel_sdvo_connector-base;
connector = intel_connector-base;
intel_connector-polled = DRM_CONNECTOR_POLL_CONNECT;
- encoder-encoder_type = DRM_MODE_ENCODER_DAC;
+ /* delay encoder_type setting until detection */
+ intel_sdvo_connector-encoder_type = DRM_MODE_ENCODER_DAC;
+ encoder-encoder_type = DRM_MODE_ENCODER_NONE;
connector-connector_type = DRM_MODE_CONNECTOR_VGA;
if (device == 0) {
@@ -2603,7 +2613,9 @@ intel_sdvo_lvds_init(struct intel_sdvo *intel_sdvo, int
device)
intel_connector = intel_sdvo_connector-base;
connector = intel_connector-base;
- encoder-encoder_type = DRM_MODE_ENCODER_LVDS;
+ /* delay encoder_type setting until detection */
+ intel_sdvo_connector-encoder_type = DRM_MODE_ENCODER_LVDS;
+ encoder-encoder_type = DRM_MODE_ENCODER_NONE;
connector-connector_type = DRM_MODE_CONNECTOR_LVDS;
if (device == 0) {
@@ -2984,7 +2996,8 @@ bool intel_sdvo_init(struct drm_device *dev, uint32_t
sdvo_reg, bool is_sdvob)
/* encoder type will be decided later */
intel_encoder = intel_sdvo-base;
intel_encoder-type = INTEL_OUTPUT_SDVO;
- drm_encoder_init(dev, intel_encoder-base, intel_sdvo_enc_funcs, 0);
+ drm_encoder_init(dev, intel_encoder-base, intel_sdvo_enc_funcs,
+DRM_MODE_ENCODER_NONE);
/* Read the regs to test if we can talk to the device */
for (i = 0; i 0x40; i++) {
--
1.8.4.5
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 0/2] Fix if multiple SDVO outputs are flagged
Currently the i915 driver can only handle well if only a single SDVO output is flagged (ie output_flags has only one bit set). If multiple outputs are flagged the side effects are only cosmetic in most cases (ie. the encoder may have the wrong type set), but there are situations (namely when intel_connector_break_all_links() is called) where this may lead to an inconsistent driver state. The following two patches fix both situations. Egbert Eich (2): drm/i915: Only break encoder linked when linked to connector drm/i915: Set up SDVO encoder type only at detect drivers/gpu/drm/i915/intel_display.c | 2 ++ drivers/gpu/drm/i915/intel_sdvo.c| 23 ++- 2 files changed, 20 insertions(+), 5 deletions(-) -- 1.8.4.5 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/2] drm/i915: Only break encoder linked when linked to connector
Depending on the SDVO output_flags SDVO may have multiple connectors
linking to the same encoder (in intel_connector-encoder-base).
Only one of those connectors should be active (ie link to the encoder
thru drm_connector-encoder.
If intel_connector_break_all_links() is called from intel_sanitize_crtc()
we may brake the crtc connection of an encoder thru an inactive connector
in which case intel_connector_break_all_links() will not be called again
for the active connector due to
if (connector-encoder-base.crtc != crtc-base)
continue;
in intel_sanitize_crtc().
This will however leave the drm_connector-encoder linkage for this
active connector in place. Subsequently this will cause multiple
warnings in intel_connector_check_state() to trigger and the driver
will eventually die in drm_encoder_crtc_ok() (because of crtc == NULL).
To avoid this break the encoder links only if the connector is active
(ie. has drm_connector-encoder set).
Signed-off-by: Egbert Eich e...@suse.de
---
drivers/gpu/drm/i915/intel_display.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 1390ab5..041f847 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -11390,6 +11390,8 @@ static void
intel_connector_break_all_links(struct intel_connector *connector)
{
connector-base.dpms = DRM_MODE_DPMS_OFF;
+ if (!connector-base.encoder)
+ return;
connector-base.encoder = NULL;
connector-encoder-connectors_active = false;
connector-encoder-base.crtc = NULL;
--
1.8.4.5
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 26/25] drm/i915: vlv: enable runtime PM
Signed-off-by: Imre Deak imre.d...@intel.com
---
drivers/gpu/drm/i915/i915_drv.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
[ I managed to leave out this last one, so sending it now on top of the
rest. ]
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 77cb7fc..3a98119 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1944,7 +1944,7 @@ struct drm_i915_cmd_table {
#define HAS_FPGA_DBG_UNCLAIMED(dev)(INTEL_INFO(dev)-has_fpga_dbg)
#define HAS_PSR(dev) (IS_HASWELL(dev) || IS_BROADWELL(dev))
#define HAS_RUNTIME_PM(dev)(IS_GEN6(dev) || IS_HASWELL(dev) || \
-IS_BROADWELL(dev))
+IS_BROADWELL(dev) || IS_VALLEYVIEW(dev))
#define INTEL_PCH_DEVICE_ID_MASK 0xff00
#define INTEL_PCH_IBX_DEVICE_ID_TYPE 0x3b00
--
1.8.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] load_cursor_argb is supposed to return a Bool, not void
By mis-declaring this function, we ended up using software cursors
because the value seen by the caller was 0.
Signed-off-by: Keith Packard kei...@keithp.com
---
src/sna/sna_display.c | 8 ++--
src/sna/sna_display_fake.c | 3 ++-
src/uxa/intel_display.c| 7 +--
3 files changed, 13 insertions(+), 5 deletions(-)
diff --git a/src/sna/sna_display.c b/src/sna/sna_display.c
index 6e2d118..a3441e1 100644
--- a/src/sna/sna_display.c
+++ b/src/sna/sna_display.c
@@ -1681,11 +1681,12 @@ sna_crtc_set_cursor_position(xf86CrtcPtr crtc, int x,
int y)
(void)drmIoctl(to_sna(crtc-scrn)-kgem.fd, DRM_IOCTL_MODE_CURSOR,
arg);
}
-static void
+static Bool
sna_crtc_load_cursor_argb(xf86CrtcPtr crtc, CARD32 *image)
{
struct sna *sna = to_sna(crtc-scrn);
struct drm_i915_gem_pwrite pwrite;
+int ret;
__DBG((%s: CRTC:%d\n, __FUNCTION__, to_sna_crtc(crtc)-id));
@@ -1694,7 +1695,10 @@ sna_crtc_load_cursor_argb(xf86CrtcPtr crtc, CARD32
*image)
pwrite.offset = 0;
pwrite.size = sna-mode.cursor_width*sna-mode.cursor_height*4;
pwrite.data_ptr = (uintptr_t)image;
- (void)drmIoctl(sna-kgem.fd, DRM_IOCTL_I915_GEM_PWRITE, pwrite);
+ ret = drmIoctl(sna-kgem.fd, DRM_IOCTL_I915_GEM_PWRITE, pwrite);
+if (ret != 0)
+return FALSE;
+return TRUE;
}
static void
diff --git a/src/sna/sna_display_fake.c b/src/sna/sna_display_fake.c
index c709d99..3cf0042 100644
--- a/src/sna/sna_display_fake.c
+++ b/src/sna/sna_display_fake.c
@@ -115,9 +115,10 @@ sna_crtc_show_cursor(xf86CrtcPtr crtc)
{
}
-static void
+static Bool
sna_crtc_load_cursor_argb(xf86CrtcPtr crtc, CARD32 *image)
{
+return TRUE;
}
static void
diff --git a/src/uxa/intel_display.c b/src/uxa/intel_display.c
index 0f06793..f755cb6 100644
--- a/src/uxa/intel_display.c
+++ b/src/uxa/intel_display.c
@@ -432,16 +432,19 @@ intel_crtc_set_cursor_position (xf86CrtcPtr crtc, int x,
int y)
drmModeMoveCursor(mode-fd, crtc_id(intel_crtc), x, y);
}
-static void
+static Bool
intel_crtc_load_cursor_argb(xf86CrtcPtr crtc, CARD32 *image)
{
struct intel_crtc *intel_crtc = crtc-driver_private;
int ret;
ret = dri_bo_subdata(intel_crtc-cursor, 0, 64*64*4, image);
- if (ret)
+ if (ret) {
xf86DrvMsg(crtc-scrn-scrnIndex, X_ERROR,
failed to set cursor: %s\n, strerror(-ret));
+return FALSE;
+}
+return TRUE;
}
static void
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] REGRESSION 3.14 i915 warning mouse cursor vanishing
Steven Noonan ste...@uplinklabs.net writes: Was using my machine normally, then my mouse cursor vanished. After switching to a VT and back to X11, my cursor came back. But I did notice a nasty trace in dmesg (below). I don't think the trace below is related to the cursor disappearing. I found a pair of bugs (one in the intel driver, one in the X server) which can cause cursor disappearances. I just sent an intel driver patch to the intel-gfx list with the subject: [PATCH] load_cursor_argb is supposed to return a Bool, not void I've posted the X server patch once, and will respond to some review comments. Either is sufficient to get a cursor back, the intel driver one means you get a working hardware cursor again, rather than using a software cursor by mistake. -- keith.pack...@intel.com pgpelSNxaVj1A.pgp Description: PGP signature ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] load_cursor_argb is supposed to return a Bool, not void
On Mon, Apr 14, 2014 at 11:22:03 -0700, Keith Packard wrote: By mis-declaring this function, we ended up using software cursors because the value seen by the caller was 0. Signed-off-by: Keith Packard kei...@keithp.com --- src/sna/sna_display.c | 8 ++-- src/sna/sna_display_fake.c | 3 ++- src/uxa/intel_display.c| 7 +-- 3 files changed, 13 insertions(+), 5 deletions(-) Only since http://cgit.freedesktop.org/xorg/xserver/commit/?id=901fbfbbbd71c0d82080957f8ba09eebbc786f2b Which could probably have used a different name to avoid silent breakage. Cheers, Julien ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] REGRESSION 3.14 i915 warning mouse cursor vanishing
On Mon, Apr 14, 2014 at 11:35:05AM -0700, Keith Packard wrote: Steven Noonan ste...@uplinklabs.net writes: Was using my machine normally, then my mouse cursor vanished. After switching to a VT and back to X11, my cursor came back. But I did notice a nasty trace in dmesg (below). I don't think the trace below is related to the cursor disappearing. Any idea what the trace is all about then? Seems it has something to do with runtime power management (maybe my aggressive kernel command-line options are triggering it). I found a pair of bugs (one in the intel driver, one in the X server) which can cause cursor disappearances. I just sent an intel driver patch to the intel-gfx list with the subject: [PATCH] load_cursor_argb is supposed to return a Bool, not void I've posted the X server patch once, and will respond to some review comments. Either is sufficient to get a cursor back, the intel driver one means you get a working hardware cursor again, rather than using a software cursor by mistake. OK, good to know. Thanks for pointing those out! ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] load_cursor_argb is supposed to return a Bool, not void
Julien Cristau jcris...@debian.org writes: Only since http://cgit.freedesktop.org/xorg/xserver/commit/?id=901fbfbbbd71c0d82080957f8ba09eebbc786f2b Which could probably have used a different name to avoid silent breakage. Yeah, that probably would have been a better change. -- keith.pack...@intel.com pgp0vcYNAo_xV.pgp Description: PGP signature ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/2] drm/i915: Enable PM Interrupts target via Display Interface.
On Mon, Apr 14, 2014 at 10:41:15PM +0530, deepa...@intel.com wrote:
From: Deepak S deepa...@intel.com
In BDW, Apart from unmasking up/down threshold interrupts. we need
to umask bit 32 of PM_INTRMASK to route interrupts to target via Display
Interface.
Signed-off-by: Deepak S deepa...@intel.com
---
drivers/gpu/drm/i915/i915_reg.h | 1 +
drivers/gpu/drm/i915/intel_pm.c | 2 ++
2 files changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index c2dd436..8c7841b 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -5105,6 +5105,7 @@ enum punit_power_well {
#define GEN6_RC6p_THRESHOLD 0xA0BC
#define GEN6_RC6pp_THRESHOLD 0xA0C0
#define GEN6_PMINTRMSK 0xA168
+#define GEN8_PMINTR_REDIRECT_TO_NON_DISP 0x7FFF
Defining is as (131) would make more sense to me.
#define GEN6_PMISR 0x44020
#define GEN6_PMIMR 0x44024 /* rps_lock */
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 27b64ab..6b123cd 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -3066,6 +3066,8 @@ static u32 gen6_rps_pm_mask(struct drm_i915_private
*dev_priv, u8 val)
if (INTEL_INFO(dev_priv-dev)-gen = 7 !IS_HASWELL(dev_priv-dev))
mask |= GEN6_PM_RP_UP_EI_EXPIRED;
+ mask = GEN8_PMINTR_REDIRECT_TO_NON_DISP;
+
return ~mask;
}
--
1.8.5.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Ville Syrjälä
Intel OTC
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] REGRESSION 3.14 i915 warning mouse cursor vanishing
Steven Noonan ste...@uplinklabs.net writes: OK, good to know. Thanks for pointing those out! As Julien points out, this bug only affects people running master from the X server though... -- keith.pack...@intel.com pgpHmhnPO7B4K.pgp Description: PGP signature ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/2] drm/i915/bdw: Implement a basic PM interrupt handler
On Mon, Apr 14, 2014 at 10:41:14PM +0530, deepa...@intel.com wrote:
From: Ben Widawsky benjamin.widaw...@intel.com
Almost all of it is reusable from the existing code. The primary
difference is we need to do even less in the interrupt handler, since
interrupts are not shared in the same way.
The patch is mostly a copy-paste of the existing snb+ code, with updates
to the relevant parts requiring changes to the interrupt handling. As
such it /should/ be relatively trivial. It's highly likely that I missed
some places where I need a gen8 version of the PM interrupts, but it has
become invisible to me by now.
This patch could probably be split into adding the new functions,
followed by actually handling the interrupts. Since the code is
currently disabled (and broken) I think the patch stands better by
itself.
v2: Move the commit about not touching the ringbuffer interrupt to the
snb_* function where it belongs (Rodrigo)
v3: Rebased on Paulo's runtime PM changes
v4: Not well validated, but rebase on
commit 730488b2eddded4497f63f70867b1256cd9e117c
Author: Paulo Zanoni paulo.r.zan...@intel.com
Date: Fri Mar 7 20:12:32 2014 -0300
drm/i915: kill dev_priv-pm.regsave
v5: Rebased on latest code base. (Deepak)
Signed-off-by: Ben Widawsky b...@bwidawsk.net
Conflicts:
drivers/gpu/drm/i915/i915_irq.c
IIRC Daniel doesn't like these conflict markers. So should be dropped.
---
drivers/gpu/drm/i915/i915_irq.c | 81
+---
drivers/gpu/drm/i915/i915_reg.h | 1 +
drivers/gpu/drm/i915/intel_drv.h | 3 +-
drivers/gpu/drm/i915/intel_pm.c | 38 ++-
4 files changed, 115 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 7a4d3ae..96c459a 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -248,6 +248,50 @@ static bool ivb_can_enable_err_int(struct drm_device
*dev)
return true;
}
+/**
+ * bdw_update_pm_irq - update GT interrupt 2
+ * @dev_priv: driver private
+ * @interrupt_mask: mask of interrupt bits to update
+ * @enabled_irq_mask: mask of interrupt bits to enable
+ *
+ * Copied from the snb function, updated with relevant register offsets
+ */
+static void bdw_update_pm_irq(struct drm_i915_private *dev_priv,
+ uint32_t interrupt_mask,
+ uint32_t enabled_irq_mask)
+{
+ uint32_t new_val;
+
+ assert_spin_locked(dev_priv-irq_lock);
+
+ if (dev_priv-pm.irqs_disabled) {
+ WARN(1, IRQs disabled\n);
+ return;
+ }
+
+ new_val = dev_priv-pm_irq_mask;
+ new_val = ~interrupt_mask;
+ new_val |= (~enabled_irq_mask interrupt_mask);
+
+ if (new_val != dev_priv-pm_irq_mask) {
+ dev_priv-pm_irq_mask = new_val;
+ I915_WRITE(GEN8_GT_IMR(2), I915_READ(GEN8_GT_IMR(2)) |
+dev_priv-pm_irq_mask);
+ POSTING_READ(GEN8_GT_IMR(2));
+ }
+}
+
+void bdw_enable_pm_irq(struct drm_i915_private *dev_priv, uint32_t mask)
+{
+ bdw_update_pm_irq(dev_priv, mask, mask);
+}
+
+void bdw_disable_pm_irq(struct drm_i915_private *dev_priv, uint32_t mask)
+{
+ bdw_update_pm_irq(dev_priv, mask, 0);
+}
+
+
Unnecessary empty line.
static bool cpt_can_enable_serr_int(struct drm_device *dev)
{
struct drm_i915_private *dev_priv = dev-dev_private;
@@ -1126,13 +1170,17 @@ static void gen6_pm_rps_work(struct work_struct *work)
spin_lock_irq(dev_priv-irq_lock);
pm_iir = dev_priv-rps.pm_iir;
dev_priv-rps.pm_iir = 0;
- /* Make sure not to corrupt PMIMR state used by ringbuffer code */
- snb_enable_pm_irq(dev_priv, dev_priv-pm_rps_events);
+ if (IS_BROADWELL(dev_priv-dev))
+ bdw_enable_pm_irq(dev_priv, dev_priv-pm_rps_events);
+ else {
+ /* Make sure not to corrupt PMIMR state used by ringbuffer */
+ snb_enable_pm_irq(dev_priv, dev_priv-pm_rps_events);
+ /* Make sure we didn't queue anything we're not going to
+ * process. */
+ WARN_ON(pm_iir ~dev_priv-pm_rps_events);
+ }
spin_unlock_irq(dev_priv-irq_lock);
- /* Make sure we didn't queue anything we're not going to process. */
- WARN_ON(pm_iir ~dev_priv-pm_rps_events);
Isn't this WARN equally valid for bdw?
-
if ((pm_iir dev_priv-pm_rps_events) == 0)
return;
@@ -1324,6 +1372,19 @@ static void snb_gt_irq_handler(struct drm_device *dev,
ivybridge_parity_error_irq_handler(dev, gt_iir);
}
+static void gen8_rps_irq_handler(struct drm_i915_private *dev_priv, u32
pm_iir)
+{
+ if ((pm_iir dev_priv-pm_rps_events) == 0)
+ return;
+
+ spin_lock(dev_priv-irq_lock);
+ dev_priv-rps.pm_iir |= pm_iir dev_priv-pm_rps_events;
+
[Intel-gfx] [PATCH I-g-t V2 2/2] tests/gem_dummy_reloc_loop: Add one subtest based on multi drm_fd to test CPU-GPU sync under multi BSD rings
The Broadwell GT3 machine has two independent BSD rings in kernel driver while
it is transparent to the user-space driver. In such case it needs to check
the CPU-GPU sync for the second BSD ring.
V1-V2: Follow Daniel's comment to add one subtext instead of one individual
test case, which is used to test the CPU-GPU sync under multi BSD rings
Signed-off-by: Zhao Yakui yakui.z...@intel.com
---
tests/gem_dummy_reloc_loop.c | 102 +-
1 file changed, 101 insertions(+), 1 deletion(-)
diff --git a/tests/gem_dummy_reloc_loop.c b/tests/gem_dummy_reloc_loop.c
index a61b59b..660d8e1 100644
--- a/tests/gem_dummy_reloc_loop.c
+++ b/tests/gem_dummy_reloc_loop.c
@@ -48,6 +48,13 @@ static drm_intel_bufmgr *bufmgr;
struct intel_batchbuffer *batch;
static drm_intel_bo *target_buffer;
+#define NUM_FD 50
+
+static int mfd[NUM_FD];
+static drm_intel_bufmgr *mbufmgr[NUM_FD];
+static struct intel_batchbuffer *mbatch[NUM_FD];
+static drm_intel_bo *mbuffer[NUM_FD];
+
/*
* Testcase: Basic check of ring-cpu sync using a dummy reloc
*
@@ -124,6 +131,50 @@ dummy_reloc_loop_random_ring(int num_rings)
}
}
+static void
+dummy_reloc_loop_random_ring_multi_fd(int num_rings)
+{
+ int i;
+ struct intel_batchbuffer *saved_batch;
+
+ saved_batch = batch;
+
+ srandom(0xdeadbeef);
+
+ for (i = 0; i 0x10; i++) {
+ int mindex;
+ int ring = random() % num_rings + 1;
+
+ mindex = random() % NUM_FD;
+ batch = mbatch[mindex];
+
+ if (ring == I915_EXEC_RENDER) {
+ BEGIN_BATCH(4);
+ OUT_BATCH(MI_COND_BATCH_BUFFER_END | MI_DO_COMPARE);
+ OUT_BATCH(0x); /* compare dword */
+ OUT_RELOC(mbuffer[mindex], I915_GEM_DOMAIN_RENDER,
+ I915_GEM_DOMAIN_RENDER, 0);
+ OUT_BATCH(MI_NOOP);
+ ADVANCE_BATCH();
+ } else {
+ BEGIN_BATCH(4);
+ OUT_BATCH(MI_FLUSH_DW | 1);
+ OUT_BATCH(0); /* reserved */
+ OUT_RELOC(mbuffer[mindex], I915_GEM_DOMAIN_RENDER,
+ I915_GEM_DOMAIN_RENDER, 0);
+ OUT_BATCH(MI_NOOP | (122) | (0xf));
+ ADVANCE_BATCH();
+ }
+ intel_batchbuffer_flush_on_ring(batch, ring);
+
+ drm_intel_bo_map(target_buffer, 0);
+ // map to force waiting on rendering
+ drm_intel_bo_unmap(target_buffer);
+ }
+
+ batch = saved_batch;
+}
+
int fd;
int devid;
int num_rings;
@@ -133,6 +184,7 @@ igt_main
igt_skip_on_simulation();
igt_fixture {
+ int i;
fd = drm_open_any();
devid = intel_get_drm_devid(fd);
num_rings = gem_get_num_rings(fd);
@@ -148,6 +200,35 @@ igt_main
target_buffer = drm_intel_bo_alloc(bufmgr, target bo, 4096,
4096);
igt_assert(target_buffer);
+
+ /* Create multi drm_fd and map one gem object to multi
gem_contexts */
+ {
+ unsigned int target_flink;
+ char buffer_name[32];
+ if (dri_bo_flink(target_buffer, target_flink)) {
+ printf(fail to get flink for target buffer\n);
+ igt_assert(0);
+ }
+ for (i = 0; i NUM_FD; i++) {
+ mfd[i] = 0;
+ mbufmgr[i] = NULL;
+ mbuffer[i] = NULL;
+ }
+ for (i = 0; i NUM_FD; i++) {
+ sprintf(buffer_name, Target buffer %d\n, i);
+ mfd[i] = drm_open_any();
+ mbufmgr[i] = drm_intel_bufmgr_gem_init(mfd[i],
4096);
+ igt_assert(mbufmgr[i]);
+ drm_intel_bufmgr_gem_enable_reuse(mbufmgr[i]);
+ mbatch[i] = intel_batchbuffer_alloc(mbufmgr[i],
devid);
+ igt_assert(mbufmgr[i]);
+ mbuffer[i] = intel_bo_gem_create_from_name(
+ mbufmgr[i],
+ buffer_name,
+ target_flink);
+ igt_assert(mbuffer[i]);
+ }
+ }
}
igt_subtest(render) {
@@ -190,8 +271,27 @@ igt_main
printf(dummy loop run on random rings completed\n);
}
}
-
+ igt_subtest(mixed_multi_fd) {
[Intel-gfx] [PATCH I-g-t V2 0/2] Tests: Add test cases based on multi drm_fd to test sync
This follows Daniel's advice to add the two test cases based on multi drm_fd to test the ring sync and CPU-GPU sync. The Broadwell GT3 machine has two independent BSD rings that can be used to process the video commands. This is implemented in kernel driver and transparent to the user-space. But we still need to check the ring sync and CPU-GPU sync for the second BSD ring. Two tests are created based on the multi drm_fds to test the sync. Multi drm_fd can assure that the second BSD ring has the opportunity to dispatch the GPU command. V1-V2: Follow Daniel's comment to add one subtext instead of one individual test case, which is used to test the CPU-GPU sync under multi BSD rings/ Zhao Yakui (2): tests: Add one ring sync case based on multi drm_fd to test ring semaphore sync under multi BSD rings tests/gem_dummy_reloc_loop: Add one subtest based on multi drm_fd to test CPU-GPU sync under multi BSD rings tests/Makefile.sources |1 + tests/gem_dummy_reloc_loop.c| 102 ++- tests/gem_multi_bsd_sync_loop.c | 172 +++ 3 files changed, 274 insertions(+), 1 deletion(-) create mode 100644 tests/gem_multi_bsd_sync_loop.c -- 1.7.10.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH I-g-t V2 1/2] tests: Add one ring sync case based on multi drm_fd to test ring semaphore sync under multi BSD rings
The Broadwell GT3 machine has two independent BSD rings in kernel driver while
it is transparent to the user-space driver. In such case it needs to check
the ring sync between the two BSD rings. At the same time it also needs to
check the sync among the second BSD ring and the other rings.
Signed-off-by: Zhao Yakui yakui.z...@intel.com
---
tests/Makefile.sources |1 +
tests/gem_multi_bsd_sync_loop.c | 172 +++
2 files changed, 173 insertions(+)
create mode 100644 tests/gem_multi_bsd_sync_loop.c
diff --git a/tests/Makefile.sources b/tests/Makefile.sources
index c957ace..7cd9ca8 100644
--- a/tests/Makefile.sources
+++ b/tests/Makefile.sources
@@ -105,6 +105,7 @@ TESTS_progs = \
gem_render_tiled_blits \
gem_ring_sync_copy \
gem_ring_sync_loop \
+ gem_multi_bsd_sync_loop \
gem_seqno_wrap \
gem_set_tiling_vs_gtt \
gem_set_tiling_vs_pwrite \
diff --git a/tests/gem_multi_bsd_sync_loop.c b/tests/gem_multi_bsd_sync_loop.c
new file mode 100644
index 000..7f5b832
--- /dev/null
+++ b/tests/gem_multi_bsd_sync_loop.c
@@ -0,0 +1,172 @@
+/*
+ * Copyright © 2014 Intel Corporation
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the Software),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
+ * IN THE SOFTWARE.
+ *
+ * Authors:
+ *Daniel Vetter daniel.vet...@ffwll.ch (based on gem_ring_sync_loop_*.c)
+ *Zhao Yakui yakui.z...@intel.com
+ *
+ */
+
+#include stdlib.h
+#include stdio.h
+#include string.h
+#include fcntl.h
+#include inttypes.h
+#include errno.h
+#include sys/stat.h
+#include sys/time.h
+#include drm.h
+#include ioctl_wrappers.h
+#include drmtest.h
+#include intel_bufmgr.h
+#include intel_batchbuffer.h
+#include intel_io.h
+#include i830_reg.h
+#include intel_chipset.h
+
+static drm_intel_bufmgr *bufmgr;
+struct intel_batchbuffer *batch;
+static drm_intel_bo *target_buffer;
+
+#define NUM_FD 50
+
+static int mfd[NUM_FD];
+static drm_intel_bufmgr *mbufmgr[NUM_FD];
+static struct intel_batchbuffer *mbatch[NUM_FD];
+static drm_intel_bo *mbuffer[NUM_FD];
+
+
+/*
+ * Testcase: Basic check of ring-ring sync using a dummy reloc
+ *
+ * Extremely efficient at catching missed irqs with semaphores=0 ...
+ */
+
+#define MI_COND_BATCH_BUFFER_END (0x3623 | 1)
+#define MI_DO_COMPARE (121)
+
+static void
+store_dword_loop(int fd)
+{
+ int i;
+ int num_rings = gem_get_num_rings(fd);
+
+ srandom(0xdeadbeef);
+
+ for (i = 0; i SLOW_QUICK(0x10, 10); i++) {
+ int ring, mindex;
+ ring = random() % num_rings + 1;
+ mindex = random() % NUM_FD;
+ batch = mbatch[mindex];
+ if (ring == I915_EXEC_RENDER) {
+ BEGIN_BATCH(4);
+ OUT_BATCH(MI_COND_BATCH_BUFFER_END | MI_DO_COMPARE);
+ OUT_BATCH(0x); /* compare dword */
+ OUT_RELOC(mbuffer[mindex], I915_GEM_DOMAIN_RENDER,
+ I915_GEM_DOMAIN_RENDER, 0);
+ OUT_BATCH(MI_NOOP);
+ ADVANCE_BATCH();
+ } else {
+ BEGIN_BATCH(4);
+ OUT_BATCH(MI_FLUSH_DW | 1);
+ OUT_BATCH(0); /* reserved */
+ OUT_RELOC(mbuffer[mindex], I915_GEM_DOMAIN_RENDER,
+ I915_GEM_DOMAIN_RENDER, 0);
+ OUT_BATCH(MI_NOOP | (122) | (0xf));
+ ADVANCE_BATCH();
+ }
+ intel_batchbuffer_flush_on_ring(batch, ring);
+ }
+
+ drm_intel_bo_map(target_buffer, 0);
+ // map to force waiting on rendering
+ drm_intel_bo_unmap(target_buffer);
+}
+
+igt_simple_main
+{
+ int fd;
+ int devid;
+ int i;
+
+ fd = drm_open_any();
+ devid = intel_get_drm_devid(fd);
+ gem_require_ring(fd, I915_EXEC_BLT);
+
+
[Intel-gfx] linux-next: manual merge of the drm-intel tree with the tree
Hi all,
Today's linux-next merge of the drm-intel tree got a conflict in
drivers/gpu/drm/i915/i915_gem_context.c between commit 691e6415c891
(drm/i915: Always use kref tracking for all contexts) from the
drm-intel-fixes tree and commit ad2ac08bf34b (drm/i915: Make contexts
non-snooped on non-LLC platforms) from the drm-intel tree.
I fixed it up (see below) and can carry the fix as necessary (no action
is required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
diff --cc drivers/gpu/drm/i915/i915_gem_context.c
index d72db15afa02,30b355afb362..
--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/i915_gem_context.c
@@@ -231,32 -232,40 +231,40 @@@ __create_hw_context(struct drm_device *
return ERR_PTR(-ENOMEM);
kref_init(ctx-ref);
- ctx-obj = i915_gem_alloc_object(dev, dev_priv-hw_context_size);
- INIT_LIST_HEAD(ctx-link);
- if (ctx-obj == NULL) {
- kfree(ctx);
- DRM_DEBUG_DRIVER(Context object allocated failed\n);
- return ERR_PTR(-ENOMEM);
- }
+ list_add_tail(ctx-link, dev_priv-context_list);
- /*
- * Try to make the context utilize L3 as well as LLC.
- *
- * On VLV we don't have L3 controls in the PTEs so we
- * shouldn't touch the cache level, especially as that
- * would make the object snooped which might have a
- * negative performance impact.
- */
- if (INTEL_INFO(dev)-gen = 7 !IS_VALLEYVIEW(dev)) {
- ret = i915_gem_object_set_cache_level(ctx-obj,
-I915_CACHE_L3_LLC);
- /* Failure shouldn't ever happen this early */
- if (WARN_ON(ret))
+ if (dev_priv-hw_context_size) {
+ ctx-obj = i915_gem_alloc_object(dev,
dev_priv-hw_context_size);
+ if (ctx-obj == NULL) {
+ ret = -ENOMEM;
goto err_out;
- }
+ }
- if (INTEL_INFO(dev)-gen = 7) {
- list_add_tail(ctx-link, dev_priv-context_list);
++ /*
++ * Try to make the context utilize L3 as well as LLC.
++ *
++ * On VLV we don't have L3 controls in the PTEs so we
++ * shouldn't touch the cache level, especially as that
++ * would make the object snooped which might have a
++ * negative performance impact.
++ */
++ if (INTEL_INFO(dev)-gen = 7 !IS_VALLEYVIEW(dev)) {
+ ret = i915_gem_object_set_cache_level(ctx-obj,
+
I915_CACHE_L3_LLC);
+ /* Failure shouldn't ever happen this early */
+ if (WARN_ON(ret))
+ goto err_out;
+ }
+ }
/* Default context will never have a file_priv */
- if (file_priv == NULL)
- return ctx;
-
- ret = idr_alloc(file_priv-context_idr, ctx, DEFAULT_CONTEXT_ID, 0,
- GFP_KERNEL);
- if (ret 0)
- goto err_out;
+ if (file_priv != NULL) {
+ ret = idr_alloc(file_priv-context_idr, ctx,
+ DEFAULT_CONTEXT_ID, 0, GFP_KERNEL);
+ if (ret 0)
+ goto err_out;
+ } else
+ ret = DEFAULT_CONTEXT_ID;
ctx-file_priv = file_priv;
ctx-id = ret;
pgpE5Vz1kWbHg.pgp
Description: PGP signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
