[Intel-gfx] Linux 3.19-rc1: i915.ko error messages at boot
lspci output: 00:02.0 VGA compatible controller [0300]: Intel Corporation 4th Gen Core Processor Integrated Graphics Controller [8086:0416] (rev 06) dmesg output: [2.379847] [drm:hsw_unclaimed_reg_detect.isra.6 [i915]] *ERROR* Unclaimed register detected. Please use the i915.mmio_debug=1 to debug this problem. [2.379847] [drm:intel_uncore_check_errors [i915]] *ERROR* Unclaimed register before interrupt [2.379868] [drm:hsw_unclaimed_reg_detect.isra.6 [i915]] *ERROR* Unclaimed register detected. Please use the i915.mmio_debug=1 to debug this problem. [2.379869] [drm:hsw_unclaimed_reg_detect.isra.6 [i915]] *ERROR* Unclaimed register detected. Please use the i915.mmio_debug=1 to debug this problem. [2.430637] [drm:hsw_unclaimed_reg_detect.isra.6 [i915]] *ERROR* Unclaimed register detected. Please use the i915.mmio_debug=1 to debug this problem.3[2.430649] [drm:intel_uncore_check_errors [i915]] *ERROR* Unclaimed register before interrupt [2.430756] [drm:hsw_unclaimed_reg_detect.isra.6 [i915]] *ERROR* Unclaimed register detected. Please use the i915.mmio_debug=1 to debug this problem. [2.430817] [drm:hsw_unclaimed_reg_detect.isra.6 [i915]] *ERROR* Unclaimed register detected. Please use the i915.mmio_debug=1 to debug this problem.[drm:hsw_unclaimed_reg_detect.isra.6 [i915]] *ERROR* Unclaimed register detected. Please use the i915.mmio_debug=1 to debug this problem. [2.430948] [drm:hsw_unclaimed_reg_detect.isra.6 [i915]] *ERROR* Unclaimed register detected. Please use the i915.mmio_debug=1 to debug this problem.[drm:hsw_unclaimed_reg_detect.isra.6 [i915]] *ERROR* Unclaimed register detected. Please use the i915.mmio_debug=1 to debug this problem. [2.619114] [drm:intel_uncore_check_errors [i915]] *ERROR* Unclaimed register before interrupt [2.619213] [drm:hsw_unclaimed_reg_detect.isra.6 [i915]] *ERROR* Unclaimed register detected. Please use the i915.mmio_debug=1 to debug this problem. [2.619275] [drm:hsw_unclaimed_reg_detect.isra.6 [i915]] *ERROR* Unclaimed register detected. Please use the i915.mmio_debug=1 to debug this problem.[drm:hsw_unclaimed_reg_detect.isra.6 [i915]] *ERROR* Unclaimed register detected. Please use the i915.mmio_debug=1 to debug this problem. [2.626522] [drm:intel_uncore_check_errors [i915]] *ERROR* Unclaimed register before interrupt [2.626616] [drm:hsw_unclaimed_reg_detect.isra.6 [i915]] *ERROR* Unclaimed register detected. Please use the i915.mmio_debug=1 to debug this problem. [2.626678] [drm:hsw_unclaimed_reg_detect.isra.6 [i915]] *ERROR* Unclaimed register detected. Please use the i915.mmio_debug=1 to debug this problem.6[2.633412] AVX2 version of gcm_enc/dec engaged. -- Pali Rohár pali.ro...@gmail.com signature.asc Description: This is a digitally signed message part. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/5] drm/i915: Refactor work that can sleep out of commit (v7)
Once we integrate our work into the atomic pipeline, plane commit
operations will need to happen with interrupts disabled, due to vblank
evasion. Our commit functions today include sleepable work, so those
operations need to be split out and run either before or after the
atomic register programming.
The solution here calculates which of those operations will need to be
performed during the 'check' phase and sets flags in an intel_crtc
sub-struct. New intel_begin_crtc_commit() and
intel_finish_crtc_commit() functions are added before and after the
actual register programming; these will eventually be called from the
atomic plane helper's .atomic_begin() and .atomic_end() entrypoints.
v2: Fix broken sprite code split
v3: Make the pre/post commit work crtc-based to match how we eventually
want this to be called from the atomic plane helpers.
v4: Some platforms that haven't had their watermark code reworked were
waiting for vblank, then calling update_sprite_watermarks in their
platform-specific disable code. These also need to be flagged out
of the critical section.
v5: Sprite plane test for primary show/hide should just set the flag to
wait for pending flips, not actually perform the wait. (Ander)
v6:
- Rebase onto latest di-nightly; picks up an important runtime PM fix.
- Handle 'wait_for_flips' flag in intel_begin_crtc_commit(). (Ander)
- Use wait_for_flips flag for primary plane update rather than
performing the wait in the check routine.
- Added kerneldoc to pre_disable/post_enable functions that are no
longer static. (Ander)
- Replace assert_pipe_enabled() in intel_disable_primary_hw_plane()
with an intel_crtc-active test; it turns out assert_pipe_enabled()
grabs some mutexes and can sleep, which we can't do with interrupts
disabled.
v7:
- Check for fb != NULL when deciding whether the sprite plane hides the
primary plane during a sprite update. (PRTS)
Signed-off-by: Matt Roper matthew.d.ro...@intel.com
---
drivers/gpu/drm/i915/intel_display.c | 199 ++-
drivers/gpu/drm/i915/intel_drv.h | 31 ++
drivers/gpu/drm/i915/intel_sprite.c | 98 -
3 files changed, 209 insertions(+), 119 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index a03955d..6bd44f3 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -2165,7 +2165,8 @@ static void intel_disable_primary_hw_plane(struct
drm_plane *plane,
struct drm_i915_private *dev_priv = dev-dev_private;
struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
- assert_pipe_enabled(dev_priv, intel_crtc-pipe);
+ if (WARN_ON(!intel_crtc-active))
+ return;
if (!intel_crtc-primary_enabled)
return;
@@ -11737,7 +11738,11 @@ static int
intel_check_primary_plane(struct drm_plane *plane,
struct intel_plane_state *state)
{
+ struct drm_device *dev = plane-dev;
+ struct drm_i915_private *dev_priv = dev-dev_private;
struct drm_crtc *crtc = state-base.crtc;
+ struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
+ struct intel_plane *intel_plane = to_intel_plane(plane);
struct drm_framebuffer *fb = state-base.fb;
struct drm_rect *dest = state-dst;
struct drm_rect *src = state-src;
@@ -11752,10 +11757,40 @@ intel_check_primary_plane(struct drm_plane *plane,
if (ret)
return ret;
- intel_crtc_wait_for_pending_flips(crtc);
- if (intel_crtc_has_pending_flip(crtc)) {
- DRM_ERROR(pipe is still busy with an old pageflip\n);
- return -EBUSY;
+ if (intel_crtc-active) {
+ intel_crtc-atomic.wait_for_flips = true;
+
+ /*
+* FBC does not work on some platforms for rotated
+* planes, so disable it when rotation is not 0 and
+* update it when rotation is set back to 0.
+*
+* FIXME: This is redundant with the fbc update done in
+* the primary plane enable function except that that
+* one is done too late. We eventually need to unify
+* this.
+*/
+ if (intel_crtc-primary_enabled
+ INTEL_INFO(dev)-gen = 4 !IS_G4X(dev)
+ dev_priv-fbc.plane == intel_crtc-plane
+ intel_plane-rotation != BIT(DRM_ROTATE_0)) {
+ intel_crtc-atomic.disable_fbc = true;
+ }
+
+ if (state-visible) {
+ /*
+* BDW signals flip done immediately if the plane
+* is disabled, even if the plane enable is already
+* armed to occur at the next vblank :(
+*/
+ if (IS_BROADWELL(dev)
[Intel-gfx] 3.19-rc1 errors when opening LID
Hello! With new 3.19-rc1 kernel every time when I open LID on my laptop, kernel prints these error lines to dmesg: [25566.368133] [drm:hsw_unclaimed_reg_detect.isra.6 [i915]] *ERROR* Unclaimed register detected. Please use the i915.mmio_debug=1 to debug this problem. [25566.368134] [drm:intel_uncore_check_errors [i915]] *ERROR* Unclaimed register before interrupt [25566.368192] [drm:hsw_unclaimed_reg_detect.isra.6 [i915]] *ERROR* Unclaimed register detected. Please use the i915.mmio_debug=1 to debug this problem. [25566.368232] [drm:hsw_unclaimed_reg_detect.isra.6 [i915]] *ERROR* Unclaimed register detected. Please use the i915.mmio_debug=1 to debug this problem.4[25568.446011] i915 :00:02.0: BAR 6: [??? 0x flags 0x2] has bogus alignment [25568.447018] pci_bus :02: Allocating resources [25568.447055] pci_bus :03: Allocating resources [25568.447135] pci_bus :04: Allocating resources [25568.447168] pci_bus :05: Allocating resources [25568.447195] pci_bus :06: Allocating resources [25568.447228] pci_bus :0e: Allocating resources [25568.447323] i915 :00:02.0: BAR 6: [??? 0x flags 0x2] has bogus alignment [25568.447557] i915 :00:02.0: BAR 6: [??? 0x flags 0x2] has bogus alignment [25568.447735] i915 :00:02.0: BAR 6: [??? 0x flags 0x2] has bogus alignment [25568.447847] i915 :00:02.0: BAR 6: [??? 0x flags 0x2] has bogus alignment [25568.448399] i915 :00:02.0: BAR 6: [??? 0x flags 0x2] has bogus alignment [25568.448438] i915 :00:02.0: BAR 6: [??? 0x flags 0x2] has bogus alignment [25568.448566] acpi MSFT:00: Cannot transition to power state D3cold for parent in (unknown) [25568.448572] acpi INT33C2:00: Cannot transition to non-D0 state from D3 [25568.448577] acpi MSFT0002:00: Cannot transition to power state D3cold for parent in (unknown) [25568.448581] acpi ELAN1010:00: Cannot transition to power state D3cold for parent in (unknown) [25568.448587] acpi INT33C3:00: Cannot transition to non-D0 state from D3 [25568.448590] acpi INT33C0:00: Cannot transition to non-D0 state from D3 [25568.448594] acpi INT33C1:00: Cannot transition to non-D0 state from D3 [25568.448598] acpi INT33C4:00: Cannot transition to non-D0 state from D3 [25568.448602] acpi INT33C5:00: Cannot transition to non-D0 state from D3 [25568.448623] acpi device:41: Cannot transition to power state D3cold for parent in (unknown) [25568.448627] acpi INT33C6:00: Cannot transition to non-D0 state from D3 [25568.448890] pci_bus :01: Allocating resources [25568.448905] i915 :00:02.0: BAR 6: [??? 0x flags 0x2] has bogus alignment [25568.449064] i915 :00:02.0: BAR 6: [??? 0x flags 0x2] has bogus alignment [25568.449472] i915 :00:02.0: BAR 6: [??? 0x flags 0x2] has bogus alignment With older kernel (3.13) I do not see these errors, so it is regression. Can you look at it? If it is needed, I can provide other logs, ACPI/DSTD dumps, etc. -- Pali Rohár pali.ro...@gmail.com signature.asc Description: This is a digitally signed message part. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 00/11] drm-intel-collector - update
This is another drm-intel-collector updated notice: http://cgit.freedesktop.org/~vivijim/drm-intel/log/?h=drm-intel-collector Here goes the update list in order for better reviewers assignment: Patch drm/i915: Specify bsd rings through exec flag - Reviewer: Patch drm/i915: add I915_PARAM_HAS_BSD2 to i915_getparam - Reviewer: Patch drm/i915: Move the ban period onto the context - Reviewer: Patch drm/i915: Add ioctl to set per-context parameters - Reviewer: Patch drm/i915: Put logical pipe_control emission into a helper. - Reviewer: Patch drm/i915: Add WaCsStallBeforeStateCacheInvalidate:bdw, chv to logical ring - Reviewer: Patch drm/i915: Remove pinned check from madvise_ioctl - Reviewer: Patch drm/i915: Extend GET_APERTURE ioctl to report available map space - Reviewer: Patch drm/i915: Display current hangcheck status in debugfs - Reviewer: Patch drm/i915/vlv: check port in infoframe_enabled v2 - Reviewer: Patch drm/i915: vlv: fix save/restore of GFX_MAX_REQ_COUNT reg - Reviewer: Round from discussions ended between Nov 21 to Dec 05. Thanks, Rodrigo. Chris Wilson (5): drm/i915: Move the ban period onto the context drm/i915: Add ioctl to set per-context parameters drm/i915: Remove pinned check from madvise_ioctl drm/i915: Extend GET_APERTURE ioctl to report available map space drm/i915: Display current hangcheck status in debugfs Imre Deak (1): drm/i915: vlv: fix save/restore of GFX_MAX_REQ_COUNT reg Jesse Barnes (1): drm/i915/vlv: check port in infoframe_enabled v2 Rodrigo Vivi (2): drm/i915: Put logical pipe_control emission into a helper. drm/i915: Add WaCsStallBeforeStateCacheInvalidate:bdw, chv to logical ring Zhipeng Gong (2): drm/i915: Specify bsd rings through exec flag drm/i915: add I915_PARAM_HAS_BSD2 to i915_getparam drivers/gpu/drm/i915/i915_debugfs.c| 62 +++ drivers/gpu/drm/i915/i915_dma.c| 5 ++ drivers/gpu/drm/i915/i915_drv.c| 4 +- drivers/gpu/drm/i915/i915_drv.h| 9 +++ drivers/gpu/drm/i915/i915_gem.c| 119 ++--- drivers/gpu/drm/i915/i915_gem_context.c| 71 + drivers/gpu/drm/i915/i915_gem_execbuffer.c | 19 - drivers/gpu/drm/i915/intel_hdmi.c | 7 +- drivers/gpu/drm/i915/intel_lrc.c | 41 +++--- include/uapi/drm/i915_drm.h| 46 ++- 10 files changed, 354 insertions(+), 29 deletions(-) -- 1.9.3 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 09/11] drm/i915: Display current hangcheck status in debugfs
From: Chris Wilson ch...@chris-wilson.co.uk
For example,
/sys/kernel/debug/dri/0/i915_hangcheck_info:
Hangcheck active, fires in 15887800ms
render ring:
seqno = -4059 [current -583]
action = 2
score = 0
ACTHD = 1ee8 [current 21f980]
max ACTHD = 0
v2: Include expiration ETA. Can anyone spot a problem?
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
Cc: Mika Kuoppala mika.kuopp...@intel.com
Tested-By: PRC QA PRTS (Patch Regression Test System Contact:
shuang...@intel.com)
Signed-off-by: Rodrigo Vivi rodrigo.v...@intel.com
---
drivers/gpu/drm/i915/i915_debugfs.c | 35 +++
1 file changed, 35 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index 9619270..5691594 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -1245,6 +1245,40 @@ out:
return ret;
}
+static int i915_hangcheck_info(struct seq_file *m, void *unused)
+{
+ struct drm_info_node *node = m-private;
+ struct drm_i915_private *dev_priv = to_i915(node-minor-dev);
+ struct intel_engine_cs *ring;
+ int i;
+
+ if (!i915.enable_hangcheck) {
+ seq_printf(m, Hangcheck disabled\n);
+ return 0;
+ }
+
+ if (timer_pending(dev_priv-gpu_error.hangcheck_timer)) {
+ seq_printf(m, Hangcheck active, fires in %dms\n,
+
jiffies_to_msecs(dev_priv-gpu_error.hangcheck_timer.expires - jiffies));
+ } else
+ seq_printf(m, Hangcheck inactive\n);
+
+ for_each_ring(ring, dev_priv, i) {
+ seq_printf(m, %s:\n, ring-name);
+ seq_printf(m, \tseqno = %d [current %d]\n,
+ ring-hangcheck.seqno, ring-get_seqno(ring, false));
+ seq_printf(m, \taction = %d\n, ring-hangcheck.action);
+ seq_printf(m, \tscore = %d\n, ring-hangcheck.score);
+ seq_printf(m, \tACTHD = 0x%08llx [current 0x%08llx]\n,
+ (long long)ring-hangcheck.acthd,
+ (long long)intel_ring_get_active_head(ring));
+ seq_printf(m, \tmax ACTHD = 0x%08llx\n,
+ (long long)ring-hangcheck.max_acthd);
+ }
+
+ return 0;
+}
+
static int ironlake_drpc_info(struct seq_file *m)
{
struct drm_info_node *node = m-private;
@@ -4438,6 +4472,7 @@ static const struct drm_info_list i915_debugfs_list[] = {
{i915_gem_hws_vebox, i915_hws_info, 0, (void *)VECS},
{i915_gem_batch_pool, i915_gem_batch_pool_info, 0},
{i915_frequency_info, i915_frequency_info, 0},
+ {i915_hangcheck_info, i915_hangcheck_info, 0},
{i915_drpc_info, i915_drpc_info, 0},
{i915_emon_status, i915_emon_status, 0},
{i915_ring_freq_table, i915_ring_freq_table, 0},
--
1.9.3
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 11/11] drm/i915: vlv: fix save/restore of GFX_MAX_REQ_COUNT reg
From: Imre Deak imre.d...@intel.com Due this typo we don't save/restore the GFX_MAX_REQ_COUNT register across suspend/resume, so fix this. This was introduced in commit ddeea5b0c36f3665446518c609be91f9336ef674 Author: Imre Deak imre.d...@intel.com Date: Mon May 5 15:19:56 2014 +0300 drm/i915: vlv: add runtime PM support I noticed this only by reading the code. To my knowledge it shouldn't cause any real problems at the moment, since the power well backing this register remains on across a runtime s/r. This may change once system-wide s0ix functionality is enabled in the kernel. v2: - resend after a missing git add -u :/ Signed-off-by: Imre Deak imre.d...@intel.com Tested-By: PRC QA PRTS (Patch Regression Test System Contact: shuang...@intel.com) Signed-off-by: Rodrigo Vivi rodrigo.v...@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 f702921..7dc8dae 100644 --- a/drivers/gpu/drm/i915/i915_drv.c +++ b/drivers/gpu/drm/i915/i915_drv.c @@ -1031,7 +1031,7 @@ static void vlv_save_gunit_s0ix_state(struct drm_i915_private *dev_priv) 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-gfx_max_req_count= I915_READ(GEN7_GFX_MAX_REQ_COUNT); s-render_hwsp = I915_READ(RENDER_HWS_PGA_GEN7); s-ecochk = I915_READ(GAM_ECOCHK); @@ -1112,7 +1112,7 @@ static void vlv_restore_gunit_s0ix_state(struct drm_i915_private *dev_priv) I915_WRITE(GEN7_LRA_LIMITS_BASE + i * 4, s-lra_limits[i]); I915_WRITE(GEN7_MEDIA_MAX_REQ_COUNT, s-media_max_req_count); - I915_WRITE(GEN7_MEDIA_MAX_REQ_COUNT, s-gfx_max_req_count); + I915_WRITE(GEN7_GFX_MAX_REQ_COUNT, s-gfx_max_req_count); I915_WRITE(RENDER_HWS_PGA_GEN7, s-render_hwsp); I915_WRITE(GAM_ECOCHK, s-ecochk); -- 1.9.3 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 01/11] drm/i915: Specify bsd rings through exec flag
From: Zhipeng Gong zhipeng.g...@intel.com
On Skylake GT3 we have 2 Video Command Streamers (VCS), which is asymmetrical.
For example, HEVC GPU commands can be only dispatched to VCS1 ring.
But userspace has no control when using VCS1 or VCS2. This patch introduces
a mechanism to avoid the default ping-pong mode and use one specific ring
through execution flag. This mechanism is usable for all the platforms
with 2 VCS rings.
v2: fix whitespace (Rodrigo)
v3: remove incorrect chunk that came on -collector rebase. (Rodrigo)
v4: change the comment (Zhipeng)
Signed-off-by: Zhipeng Gong zhipeng.g...@intel.com
Reviewed-by-by: Rodrigo Vivi rodrigo.v...@intel.com
Signed-off-by: Rodrigo Vivi rodrigo.v...@intel.com
---
drivers/gpu/drm/i915/i915_gem_execbuffer.c | 19 +--
include/uapi/drm/i915_drm.h| 8 +++-
2 files changed, 24 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
index 8330660..a9bcfab 100644
--- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
@@ -1386,8 +1386,23 @@ i915_gem_do_execbuffer(struct drm_device *dev, void
*data,
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];
+
+ switch (args-flags I915_EXEC_BSD_MASK) {
+ case I915_EXEC_BSD_DEFAULT:
+ ring_id = gen8_dispatch_bsd_ring(dev, file);
+ ring = dev_priv-ring[ring_id];
+ break;
+ case I915_EXEC_BSD_RING1:
+ ring = dev_priv-ring[VCS];
+ break;
+ case I915_EXEC_BSD_RING2:
+ ring = dev_priv-ring[VCS2];
+ break;
+ default:
+ DRM_DEBUG(execbuf with unknown bsd ring: %d\n,
+ (int)(args-flags
I915_EXEC_BSD_MASK));
+ return -EINVAL;
+ }
} else
ring = dev_priv-ring[VCS];
} else
diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h
index 2502622..fcb16bf 100644
--- a/include/uapi/drm/i915_drm.h
+++ b/include/uapi/drm/i915_drm.h
@@ -737,7 +737,13 @@ struct drm_i915_gem_execbuffer2 {
*/
#define I915_EXEC_HANDLE_LUT (112)
-#define __I915_EXEC_UNKNOWN_FLAGS -(I915_EXEC_HANDLE_LUT1)
+/** Used for switching BSD rings on the platforms with two BSD rings */
+#define I915_EXEC_BSD_MASK (313)
+#define I915_EXEC_BSD_DEFAULT (013) /* default ping-pong mode */
+#define I915_EXEC_BSD_RING1(113)
+#define I915_EXEC_BSD_RING2(213)
+
+#define __I915_EXEC_UNKNOWN_FLAGS -(115)
#define I915_EXEC_CONTEXT_ID_MASK (0x)
#define i915_execbuffer2_set_context_id(eb2, context) \
--
1.9.3
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 04/11] drm/i915: Add ioctl to set per-context parameters
From: Chris Wilson ch...@chris-wilson.co.uk
Sometimes we wish to tweak how an individual context behaves. Since we
always create a context for every filp, this means that individual
processes can fine tune their behaviour even if they do not explicitly
create a context.
The first example parameter here is to enable multi-process GPU testing,
but the interface should be able to cope with passing arbitrarily complex
parameters.
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
Signed-off-by: Rodrigo Vivi rodrigo.v...@intel.com
---
drivers/gpu/drm/i915/i915_dma.c | 2 +
drivers/gpu/drm/i915/i915_drv.h | 4 ++
drivers/gpu/drm/i915/i915_gem_context.c | 69 +
include/uapi/drm/i915_drm.h | 12 ++
4 files changed, 87 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
index 126a36f..3c3f33f 100644
--- a/drivers/gpu/drm/i915/i915_dma.c
+++ b/drivers/gpu/drm/i915/i915_dma.c
@@ -1066,6 +1066,8 @@ const struct drm_ioctl_desc i915_ioctls[] = {
DRM_IOCTL_DEF_DRV(I915_REG_READ, i915_reg_read_ioctl,
DRM_UNLOCKED|DRM_RENDER_ALLOW),
DRM_IOCTL_DEF_DRV(I915_GET_RESET_STATS, i915_get_reset_stats_ioctl,
DRM_UNLOCKED|DRM_RENDER_ALLOW),
DRM_IOCTL_DEF_DRV(I915_GEM_USERPTR, i915_gem_userptr_ioctl,
DRM_UNLOCKED|DRM_RENDER_ALLOW),
+ DRM_IOCTL_DEF_DRV(I915_GEM_CONTEXT_GETPARAM,
i915_gem_context_getparam_ioctl, DRM_UNLOCKED|DRM_RENDER_ALLOW),
+ DRM_IOCTL_DEF_DRV(I915_GEM_CONTEXT_SETPARAM,
i915_gem_context_setparam_ioctl, DRM_UNLOCKED|DRM_RENDER_ALLOW),
};
int i915_max_ioctl = ARRAY_SIZE(i915_ioctls);
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 3749415..9ae515e 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2898,6 +2898,10 @@ int i915_gem_context_create_ioctl(struct drm_device
*dev, void *data,
struct drm_file *file);
int i915_gem_context_destroy_ioctl(struct drm_device *dev, void *data,
struct drm_file *file);
+int i915_gem_context_getparam_ioctl(struct drm_device *dev, void *data,
+ struct drm_file *file_priv);
+int i915_gem_context_setparam_ioctl(struct drm_device *dev, void *data,
+ struct drm_file *file_priv);
/* i915_gem_evict.c */
int __must_check i915_gem_evict_something(struct drm_device *dev,
diff --git a/drivers/gpu/drm/i915/i915_gem_context.c
b/drivers/gpu/drm/i915/i915_gem_context.c
index bf9778e..8603bf4 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/i915_gem_context.c
@@ -794,3 +794,72 @@ int i915_gem_context_destroy_ioctl(struct drm_device *dev,
void *data,
DRM_DEBUG_DRIVER(HW context %d destroyed\n, args-ctx_id);
return 0;
}
+
+int i915_gem_context_getparam_ioctl(struct drm_device *dev, void *data,
+ struct drm_file *file)
+{
+ struct drm_i915_file_private *file_priv = file-driver_priv;
+ struct drm_i915_gem_context_param *args = data;
+ struct intel_context *ctx;
+ int ret;
+
+ ret = i915_mutex_lock_interruptible(dev);
+ if (ret)
+ return ret;
+
+ ctx = i915_gem_context_get(file_priv, args-ctx_id);
+ if (IS_ERR(ctx)) {
+ mutex_unlock(dev-struct_mutex);
+ return PTR_ERR(ctx);
+ }
+
+ args-size = 0;
+ switch (args-param) {
+ case I915_CONTEXT_PARAM_BAN_PERIOD:
+ args-value = ctx-hang_stats.ban_period_seconds;
+ break;
+ default:
+ ret = -EINVAL;
+ break;
+ }
+ mutex_unlock(dev-struct_mutex);
+
+ return ret;
+}
+
+int i915_gem_context_setparam_ioctl(struct drm_device *dev, void *data,
+ struct drm_file *file)
+{
+ struct drm_i915_file_private *file_priv = file-driver_priv;
+ struct drm_i915_gem_context_param *args = data;
+ struct intel_context *ctx;
+ int ret;
+
+ ret = i915_mutex_lock_interruptible(dev);
+ if (ret)
+ return ret;
+
+ ctx = i915_gem_context_get(file_priv, args-ctx_id);
+ if (IS_ERR(ctx)) {
+ mutex_unlock(dev-struct_mutex);
+ return PTR_ERR(ctx);
+ }
+
+ switch (args-param) {
+ case I915_CONTEXT_PARAM_BAN_PERIOD:
+ if (args-size)
+ ret = -EINVAL;
+ else if (args-value ctx-hang_stats.ban_period_seconds
+!capable(CAP_SYS_ADMIN))
+ ret = -EPERM;
+ else
+ ctx-hang_stats.ban_period_seconds = args-value;
+ break;
+ default:
+ ret = -EINVAL;
+ break;
+ }
+ mutex_unlock(dev-struct_mutex);
+
+ return ret;
+}
diff --git
[Intel-gfx] [PATCH 08/11] drm/i915: Extend GET_APERTURE ioctl to report available map space
From: Chris Wilson ch...@chris-wilson.co.uk
When constructing a batchbuffer, it is sometimes crucial to know the
largest hole into which we can fit a fenceable buffer (for example when
handling very large objects on gen2 and gen3). This depends on the
fragmentation of pinned buffers inside the aperture, a question only the
kernel can easily answer.
This patch extends the current DRM_I915_GEM_GET_APERTURE ioctl to
include a couple of new fields in its reply to userspace - the total
amount of space available in the mappable region of the aperture and
also the single largest block available.
This is not quite what userspace wants to answer the question of whether
this batch will fit as fences are also required to meet severe alignment
constraints within the batch. For this purpose, a third conservative
estimate of largest fence available is also provided. For when userspace
needs more than one batch, we also provide the culmulative space
available for fences such that it has some additional guidance to how
much space it could allocate to fences. Conservatism still wins.
The patch also adds a debugfs file for convenient testing and reporting.
v2: The first object cannot end at offset 0, so we can use last==0 to
detect the empty list.
v3: Expand all values to 64bit, just in case.
Report total mappable aperture size for userspace that cannot easily
determine it by inspecting the PCI device.
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
Signed-off-by: Rodrigo Vivi rodrigo.v...@intel.com
---
drivers/gpu/drm/i915/i915_debugfs.c | 27 +
drivers/gpu/drm/i915/i915_gem.c | 110 ++--
include/uapi/drm/i915_drm.h | 25
3 files changed, 158 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index e515aad..9619270 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -498,6 +498,32 @@ static int i915_gem_object_info(struct seq_file *m, void*
data)
return 0;
}
+static int i915_gem_aperture_info(struct seq_file *m, void *data)
+{
+ struct drm_info_node *node = m-private;
+ struct drm_i915_gem_get_aperture arg;
+ int ret;
+
+ ret = i915_gem_get_aperture_ioctl(node-minor-dev, arg, NULL);
+ if (ret)
+ return ret;
+
+ seq_printf(m, Total size of the GTT: %llu bytes\n,
+ arg.aper_size);
+ seq_printf(m, Available space in the GTT: %llu bytes\n,
+ arg.aper_available_size);
+ seq_printf(m, Available space in the mappable aperture: %llu bytes\n,
+ arg.map_available_size);
+ seq_printf(m, Single largest space in the mappable aperture: %llu
bytes\n,
+ arg.map_largest_size);
+ seq_printf(m, Available space for fences: %llu bytes\n,
+ arg.fence_available_size);
+ seq_printf(m, Single largest fence available: %llu bytes\n,
+ arg.fence_largest_size);
+
+ return 0;
+}
+
static int i915_gem_gtt_info(struct seq_file *m, void *data)
{
struct drm_info_node *node = m-private;
@@ -4395,6 +4421,7 @@ static int i915_debugfs_create(struct dentry *root,
static const struct drm_info_list i915_debugfs_list[] = {
{i915_capabilities, i915_capabilities, 0},
{i915_gem_objects, i915_gem_object_info, 0},
+ {i915_gem_aperture, i915_gem_aperture_info, 0},
{i915_gem_gtt, i915_gem_gtt_info, 0},
{i915_gem_pinned, i915_gem_gtt_info, 0, (void *) PINNED_LIST},
{i915_gem_active, i915_gem_object_list_info, 0, (void *) ACTIVE_LIST},
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 940fd24..8c4a6e1 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -31,6 +31,7 @@
#include i915_drv.h
#include i915_trace.h
#include intel_drv.h
+#include linux/list_sort.h
#include linux/oom.h
#include linux/shmem_fs.h
#include linux/slab.h
@@ -159,6 +160,49 @@ i915_gem_object_is_inactive(struct drm_i915_gem_object
*obj)
return i915_gem_obj_bound_any(obj) !obj-active;
}
+static int obj_rank_by_ggtt(void *priv,
+ struct list_head *A,
+ struct list_head *B)
+{
+ struct drm_i915_gem_object *a = list_entry(A,typeof(*a), obj_exec_link);
+ struct drm_i915_gem_object *b = list_entry(B,typeof(*b), obj_exec_link);
+
+ return i915_gem_obj_ggtt_offset(a) - i915_gem_obj_ggtt_offset(b);
+}
+
+static u32 __fence_size(struct drm_i915_private *dev_priv, u32 start, u32 end)
+{
+ u32 size = end - start;
+ u32 fence_size;
+
+ if (INTEL_INFO(dev_priv)-gen 4) {
+ u32 fence_max;
+ u32 fence_next;
+
+ if (IS_GEN3(dev_priv)) {
+ fence_max = I830_FENCE_MAX_SIZE_VAL 20;
+ fence_next = 1024*1024;
+
[Intel-gfx] [PATCH 03/11] drm/i915: Move the ban period onto the context
From: Chris Wilson ch...@chris-wilson.co.uk
This will allow us to set per-file, or even per-context, periods in the
future.
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
Signed-off-by: Rodrigo Vivi rodrigo.v...@intel.com
---
drivers/gpu/drm/i915/i915_drv.h | 5 +
drivers/gpu/drm/i915/i915_gem.c | 3 ++-
drivers/gpu/drm/i915/i915_gem_context.c | 2 ++
3 files changed, 9 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 921e4c5..3749415 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -678,6 +678,11 @@ struct i915_ctx_hang_stats {
/* Time when this context was last blamed for a GPU reset */
unsigned long guilty_ts;
+ /* If the contexts causes a second GPU hang within this time,
+* it is permanently banned from submitting any more work.
+*/
+ unsigned long ban_period_seconds;
+
/* This context is banned to submit more work */
bool banned;
};
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 2b6ecfd..67e9100 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -2547,7 +2547,8 @@ static bool i915_context_is_banned(struct
drm_i915_private *dev_priv,
if (ctx-hang_stats.banned)
return true;
- if (elapsed = DRM_I915_CTX_BAN_PERIOD) {
+ if (ctx-hang_stats.ban_period_seconds
+ elapsed = ctx-hang_stats.ban_period_seconds) {
if (!i915_gem_context_is_default(ctx)) {
DRM_DEBUG(context hanging too fast, banning!\n);
return true;
diff --git a/drivers/gpu/drm/i915/i915_gem_context.c
b/drivers/gpu/drm/i915/i915_gem_context.c
index 9b23fb1..bf9778e 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/i915_gem_context.c
@@ -222,6 +222,8 @@ __create_hw_context(struct drm_device *dev,
* is no remap info, it will be a NOP. */
ctx-remap_slice = (1 NUM_L3_SLICES(dev)) - 1;
+ ctx-hang_stats.ban_period_seconds = DRM_I915_CTX_BAN_PERIOD;
+
return ctx;
err_out:
--
1.9.3
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 02/11] drm/i915: add I915_PARAM_HAS_BSD2 to i915_getparam
From: Zhipeng Gong zhipeng.g...@intel.com
This will let userland only try to use the new ring
when the appropriate kernel is present
Signed-off-by: Zhipeng Gong zhipeng.g...@intel.com
Signed-off-by: Rodrigo Vivi rodrigo.v...@intel.com
Reviewed--by: Rodrigo Vivi rodrigo.v...@intel.com
---
drivers/gpu/drm/i915/i915_dma.c | 3 +++
include/uapi/drm/i915_drm.h | 1 +
2 files changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
index 52730ed..126a36f 100644
--- a/drivers/gpu/drm/i915/i915_dma.c
+++ b/drivers/gpu/drm/i915/i915_dma.c
@@ -92,6 +92,9 @@ static int i915_getparam(struct drm_device *dev, void *data,
case I915_PARAM_HAS_VEBOX:
value = intel_ring_initialized(dev_priv-ring[VECS]);
break;
+ case I915_PARAM_HAS_BSD2:
+ value = intel_ring_initialized(dev_priv-ring[VCS2]);
+ break;
case I915_PARAM_HAS_RELAXED_FENCING:
value = 1;
break;
diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h
index fcb16bf..fa99129 100644
--- a/include/uapi/drm/i915_drm.h
+++ b/include/uapi/drm/i915_drm.h
@@ -341,6 +341,7 @@ typedef struct drm_i915_irq_wait {
#define I915_PARAM_HAS_WT 27
#define I915_PARAM_CMD_PARSER_VERSION 28
#define I915_PARAM_HAS_COHERENT_PHYS_GTT 29
+#define I915_PARAM_HAS_BSD2 30
typedef struct drm_i915_getparam {
int param;
--
1.9.3
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 07/11] drm/i915: Remove pinned check from madvise_ioctl
From: Chris Wilson ch...@chris-wilson.co.uk
We don't need to incur the overhead of checking whether the object is
pinned prior to changing its madvise. If the object is pinned, the
madvise will not take effect until it is unpinned and so we cannot free
the pages being pointed at by hardware. Marking a pinned object with
allocated pages as DONTNEED will not trigger any undue warnings. The check
is therefore superfluous, and by removing it we can remove a linear walk
over all the vma the object has.
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
Signed-off-by: Rodrigo Vivi rodrigo.v...@intel.com
---
drivers/gpu/drm/i915/i915_gem.c | 6 --
1 file changed, 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 67e9100..940fd24 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -4369,11 +4369,6 @@ i915_gem_madvise_ioctl(struct drm_device *dev, void
*data,
goto unlock;
}
- if (i915_gem_obj_is_pinned(obj)) {
- ret = -EINVAL;
- goto out;
- }
-
if (obj-pages
obj-tiling_mode != I915_TILING_NONE
dev_priv-quirks QUIRK_PIN_SWIZZLED_PAGES) {
@@ -4392,7 +4387,6 @@ i915_gem_madvise_ioctl(struct drm_device *dev, void *data,
args-retained = obj-madv != __I915_MADV_PURGED;
-out:
drm_gem_object_unreference(obj-base);
unlock:
mutex_unlock(dev-struct_mutex);
--
1.9.3
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 10/11] drm/i915/vlv: check port in infoframe_enabled v2
From: Jesse Barnes jbar...@virtuousgeek.org Same as IBX and G4x, they all share the same genetic material. v2: we all need a bit more port in our lives Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org Tested-By: PRC QA PRTS (Patch Regression Test System Contact: shuang...@intel.com) Signed-off-by: Rodrigo Vivi rodrigo.v...@intel.com --- drivers/gpu/drm/i915/intel_hdmi.c | 7 ++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/intel_hdmi.c b/drivers/gpu/drm/i915/intel_hdmi.c index 3abc200..62606e6 100644 --- a/drivers/gpu/drm/i915/intel_hdmi.c +++ b/drivers/gpu/drm/i915/intel_hdmi.c @@ -323,10 +323,15 @@ static bool vlv_infoframe_enabled(struct drm_encoder *encoder) struct drm_device *dev = encoder-dev; struct drm_i915_private *dev_priv = dev-dev_private; struct intel_crtc *intel_crtc = to_intel_crtc(encoder-crtc); + struct intel_digital_port *intel_dig_port = enc_to_dig_port(encoder); int reg = VLV_TVIDEO_DIP_CTL(intel_crtc-pipe); u32 val = I915_READ(reg); + u32 port = intel_dig_port-port; - return val VIDEO_DIP_ENABLE; + if (port == (val VIDEO_DIP_PORT_MASK)) + return val VIDEO_DIP_ENABLE; + + return false; } static void hsw_write_infoframe(struct drm_encoder *encoder, -- 1.9.3 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] 3.19-rc1 errors when opening LID
Pali, Do you known how to run git bisect as this is probably the best way to continue. Otherwise, I can teach you how it's not hard if your willing to learn :). Cheers Nick On 2014-12-24 01:51 PM, Pali Rohár wrote: Hello! With new 3.19-rc1 kernel every time when I open LID on my laptop, kernel prints these error lines to dmesg: [25566.368133] [drm:hsw_unclaimed_reg_detect.isra.6 [i915]] *ERROR* Unclaimed register detected. Please use the i915.mmio_debug=1 to debug this problem. [25566.368134] [drm:intel_uncore_check_errors [i915]] *ERROR* Unclaimed register before interrupt [25566.368192] [drm:hsw_unclaimed_reg_detect.isra.6 [i915]] *ERROR* Unclaimed register detected. Please use the i915.mmio_debug=1 to debug this problem. [25566.368232] [drm:hsw_unclaimed_reg_detect.isra.6 [i915]] *ERROR* Unclaimed register detected. Please use the i915.mmio_debug=1 to debug this problem.4[25568.446011] i915 :00:02.0: BAR 6: [??? 0x flags 0x2] has bogus alignment [25568.447018] pci_bus :02: Allocating resources [25568.447055] pci_bus :03: Allocating resources [25568.447135] pci_bus :04: Allocating resources [25568.447168] pci_bus :05: Allocating resources [25568.447195] pci_bus :06: Allocating resources [25568.447228] pci_bus :0e: Allocating resources [25568.447323] i915 :00:02.0: BAR 6: [??? 0x flags 0x2] has bogus alignment [25568.447557] i915 :00:02.0: BAR 6: [??? 0x flags 0x2] has bogus alignment [25568.447735] i915 :00:02.0: BAR 6: [??? 0x flags 0x2] has bogus alignment [25568.447847] i915 :00:02.0: BAR 6: [??? 0x flags 0x2] has bogus alignment [25568.448399] i915 :00:02.0: BAR 6: [??? 0x flags 0x2] has bogus alignment [25568.448438] i915 :00:02.0: BAR 6: [??? 0x flags 0x2] has bogus alignment [25568.448566] acpi MSFT:00: Cannot transition to power state D3cold for parent in (unknown) [25568.448572] acpi INT33C2:00: Cannot transition to non-D0 state from D3 [25568.448577] acpi MSFT0002:00: Cannot transition to power state D3cold for parent in (unknown) [25568.448581] acpi ELAN1010:00: Cannot transition to power state D3cold for parent in (unknown) [25568.448587] acpi INT33C3:00: Cannot transition to non-D0 state from D3 [25568.448590] acpi INT33C0:00: Cannot transition to non-D0 state from D3 [25568.448594] acpi INT33C1:00: Cannot transition to non-D0 state from D3 [25568.448598] acpi INT33C4:00: Cannot transition to non-D0 state from D3 [25568.448602] acpi INT33C5:00: Cannot transition to non-D0 state from D3 [25568.448623] acpi device:41: Cannot transition to power state D3cold for parent in (unknown) [25568.448627] acpi INT33C6:00: Cannot transition to non-D0 state from D3 [25568.448890] pci_bus :01: Allocating resources [25568.448905] i915 :00:02.0: BAR 6: [??? 0x flags 0x2] has bogus alignment [25568.449064] i915 :00:02.0: BAR 6: [??? 0x flags 0x2] has bogus alignment [25568.449472] i915 :00:02.0: BAR 6: [??? 0x flags 0x2] has bogus alignment With older kernel (3.13) I do not see these errors, so it is regression. Can you look at it? If it is needed, I can provide other logs, ACPI/DSTD dumps, etc. ___ 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
