[Intel-gfx] [PATCH] drm: Document code of conduct
freedesktop.org has adopted a formal&enforced code of conduct: https://www.fooishbar.org/blog/fdo-contributor-covenant/ https://www.freedesktop.org/wiki/CodeOfConduct/ Besides formalizing things a bit more I don't think this changes anything for us, we've already peer-enforced respectful and constructive interactions since a long time. But it's good to document things properly. Note: As Daniel Stone mentioned in the announcement fd.o admins started chatting with the communities their hosting, which includs the X.org foundation board, to figure out how to fan out enforcement and allow projects to run things on their own (with fd.o still as the fallback). So the details of enforcement (and appealing decisions) might still change, but since this involves the board and lots more people it'll take a while to get there. For now this is good enough I think. For the text itself I went with the same blurb as the Wayland project, didn't feel creative yet this early in the morning: https://cgit.freedesktop.org/wayland/wayland/commit/?id=0eefe99fe0683ae409b665a8b18cc7eb648c6c0c Cc: Daniel Stone Cc: Keith Packard Cc: tfh...@err.no Signed-off-by: Daniel Vetter --- Documentation/gpu/introduction.rst | 11 +++ 1 file changed, 11 insertions(+) diff --git a/Documentation/gpu/introduction.rst b/Documentation/gpu/introduction.rst index 05a82bdfbca4..0f5173e29bdc 100644 --- a/Documentation/gpu/introduction.rst +++ b/Documentation/gpu/introduction.rst @@ -85,3 +85,14 @@ This means that there's a blackout-period of about one month where feature work can't be merged. The recommended way to deal with that is having a -next tree that's always open, but making sure to not feed it into linux-next during the blackout period. As an example, drm-misc works like that. + +Code of Conduct +--- + +As a freedesktop.org project, dri-devel and the DRM community follows the +Contributor Covenant, found at: https://www.freedesktop.org/wiki/CodeOfConduct + +Please conduct yourself in a respectful and civilised manner when +interacting with community members on mailing lists, IRC, or bug +trackers. The community represents the project as a whole, and abusive +or bullying behaviour is not tolerated by the project. -- 2.11.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm: i915: Avoid format string expansion from engine names
While highly unlikely, this makes sure that the string built from engine names won't be processed as a format string. Signed-off-by: Kees Cook --- drivers/gpu/drm/i915/intel_hangcheck.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/intel_hangcheck.c b/drivers/gpu/drm/i915/intel_hangcheck.c index f05971f5586f..be3550cec8e4 100644 --- a/drivers/gpu/drm/i915/intel_hangcheck.c +++ b/drivers/gpu/drm/i915/intel_hangcheck.c @@ -407,7 +407,7 @@ static void hangcheck_declare_hang(struct drm_i915_private *i915, "%s, ", engine->name); msg[len-2] = '\0'; - return i915_handle_error(i915, hung, msg); + return i915_handle_error(i915, hung, "%s", msg); } /* -- 2.7.4 -- Kees Cook Pixel Security ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH igt] igt/vc4_dmabuf_poll: Add a test for polling to wait for dmabuf fences.
This successfully catches vc4's lack of dmabuf fencing.
Signed-off-by: Eric Anholt
---
Has anyone looked into shared infrastructure for tests to do
KMS/dmabuf/etc. things with a generic "get a BO that's being rendered
to for this driver" call?
tests/Makefile.am | 2 ++
tests/Makefile.sources | 1 +
tests/vc4_dmabuf_poll.c | 85 +
3 files changed, 88 insertions(+)
create mode 100644 tests/vc4_dmabuf_poll.c
diff --git a/tests/Makefile.am b/tests/Makefile.am
index 8930c245043d..7c40c9ea8276 100644
--- a/tests/Makefile.am
+++ b/tests/Makefile.am
@@ -114,6 +114,8 @@ vc4_create_bo_CFLAGS = $(AM_CFLAGS) $(DRM_VC4_CFLAGS)
vc4_create_bo_LDADD = $(LDADD) $(DRM_VC4_LIBS)
vc4_lookup_fail_CFLAGS = $(AM_CFLAGS) $(DRM_VC4_CFLAGS)
vc4_lookup_fail_LDADD = $(LDADD) $(DRM_VC4_LIBS)
+vc4_dmabuf_poll_CFLAGS = $(AM_CFLAGS) $(DRM_VC4_CFLAGS)
+vc4_dmabuf_poll_LDADD = $(LDADD) $(DRM_VC4_LIBS)
vc4_wait_bo_CFLAGS = $(AM_CFLAGS) $(DRM_VC4_CFLAGS)
vc4_wait_bo_LDADD = $(LDADD) $(DRM_VC4_LIBS)
vc4_wait_seqno_CFLAGS = $(AM_CFLAGS) $(DRM_VC4_CFLAGS)
diff --git a/tests/Makefile.sources b/tests/Makefile.sources
index 6e07d9387f83..b579e28c6669 100644
--- a/tests/Makefile.sources
+++ b/tests/Makefile.sources
@@ -6,6 +6,7 @@ NOUVEAU_TESTS_M = \
VC4_TESTS_M = \
vc4_create_bo \
+ vc4_dmabuf_poll \
vc4_lookup_fail \
vc4_wait_bo \
vc4_wait_seqno \
diff --git a/tests/vc4_dmabuf_poll.c b/tests/vc4_dmabuf_poll.c
new file mode 100644
index ..ac44d4cf80c7
--- /dev/null
+++ b/tests/vc4_dmabuf_poll.c
@@ -0,0 +1,85 @@
+/*
+ * Copyright © 2017 Broadcom
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
+ * IN THE SOFTWARE.
+ */
+
+#include "igt.h"
+#include "igt_vc4.h"
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include "vc4_drm.h"
+
+static void
+poll_write_bo_test(int fd, int poll_flag)
+{
+ size_t size = 1024 * 1024 * 4;
+ uint32_t clearval = 0xaabbccdd;
+ /* Get a BO that's being rendered to. */
+ int handle = igt_vc4_get_cleared_bo(fd, size, clearval);
+ int dmabuf_fd = prime_handle_to_fd(fd, handle);
+ struct pollfd p = {
+ .fd = dmabuf_fd,
+ .events = POLLIN,
+ };
+ struct drm_vc4_wait_bo wait = {
+ .handle = handle,
+ .timeout_ns = 0,
+ };
+
+ /* Block for a couple of minutes waiting for rendering to complete. */
+ int poll_ret = poll(&p, 1, 120 * 1000);
+ igt_assert(poll_ret == 1);
+
+ /* Now that we've waited for idle, a nonblocking wait for the
+* BO should pass.
+*/
+ do_ioctl(fd, DRM_IOCTL_VC4_WAIT_BO, &wait);
+
+ close(dmabuf_fd);
+ gem_close(fd, handle);
+}
+
+igt_main
+{
+ int fd;
+
+ igt_fixture
+ fd = drm_open_driver(DRIVER_VC4);
+
+ igt_subtest("poll-write-waits-until-write-done") {
+ poll_write_bo_test(fd, POLLOUT);
+ }
+
+ igt_subtest("poll-read-waits-until-write-done") {
+ poll_write_bo_test(fd, POLLIN);
+ }
+
+ igt_fixture
+ close(fd);
+}
--
2.11.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BAT: warning for Classify the engines in class + instance (v5)
== Series Details == Series: Classify the engines in class + instance (v5) URL : https://patchwork.freedesktop.org/series/22808/ State : warning == Summary == Series 22808v1 Classify the engines in class + instance (v5) https://patchwork.freedesktop.org/api/1.0/series/22808/revisions/1/mbox/ Test gem_exec_basic: Subgroup readonly-default: pass -> DMESG-WARN (fi-snb-2600) fdo#100643 Subgroup readonly-render: dmesg-warn -> PASS (fi-snb-2600) fdo#100643 Test gem_exec_flush: Subgroup basic-batch-kernel-default-uc: dmesg-warn -> DMESG-FAIL (fi-snb-2600) fdo#100643 Test gem_exec_reloc: Subgroup basic-cpu-active: dmesg-warn -> PASS (fi-snb-2600) fdo#100643 Subgroup basic-cpu-read-active: dmesg-warn -> PASS (fi-snb-2520m) fdo#100643 Subgroup basic-cpu-read-noreloc: pass -> DMESG-WARN (fi-snb-2600) Subgroup basic-gtt-active: pass -> DMESG-WARN (fi-snb-2600) Subgroup basic-gtt-cpu-active: pass -> DMESG-WARN (fi-snb-2520m) Subgroup basic-gtt-read: pass -> DMESG-WARN (fi-snb-2600) Subgroup basic-gtt-read-active: pass -> DMESG-WARN (fi-snb-2520m) Subgroup basic-gtt-read-noreloc: dmesg-warn -> PASS (fi-snb-2600) fdo#100643 Subgroup basic-softpin: pass -> DMESG-WARN (fi-snb-2520m) Subgroup basic-write-cpu: dmesg-warn -> PASS (fi-snb-2600) fdo#100643 Subgroup basic-write-cpu-active: dmesg-warn -> PASS (fi-snb-2520m) fdo#100643 Subgroup basic-write-gtt-active: pass -> DMESG-WARN (fi-snb-2520m) fdo#100643 dmesg-warn -> PASS (fi-snb-2600) fdo#100643 Subgroup basic-write-read-active: dmesg-warn -> PASS (fi-snb-2520m) fdo#100643 Test gem_exec_store: Subgroup basic-all: dmesg-warn -> PASS (fi-snb-2520m) fdo#100643 Subgroup basic-default: pass -> DMESG-WARN (fi-snb-2520m) fdo#100643 Subgroup basic-render: dmesg-warn -> PASS (fi-snb-2520m) fdo#100643 Test gem_exec_suspend: Subgroup basic: pass -> DMESG-WARN (fi-snb-2520m) Test gem_mmap_gtt: Subgroup basic-copy: pass -> DMESG-WARN (fi-snb-2520m) fdo#100643 Subgroup basic-read: dmesg-warn -> PASS (fi-snb-2520m) fdo#100643 Subgroup basic-write-gtt-no-prefault: pass -> DMESG-WARN (fi-snb-2520m) fdo#100643 Test gem_render_tiled_blits: Subgroup basic: pass -> DMESG-WARN (fi-snb-2520m) Test gem_ringfill: Subgroup basic-default-fd: pass -> DMESG-WARN (fi-snb-2520m) Test kms_addfb_basic: Subgroup addfb25-x-tiled-mismatch: dmesg-warn -> PASS (fi-snb-2600) fdo#100643 Subgroup addfb25-yf-tiled: pass -> DMESG-WARN (fi-snb-2600) Subgroup bad-pitch-128: dmesg-warn -> PASS (fi-snb-2600) fdo#100643 Subgroup bad-pitch-32: pass -> DMESG-WARN (fi-snb-2600) fdo#100643 Subgroup basic-x-tiled: dmesg-warn -> PASS (fi-snb-2600) fdo#100643 Subgroup basic-y-tiled: pass -> DMESG-WARN (fi-snb-2600) fdo#100643 Subgroup invalid-get-prop: dmesg-warn -> PASS (fi-snb-2600) fdo#100643 Subgroup invalid-get-prop-any: pass -> DMESG-WARN (fi-snb-2600) fdo#100643 Subgroup small-bo: dmesg-warn -> PASS (fi-snb-2600) fdo#100643 Subgroup tile-pitch-mismatch: pass -> DMESG-WARN (fi-snb-2600) fdo#100643 Subgroup unused-offsets: dmesg-warn -> PASS (fi-snb-2600) fdo#100643 Subgroup unused-pitches: pass -> DMESG-WARN (fi-snb-2600) fdo#100643 Test kms_force_connector_basic: Subgroup force-edid: dmesg-warn -> PASS (fi-snb-2600) fdo#100643 Subgroup prune-stale-modes: pass -> DMESG-WARN (fi-snb-2600) fdo#100643 Test kms_pipe_crc_basic: Subgroup suspend-read-crc-pipe-c: dmesg-warn -> PASS (fi-kbl-7560u) fdo#100445 Test kms_setmode: Subgroup basic-clone-single-crtc: pass -> DMESG-WARN (fi-snb-2600) Test prime_vgem: Subgroup basic-fence-mmap: WARNING: Long output truncated e461ecfd413fb930d00f44f3de0019e528b4731f drm-tip: 2017y-04m-10d-14h-25m-24s UTC integration manifest 0e152e1 drm/i915: Use the engine class to get the context size 8556ab7 drm/i915: Split the engine info table in two levels, usi
[Intel-gfx] [PATCH 5/5] drm/i915: Use the engine class to get the context size
From: Daniele Ceraolo Spurio
Technically speaking, the context size is per engine class, not per
instance.
v2: Add MISSING_CASE (Tvrtko)
v3: Rebased
Cc: Paulo Zanoni
Cc: Rodrigo Vivi
Cc: Chris Wilson
Signed-off-by: Daniele Ceraolo Spurio
Reviewed-by: Tvrtko Ursulin
Signed-off-by: Oscar Mateo
---
drivers/gpu/drm/i915/intel_lrc.c | 33 +
drivers/gpu/drm/i915/intel_lrc.h | 6 +-
2 files changed, 26 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 0dc1cc4..1c6672c 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -1908,8 +1908,10 @@ static void execlists_init_reg_state(u32 *regs,
}
/**
- * intel_lr_context_size() - return the size of the context for an engine
- * @engine: which engine to find the context size for
+ * intel_lr_class_context_size() - return the size of the context for a given
+ * engine class
+ * @dev_priv: i915 device private
+ * @class: which engine class to find the context size for
*
* Each engine may require a different amount of space for a context image,
* so when allocating (or copying) an image, this function can be used to
@@ -1921,25 +1923,32 @@ static void execlists_init_reg_state(u32 *regs,
* in LRC mode, but does not include the "shared data page" used with
* GuC submission. The caller should account for this if using the GuC.
*/
-uint32_t intel_lr_context_size(struct intel_engine_cs *engine)
+uint32_t intel_lr_class_context_size(struct drm_i915_private *dev_priv, u8
class)
{
int ret = 0;
- WARN_ON(INTEL_GEN(engine->i915) < 8);
+ WARN_ON(INTEL_GEN(dev_priv) < 8);
- switch (engine->id) {
- case RCS:
- if (INTEL_GEN(engine->i915) >= 9)
+ switch (class) {
+ case RENDER_CLASS:
+ switch (INTEL_GEN(dev_priv)) {
+ default:
+ MISSING_CASE(INTEL_GEN(dev_priv));
+ case 9:
ret = GEN9_LR_CONTEXT_RENDER_SIZE;
- else
+ break;
+ case 8:
ret = GEN8_LR_CONTEXT_RENDER_SIZE;
+ break;
+ }
break;
- case VCS:
- case BCS:
- case VECS:
- case VCS2:
+ case VIDEO_DECODE_CLASS:
+ case VIDEO_ENHANCEMENT_CLASS:
+ case COPY_ENGINE_CLASS:
ret = GEN8_LR_CONTEXT_OTHER_SIZE;
break;
+ default:
+ MISSING_CASE(class);
}
return ret;
diff --git a/drivers/gpu/drm/i915/intel_lrc.h b/drivers/gpu/drm/i915/intel_lrc.h
index e8015e7..bde2b6e 100644
--- a/drivers/gpu/drm/i915/intel_lrc.h
+++ b/drivers/gpu/drm/i915/intel_lrc.h
@@ -78,7 +78,11 @@ enum {
struct drm_i915_private;
struct i915_gem_context;
-uint32_t intel_lr_context_size(struct intel_engine_cs *engine);
+uint32_t intel_lr_class_context_size(struct drm_i915_private *dev_priv, u8
class);
+static inline uint32_t intel_lr_context_size(struct intel_engine_cs *engine)
+{
+ return intel_lr_class_context_size(engine->i915, engine->class);
+}
void intel_lr_context_resume(struct drm_i915_private *dev_priv);
uint64_t intel_lr_context_descriptor(struct i915_gem_context *ctx,
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/5] drm/i915: Classify the engines in class + instance
From: Daniele Ceraolo Spurio
In such a way that vcs and vcs2 are just two different instances (0 and 1)
of the same engine class (VIDEO_DECODE_CLASS).
v2: Align the instance types (Tvrtko)
v3: Don't use enums for bspec-defined stuff (Michal)
Cc: Paulo Zanoni
Cc: Rodrigo Vivi
Cc: Chris Wilson
Signed-off-by: Daniele Ceraolo Spurio
Reviewed-by: Tvrtko Ursulin
Reviewed-by: Michal Wajdeczko
Signed-off-by: Oscar Mateo
---
drivers/gpu/drm/i915/i915_reg.h | 8
drivers/gpu/drm/i915/intel_engine_cs.c | 14 ++
drivers/gpu/drm/i915/intel_ringbuffer.h | 4
3 files changed, 26 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 11b12f4..4c72ada 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -85,6 +85,14 @@ static inline bool i915_mmio_reg_valid(i915_reg_t reg)
#define VECS_HW3
#define VCS2_HW4
+/* Engine class */
+
+#define RENDER_CLASS 0
+#define VIDEO_DECODE_CLASS 1
+#define VIDEO_ENHANCEMENT_CLASS2
+#define COPY_ENGINE_CLASS 3
+#define OTHER_CLASS4
+
/* PCI config space */
#define MCHBAR_I915 0x44
diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c
b/drivers/gpu/drm/i915/intel_engine_cs.c
index 92f871c..bb22927 100644
--- a/drivers/gpu/drm/i915/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/intel_engine_cs.c
@@ -30,6 +30,8 @@
const char *name;
unsigned int exec_id;
unsigned int hw_id;
+ u8 class;
+ u8 instance;
u32 mmio_base;
unsigned irq_shift;
int (*init_legacy)(struct intel_engine_cs *engine);
@@ -39,6 +41,8 @@
.name = "rcs",
.hw_id = RCS_HW,
.exec_id = I915_EXEC_RENDER,
+ .class = RENDER_CLASS,
+ .instance = 0,
.mmio_base = RENDER_RING_BASE,
.irq_shift = GEN8_RCS_IRQ_SHIFT,
.init_execlists = logical_render_ring_init,
@@ -48,6 +52,8 @@
.name = "bcs",
.hw_id = BCS_HW,
.exec_id = I915_EXEC_BLT,
+ .class = COPY_ENGINE_CLASS,
+ .instance = 0,
.mmio_base = BLT_RING_BASE,
.irq_shift = GEN8_BCS_IRQ_SHIFT,
.init_execlists = logical_xcs_ring_init,
@@ -57,6 +63,8 @@
.name = "vcs",
.hw_id = VCS_HW,
.exec_id = I915_EXEC_BSD,
+ .class = VIDEO_DECODE_CLASS,
+ .instance = 0,
.mmio_base = GEN6_BSD_RING_BASE,
.irq_shift = GEN8_VCS1_IRQ_SHIFT,
.init_execlists = logical_xcs_ring_init,
@@ -66,6 +74,8 @@
.name = "vcs2",
.hw_id = VCS2_HW,
.exec_id = I915_EXEC_BSD,
+ .class = VIDEO_DECODE_CLASS,
+ .instance = 1,
.mmio_base = GEN8_BSD2_RING_BASE,
.irq_shift = GEN8_VCS2_IRQ_SHIFT,
.init_execlists = logical_xcs_ring_init,
@@ -75,6 +85,8 @@
.name = "vecs",
.hw_id = VECS_HW,
.exec_id = I915_EXEC_VEBOX,
+ .class = VIDEO_ENHANCEMENT_CLASS,
+ .instance = 0,
.mmio_base = VEBOX_RING_BASE,
.irq_shift = GEN8_VECS_IRQ_SHIFT,
.init_execlists = logical_xcs_ring_init,
@@ -101,6 +113,8 @@
engine->hw_id = engine->guc_id = info->hw_id;
engine->mmio_base = info->mmio_base;
engine->irq_shift = info->irq_shift;
+ engine->class = info->class;
+ engine->instance = info->instance;
/* Nothing to do here, execute in order of dependencies */
engine->schedule = NULL;
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.h
b/drivers/gpu/drm/i915/intel_ringbuffer.h
index cbe61d3..f54fe7d 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.h
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.h
@@ -193,6 +193,10 @@ struct intel_engine_cs {
enum intel_engine_id id;
unsigned int exec_id;
unsigned int hw_id;
+
+ u8 class;
+ u8 instance;
+
unsigned int guc_id;
u32 mmio_base;
unsigned int irq_shift;
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 3/5] drm/i915: Generate the engine name based on the instance number
Not really needed, but makes the next change a little bit more compact.
v2:
- Use zero-based numbering for engine names: xcs0, xcs1.. xcsN (Tvrtko, Chris)
- Make sure the mock engine name is null-terminated (Tvrtko, Chris)
v3: Because I'm stupid (Chris)
v4: Verify engine name wasn't truncated (Michal)
v5:
- Kill the warning in mock engine (Chris)
Cc: Paulo Zanoni
Cc: Rodrigo Vivi
Cc: Chris Wilson
Cc: Daniele Ceraolo Spurio
Reviewed-by: Tvrtko Ursulin
Reviewed-by: Michal Wajdeczko
Signed-off-by: Oscar Mateo
---
drivers/gpu/drm/i915/intel_engine_cs.c | 5 +++--
drivers/gpu/drm/i915/intel_ringbuffer.h | 4 +++-
drivers/gpu/drm/i915/selftests/mock_engine.c | 2 +-
3 files changed, 7 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c
b/drivers/gpu/drm/i915/intel_engine_cs.c
index a7ffa4c..5e5cda0 100644
--- a/drivers/gpu/drm/i915/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/intel_engine_cs.c
@@ -71,7 +71,7 @@
.init_legacy = intel_init_bsd_ring_buffer,
},
[VCS2] = {
- .name = "vcs2",
+ .name = "vcs",
.hw_id = VCS2_HW,
.exec_id = I915_EXEC_BSD,
.class = VIDEO_DECODE_CLASS,
@@ -108,7 +108,8 @@
engine->id = id;
engine->i915 = dev_priv;
- engine->name = info->name;
+ WARN_ON(snprintf(engine->name, sizeof(engine->name), "%s%u",
+info->name, info->instance) >= sizeof(engine->name));
engine->exec_id = info->exec_id;
engine->hw_id = engine->guc_id = info->hw_id;
engine->mmio_base = info->mmio_base;
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.h
b/drivers/gpu/drm/i915/intel_ringbuffer.h
index 8b53ddb..fd8994b 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.h
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.h
@@ -187,9 +187,11 @@ enum intel_engine_id {
VECS
};
+#define INTEL_ENGINE_CS_MAX_NAME 8
+
struct intel_engine_cs {
struct drm_i915_private *i915;
- const char *name;
+ char name[INTEL_ENGINE_CS_MAX_NAME];
enum intel_engine_id id;
unsigned int exec_id;
unsigned int hw_id;
diff --git a/drivers/gpu/drm/i915/selftests/mock_engine.c
b/drivers/gpu/drm/i915/selftests/mock_engine.c
index b89050e..b8e53bd 100644
--- a/drivers/gpu/drm/i915/selftests/mock_engine.c
+++ b/drivers/gpu/drm/i915/selftests/mock_engine.c
@@ -140,7 +140,7 @@ struct intel_engine_cs *mock_engine(struct drm_i915_private
*i915,
/* minimal engine setup for requests */
engine->base.i915 = i915;
- engine->base.name = name;
+ snprintf(engine->base.name, sizeof(engine->base.name), "%s", name);
engine->base.id = id++;
engine->base.status_page.page_addr = (void *)(engine + 1);
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/5] drm/i915: Use the same vfunc for BSD2 ring init
If we needed to do something different for the init functions, we could
always look at the engine instance to make the distinction. But, in any
case, the two functions are virtually identical already (please notice
that BSD2_RING is only used from gen8 onwards).
With this, the init functions depends excusively on the engine class
(a fact that we will use soon).
v2: Commit message
Cc: Paulo Zanoni
Cc: Rodrigo Vivi
Cc: Chris Wilson
Cc: Daniele Ceraolo Spurio
Signed-off-by: Oscar Mateo
Reviewed-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/intel_engine_cs.c | 2 +-
drivers/gpu/drm/i915/intel_ringbuffer.c | 14 --
drivers/gpu/drm/i915/intel_ringbuffer.h | 1 -
3 files changed, 1 insertion(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c
b/drivers/gpu/drm/i915/intel_engine_cs.c
index bb22927..a7ffa4c 100644
--- a/drivers/gpu/drm/i915/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/intel_engine_cs.c
@@ -79,7 +79,7 @@
.mmio_base = GEN8_BSD2_RING_BASE,
.irq_shift = GEN8_VCS2_IRQ_SHIFT,
.init_execlists = logical_xcs_ring_init,
- .init_legacy = intel_init_bsd2_ring_buffer,
+ .init_legacy = intel_init_bsd_ring_buffer,
},
[VECS] = {
.name = "vecs",
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c
b/drivers/gpu/drm/i915/intel_ringbuffer.c
index c98acc2..81eee42 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.c
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
@@ -2175,20 +2175,6 @@ int intel_init_bsd_ring_buffer(struct intel_engine_cs
*engine)
return intel_init_ring_buffer(engine);
}
-/**
- * Initialize the second BSD ring (eg. Broadwell GT3, Skylake GT3)
- */
-int intel_init_bsd2_ring_buffer(struct intel_engine_cs *engine)
-{
- struct drm_i915_private *dev_priv = engine->i915;
-
- intel_ring_default_vfuncs(dev_priv, engine);
-
- engine->emit_flush = gen6_bsd_ring_flush;
-
- return intel_init_ring_buffer(engine);
-}
-
int intel_init_blt_ring_buffer(struct intel_engine_cs *engine)
{
struct drm_i915_private *dev_priv = engine->i915;
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.h
b/drivers/gpu/drm/i915/intel_ringbuffer.h
index f54fe7d..8b53ddb 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.h
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.h
@@ -555,7 +555,6 @@ int intel_ring_pin(struct intel_ring *ring,
int intel_init_render_ring_buffer(struct intel_engine_cs *engine);
int intel_init_bsd_ring_buffer(struct intel_engine_cs *engine);
-int intel_init_bsd2_ring_buffer(struct intel_engine_cs *engine);
int intel_init_blt_ring_buffer(struct intel_engine_cs *engine);
int intel_init_vebox_ring_buffer(struct intel_engine_cs *engine);
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 4/5] drm/i915: Split the engine info table in two levels, using class + instance
There are some properties that logically belong to the engine class, and some
that belong to the engine instance. Make it explicit.
v2: Commit message (Tvrtko)
v3:
- Rebased
- Exec/uabi id should be per instance (Chris)
v4:
- Rebased
- Avoid re-ordering fields for smaller diff (Tvrtko)
- Bug on oob access to the class array (Michal)
v5: Bug on the right thing (Michal)
v6: Rebased
Cc: Tvrtko Ursulin
Cc: Paulo Zanoni
Cc: Rodrigo Vivi
Cc: Chris Wilson
Cc: Daniele Ceraolo Spurio
Reviewed-by: Michal Wajdeczko
Signed-off-by: Oscar Mateo
Conflicts:
drivers/gpu/drm/i915/intel_engine_cs.c
---
drivers/gpu/drm/i915/intel_engine_cs.c | 65 ++
1 file changed, 42 insertions(+), 23 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c
b/drivers/gpu/drm/i915/intel_engine_cs.c
index 5e5cda0..80cb0ff 100644
--- a/drivers/gpu/drm/i915/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/intel_engine_cs.c
@@ -26,71 +26,84 @@
#include "intel_ringbuffer.h"
#include "intel_lrc.h"
-static const struct engine_info {
+struct engine_class_info {
const char *name;
- unsigned int exec_id;
+ int (*init_legacy)(struct intel_engine_cs *engine);
+ int (*init_execlists)(struct intel_engine_cs *engine);
+};
+
+static const struct engine_class_info intel_engine_classes[] = {
+ [RENDER_CLASS] = {
+ .name = "rcs",
+ .init_execlists = logical_render_ring_init,
+ .init_legacy = intel_init_render_ring_buffer,
+ },
+ [COPY_ENGINE_CLASS] = {
+ .name = "bcs",
+ .init_execlists = logical_xcs_ring_init,
+ .init_legacy = intel_init_blt_ring_buffer,
+ },
+ [VIDEO_DECODE_CLASS] = {
+ .name = "vcs",
+ .init_execlists = logical_xcs_ring_init,
+ .init_legacy = intel_init_bsd_ring_buffer,
+ },
+ [VIDEO_ENHANCEMENT_CLASS] = {
+ .name = "vecs",
+ .init_execlists = logical_xcs_ring_init,
+ .init_legacy = intel_init_vebox_ring_buffer,
+ },
+};
+
+struct engine_info {
unsigned int hw_id;
+ unsigned int exec_id;
u8 class;
u8 instance;
u32 mmio_base;
unsigned irq_shift;
- int (*init_legacy)(struct intel_engine_cs *engine);
- int (*init_execlists)(struct intel_engine_cs *engine);
-} intel_engines[] = {
+};
+
+static const struct engine_info intel_engines[] = {
[RCS] = {
- .name = "rcs",
.hw_id = RCS_HW,
.exec_id = I915_EXEC_RENDER,
.class = RENDER_CLASS,
.instance = 0,
.mmio_base = RENDER_RING_BASE,
.irq_shift = GEN8_RCS_IRQ_SHIFT,
- .init_execlists = logical_render_ring_init,
- .init_legacy = intel_init_render_ring_buffer,
},
[BCS] = {
- .name = "bcs",
.hw_id = BCS_HW,
.exec_id = I915_EXEC_BLT,
.class = COPY_ENGINE_CLASS,
.instance = 0,
.mmio_base = BLT_RING_BASE,
.irq_shift = GEN8_BCS_IRQ_SHIFT,
- .init_execlists = logical_xcs_ring_init,
- .init_legacy = intel_init_blt_ring_buffer,
},
[VCS] = {
- .name = "vcs",
.hw_id = VCS_HW,
.exec_id = I915_EXEC_BSD,
.class = VIDEO_DECODE_CLASS,
.instance = 0,
.mmio_base = GEN6_BSD_RING_BASE,
.irq_shift = GEN8_VCS1_IRQ_SHIFT,
- .init_execlists = logical_xcs_ring_init,
- .init_legacy = intel_init_bsd_ring_buffer,
},
[VCS2] = {
- .name = "vcs",
.hw_id = VCS2_HW,
.exec_id = I915_EXEC_BSD,
.class = VIDEO_DECODE_CLASS,
.instance = 1,
.mmio_base = GEN8_BSD2_RING_BASE,
.irq_shift = GEN8_VCS2_IRQ_SHIFT,
- .init_execlists = logical_xcs_ring_init,
- .init_legacy = intel_init_bsd_ring_buffer,
},
[VECS] = {
- .name = "vecs",
.hw_id = VECS_HW,
.exec_id = I915_EXEC_VEBOX,
.class = VIDEO_ENHANCEMENT_CLASS,
.instance = 0,
.mmio_base = VEBOX_RING_BASE,
.irq_shift = GEN8_VECS_IRQ_SHIFT,
- .init_execlists = logical_xcs_ring_init,
- .init_legacy = intel_init_vebox_ring_buffer,
},
};
@@ -99,8 +112,12 @@
enum intel_engine_id id)
{
const struct engine_info *info = &intel_engines[id];
+ const struct engine_class_info *class_info;
struct intel_engine_cs *engine;
+ GEM_BUG_ON(info->class >= ARRAY_SIZE(intel_engine_classes));
+ class_info = &intel_engine_classes[info->class]
[Intel-gfx] [PATCH 0/5] Classify the engines in class + instance (v5)
This refactoring helps simplify a few things here and there. Daniele Ceraolo Spurio (2): drm/i915: Classify the engines in class + instance drm/i915: Use the engine class to get the context size Oscar Mateo (3): drm/i915: Use the same vfunc for BSD2 ring init drm/i915: Generate the engine name based on the instance number drm/i915: Split the engine info table in two levels, using class + instance drivers/gpu/drm/i915/i915_reg.h | 8 +++ drivers/gpu/drm/i915/intel_engine_cs.c | 80 drivers/gpu/drm/i915/intel_lrc.c | 33 +++- drivers/gpu/drm/i915/intel_lrc.h | 6 ++- drivers/gpu/drm/i915/intel_ringbuffer.c | 14 - drivers/gpu/drm/i915/intel_ringbuffer.h | 9 +++- drivers/gpu/drm/i915/selftests/mock_engine.c | 2 +- 7 files changed, 99 insertions(+), 53 deletions(-) -- 1.9.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm: Fix get_property logic fumble
On Mon, Apr 10, 2017 at 01:54:45PM +0200, Daniel Vetter wrote:
> Yet again I've proven that I can't negate conditions :(
>
> Fixes: eb8eb02ed850 ("drm: Drop modeset_lock_all from the getproperty ioctl")
> Cc: Maarten Lankhorst
> Cc: Daniel Vetter
> Cc: Jani Nikula
> Cc: Sean Paul
Reviewed-by: Sean Paul
> Reported-by: Tvrtko Ursulin
> Cc: Tvrtko Ursulin
> Signed-off-by: Daniel Vetter
> ---
> drivers/gpu/drm/drm_property.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/drm_property.c b/drivers/gpu/drm/drm_property.c
> index 3feef0659940..3e88fa24eab3 100644
> --- a/drivers/gpu/drm/drm_property.c
> +++ b/drivers/gpu/drm/drm_property.c
> @@ -476,7 +476,7 @@ int drm_mode_getproperty_ioctl(struct drm_device *dev,
> drm_property_type_is(property, DRM_MODE_PROP_BITMASK)) {
> list_for_each_entry(prop_enum, &property->enum_list, head) {
> enum_count++;
> - if (out_resp->count_enum_blobs <= enum_count)
> + if (out_resp->count_enum_blobs < enum_count)
> continue;
>
> if (copy_to_user(&enum_ptr[copied].value,
> --
> 2.11.0
--
Sean Paul, Software Engineer, Google / Chromium OS
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Lie and treat all engines as idle if wedged
Similar to commit 8490ae207f1d ("drm/i915: Suppress busy status for
engines if wedged") we also want to report intel_engine_is_idle() as
true as well as the main intel_engines_are_idle(), as we now check that
the engines are idle when overwriting the HWS page. This is not true
whilst we are setting the device as wedged, at least according to our
bookkeeping, so we have to lie to ourselves!
[ 383.588601] [drm:i915_reset [i915]] *ERROR* Failed to reset chip: -110
[ 383.588685] [ cut here ]
[ 383.588755] WARNING: CPU: 0 PID: 12 at
drivers/gpu/drm/i915/intel_engine_cs.c:226
intel_engine_init_global_seqno+0x222/0x290 [i915]
[ 383.588757] WARN_ON(!intel_engine_is_idle(engine))
[ 383.588759] Modules linked in: ctr ccm snd_hda_codec_hdmi
snd_hda_codec_conexant snd_hda_codec_generic snd_hda_intel snd_hda_codec
snd_hda_core arc4 iwldvm mac80211 snd_pcm snd_hwdep snd_seq_midi
snd_seq_midi_event rfcomm bnep snd_rawmidi intel_powerclamp coretemp
dm_multipath iwlwifi crct10dif_pclmul snd_seq crc32_pclmul ghash_clmulni_intel
btusb aesni_intel btrtl btbcm aes_x86_64 crypto_simd cryptd btintel snd_timer
glue_helper bluetooth intel_ips snd_seq_device cfg80211 snd soundcore
binfmt_misc mei_me mei dm_mirror dm_region_hash dm_log i915 intel_gtt
i2c_algo_bit drm_kms_helper cfbfillrect syscopyarea cfbimgblt sysfillrect
sysimgblt fb_sys_fops cfbcopyarea prime_numbers ahci libahci drm e1000e
[ 383.588851] CPU: 0 PID: 12 Comm: migration/0 Not tainted 4.11.0-rc5+ #207
[ 383.588853] Hardware name: LENOVO 514328U/514328U, BIOS 6QET44WW (1.14 )
04/20/2010
[ 383.588855] Call Trace:
[ 383.588866] dump_stack+0x63/0x90
[ 383.588871] __warn+0xc7/0xf0
[ 383.588876] warn_slowpath_fmt+0x4a/0x50
[ 383.53] ? set_next_entity+0x821/0x910
[ 383.588943] intel_engine_init_global_seqno+0x222/0x290 [i915]
[ 383.588998] __i915_gem_set_wedged_BKL+0xa4/0x190 [i915]
[ 383.589003] ? __switch_to+0x215/0x390
[ 383.589008] multi_cpu_stop+0xbb/0xe0
[ 383.589012] ? cpu_stop_queue_work+0x90/0x90
[ 383.589016] cpu_stopper_thread+0x82/0x110
[ 383.589021] smpboot_thread_fn+0x137/0x190
[ 383.589026] kthread+0xf7/0x130
[ 383.589030] ? sort_range+0x20/0x20
[ 383.589034] ? kthread_park+0x90/0x90
[ 383.589040] ret_from_fork+0x2c/0x40
Fixes: 2ca9faa551c4 ("drm/i915: Assert the engine is idle before overwiting the
HWS")
Signed-off-by: Chris Wilson
Cc: Joonas Lahtinen
---
drivers/gpu/drm/i915/intel_engine_cs.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c
b/drivers/gpu/drm/i915/intel_engine_cs.c
index 9b7771d7fe24..94772c1c1999 100644
--- a/drivers/gpu/drm/i915/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/intel_engine_cs.c
@@ -1078,6 +1078,10 @@ bool intel_engine_is_idle(struct intel_engine_cs *engine)
{
struct drm_i915_private *dev_priv = engine->i915;
+ /* More white lies, if wedged, hw state is inconsistent */
+ if (i915_terminally_wedged(&dev_priv->gpu_error))
+ return true;
+
/* We have to allow time for writes to land from the GPU. */
if (engine->irq_seqno_barrier)
engine->irq_seqno_barrier(engine);
--
2.11.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BAT: warning for series starting with [1/3] drm/i915: Stop second guessing the caller for intel_uncore_wait_for_register() (rev2)
== Series Details == Series: series starting with [1/3] drm/i915: Stop second guessing the caller for intel_uncore_wait_for_register() (rev2) URL : https://patchwork.freedesktop.org/series/22786/ State : warning == Summary == Series 22786v2 Series without cover letter https://patchwork.freedesktop.org/api/1.0/series/22786/revisions/2/mbox/ Test core_auth: Subgroup basic-auth: dmesg-warn -> PASS (fi-snb-2600) fdo#100643 dmesg-warn -> PASS (fi-snb-2520m) fdo#100643 Test drv_getparams_basic: Subgroup basic-subslice-total: dmesg-warn -> PASS (fi-snb-2520m) fdo#100643 Test drv_module_reload: Subgroup basic-no-display: dmesg-warn -> PASS (fi-snb-2600) fdo#100643 dmesg-warn -> PASS (fi-snb-2520m) fdo#100643 Subgroup basic-reload: dmesg-warn -> PASS (fi-snb-2600) fdo#100643 dmesg-warn -> PASS (fi-snb-2520m) fdo#100643 Subgroup basic-reload-final: dmesg-warn -> PASS (fi-snb-2600) fdo#100643 dmesg-warn -> PASS (fi-snb-2520m) fdo#100643 Test gem_basic: Subgroup create-close: dmesg-warn -> PASS (fi-snb-2520m) fdo#100643 Test gem_busy: Subgroup basic-hang-default: dmesg-warn -> PASS (fi-snb-2600) fdo#100643 dmesg-warn -> PASS (fi-snb-2520m) fdo#100643 Test gem_close_race: Subgroup basic-threads: dmesg-warn -> PASS (fi-snb-2600) fdo#100643 dmesg-warn -> PASS (fi-snb-2520m) fdo#100643 Test gem_cs_tlb: Subgroup basic-default: dmesg-warn -> PASS (fi-snb-2520m) fdo#100643 Test gem_ctx_basic: dmesg-warn -> PASS (fi-snb-2600) fdo#100643 dmesg-warn -> PASS (fi-snb-2520m) fdo#100643 Test gem_ctx_create: Subgroup basic-files: dmesg-warn -> PASS (fi-snb-2600) fdo#100643 dmesg-warn -> PASS (fi-snb-2520m) fdo#100643 Test gem_ctx_param: Subgroup basic-default: dmesg-warn -> PASS (fi-snb-2520m) fdo#100643 Test gem_ctx_switch: Subgroup basic-default: dmesg-warn -> PASS (fi-snb-2600) fdo#100643 dmesg-warn -> PASS (fi-snb-2520m) fdo#100643 Subgroup basic-default-heavy: dmesg-warn -> PASS (fi-snb-2600) fdo#100643 dmesg-warn -> PASS (fi-snb-2520m) fdo#100643 Test gem_exec_basic: Subgroup gtt-render: dmesg-warn -> PASS (fi-snb-2520m) fdo#100643 Subgroup readonly-bsd: dmesg-warn -> PASS (fi-snb-2520m) fdo#100643 Subgroup readonly-default: dmesg-warn -> PASS (fi-snb-2520m) fdo#100643 Subgroup readonly-render: dmesg-warn -> PASS (fi-snb-2600) fdo#100643 Test gem_exec_create: Subgroup basic: dmesg-warn -> PASS (fi-snb-2600) fdo#100643 dmesg-warn -> PASS (fi-snb-2520m) fdo#100643 Test gem_exec_fence: Subgroup await-hang-default: dmesg-warn -> PASS (fi-snb-2600) fdo#100643 dmesg-warn -> PASS (fi-snb-2520m) fdo#100643 Subgroup basic-await-default: dmesg-warn -> PASS (fi-snb-2600) fdo#100643 dmesg-warn -> PASS (fi-snb-2520m) fdo#100643 Subgroup basic-wait-default: dmesg-warn -> PASS (fi-snb-2520m) fdo#100643 Subgroup nb-await-default: dmesg-warn -> PASS (fi-snb-2600) fdo#100643 dmesg-warn -> PASS (fi-snb-2520m) fdo#100643 Test gem_exec_flush: Subgroup basic-batch-kernel-default-uc: dmesg-warn -> FAIL (fi-snb-2600) fdo#100643 dmesg-warn -> PASS (fi-snb-2520m) fdo#100643 Subgroup basic-batch-kernel-default-wb: dmesg-warn -> PASS (fi-snb-2600) fdo#100643 dmesg-warn -> PASS (fi-snb-2520m) fdo#100643 Subgroup basic-uc-pro-default: dmesg-warn -> PASS (fi-snb-2600) fdo#100643 dmesg-warn -> PASS (fi-snb-2520m) fdo#100643 Subgroup basic-uc-prw-default: dmesg-warn -> PASS (fi-snb-2600) fdo#100643 dmesg-warn -> PASS (fi-snb-2520m) fdo#100643 Subgroup basic-uc-ro-default: dmesg-warn -> PASS (fi-snb-2600) fdo#100643 dmesg-warn -> PASS (fi-snb-2520m) fdo#100643 Subgroup basic-uc-rw-default: dmesg-warn -> PASS (fi-snb-2600) fdo#100643 dmesg-warn -> PASS (fi-snb-2520m) fdo#100643 Subgroup basic-uc-set-default: dmesg-warn -> PASS (fi-snb-2600) fdo#100
[Intel-gfx] ✗ Fi.CI.BAT: warning for drm/i915/execlists: Document runtime pm for intel_lrc_irq_handler()
== Series Details == Series: drm/i915/execlists: Document runtime pm for intel_lrc_irq_handler() URL : https://patchwork.freedesktop.org/series/22790/ State : warning == Summary == Series 22790v1 drm/i915/execlists: Document runtime pm for intel_lrc_irq_handler() https://patchwork.freedesktop.org/api/1.0/series/22790/revisions/1/mbox/ Test gem_exec_basic: Subgroup basic-render: pass -> DMESG-WARN (fi-snb-2520m) Subgroup gtt-bsd: pass -> DMESG-WARN (fi-snb-2520m) Subgroup gtt-default: pass -> DMESG-WARN (fi-snb-2520m) Subgroup gtt-render: dmesg-warn -> PASS (fi-snb-2520m) fdo#100643 Subgroup readonly-default: pass -> DMESG-WARN (fi-snb-2600) fdo#100643 Subgroup readonly-render: dmesg-warn -> PASS (fi-snb-2600) fdo#100643 Test gem_exec_reloc: Subgroup basic-cpu-read-noreloc: pass -> DMESG-WARN (fi-snb-2600) Subgroup basic-gtt-read: pass -> DMESG-WARN (fi-snb-2600) Subgroup basic-gtt-read-noreloc: dmesg-warn -> PASS (fi-snb-2600) fdo#100643 Subgroup basic-write-cpu: dmesg-warn -> PASS (fi-snb-2600) fdo#100643 Subgroup basic-write-gtt-active: dmesg-warn -> PASS (fi-snb-2600) fdo#100643 Test gem_exec_store: Subgroup basic-all: dmesg-warn -> PASS (fi-snb-2520m) fdo#100643 Subgroup basic-blt: pass -> DMESG-WARN (fi-snb-2520m) Subgroup basic-default: dmesg-warn -> PASS (fi-snb-2600) fdo#100643 Subgroup basic-render: pass -> DMESG-WARN (fi-snb-2600) fdo#100643 dmesg-warn -> PASS (fi-snb-2520m) fdo#100643 Test gem_mmap_gtt: Subgroup basic-read-write: dmesg-warn -> PASS (fi-snb-2520m) fdo#100643 Subgroup basic-read-write-distinct: pass -> DMESG-WARN (fi-snb-2520m) Subgroup basic-small-bo: dmesg-warn -> PASS (fi-snb-2520m) fdo#100643 Test gem_ringfill: Subgroup basic-default-fd: pass -> DMESG-WARN (fi-snb-2520m) Test kms_addfb_basic: Subgroup basic: pass -> DMESG-WARN (fi-snb-2600) Subgroup basic-x-tiled: dmesg-warn -> PASS (fi-snb-2600) fdo#100643 Subgroup framebuffer-vs-set-tiling: pass -> DMESG-WARN (fi-snb-2600) Subgroup invalid-get-prop: dmesg-warn -> PASS (fi-snb-2600) fdo#100643 Subgroup size-max: pass -> DMESG-WARN (fi-snb-2600) Subgroup small-bo: dmesg-warn -> PASS (fi-snb-2600) fdo#100643 Subgroup unused-modifier: pass -> DMESG-WARN (fi-snb-2600) Subgroup unused-offsets: dmesg-warn -> PASS (fi-snb-2600) fdo#100643 Test kms_flip: Subgroup basic-flip-vs-modeset: pass -> DMESG-WARN (fi-kbl-7560u) Test kms_pipe_crc_basic: Subgroup hang-read-crc-pipe-a: pass -> DMESG-WARN (fi-kbl-7560u) Subgroup suspend-read-crc-pipe-c: dmesg-warn -> PASS (fi-kbl-7560u) fdo#100445 Test kms_setmode: Subgroup basic-clone-single-crtc: pass -> DMESG-WARN (fi-snb-2600) Test prime_self_import: Subgroup basic-with_fd_dup: pass -> DMESG-WARN (fi-snb-2600) Subgroup basic-with_one_bo: dmesg-warn -> PASS (fi-snb-2600) fdo#100643 Test prime_vgem: Subgroup basic-busy-default: pass -> DMESG-WARN (fi-snb-2600) fdo#100643 Subgroup basic-fence-flip: dmesg-warn -> PASS (fi-snb-2600) fdo#100643 Subgroup basic-fence-mmap: pass -> DMESG-WARN (fi-snb-2600) fdo#100643 Subgroup basic-fence-read: dmesg-warn -> PASS (fi-snb-2600) fdo#100643 Subgroup basic-read: pass -> DMESG-WARN (fi-snb-2520m) Subgroup basic-sync-default: dmesg-warn -> PASS (fi-snb-2520m) fdo#100643 fdo#100643 https://bugs.freedesktop.org/show_bug.cgi?id=100643 fdo#100445 https://bugs.freedesktop.org/show_bug.cgi?id=100445 fi-bdw-5557u total:278 pass:267 dwarn:0 dfail:0 fail:0 skip:11 time:431s fi-bdw-gvtdvmtotal:278 pass:256 dwarn:8 dfail:0 fail:0 skip:14 time:434s fi-bsw-n3050 total:278 pass:242 dwarn:0 dfail:0 fail:0 skip:36 time:572s WARNING: Long output truncated e461ecfd413fb930d00f44f3de0019e528b4731f drm-tip: 2017y-04m-10d-14h-25m-24s UTC integration manifest e51f5a0 drm/i915/execlists: Document runtime pm for intel_lrc_irq_handler() == Logs == For more det
[Intel-gfx] [maintainer-tools PATCH] dim: Expand drm-misc branch explanations
Add a bit more colour to the -misc branch explanations, and add a merge timeline
similar to the chart used in drm-intel.
Signed-off-by: Sean Paul
---
I've compiled the with this patch and hosted the output here:
https://people.freedesktop.org/~seanpaul/drm-misc.html
Makefile | 5
drm-misc-timeline.json | 67 ++
drm-misc-timeline.rst | 29 ++
drm-misc.rst | 35 +++---
4 files changed, 127 insertions(+), 9 deletions(-)
create mode 100644 drm-misc-timeline.json
create mode 100644 drm-misc-timeline.rst
diff --git a/Makefile b/Makefile
index 4291049..e079e35 100644
--- a/Makefile
+++ b/Makefile
@@ -17,6 +17,11 @@ drm-intel.html: drm-intel.rst drm-intel-flow.svg
drm-intel-timeline.rst drm-inte
rst2html $< > $@
sed -i 's/ $@
+ sed -i 's/2', 'b~>3', 'c~>4', 'd~>5', 'e~>6', 'f~>8',
+ /* -next to linus */
+ 'g~>1 feature merge', 'h~>0 feature merge',
+ /* misc-fixes to -next */
+ 'i~>a', 'j~>b', 'k~>c', 'l~>d', 'm~>e', 'n~>f',
+ /* misc-next-fixes to -next */
+ 'o~>g', 'q~>p',
+ /* misc-next to -next */
+ 'r~>s', 'x~>t', 'y~>u', 'z~>v', ';~>w', ':~>"'
+
+ ],
+
+ config: { hscale:3 },
+}
+
diff --git a/drm-misc-timeline.rst b/drm-misc-timeline.rst
new file mode 100644
index 000..6972777
--- /dev/null
+++ b/drm-misc-timeline.rst
@@ -0,0 +1,29 @@
+.. raw:: html
+
+
+ /* Embedded WaveDrom skin from http://wavedrom.com/skins/default.js */
+
+.. raw:: html
+ :url: http://wavedrom.com/skins/default.js
+
+.. raw:: html
+
+
+
+ /* Embedded WaveDrom engine from http://wavedrom.com/WaveDrom.js */
+
+.. raw:: html
+ :url: http://wavedrom.com/WaveDrom.js
+
+.. raw:: html
+
+
+
+
+.. raw:: html
+ :file: drm-misc-timeline.json
+
+.. raw:: html
+
+
+
diff --git a/drm-misc.rst b/drm-misc.rst
index 45ea795..caba8dc 100644
--- a/drm-misc.rst
+++ b/drm-misc.rst
@@ -38,20 +38,26 @@ drm-misc-next
This is the main feature branch where most of the patches land. This branch is
always open to "hide" the merge window from developers. To avoid upsetting
-linux-next and causing mayhem in the merge window in general no pull requests
-are sent to upstream 1-2 weeks before the merge window opens. Outside of that
-feature freeze period pull requests are sent to upstream roughly every week, to
-avoid too much coordination pains.
-
-If you're unsure apply your patch here, it can always be cherry-picked to one
of
-the -fixes patches later on. But in contrast to the drm-intel flow
+linux-next and causing mayhem in the merge window, in general no pull requests
+are sent to upstream after rc6 of the current kernel release. Outside of that
+feature freeze period, pull requests are sent to upstream roughly every 1-2
+weeks, to avoid too much coordination pains. See the timeline below for a
+visualization of patch flow.
+
+If you're unsure, apply your patch here, it can always be cherry-picked to one
+of the -fixes branches later on. But in contrast to the drm-intel flow
cherry-picking is not the default.
drm-misc-next-fixes
~~~
-This is for bugfixes to drm-misc-next after feature freeze, but before -rc1 is
-tagged.
+This branch is only relevant between rc6 of the current kernel version (X) and
+rc1 of the next (X+1). This is the feature freeze period mentioned above in the
+drm-misc-next section. During this time, drm-misc-next will roll over to target
+kernel version X+2, and drm-misc-fixes will still be on kernel version X, so
+drm-misc-next-fixes is used for fixes that target X+1.
+
+See the timeline below for a visualization of patch flow.
drm-misc-fixes
~~
@@ -67,6 +73,17 @@ updated drm-tip gets rebuilt. If there's a conflict see
section on `resolving
conflicts when rebuilding drm-tip
`_.
+Merge Timeline
+~~
+
+This chart describes the merge timelines for various branches in terms of one
+kernel release cycle. Worth noting is that we're working on two or three kernel
+releases at the same time. Big features take a long time to hit a kernel
+release. There are no fast paths.
+
+.. include:: drm-misc-timeline.rst
+
+
Merge Criteria
==
--
2.12.2.715.g7642488e1d-goog
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2] drm/i915: Acquire uncore.lock over intel_uncore_wait_for_register()
On Mon, Apr 10, 2017 at 04:55:31PM +0100, Chris Wilson wrote:
> We acquire the forcewake and use I915_READ_FW instead for the atomic
> wait within intel_uncore_wait_for_register. However, this still leaves
> us vulnerable to concurrent mmio access to the register, which can cause
> system hangs on gen7. The protection is to acquire uncore.lock around
> each register, so lets add it back.
>
> v2: Wrap __intel_wait_for_register_fw() to re-use its atomic wait_for
> loop and spare adding another for ourselves.
>
> Signed-off-by: Chris Wilson
> Cc: Michal Wajdeczko
> Cc: Joonas Lahtinen
> ---
> drivers/gpu/drm/i915/intel_uncore.c | 14 ++
> 1 file changed, 10 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_uncore.c
> b/drivers/gpu/drm/i915/intel_uncore.c
> index 53c8457869f6..01cea3b7a704 100644
> --- a/drivers/gpu/drm/i915/intel_uncore.c
> +++ b/drivers/gpu/drm/i915/intel_uncore.c
> @@ -1661,14 +1661,20 @@ int intel_wait_for_register(struct drm_i915_private
> *dev_priv,
> u32 value,
> unsigned int timeout_ms)
> {
> -
> unsigned fw =
> intel_uncore_forcewake_for_reg(dev_priv, reg, FW_REG_READ);
> int ret;
>
> - intel_uncore_forcewake_get(dev_priv, fw);
> - ret = wait_for_us((I915_READ_FW(reg) & mask) == value, 2);
> - intel_uncore_forcewake_put(dev_priv, fw);
> + spin_lock_irq(&dev_priv->uncore.lock);
> + intel_uncore_forcewake_get__locked(dev_priv, fw);
> +
> + ret = __intel_wait_for_register_fw(dev_priv,
> +reg, mask, value,
> +2, 0, NULL);
> +
> + intel_uncore_forcewake_put__locked(dev_priv, fw);
> + spin_unlock_irq(&dev_priv->uncore.lock);
Hmm, shouldn't we use spin_lock_irqsave/spin_unlock_irqrestore here?
Like in GEN6_READ_HEADER/GEN6_READ_FOOTER.
-Michal
> +
> if (ret)
> ret = wait_for((I915_READ_NOTRACE(reg) & mask) == value,
> timeout_ms);
> --
> 2.11.0
>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2] drm/i915: Acquire uncore.lock over intel_uncore_wait_for_register()
We acquire the forcewake and use I915_READ_FW instead for the atomic
wait within intel_uncore_wait_for_register. However, this still leaves
us vulnerable to concurrent mmio access to the register, which can cause
system hangs on gen7. The protection is to acquire uncore.lock around
each register, so lets add it back.
v2: Wrap __intel_wait_for_register_fw() to re-use its atomic wait_for
loop and spare adding another for ourselves.
Signed-off-by: Chris Wilson
Cc: Michal Wajdeczko
Cc: Joonas Lahtinen
---
drivers/gpu/drm/i915/intel_uncore.c | 14 ++
1 file changed, 10 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_uncore.c
b/drivers/gpu/drm/i915/intel_uncore.c
index 53c8457869f6..01cea3b7a704 100644
--- a/drivers/gpu/drm/i915/intel_uncore.c
+++ b/drivers/gpu/drm/i915/intel_uncore.c
@@ -1661,14 +1661,20 @@ int intel_wait_for_register(struct drm_i915_private
*dev_priv,
u32 value,
unsigned int timeout_ms)
{
-
unsigned fw =
intel_uncore_forcewake_for_reg(dev_priv, reg, FW_REG_READ);
int ret;
- intel_uncore_forcewake_get(dev_priv, fw);
- ret = wait_for_us((I915_READ_FW(reg) & mask) == value, 2);
- intel_uncore_forcewake_put(dev_priv, fw);
+ spin_lock_irq(&dev_priv->uncore.lock);
+ intel_uncore_forcewake_get__locked(dev_priv, fw);
+
+ ret = __intel_wait_for_register_fw(dev_priv,
+ reg, mask, value,
+ 2, 0, NULL);
+
+ intel_uncore_forcewake_put__locked(dev_priv, fw);
+ spin_unlock_irq(&dev_priv->uncore.lock);
+
if (ret)
ret = wait_for((I915_READ_NOTRACE(reg) & mask) == value,
timeout_ms);
--
2.11.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v4] ACPI / bus: Introduce a list of ids for "always present" devices
Several cherrytrail devices (all of which ship with windows 10) hide the
lpss pwm controller in ACPI, typically the _STA method looks like this:
Method (_STA, 0, NotSerialized) // _STA: Status
{
If (OSID == One)
{
Return (Zero)
}
Return (0x0F)
}
Where OSID is some dark magic seen in all cherrytrail ACPI tables making
the machine behave differently depending on which OS it *thinks* it is
booting, this gets set in a number of ways which we cannot control, on
some newer machines it simple hardcoded to "One" aka win10.
This causes the PWM controller to get hidden, which means Linux cannot
control the backlight level on cht based tablets / laptops.
Since loading the driver for this does no harm (the only in kernel user
of it is the i915 driver, which will only use it when it needs it), this
commit makes acpi_bus_get_status() always set status to ACPI_STA_DEFAULT
for the 80862288 device, fixing the lack of backlight control.
Signed-off-by: Hans de Goede
---
Changes in v2:
-Use pr_debug instead of ACPI_DEBUG_PRINT
Changes in v3:
-Un-inline acpi_set_device_status and do the always_present_device_ids
table check inside the un-inlined version of it
Changes in v4:
-Use dev_info instead of pr_debug
-Not only check for ACPI HID but also for CPU (SoC) model so as to not
for devices present on other models then for which the quirk is intended and
to avoid enabling unrelated ACPI devices which happen to use the same HID
---
drivers/acpi/bus.c | 55 +
include/acpi/acpi_bus.h | 6 +-
2 files changed, 56 insertions(+), 5 deletions(-)
diff --git a/drivers/acpi/bus.c b/drivers/acpi/bus.c
index 34fbe02..94106fe 100644
--- a/drivers/acpi/bus.c
+++ b/drivers/acpi/bus.c
@@ -34,6 +34,8 @@
#include
#include
#ifdef CONFIG_X86
+#include
+#include
#include
#endif
#include
@@ -132,6 +134,59 @@ int acpi_bus_get_status(struct acpi_device *device)
}
EXPORT_SYMBOL(acpi_bus_get_status);
+#ifdef CONFIG_X86
+/*
+ * Some ACPI devices are hidden (status == 0x0) in recent BIOS-es because
+ * some recent windows drivers bind to one device but poke at multiple
+ * devices at the same time, so the others get hidden.
+ * We work around this by always reporting ACPI_STA_DEFAULT for these
+ * devices. Note this MUST only be done for devices where this is safe.
+ *
+ * This forcing of devices to be present is limited to specific CPU (SoC)
+ * models both to avoid potentially causing trouble on other models and
+ * because some HIDs are re-used on different SoCs for completely
+ * different devices.
+ */
+struct always_present_device_id {
+ struct acpi_device_id hid[2];
+ struct x86_cpu_id cpu_id[2];
+};
+
+#define ENTRY(hid, cpu_model) {
\
+ { { hid, }, {} }, \
+ { { X86_VENDOR_INTEL, 6, cpu_model, X86_FEATURE_ANY, }, {} }, \
+}
+
+static const struct always_present_device_id always_present_device_ids[] = {
+ /*
+* Cherrytrail pwm directly poked by GPU driver in win10,
+* but Linux uses a separate pwm driver, harmless if not used.
+*/
+ ENTRY("80862288", INTEL_FAM6_ATOM_AIRMONT),
+};
+#endif
+
+void acpi_set_device_status(struct acpi_device *adev, u32 sta)
+{
+ u32 *status = (u32 *)&adev->status;
+#ifdef CONFIG_X86
+ int i;
+
+ /* acpi_match_device_ids checks status, so start with default */
+ *status = ACPI_STA_DEFAULT;
+ for (i = 0; i < ARRAY_SIZE(always_present_device_ids); i++) {
+ if (acpi_match_device_ids(adev,
+ always_present_device_ids[i].hid) == 0 &&
+ x86_match_cpu(always_present_device_ids[i].cpu_id)) {
+ dev_info(&adev->dev, "Device [%s] is in always present
list setting status [%08x]\n",
+adev->pnp.bus_id, ACPI_STA_DEFAULT);
+ return;
+ }
+ }
+#endif
+ *status = sta;
+}
+
void acpi_bus_private_data_handler(acpi_handle handle,
void *context)
{
diff --git a/include/acpi/acpi_bus.h b/include/acpi/acpi_bus.h
index 64498d5..a6ae057 100644
--- a/include/acpi/acpi_bus.h
+++ b/include/acpi/acpi_bus.h
@@ -441,11 +441,6 @@ static inline void *acpi_driver_data(struct acpi_device *d)
#define to_acpi_device(d) container_of(d, struct acpi_device, dev)
#define to_acpi_driver(d) container_of(d, struct acpi_driver, drv)
-static inline void acpi_set_device_status(struct acpi_device *adev, u32 sta)
-{
- *((u32 *)&adev->status) = sta;
-}
-
static inline void acpi_set_hp_context(struct acpi_device *adev,
struct acpi_hotplug_context *hp)
{
@@ -494,6 +489,7 @@ void acpi_bus_put_acpi_device(struct acpi_device *adev);
acpi_status acpi_bus_get_status_handle(acpi_handle handle,
[Intel-gfx] [PATCH] drm/i915/execlists: Document runtime pm for intel_lrc_irq_handler()
We indirectly hold the runtime-pm for the intel_lrc_irq_handler() by virtue of dev_priv->gt.awake keeping a wakeref whilst the requests are busy. As this is not obvious from the code, add a comment. Signed-off-by: Chris Wilson Cc: Tvrtko Ursulin --- drivers/gpu/drm/i915/intel_lrc.c | 9 + 1 file changed, 9 insertions(+) diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c index 0dc1cc4ad6e7..e16cc28dc783 100644 --- a/drivers/gpu/drm/i915/intel_lrc.c +++ b/drivers/gpu/drm/i915/intel_lrc.c @@ -515,6 +515,15 @@ static void intel_lrc_irq_handler(unsigned long data) struct execlist_port *port = engine->execlist_port; struct drm_i915_private *dev_priv = engine->i915; + /* We can skip acquiring intel_runtime_pm_get() here as it was taken +* on our behalf by the request (see i915_gem_mark_busy ()) and it will +* not be relinquished until the device is idle (see +* i915_gem_idle_work_handler()). As a precaution, we make sure +* that all ELSP are drained i.e. we have processed the CSB, +* before allowing ourselves to idle and calling intel_runtime_pm_put(). +*/ + GEM_BUG_ON(!dev_priv->gt.awake); + intel_uncore_forcewake_get(dev_priv, engine->fw_domains); /* Prefer doing test_and_clear_bit() as a two stage operation to avoid -- 2.11.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] ACPI / bus: Introduce a list of ids for "always present" devices
Hi,
On 10-04-17 15:56, Takashi Iwai wrote:
On Sun, 09 Apr 2017 22:32:46 +0200,
Hans de Goede wrote:
Hi,
On 27-02-17 23:53, Takashi Iwai wrote:
On Mon, 27 Feb 2017 22:27:58 +0100,
Rafael J. Wysocki wrote:
On Mon, Feb 27, 2017 at 3:40 PM, Takashi Iwai wrote:
Oh, this is interesting, please let me join to the party.
We've hit a similar problem, but for other one: namely, it's INT0002
that is found on a few CHT devices. It's never bound properly by a
similar reason, where _STA is always zero on Linux:
Method (_STA, 0, NotSerialized) // _STA: Status
{
If (SOCS <= 0x04)
{
Return (0x0F)
}
Else
{
Return (Zero)
}
}
The device is supposed to be a "virtual GPIO" stuff, and the driver
hasn't been upstreamed from Intel. Due to the lack of this driver
(and it's binding), the machine gets spurious IRQ#9 after the PM
resume, and it locks up at the second time of PM.
Well, the solution here seems to be to acquire the missing driver
instead of adding quirks to the ACPI core.
The driver is available (not upstreamed, though), but it's not bound
due to _STA above. That's why I'm interested in this thread.
Takashi thanks for pointing me to the INT0002 device / driver to
fix the spurious IRQ#9 after the PM resume issue. I was seeing this
on the GPD-win too (when suspending with power-button + wakeup with
spacebar). I've added a patch to add the INT0002 device to the
always present device list + cleaned up the INT0002 driver. I plan
to submit this upstream soon.
If you want to test this on your device you need these patches:
https://github.com/jwrdegoede/linux-sunxi/commit/a1a6e92f2665376ed72f575553238a93e88bb037
https://github.com/jwrdegoede/linux-sunxi/commit/4946f68f8eaa300f42289bf767722d78cf7fa9e2
https://github.com/jwrdegoede/linux-sunxi/commit/32640c816dd60d17f003ae8306863da01c215afb
https://github.com/jwrdegoede/linux-sunxi/commit/abb6a9d69690bb2a1a00b184b06cdae43d6ad001
Thanks Hans, these look promising!
One remaining concern is that INT0002 seems serving for other purpose,
too, in drivers/platform/x86/intel_menlow.c for the thermal
management. I wonder whether we can enable INT0002 unconditionally.
Oh, good point I already had the following in the driver to deal with this:
static const struct x86_cpu_id int0002_cpu_ids[] = {
/*
* Limit ourselves to Cherry Trail for now, until testing shows we
* need to handle the INT0002 device on Baytrail too.
* ICPU(INTEL_FAM6_ATOM_SILVERMONT1), * Valleyview, Bay Trail *
*/
ICPU(INTEL_FAM6_ATOM_AIRMONT), /* Braswell, Cherry Trail */
{}
};
probe()
{
/* Menlow has a different INT0002 device? */
data->cpu_id = x86_match_cpu(int0002_cpu_ids);
if (!data->cpu_id)
return -ENODEV;
}
But I guess we need to do the same for the always present stuff to force the
status to present, so now I've :
#ifdef CONFIG_X86
/*
* Some ACPI devices are hidden (status == 0x0) in recent BIOS-es because
* some recent windows drivers bind to one device but poke at multiple
* devices at the same time, so the others get hidden.
* We work around this by always reporting ACPI_STA_DEFAULT for these
* devices. Note this MUST only be done for devices where this is safe.
*
* This forcing of devices to be present is limited to specific CPU (SoC)
* models both to avoid potentially causing trouble on other models and
* because some HIDs are re-used on different SoCs for completely
* different devices.
*/
struct always_present_device_id {
struct acpi_device_id hid[2];
struct x86_cpu_id cpu_id[2];
};
#define ENTRY(hid, cpu_model) { \
{ { hid, }, {} }, \
{ { X86_VENDOR_INTEL, 6, cpu_model, X86_FEATURE_ANY, }, {} }\
}
static const struct always_present_device_id always_present_device_ids[] = {
/*
* Cherrytrail pwm directly poked by GPU driver in win10,
* but Linux uses a separate pwm driver, harmless if not used.
*/
ENTRY("80862288", INTEL_FAM6_ATOM_AIRMONT),
/*
* The INT0002 device is necessary to clear wakeup interrupt sources
* on Cherry Trail devices, without it we get nobody cared IRQ msgs.
*/
ENTRY("INT0002", INTEL_FAM6_ATOM_AIRMONT),
};
#endif
void acpi_set_device_status(struct acpi_device *adev, u32 sta)
{
u32 *status = (u32 *)&adev->status;
#ifdef CONFIG_X86
int i;
/* acpi_match_device_ids checks status, so start with default */
*status = ACPI_STA_DEFAULT;
for (i = 0; i < ARRAY_SIZE(always_present_device_ids); i++) {
if (acpi_match_device_ids(adev,
always_present_device_ids[i].hid) == 0 &&
x86_match_cpu(always_prese
Re: [Intel-gfx] [PATCH 2/3] drm/i915: Stop sleeping from inside gen6_bsd_submit_request()
On Mon, Apr 10, 2017 at 05:23:35PM +0200, Michal Wajdeczko wrote:
> On Mon, Apr 10, 2017 at 04:02:06PM +0100, Chris Wilson wrote:
> > submit_request() is called from an atomic context, it's not allowed to
> > sleep. We have to be careful in our parameters to
> > intel_uncore_wait_for_register() to limit ourselves to the atomic wait
> > loop and not incur the wrath of our warnings.
> >
> > Fixes: 6976e74b5fa1 ("drm/i915: Don't allow overuse of
> > __intel_wait_for_register_fw()")
> > Signed-off-by: Chris Wilson
> > Cc: Michal Wajdeczko
> > Cc: Joonas Lahtinen
> > Link:
> > http://patchwork.freedesktop.org/patch/msgid/20170410143807.22725-1-ch...@chris-wilson.co.uk
> > ---
> > drivers/gpu/drm/i915/intel_ringbuffer.c | 10 +-
> > 1 file changed, 5 insertions(+), 5 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c
> > b/drivers/gpu/drm/i915/intel_ringbuffer.c
> > index c98acc27279a..331da59a1eb5 100644
> > --- a/drivers/gpu/drm/i915/intel_ringbuffer.c
> > +++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
> > @@ -1729,11 +1729,11 @@ static void gen6_bsd_submit_request(struct
> > drm_i915_gem_request *request)
> > I915_WRITE64_FW(GEN6_BSD_RNCID, 0x0);
> >
> > /* Wait for the ring not to be idle, i.e. for it to wake up. */
> > - if (intel_wait_for_register_fw(dev_priv,
> > - GEN6_BSD_SLEEP_PSMI_CONTROL,
> > - GEN6_BSD_SLEEP_INDICATOR,
> > - 0,
> > - 50))
> > + if (__intel_wait_for_register_fw(dev_priv,
> > +GEN6_BSD_SLEEP_PSMI_CONTROL,
> > +GEN6_BSD_SLEEP_INDICATOR,
> > +0,
> > +1000, 0, NULL))
>
> Hmm, it's now 50x smaller timeout, but let's hope it's still enough, hence
We have already told the device to leave rc6 (we hold forcewake) so this
should be a formality. For the last few months we have been running with
a sleep after 2us, and have never seen the warning about sleeping from
here in CI -- so I think a 1ms (i.e. 500x longer) timeout is safe.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 3/3] drm/i915: Acquire uncore.lock over intel_uncore_wait_for_register()
On Mon, Apr 10, 2017 at 04:02:07PM +0100, Chris Wilson wrote:
> We acquire the forcewake and use I915_READ_FW instead for the atomic
> wait within intel_uncore_wait_for_register. However, this still leaves
> us vulnerable to concurrent mmio access to the register, which can cause
> system hangs on gen7. The protection is to acquire uncore.lock around
> each register, so lets add it back.
>
> Signed-off-by: Chris Wilson
> Cc: Michal Wajdeczko
> Cc: Joonas Lahtinen
> ---
> drivers/gpu/drm/i915/intel_uncore.c | 10 +++---
> 1 file changed, 7 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_uncore.c
> b/drivers/gpu/drm/i915/intel_uncore.c
> index 53c8457869f6..d2ba3011c2f0 100644
> --- a/drivers/gpu/drm/i915/intel_uncore.c
> +++ b/drivers/gpu/drm/i915/intel_uncore.c
> @@ -1661,14 +1661,18 @@ int intel_wait_for_register(struct drm_i915_private
> *dev_priv,
> u32 value,
> unsigned int timeout_ms)
> {
> -
> unsigned fw =
> intel_uncore_forcewake_for_reg(dev_priv, reg, FW_REG_READ);
> int ret;
>
> - intel_uncore_forcewake_get(dev_priv, fw);
> + spin_lock_irq(&dev_priv->uncore.lock);
> + intel_uncore_forcewake_get__locked(dev_priv, fw);
> +
> ret = wait_for_us((I915_READ_FW(reg) & mask) == value, 2);
To further decrease driver size we may try to call here our helper function:
ret = __intel_wait_for_register_fw(dev_priv, reg, mask, value, 2, 0,
NULL);
-Michal
> - intel_uncore_forcewake_put(dev_priv, fw);
> +
> + intel_uncore_forcewake_put__locked(dev_priv, fw);
> + spin_unlock_irq(&dev_priv->uncore.lock);
> +
> if (ret)
> ret = wait_for((I915_READ_NOTRACE(reg) & mask) == value,
> timeout_ms);
> --
> 2.11.0
>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/3] drm/i915: Stop second guessing the caller for intel_uncore_wait_for_register()
On Mon, Apr 10, 2017 at 05:20:32PM +0200, Michal Wajdeczko wrote: > On Mon, Apr 10, 2017 at 04:02:05PM +0100, Chris Wilson wrote: > > Allow the caller to use the fast_timeout_us to specify how long to wait > > within the atomic section, rather than transparently switching to a > > sleeping loop for larger values. This is required as some callsites may > > need a long wait and are in an atomic section. > > > > Signed-off-by: Chris Wilson > > Cc: Michal Wajdeczko > > Cc: Joonas Lahtinen > > --- > > drivers/gpu/drm/i915/intel_uncore.c | 11 ++- > > 1 file changed, 6 insertions(+), 5 deletions(-) > > > > diff --git a/drivers/gpu/drm/i915/intel_uncore.c > > b/drivers/gpu/drm/i915/intel_uncore.c > > index eb38392a2435..53c8457869f6 100644 > > --- a/drivers/gpu/drm/i915/intel_uncore.c > > +++ b/drivers/gpu/drm/i915/intel_uncore.c > > @@ -1601,7 +1601,7 @@ static int gen6_reset_engines(struct drm_i915_private > > *dev_priv, > > * > > * Otherwise, the wait will timeout after @slow_timeout_ms milliseconds. > > * For atomic context @slow_timeout_ms must be zero and @fast_timeout_us > > - * must be not larger than 10 microseconds. > > + * must be not larger than 20, microseconds. > > So we don't enforce this any more ? I considered adding a GEM_BUG_ON / GEM_WARN_ON, but really just not listening to them and hitting the sleep was my answer to sillyness. Atomic spinning for 20ms is not acceptable. :| > > * Note that this routine assumes the caller holds forcewake asserted, it > > is > > * not suitable for very long waits. See intel_wait_for_register() if you > > @@ -1623,16 +1623,17 @@ int __intel_wait_for_register_fw(struct > > drm_i915_private *dev_priv, > > int ret; > > > > /* Catch any overuse of this function */ > > - might_sleep_if(fast_timeout_us > 10 || slow_timeout_ms); > > + might_sleep_if(slow_timeout_ms); > > > > - if (fast_timeout_us > 10) > > - ret = _wait_for(done, fast_timeout_us, 10); > > - else > > + ret = -ETIMEDOUT; > > + if (fast_timeout_us && fast_timeout_us < 2) > > ret = _wait_for_atomic(done, fast_timeout_us, 0); > > if (ret) > > ret = wait_for(done, slow_timeout_ms); > > What if someone passes fast=20001us and slow=0ms ? > Maybe like this: > > might_sleep_if(fast_timeout_us > 2 || slow_timeout_ms); > > if (fast_timeout_us && fast_timeout_us < 2) > ret = _wait_for_atomic(done, fast_timeout_us, 0); > else > slow_timeout_ms += fast_timeout_us/1000; No. Just shoot it down in review. -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/3] drm/i915: Stop second guessing the caller for intel_uncore_wait_for_register()
== Series Details == Series: series starting with [1/3] drm/i915: Stop second guessing the caller for intel_uncore_wait_for_register() URL : https://patchwork.freedesktop.org/series/22786/ State : success == Summary == Series 22786v1 Series without cover letter https://patchwork.freedesktop.org/api/1.0/series/22786/revisions/1/mbox/ Test core_auth: Subgroup basic-auth: dmesg-warn -> PASS (fi-snb-2520m) fdo#100643 dmesg-warn -> PASS (fi-snb-2600) fdo#100643 Test drv_getparams_basic: Subgroup basic-subslice-total: dmesg-warn -> PASS (fi-snb-2520m) fdo#100643 Test drv_module_reload: Subgroup basic-no-display: dmesg-warn -> PASS (fi-snb-2520m) fdo#100643 dmesg-warn -> PASS (fi-snb-2600) fdo#100643 Subgroup basic-reload: dmesg-warn -> PASS (fi-snb-2520m) fdo#100643 dmesg-warn -> PASS (fi-snb-2600) fdo#100643 Subgroup basic-reload-final: dmesg-warn -> PASS (fi-snb-2520m) fdo#100643 dmesg-warn -> PASS (fi-snb-2600) fdo#100643 Test gem_basic: Subgroup create-close: dmesg-warn -> PASS (fi-snb-2520m) fdo#100643 Test gem_busy: Subgroup basic-hang-default: dmesg-warn -> PASS (fi-snb-2520m) fdo#100643 dmesg-warn -> PASS (fi-snb-2600) fdo#100643 Test gem_close_race: Subgroup basic-threads: dmesg-warn -> PASS (fi-snb-2520m) fdo#100643 dmesg-warn -> PASS (fi-snb-2600) fdo#100643 Test gem_cs_tlb: Subgroup basic-default: dmesg-warn -> PASS (fi-snb-2520m) fdo#100643 Test gem_ctx_basic: dmesg-warn -> PASS (fi-snb-2520m) fdo#100643 dmesg-warn -> PASS (fi-snb-2600) fdo#100643 Test gem_ctx_create: Subgroup basic-files: dmesg-warn -> PASS (fi-snb-2520m) fdo#100643 dmesg-warn -> PASS (fi-snb-2600) fdo#100643 Test gem_ctx_param: Subgroup basic-default: dmesg-warn -> PASS (fi-snb-2520m) fdo#100643 Test gem_ctx_switch: Subgroup basic-default: dmesg-warn -> PASS (fi-snb-2520m) fdo#100643 dmesg-warn -> PASS (fi-snb-2600) fdo#100643 Subgroup basic-default-heavy: dmesg-warn -> PASS (fi-snb-2520m) fdo#100643 dmesg-warn -> PASS (fi-snb-2600) fdo#100643 Test gem_exec_basic: Subgroup gtt-render: dmesg-warn -> PASS (fi-snb-2520m) fdo#100643 Subgroup readonly-bsd: dmesg-warn -> PASS (fi-snb-2520m) fdo#100643 Subgroup readonly-default: dmesg-warn -> PASS (fi-snb-2520m) fdo#100643 Subgroup readonly-render: dmesg-warn -> PASS (fi-snb-2600) fdo#100643 Test gem_exec_create: Subgroup basic: dmesg-warn -> PASS (fi-snb-2520m) fdo#100643 dmesg-warn -> PASS (fi-snb-2600) fdo#100643 Test gem_exec_fence: Subgroup await-hang-default: dmesg-warn -> PASS (fi-snb-2520m) fdo#100643 dmesg-warn -> PASS (fi-snb-2600) fdo#100643 Subgroup basic-await-default: dmesg-warn -> PASS (fi-snb-2520m) fdo#100643 dmesg-warn -> PASS (fi-snb-2600) fdo#100643 Subgroup basic-wait-default: dmesg-warn -> PASS (fi-snb-2520m) fdo#100643 Subgroup nb-await-default: dmesg-warn -> PASS (fi-snb-2520m) fdo#100643 dmesg-warn -> PASS (fi-snb-2600) fdo#100643 Test gem_exec_flush: Subgroup basic-batch-kernel-default-uc: dmesg-warn -> PASS (fi-snb-2520m) fdo#100643 dmesg-warn -> FAIL (fi-snb-2600) fdo#100643 Subgroup basic-batch-kernel-default-wb: dmesg-warn -> PASS (fi-snb-2520m) fdo#100643 dmesg-warn -> PASS (fi-snb-2600) fdo#100643 Subgroup basic-uc-pro-default: dmesg-warn -> PASS (fi-snb-2520m) fdo#100643 dmesg-warn -> PASS (fi-snb-2600) fdo#100643 Subgroup basic-uc-prw-default: dmesg-warn -> PASS (fi-snb-2520m) fdo#100643 dmesg-warn -> PASS (fi-snb-2600) fdo#100643 Subgroup basic-uc-ro-default: dmesg-warn -> PASS (fi-snb-2520m) fdo#100643 dmesg-warn -> PASS (fi-snb-2600) fdo#100643 Subgroup basic-uc-rw-default: dmesg-warn -> PASS (fi-snb-2520m) fdo#100643 dmesg-warn -> PASS (fi-snb-2600) fdo#100643 Subgroup basic-uc-set-default: dmesg-warn -> PASS (fi-snb-2520m) fdo#100643
Re: [Intel-gfx] [PATCH 2/3] drm/i915: Stop sleeping from inside gen6_bsd_submit_request()
On Mon, Apr 10, 2017 at 04:02:06PM +0100, Chris Wilson wrote:
> submit_request() is called from an atomic context, it's not allowed to
> sleep. We have to be careful in our parameters to
> intel_uncore_wait_for_register() to limit ourselves to the atomic wait
> loop and not incur the wrath of our warnings.
>
> Fixes: 6976e74b5fa1 ("drm/i915: Don't allow overuse of
> __intel_wait_for_register_fw()")
> Signed-off-by: Chris Wilson
> Cc: Michal Wajdeczko
> Cc: Joonas Lahtinen
> Link:
> http://patchwork.freedesktop.org/patch/msgid/20170410143807.22725-1-ch...@chris-wilson.co.uk
> ---
> drivers/gpu/drm/i915/intel_ringbuffer.c | 10 +-
> 1 file changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c
> b/drivers/gpu/drm/i915/intel_ringbuffer.c
> index c98acc27279a..331da59a1eb5 100644
> --- a/drivers/gpu/drm/i915/intel_ringbuffer.c
> +++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
> @@ -1729,11 +1729,11 @@ static void gen6_bsd_submit_request(struct
> drm_i915_gem_request *request)
> I915_WRITE64_FW(GEN6_BSD_RNCID, 0x0);
>
> /* Wait for the ring not to be idle, i.e. for it to wake up. */
> - if (intel_wait_for_register_fw(dev_priv,
> -GEN6_BSD_SLEEP_PSMI_CONTROL,
> -GEN6_BSD_SLEEP_INDICATOR,
> -0,
> -50))
> + if (__intel_wait_for_register_fw(dev_priv,
> + GEN6_BSD_SLEEP_PSMI_CONTROL,
> + GEN6_BSD_SLEEP_INDICATOR,
> + 0,
> + 1000, 0, NULL))
Hmm, it's now 50x smaller timeout, but let's hope it's still enough, hence
Reviewed-by: Michal Wajdeczko
-Michal
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/3] drm/i915: Stop second guessing the caller for intel_uncore_wait_for_register()
On Mon, Apr 10, 2017 at 04:02:05PM +0100, Chris Wilson wrote: > Allow the caller to use the fast_timeout_us to specify how long to wait > within the atomic section, rather than transparently switching to a > sleeping loop for larger values. This is required as some callsites may > need a long wait and are in an atomic section. > > Signed-off-by: Chris Wilson > Cc: Michal Wajdeczko > Cc: Joonas Lahtinen > --- > drivers/gpu/drm/i915/intel_uncore.c | 11 ++- > 1 file changed, 6 insertions(+), 5 deletions(-) > > diff --git a/drivers/gpu/drm/i915/intel_uncore.c > b/drivers/gpu/drm/i915/intel_uncore.c > index eb38392a2435..53c8457869f6 100644 > --- a/drivers/gpu/drm/i915/intel_uncore.c > +++ b/drivers/gpu/drm/i915/intel_uncore.c > @@ -1601,7 +1601,7 @@ static int gen6_reset_engines(struct drm_i915_private > *dev_priv, > * > * Otherwise, the wait will timeout after @slow_timeout_ms milliseconds. > * For atomic context @slow_timeout_ms must be zero and @fast_timeout_us > - * must be not larger than 10 microseconds. > + * must be not larger than 20, microseconds. So we don't enforce this any more ? > * > * Note that this routine assumes the caller holds forcewake asserted, it is > * not suitable for very long waits. See intel_wait_for_register() if you > @@ -1623,16 +1623,17 @@ int __intel_wait_for_register_fw(struct > drm_i915_private *dev_priv, > int ret; > > /* Catch any overuse of this function */ > - might_sleep_if(fast_timeout_us > 10 || slow_timeout_ms); > + might_sleep_if(slow_timeout_ms); > > - if (fast_timeout_us > 10) > - ret = _wait_for(done, fast_timeout_us, 10); > - else > + ret = -ETIMEDOUT; > + if (fast_timeout_us && fast_timeout_us < 2) > ret = _wait_for_atomic(done, fast_timeout_us, 0); > if (ret) > ret = wait_for(done, slow_timeout_ms); What if someone passes fast=20001us and slow=0ms ? Maybe like this: might_sleep_if(fast_timeout_us > 2 || slow_timeout_ms); if (fast_timeout_us && fast_timeout_us < 2) ret = _wait_for_atomic(done, fast_timeout_us, 0); else slow_timeout_ms += fast_timeout_us/1000; if (slow_timeout_ms) ret = wait_for(done, slow_timeout_ms); -Michal ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2] drm/i915: Don't allow overuse of __intel_wait_for_register_fw()
On Mon, Apr 10, 2017 at 02:58:34PM +, Saarinen, Jani wrote: > HI, > > -Original Message- > > From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf > > Of Chris Wilson > > Sent: Monday, April 10, 2017 5:26 PM > > To: Wajdeczko, Michal > > Cc: intel-gfx@lists.freedesktop.org > > Subject: Re: [Intel-gfx] [PATCH v2] drm/i915: Don't allow overuse of > > __intel_wait_for_register_fw() > > > > On Mon, Apr 10, 2017 at 12:17:47PM +, Michal Wajdeczko wrote: > > > This function should not be called with long timeouts in atomic context. > > > Annotate it as might_sleep if timeout is longer than 10us. > > > > > > v2: fix comment (Michal) > > > > > > Signed-off-by: Michal Wajdeczko > > > Suggested-by: Chris Wilson > > > Cc: Chris Wilson > > > > Reviewed-by: Chris Wilson > > > > And pushed, thanks for the patch and for including the limits in the doc. > > -Chris > Was there reason why pushed as clearly seen issues on pw run: > https://patchwork.freedesktop.org/series/22774/ > Or is there known issues we are planning to fix now? Now same faults on on > tip: https://intel-gfx-ci.01.org/CI/ Because I was blind. The bug was latent and fix is sent. -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BAT: warning for drm/i915: Stop sleeping from inside gen6_bsd_submit_request() (rev2)
== Series Details == Series: drm/i915: Stop sleeping from inside gen6_bsd_submit_request() (rev2) URL : https://patchwork.freedesktop.org/series/22783/ State : warning == Summary == Series 22783v2 drm/i915: Stop sleeping from inside gen6_bsd_submit_request() https://patchwork.freedesktop.org/api/1.0/series/22783/revisions/2/mbox/ Test drv_getparams_basic: Subgroup basic-subslice-total: dmesg-warn -> PASS (fi-snb-2520m) Test drv_hangman: Subgroup error-state-basic: pass -> DMESG-WARN (fi-snb-2520m) Test gem_basic: Subgroup create-close: dmesg-warn -> PASS (fi-snb-2520m) Subgroup create-fd-close: pass -> DMESG-WARN (fi-snb-2520m) Test gem_ctx_param: Subgroup basic-default: dmesg-warn -> PASS (fi-snb-2520m) Test gem_exec_basic: Subgroup basic-render: pass -> DMESG-WARN (fi-snb-2520m) Subgroup gtt-bsd: pass -> DMESG-WARN (fi-snb-2600) pass -> DMESG-WARN (fi-snb-2520m) Subgroup gtt-default: pass -> DMESG-WARN (fi-snb-2520m) Subgroup gtt-render: dmesg-warn -> PASS (fi-snb-2520m) Subgroup readonly-blt: pass -> DMESG-WARN (fi-snb-2520m) Subgroup readonly-bsd: dmesg-warn -> PASS (fi-snb-2520m) Subgroup readonly-default: dmesg-warn -> PASS (fi-snb-2520m) Subgroup readonly-render: dmesg-warn -> PASS (fi-snb-2600) Test gem_exec_fence: Subgroup basic-busy-default: pass -> DMESG-WARN (fi-snb-2520m) Subgroup basic-wait-default: dmesg-warn -> PASS (fi-snb-2520m) Test gem_exec_reloc: Subgroup basic-cpu-gtt-active: dmesg-warn -> PASS (fi-snb-2520m) Subgroup basic-cpu-read-noreloc: pass -> DMESG-WARN (fi-snb-2600) Subgroup basic-gtt-active: pass -> DMESG-WARN (fi-snb-2520m) Subgroup basic-gtt-cpu-active: pass -> DMESG-WARN (fi-snb-2520m) Subgroup basic-gtt-read: pass -> DMESG-WARN (fi-snb-2600) Subgroup basic-gtt-read-noreloc: dmesg-warn -> PASS (fi-snb-2600) Subgroup basic-write-cpu: dmesg-warn -> PASS (fi-snb-2600) Subgroup basic-write-gtt-active: dmesg-warn -> PASS (fi-snb-2600) Test gem_exec_store: Subgroup basic-all: dmesg-warn -> PASS (fi-snb-2520m) Subgroup basic-blt: pass -> DMESG-WARN (fi-snb-2520m) Subgroup basic-render: dmesg-warn -> PASS (fi-snb-2520m) Test gem_exec_suspend: Subgroup basic-s4-devices: dmesg-warn -> PASS (fi-kbl-7560u) fdo#100125 Test gem_ringfill: Subgroup basic-default-fd: pass -> DMESG-WARN (fi-snb-2520m) Test kms_addfb_basic: Subgroup bad-pitch-128: dmesg-warn -> PASS (fi-snb-2600) Subgroup bad-pitch-256: pass -> DMESG-WARN (fi-snb-2600) Test kms_flip: Subgroup basic-flip-vs-dpms: pass -> DMESG-WARN (fi-kbl-7560u) Test kms_force_connector_basic: Subgroup force-edid: dmesg-warn -> PASS (fi-snb-2600) Subgroup prune-stale-modes: pass -> DMESG-WARN (fi-snb-2600) Test kms_frontbuffer_tracking: Subgroup basic: pass -> DMESG-WARN (fi-kbl-7560u) Test kms_pipe_crc_basic: Subgroup nonblocking-crc-pipe-b: pass -> DMESG-WARN (fi-kbl-7560u) Subgroup read-crc-pipe-c-frame-sequence: pass -> DMESG-WARN (fi-kbl-7560u) Subgroup suspend-read-crc-pipe-c: dmesg-warn -> PASS (fi-kbl-7560u) fdo#100445 Test prime_self_import: Subgroup basic-with_fd_dup: pass -> DMESG-WARN (fi-snb-2600) Subgroup basic-with_one_bo: dmesg-warn -> PASS (fi-snb-2600) Test prime_vgem: Subgroup basic-busy-default: WARNING: Long output truncated e461ecfd413fb930d00f44f3de0019e528b4731f drm-tip: 2017y-04m-10d-14h-25m-24s UTC integration manifest 5a4d34a drm/i915: Stop sleeping from inside gen6_bsd_submit_request() == Logs == For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_4462/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] Old Laptop Linux Driver
Hi all, I am looking for the best driver to use on an old computer running RHEL 7.2. The computer is a Gateway m465-g which has an Intel 945gm Chipset with integrated graphics - intel graphics media accelerator (GMA) 950. What driver am I looking for, and how would I install it. The computer does not connect to the internet. Any advice? Thanks Steven Steven Stangle Software Engineer Engineering Leadership Program General Dynamics Mission Systems 100 Plastics Ave Pittsfield, MA 01201 Work - (413) 494-3574 Cell - (518) 791-6737 This message and/or attachments may include information subject to GD Corporate Policies 07-103 and 07-105 and is intended to be accessed only by authorized recipients. Use, storage and transmission are governed by General Dynamics and its policies. Contractual restrictions apply to third parties. Recipients should refer to the policies or contract to determine proper handling. Unauthorized review, use, disclosure or distribution is prohibited. If you are not an intended recipient, please contact the sender and destroy all copies of the original message. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/3] drm/i915: Stop sleeping from inside gen6_bsd_submit_request()
submit_request() is called from an atomic context, it's not allowed to
sleep. We have to be careful in our parameters to
intel_uncore_wait_for_register() to limit ourselves to the atomic wait
loop and not incur the wrath of our warnings.
Fixes: 6976e74b5fa1 ("drm/i915: Don't allow overuse of
__intel_wait_for_register_fw()")
Signed-off-by: Chris Wilson
Cc: Michal Wajdeczko
Cc: Joonas Lahtinen
Link:
http://patchwork.freedesktop.org/patch/msgid/20170410143807.22725-1-ch...@chris-wilson.co.uk
---
drivers/gpu/drm/i915/intel_ringbuffer.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c
b/drivers/gpu/drm/i915/intel_ringbuffer.c
index c98acc27279a..331da59a1eb5 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.c
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
@@ -1729,11 +1729,11 @@ static void gen6_bsd_submit_request(struct
drm_i915_gem_request *request)
I915_WRITE64_FW(GEN6_BSD_RNCID, 0x0);
/* Wait for the ring not to be idle, i.e. for it to wake up. */
- if (intel_wait_for_register_fw(dev_priv,
- GEN6_BSD_SLEEP_PSMI_CONTROL,
- GEN6_BSD_SLEEP_INDICATOR,
- 0,
- 50))
+ if (__intel_wait_for_register_fw(dev_priv,
+GEN6_BSD_SLEEP_PSMI_CONTROL,
+GEN6_BSD_SLEEP_INDICATOR,
+0,
+1000, 0, NULL))
DRM_ERROR("timed out waiting for the BSD ring to wake up\n");
/* Now that the ring is fully powered up, update the tail */
--
2.11.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/3] drm/i915: Stop second guessing the caller for intel_uncore_wait_for_register()
Allow the caller to use the fast_timeout_us to specify how long to wait within the atomic section, rather than transparently switching to a sleeping loop for larger values. This is required as some callsites may need a long wait and are in an atomic section. Signed-off-by: Chris Wilson Cc: Michal Wajdeczko Cc: Joonas Lahtinen --- drivers/gpu/drm/i915/intel_uncore.c | 11 ++- 1 file changed, 6 insertions(+), 5 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_uncore.c b/drivers/gpu/drm/i915/intel_uncore.c index eb38392a2435..53c8457869f6 100644 --- a/drivers/gpu/drm/i915/intel_uncore.c +++ b/drivers/gpu/drm/i915/intel_uncore.c @@ -1601,7 +1601,7 @@ static int gen6_reset_engines(struct drm_i915_private *dev_priv, * * Otherwise, the wait will timeout after @slow_timeout_ms milliseconds. * For atomic context @slow_timeout_ms must be zero and @fast_timeout_us - * must be not larger than 10 microseconds. + * must be not larger than 20, microseconds. * * Note that this routine assumes the caller holds forcewake asserted, it is * not suitable for very long waits. See intel_wait_for_register() if you @@ -1623,16 +1623,17 @@ int __intel_wait_for_register_fw(struct drm_i915_private *dev_priv, int ret; /* Catch any overuse of this function */ - might_sleep_if(fast_timeout_us > 10 || slow_timeout_ms); + might_sleep_if(slow_timeout_ms); - if (fast_timeout_us > 10) - ret = _wait_for(done, fast_timeout_us, 10); - else + ret = -ETIMEDOUT; + if (fast_timeout_us && fast_timeout_us < 2) ret = _wait_for_atomic(done, fast_timeout_us, 0); if (ret) ret = wait_for(done, slow_timeout_ms); + if (out_value) *out_value = reg_value; + return ret; #undef done } -- 2.11.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 3/3] drm/i915: Acquire uncore.lock over intel_uncore_wait_for_register()
We acquire the forcewake and use I915_READ_FW instead for the atomic
wait within intel_uncore_wait_for_register. However, this still leaves
us vulnerable to concurrent mmio access to the register, which can cause
system hangs on gen7. The protection is to acquire uncore.lock around
each register, so lets add it back.
Signed-off-by: Chris Wilson
Cc: Michal Wajdeczko
Cc: Joonas Lahtinen
---
drivers/gpu/drm/i915/intel_uncore.c | 10 +++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_uncore.c
b/drivers/gpu/drm/i915/intel_uncore.c
index 53c8457869f6..d2ba3011c2f0 100644
--- a/drivers/gpu/drm/i915/intel_uncore.c
+++ b/drivers/gpu/drm/i915/intel_uncore.c
@@ -1661,14 +1661,18 @@ int intel_wait_for_register(struct drm_i915_private
*dev_priv,
u32 value,
unsigned int timeout_ms)
{
-
unsigned fw =
intel_uncore_forcewake_for_reg(dev_priv, reg, FW_REG_READ);
int ret;
- intel_uncore_forcewake_get(dev_priv, fw);
+ spin_lock_irq(&dev_priv->uncore.lock);
+ intel_uncore_forcewake_get__locked(dev_priv, fw);
+
ret = wait_for_us((I915_READ_FW(reg) & mask) == value, 2);
- intel_uncore_forcewake_put(dev_priv, fw);
+
+ intel_uncore_forcewake_put__locked(dev_priv, fw);
+ spin_unlock_irq(&dev_priv->uncore.lock);
+
if (ret)
ret = wait_for((I915_READ_NOTRACE(reg) & mask) == value,
timeout_ms);
--
2.11.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2] drm/i915: Don't allow overuse of __intel_wait_for_register_fw()
On Mon, Apr 10, 2017 at 03:26:06PM +0100, Chris Wilson wrote: > On Mon, Apr 10, 2017 at 12:17:47PM +, Michal Wajdeczko wrote: > > This function should not be called with long timeouts in atomic context. > > Annotate it as might_sleep if timeout is longer than 10us. > > > > v2: fix comment (Michal) > > > > Signed-off-by: Michal Wajdeczko > > Suggested-by: Chris Wilson > > Cc: Chris Wilson > > Reviewed-by: Chris Wilson > > And pushed, thanks for the patch and for including the limits in the > doc. Drat, skimmed over the warning from patchwork. Just didn't believe we had that latent bug... -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2] drm/i915: Don't allow overuse of __intel_wait_for_register_fw()
HI, > -Original Message- > From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf > Of Chris Wilson > Sent: Monday, April 10, 2017 5:26 PM > To: Wajdeczko, Michal > Cc: intel-gfx@lists.freedesktop.org > Subject: Re: [Intel-gfx] [PATCH v2] drm/i915: Don't allow overuse of > __intel_wait_for_register_fw() > > On Mon, Apr 10, 2017 at 12:17:47PM +, Michal Wajdeczko wrote: > > This function should not be called with long timeouts in atomic context. > > Annotate it as might_sleep if timeout is longer than 10us. > > > > v2: fix comment (Michal) > > > > Signed-off-by: Michal Wajdeczko > > Suggested-by: Chris Wilson > > Cc: Chris Wilson > > Reviewed-by: Chris Wilson > > And pushed, thanks for the patch and for including the limits in the doc. > -Chris Was there reason why pushed as clearly seen issues on pw run: https://patchwork.freedesktop.org/series/22774/ Or is there known issues we are planning to fix now? Now same faults on on tip: https://intel-gfx-ci.01.org/CI/ Br, Jani Saarinen Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Stop sleeping from inside gen6_bsd_submit_request()
On Mon, Apr 10, 2017 at 04:43:45PM +0200, Michal Wajdeczko wrote:
> On Mon, Apr 10, 2017 at 03:38:07PM +0100, Chris Wilson wrote:
> > submit_request() is called from an atomic context, it's not allowed to
> > sleep. We have to be careful in our parameters to
> > intel_uncore_wait_for_register() to limit ourselves to the atomic wait
> > loop and not incur the wrath of our warnings.
> >
> > Fixes: 6976e74b5fa1 ("drm/i915: Don't allow overuse of
> > __intel_wait_for_register_fw()")
> > Signed-off-by: Chris Wilson
> > Cc: Michal Wajdeczko
> > Cc: Joonas Lahtinen
> > ---
> > drivers/gpu/drm/i915/intel_ringbuffer.c | 10 +-
> > 1 file changed, 5 insertions(+), 5 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c
> > b/drivers/gpu/drm/i915/intel_ringbuffer.c
> > index c98acc27279a..331da59a1eb5 100644
> > --- a/drivers/gpu/drm/i915/intel_ringbuffer.c
> > +++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
> > @@ -1729,11 +1729,11 @@ static void gen6_bsd_submit_request(struct
> > drm_i915_gem_request *request)
> > I915_WRITE64_FW(GEN6_BSD_RNCID, 0x0);
> >
> > /* Wait for the ring not to be idle, i.e. for it to wake up. */
> > - if (intel_wait_for_register_fw(dev_priv,
> > - GEN6_BSD_SLEEP_PSMI_CONTROL,
> > - GEN6_BSD_SLEEP_INDICATOR,
> > - 0,
> > - 50))
> > + if (__intel_wait_for_register_fw(dev_priv,
> > +GEN6_BSD_SLEEP_PSMI_CONTROL,
> > +GEN6_BSD_SLEEP_INDICATOR,
> > +0,
> > +1000, 0, NULL))
>
> 1000us will still cause __intel_wait_for_register_fw to complain. Limit is
> 10us.
Time to kill that then as well.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Stop sleeping from inside gen6_bsd_submit_request()
On Mon, Apr 10, 2017 at 03:38:07PM +0100, Chris Wilson wrote:
> submit_request() is called from an atomic context, it's not allowed to
> sleep. We have to be careful in our parameters to
> intel_uncore_wait_for_register() to limit ourselves to the atomic wait
> loop and not incur the wrath of our warnings.
>
> Fixes: 6976e74b5fa1 ("drm/i915: Don't allow overuse of
> __intel_wait_for_register_fw()")
> Signed-off-by: Chris Wilson
> Cc: Michal Wajdeczko
> Cc: Joonas Lahtinen
> ---
> drivers/gpu/drm/i915/intel_ringbuffer.c | 10 +-
> 1 file changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c
> b/drivers/gpu/drm/i915/intel_ringbuffer.c
> index c98acc27279a..331da59a1eb5 100644
> --- a/drivers/gpu/drm/i915/intel_ringbuffer.c
> +++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
> @@ -1729,11 +1729,11 @@ static void gen6_bsd_submit_request(struct
> drm_i915_gem_request *request)
> I915_WRITE64_FW(GEN6_BSD_RNCID, 0x0);
>
> /* Wait for the ring not to be idle, i.e. for it to wake up. */
> - if (intel_wait_for_register_fw(dev_priv,
> -GEN6_BSD_SLEEP_PSMI_CONTROL,
> -GEN6_BSD_SLEEP_INDICATOR,
> -0,
> -50))
> + if (__intel_wait_for_register_fw(dev_priv,
> + GEN6_BSD_SLEEP_PSMI_CONTROL,
> + GEN6_BSD_SLEEP_INDICATOR,
> + 0,
> + 1000, 0, NULL))
1000us will still cause __intel_wait_for_register_fw to complain. Limit is 10us.
-Michal
> DRM_ERROR("timed out waiting for the BSD ring to wake up\n");
>
> /* Now that the ring is fully powered up, update the tail */
> --
> 2.11.0
>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Stop sleeping from inside gen6_bsd_submit_request()
submit_request() is called from an atomic context, it's not allowed to
sleep. We have to be careful in our parameters to
intel_uncore_wait_for_register() to limit ourselves to the atomic wait
loop and not incur the wrath of our warnings.
Fixes: 6976e74b5fa1 ("drm/i915: Don't allow overuse of
__intel_wait_for_register_fw()")
Signed-off-by: Chris Wilson
Cc: Michal Wajdeczko
Cc: Joonas Lahtinen
---
drivers/gpu/drm/i915/intel_ringbuffer.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c
b/drivers/gpu/drm/i915/intel_ringbuffer.c
index c98acc27279a..331da59a1eb5 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.c
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
@@ -1729,11 +1729,11 @@ static void gen6_bsd_submit_request(struct
drm_i915_gem_request *request)
I915_WRITE64_FW(GEN6_BSD_RNCID, 0x0);
/* Wait for the ring not to be idle, i.e. for it to wake up. */
- if (intel_wait_for_register_fw(dev_priv,
- GEN6_BSD_SLEEP_PSMI_CONTROL,
- GEN6_BSD_SLEEP_INDICATOR,
- 0,
- 50))
+ if (__intel_wait_for_register_fw(dev_priv,
+GEN6_BSD_SLEEP_PSMI_CONTROL,
+GEN6_BSD_SLEEP_INDICATOR,
+0,
+1000, 0, NULL))
DRM_ERROR("timed out waiting for the BSD ring to wake up\n");
/* Now that the ring is fully powered up, update the tail */
--
2.11.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Stop sleeping from inside gen6_bsd_submit_request()
submit_request() is called from an atomic context, it's not allowed to
sleep. We have to be careful in our parameters to
intel_uncore_wait_for_register() to limit ourselves to the atomic wait
loop and not incur the wrath of our warnings.
Fixes: 3fc7d86b3268 ("drm/i915: Drop const qualifiers from params in
wait_for_register()")
Signed-off-by: Chris Wilson
Cc: Michal Wajdeczko
Cc: Joonas Lahtinen
---
drivers/gpu/drm/i915/intel_ringbuffer.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c
b/drivers/gpu/drm/i915/intel_ringbuffer.c
index c98acc27279a..331da59a1eb5 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.c
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
@@ -1729,11 +1729,11 @@ static void gen6_bsd_submit_request(struct
drm_i915_gem_request *request)
I915_WRITE64_FW(GEN6_BSD_RNCID, 0x0);
/* Wait for the ring not to be idle, i.e. for it to wake up. */
- if (intel_wait_for_register_fw(dev_priv,
- GEN6_BSD_SLEEP_PSMI_CONTROL,
- GEN6_BSD_SLEEP_INDICATOR,
- 0,
- 50))
+ if (__intel_wait_for_register_fw(dev_priv,
+GEN6_BSD_SLEEP_PSMI_CONTROL,
+GEN6_BSD_SLEEP_INDICATOR,
+0,
+1000, 0, NULL))
DRM_ERROR("timed out waiting for the BSD ring to wake up\n");
/* Now that the ring is fully powered up, update the tail */
--
2.11.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2] drm/i915: Don't allow overuse of __intel_wait_for_register_fw()
On Mon, Apr 10, 2017 at 12:17:47PM +, Michal Wajdeczko wrote: > This function should not be called with long timeouts in atomic context. > Annotate it as might_sleep if timeout is longer than 10us. > > v2: fix comment (Michal) > > Signed-off-by: Michal Wajdeczko > Suggested-by: Chris Wilson > Cc: Chris Wilson Reviewed-by: Chris Wilson And pushed, thanks for the patch and for including the limits in the doc. -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] ACPI / bus: Introduce a list of ids for "always present" devices
On Sun, 09 Apr 2017 22:32:46 +0200,
Hans de Goede wrote:
>
> Hi,
>
> On 27-02-17 23:53, Takashi Iwai wrote:
> > On Mon, 27 Feb 2017 22:27:58 +0100,
> > Rafael J. Wysocki wrote:
> >>
> >> On Mon, Feb 27, 2017 at 3:40 PM, Takashi Iwai wrote:
>
>
>
> >>> Oh, this is interesting, please let me join to the party.
> >>>
> >>> We've hit a similar problem, but for other one: namely, it's INT0002
> >>> that is found on a few CHT devices. It's never bound properly by a
> >>> similar reason, where _STA is always zero on Linux:
> >>>
> >>> Method (_STA, 0, NotSerialized) // _STA: Status
> >>> {
> >>> If (SOCS <= 0x04)
> >>> {
> >>> Return (0x0F)
> >>> }
> >>> Else
> >>> {
> >>> Return (Zero)
> >>> }
> >>> }
> >>>
> >>> The device is supposed to be a "virtual GPIO" stuff, and the driver
> >>> hasn't been upstreamed from Intel. Due to the lack of this driver
> >>> (and it's binding), the machine gets spurious IRQ#9 after the PM
> >>> resume, and it locks up at the second time of PM.
> >>
> >> Well, the solution here seems to be to acquire the missing driver
> >> instead of adding quirks to the ACPI core.
> >
> > The driver is available (not upstreamed, though), but it's not bound
> > due to _STA above. That's why I'm interested in this thread.
>
> Takashi thanks for pointing me to the INT0002 device / driver to
> fix the spurious IRQ#9 after the PM resume issue. I was seeing this
> on the GPD-win too (when suspending with power-button + wakeup with
> spacebar). I've added a patch to add the INT0002 device to the
> always present device list + cleaned up the INT0002 driver. I plan
> to submit this upstream soon.
>
> If you want to test this on your device you need these patches:
>
> https://github.com/jwrdegoede/linux-sunxi/commit/a1a6e92f2665376ed72f575553238a93e88bb037
> https://github.com/jwrdegoede/linux-sunxi/commit/4946f68f8eaa300f42289bf767722d78cf7fa9e2
> https://github.com/jwrdegoede/linux-sunxi/commit/32640c816dd60d17f003ae8306863da01c215afb
> https://github.com/jwrdegoede/linux-sunxi/commit/abb6a9d69690bb2a1a00b184b06cdae43d6ad001
Thanks Hans, these look promising!
One remaining concern is that INT0002 seems serving for other purpose,
too, in drivers/platform/x86/intel_menlow.c for the thermal
management. I wonder whether we can enable INT0002 unconditionally.
Takashi
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2] drm/i915: Use wait_for_register in lpt_reset_fdi_mphy()
On Mon, Apr 10, 2017 at 04:34:30PM +0300, Ville Syrjälä wrote: > On Mon, Apr 10, 2017 at 01:56:31PM +0100, Chris Wilson wrote: > > On Mon, Apr 10, 2017 at 12:41:30PM +0100, Chris Wilson wrote: > > > On Mon, Apr 10, 2017 at 10:22:00AM +, Michal Wajdeczko wrote: > > > > There is no need to use macros as we can use generic function. > > > > And we can save ~2000 bytes in driver footprint. > > > > > > > > v2: drop ret var, add 10ms fallback (Chris) > > > > > > > > Signed-off-by: Michal Wajdeczko > > > > Cc: Paulo Zanoni > > > > Cc: Chris Wilson > > > Reviewed-by: Chris Wilson > > > > Hmm, forgot the convesion from I915_READ to I915_READ_FW. That should be > > safe here as this gen doesn't have the concurrent cacheline issue, iirc? > > Isn't HSW exactly the platform where it happens very easily? I thought lpt was later, or rather I just assume that any codename I don't recognise is postmodern. -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2] drm/i915: Use wait_for_register in lpt_reset_fdi_mphy()
On Mon, Apr 10, 2017 at 01:56:31PM +0100, Chris Wilson wrote: > On Mon, Apr 10, 2017 at 12:41:30PM +0100, Chris Wilson wrote: > > On Mon, Apr 10, 2017 at 10:22:00AM +, Michal Wajdeczko wrote: > > > There is no need to use macros as we can use generic function. > > > And we can save ~2000 bytes in driver footprint. > > > > > > v2: drop ret var, add 10ms fallback (Chris) > > > > > > Signed-off-by: Michal Wajdeczko > > > Cc: Paulo Zanoni > > > Cc: Chris Wilson > > Reviewed-by: Chris Wilson > > Hmm, forgot the convesion from I915_READ to I915_READ_FW. That should be > safe here as this gen doesn't have the concurrent cacheline issue, iirc? Isn't HSW exactly the platform where it happens very easily? -- Ville Syrjälä Intel OTC ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Drop const qualifiers from params in wait_for_register()
On Mon, Apr 10, 2017 at 10:00:30AM -, Patchwork wrote: > == Series Details == > > Series: drm/i915: Drop const qualifiers from params in wait_for_register() > URL : https://patchwork.freedesktop.org/series/22763/ > State : success > > == Summary == > > Series 22763v1 drm/i915: Drop const qualifiers from params in > wait_for_register() > https://patchwork.freedesktop.org/api/1.0/series/22763/revisions/1/mbox/ > > Test gem_exec_suspend: > Subgroup basic-s4-devices: > pass -> DMESG-WARN (fi-kbl-7560u) fdo#100125 > Test kms_pipe_crc_basic: > Subgroup suspend-read-crc-pipe-a: > pass -> FAIL (fi-skl-6700k) fdo#100367 > > fdo#100125 https://bugs.freedesktop.org/show_bug.cgi?id=100125 > fdo#100367 https://bugs.freedesktop.org/show_bug.cgi?id=100367 Pushed, thanks for the patch. -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Use wait_for_register in hsw_disable_lcpll()
== Series Details == Series: drm/i915: Use wait_for_register in hsw_disable_lcpll() URL : https://patchwork.freedesktop.org/series/22776/ State : success == Summary == Series 22776v1 drm/i915: Use wait_for_register in hsw_disable_lcpll() https://patchwork.freedesktop.org/api/1.0/series/22776/revisions/1/mbox/ fi-bdw-5557u total:278 pass:267 dwarn:0 dfail:0 fail:0 skip:11 time:429s fi-bdw-gvtdvmtotal:278 pass:256 dwarn:8 dfail:0 fail:0 skip:14 time:430s fi-bsw-n3050 total:278 pass:242 dwarn:0 dfail:0 fail:0 skip:36 time:573s fi-bxt-j4205 total:278 pass:259 dwarn:0 dfail:0 fail:0 skip:19 time:505s fi-bxt-t5700 total:278 pass:258 dwarn:0 dfail:0 fail:0 skip:20 time:550s fi-byt-j1900 total:278 pass:254 dwarn:0 dfail:0 fail:0 skip:24 time:479s fi-byt-n2820 total:278 pass:250 dwarn:0 dfail:0 fail:0 skip:28 time:482s fi-hsw-4770 total:278 pass:262 dwarn:0 dfail:0 fail:0 skip:16 time:416s fi-hsw-4770r total:278 pass:262 dwarn:0 dfail:0 fail:0 skip:16 time:410s fi-ilk-650 total:278 pass:228 dwarn:0 dfail:0 fail:0 skip:50 time:425s fi-ivb-3520m total:278 pass:260 dwarn:0 dfail:0 fail:0 skip:18 time:495s fi-ivb-3770 total:278 pass:260 dwarn:0 dfail:0 fail:0 skip:18 time:471s fi-kbl-7500u total:278 pass:260 dwarn:0 dfail:0 fail:0 skip:18 time:449s fi-kbl-7560u total:278 pass:268 dwarn:0 dfail:0 fail:0 skip:10 time:567s fi-skl-6260u total:278 pass:268 dwarn:0 dfail:0 fail:0 skip:10 time:451s fi-skl-6700hqtotal:278 pass:261 dwarn:0 dfail:0 fail:0 skip:17 time:570s fi-skl-6700k total:278 pass:256 dwarn:4 dfail:0 fail:0 skip:18 time:457s fi-skl-6770hqtotal:278 pass:268 dwarn:0 dfail:0 fail:0 skip:10 time:495s fi-skl-gvtdvmtotal:278 pass:265 dwarn:0 dfail:0 fail:0 skip:13 time:432s fi-snb-2520m total:278 pass:250 dwarn:0 dfail:0 fail:0 skip:28 time:530s fi-snb-2600 total:278 pass:248 dwarn:0 dfail:0 fail:1 skip:29 time:405s 02f6d3e01f3e1b6b91efeaceabd24e36e0540b49 drm-tip: 2017y-04m-10d-11h-06m-04s UTC integration manifest eb658bc drm/i915: Use wait_for_register in hsw_disable_lcpll() == Logs == For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_4461/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2] drm/i915: Use wait_for_register in lpt_reset_fdi_mphy()
On Mon, Apr 10, 2017 at 12:41:30PM +0100, Chris Wilson wrote: > On Mon, Apr 10, 2017 at 10:22:00AM +, Michal Wajdeczko wrote: > > There is no need to use macros as we can use generic function. > > And we can save ~2000 bytes in driver footprint. > > > > v2: drop ret var, add 10ms fallback (Chris) > > > > Signed-off-by: Michal Wajdeczko > > Cc: Paulo Zanoni > > Cc: Chris Wilson > Reviewed-by: Chris Wilson Hmm, forgot the convesion from I915_READ to I915_READ_FW. That should be safe here as this gen doesn't have the concurrent cacheline issue, iirc? -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Use wait_for_register in hsw_disable_lcpll()
On Mon, Apr 10, 2017 at 12:30:43PM +, Michal Wajdeczko wrote: > There is no need to use macro as we can use generic function. > And as side effect we can lower driver footprint. > > Signed-off-by: Michal Wajdeczko > Cc: Chris Wilson > Cc: Paulo Zanoni > --- > drivers/gpu/drm/i915/intel_display.c | 8 > 1 file changed, 4 insertions(+), 4 deletions(-) > > diff --git a/drivers/gpu/drm/i915/intel_display.c > b/drivers/gpu/drm/i915/intel_display.c > index eeb828c..2fce1a7 100644 > --- a/drivers/gpu/drm/i915/intel_display.c > +++ b/drivers/gpu/drm/i915/intel_display.c > @@ -8693,11 +8693,11 @@ static void hsw_disable_lcpll(struct drm_i915_private > *dev_priv, > val |= LCPLL_CD_SOURCE_FCLK; > I915_WRITE(LCPLL_CTL, val); > > - if (wait_for_us(I915_READ(LCPLL_CTL) & > - LCPLL_CD_SOURCE_FCLK_DONE, 1)) > + if (__intel_wait_for_register_fw(dev_priv, LCPLL_CTL, > + LCPLL_CD_SOURCE_FCLK_DONE, > + LCPLL_CD_SOURCE_FCLK_DONE, > + 1, 0, &val)) This changes it from a I915_READ() to I915_READ_FW. It should be safe to drop the forcewakes, but the jury is out over the spinlock. Can anyone else concurrently access the same cacheline? -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BAT: warning for drm/i915: Don't allow overuse of __intel_wait_for_register_fw() (rev2)
== Series Details == Series: drm/i915: Don't allow overuse of __intel_wait_for_register_fw() (rev2) URL : https://patchwork.freedesktop.org/series/22774/ State : warning == Summary == Series 22774v2 drm/i915: Don't allow overuse of __intel_wait_for_register_fw() https://patchwork.freedesktop.org/api/1.0/series/22774/revisions/2/mbox/ Test core_auth: Subgroup basic-auth: pass -> DMESG-WARN (fi-snb-2520m) pass -> DMESG-WARN (fi-snb-2600) Test drv_getparams_basic: Subgroup basic-subslice-total: pass -> DMESG-WARN (fi-snb-2520m) Test drv_module_reload: Subgroup basic-no-display: pass -> DMESG-WARN (fi-snb-2520m) pass -> DMESG-WARN (fi-snb-2600) Subgroup basic-reload: pass -> DMESG-WARN (fi-snb-2520m) pass -> DMESG-WARN (fi-snb-2600) Subgroup basic-reload-final: pass -> DMESG-WARN (fi-snb-2520m) pass -> DMESG-WARN (fi-snb-2600) Test gem_basic: Subgroup create-close: pass -> DMESG-WARN (fi-snb-2520m) Test gem_busy: Subgroup basic-hang-default: pass -> DMESG-WARN (fi-snb-2520m) pass -> DMESG-WARN (fi-snb-2600) Test gem_close_race: Subgroup basic-threads: pass -> DMESG-WARN (fi-snb-2520m) pass -> DMESG-WARN (fi-snb-2600) Test gem_cs_tlb: Subgroup basic-default: pass -> DMESG-WARN (fi-snb-2520m) Test gem_ctx_basic: pass -> DMESG-WARN (fi-snb-2520m) pass -> DMESG-WARN (fi-snb-2600) Test gem_ctx_create: Subgroup basic-files: pass -> DMESG-WARN (fi-snb-2520m) fdo#100247 pass -> DMESG-WARN (fi-snb-2600) Test gem_ctx_param: Subgroup basic-default: pass -> DMESG-WARN (fi-snb-2520m) Test gem_ctx_switch: Subgroup basic-default: pass -> DMESG-WARN (fi-snb-2520m) pass -> DMESG-WARN (fi-snb-2600) Subgroup basic-default-heavy: pass -> DMESG-WARN (fi-snb-2520m) pass -> DMESG-WARN (fi-snb-2600) Test gem_exec_basic: Subgroup basic-render: pass -> DMESG-WARN (fi-snb-2520m) Subgroup gtt-bsd: pass -> DMESG-WARN (fi-snb-2520m) pass -> DMESG-WARN (fi-snb-2600) Subgroup gtt-default: pass -> DMESG-WARN (fi-snb-2520m) Subgroup readonly-blt: pass -> DMESG-WARN (fi-snb-2520m) Test gem_exec_create: Subgroup basic: pass -> DMESG-WARN (fi-snb-2520m) pass -> DMESG-WARN (fi-snb-2600) Test gem_exec_fence: Subgroup await-hang-default: pass -> DMESG-WARN (fi-snb-2520m) pass -> DMESG-WARN (fi-snb-2600) Subgroup basic-await-default: pass -> DMESG-WARN (fi-snb-2520m) pass -> DMESG-WARN (fi-snb-2600) Subgroup basic-busy-default: pass -> DMESG-WARN (fi-snb-2520m) Subgroup nb-await-default: pass -> DMESG-WARN (fi-snb-2520m) pass -> DMESG-WARN (fi-snb-2600) Test gem_exec_flush: Subgroup basic-batch-kernel-default-uc: pass -> DMESG-WARN (fi-snb-2520m) fail -> DMESG-WARN (fi-snb-2600) fdo#17 Subgroup basic-batch-kernel-default-wb: pass -> DMESG-WARN (fi-snb-2520m) pass -> DMESG-WARN (fi-snb-2600) Subgroup basic-uc-pro-default: pass -> DMESG-WARN (fi-snb-2520m) pass -> DMESG-WARN (fi-snb-2600) Subgroup basic-uc-prw-default: pass -> DMESG-WARN (fi-snb-2520m) pass -> DMESG-WARN (fi-snb-2600) Subgroup basic-uc-ro-default: pass -> DMESG-WARN (fi-snb-2520m) pass -> DMESG-WARN (fi-snb-2600) Subgroup basic-uc-rw-default: pass -> DMESG-WARN (fi-snb-2520m) pass -> DMESG-WARN (fi-snb-2600) Subgroup basic-uc-set-default: pass -> DMESG-WARN (fi-snb-2520m) pass -> DMESG-WARN (fi-snb-2600) Subgroup basic-wb-pro-default: WARNING: Long output truncated fi-bdw-gvtdvm failed to collect. IGT log at Patchwork_4460/fi-bdw-gvtdvm/igt.log 02f6d3e01f3e1b6b91efeaceabd24e36e0540b49 drm-tip: 2017y-04m-10d-11h-06m-04s UTC integration manifest 303fb68 drm/i915: Don't allow overuse of __intel_wait_for_register_fw() == Logs == For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_4460/ __
[Intel-gfx] [PATCH] drm/i915: Use wait_for_register in hsw_disable_lcpll()
There is no need to use macro as we can use generic function.
And as side effect we can lower driver footprint.
Signed-off-by: Michal Wajdeczko
Cc: Chris Wilson
Cc: Paulo Zanoni
---
drivers/gpu/drm/i915/intel_display.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index eeb828c..2fce1a7 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -8693,11 +8693,11 @@ static void hsw_disable_lcpll(struct drm_i915_private
*dev_priv,
val |= LCPLL_CD_SOURCE_FCLK;
I915_WRITE(LCPLL_CTL, val);
- if (wait_for_us(I915_READ(LCPLL_CTL) &
- LCPLL_CD_SOURCE_FCLK_DONE, 1))
+ if (__intel_wait_for_register_fw(dev_priv, LCPLL_CTL,
+LCPLL_CD_SOURCE_FCLK_DONE,
+LCPLL_CD_SOURCE_FCLK_DONE,
+1, 0, &val))
DRM_ERROR("Switching to FCLK failed\n");
-
- val = I915_READ(LCPLL_CTL);
}
val |= LCPLL_PLL_DISABLE;
--
2.7.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm: Fix get_property logic fumble
Op 10-04-17 om 13:54 schreef Daniel Vetter:
> Yet again I've proven that I can't negate conditions :(
>
> Fixes: eb8eb02ed850 ("drm: Drop modeset_lock_all from the getproperty ioctl")
> Cc: Maarten Lankhorst
> Cc: Daniel Vetter
> Cc: Jani Nikula
> Cc: Sean Paul
> Reported-by: Tvrtko Ursulin
> Cc: Tvrtko Ursulin
> Signed-off-by: Daniel Vetter
> ---
> drivers/gpu/drm/drm_property.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/drm_property.c b/drivers/gpu/drm/drm_property.c
> index 3feef0659940..3e88fa24eab3 100644
> --- a/drivers/gpu/drm/drm_property.c
> +++ b/drivers/gpu/drm/drm_property.c
> @@ -476,7 +476,7 @@ int drm_mode_getproperty_ioctl(struct drm_device *dev,
> drm_property_type_is(property, DRM_MODE_PROP_BITMASK)) {
> list_for_each_entry(prop_enum, &property->enum_list, head) {
> enum_count++;
> - if (out_resp->count_enum_blobs <= enum_count)
> + if (out_resp->count_enum_blobs < enum_count)
> continue;
>
> if (copy_to_user(&enum_ptr[copied].value,
Neither can I, glanced over it while looking why the bisect pointed at this
commit.
Reviewed-by: Maarten Lankhorst
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH i-g-t v2] tests/kms_concurrent: Concurrent and interruptible subtests for atomic
Op 10-04-17 om 14:11 schreef Mika Kahola:
> On Wed, 2017-03-29 at 11:53 +0200, Maarten Lankhorst wrote:
>> Op 15-03-17 om 09:43 schreef Mika Kahola:
>>> This test case introduces concurrently running test cases for
>>> atomic
>>> modesetting.
>>>
>>> The first test or thread draws blue backround with black holes on
>>> it.
>>> These holes are covered by rectangular, blue planes that are placed
>>> randomly like in test case 'kms_plane_multiple'.
>>>
>>> The second thread changes resolution from higher to lower one and
>>> back.
>>> The delay between resolution changes is randomly selected between
>>> 20 and
>>> 50 milliseconds.
>>>
>>> The test runs by default 32 iterations to increase the coverage.
>>>
>>> v2: use igt_fork instead of pthreads to create concurrent test runs
>>> (Maarten)
>>>
>>> Signed-off-by: Mika Kahola
>>> ---
>>> tests/Makefile.sources | 1 +
>>> tests/kms_concurrent.c | 630
>>> +
>>> 2 files changed, 631 insertions(+)
>>> create mode 100644 tests/kms_concurrent.c
>>>
>>>
>>> +static int
>>> +display_commit_mode(data_t *data, igt_crc_t *crc)
>>> +{
>>> + char buf[256];
>>> + struct drm_event *e = (void *)buf;
>>> + int n, ret;
>>> + int flags = DRM_MODE_PAGE_FLIP_EVENT |
>>> DRM_MODE_ATOMIC_ALLOW_MODESET | DRM_MODE_ATOMIC_NONBLOCK;
>>> +
>>> + ret = igt_display_try_commit_atomic(&data->display,
>>> + flags,
>>> + NULL);
>>> + igt_skip_on(ret != 0);
>>> +
>>> + igt_set_timeout(1, "Stuck on page flip");
>>> + ret = read(data->display.drm_fd, buf, sizeof(buf));
>>> + igt_assert(ret >= 0);
>>> +
>>> + igt_assert_eq(e->type, DRM_EVENT_FLIP_COMPLETE);
>>> + igt_reset_timeout();
>>> +
>>> + return n;
>>> +}
>>> +
>>> +static void
>>> +test_grab_crc(data_t *data, color_t *color, igt_crc_t *crc /* out
>>> */)
>>> +{
>>> + drmModeModeInfo *mode;
>>> + igt_plane_t *primary;
>>> + int ret;
>>> +
>>> + igt_output_set_pipe(data->output, data->pipe);
>>> +
>>> + primary = igt_output_get_plane_type(data->output,
>>> DRM_PLANE_TYPE_PRIMARY);
>>> + data->plane[primary->index] = primary;
>>> +
>>> + mode = igt_output_get_mode(data->output);
>>> +
>>> + igt_create_color_fb(data->drm_fd, mode->hdisplay, mode-
vdisplay,
>>> + DRM_FORMAT_XRGB,
>>> + LOCAL_I915_FORMAT_MOD_X_TILED,
>>> + color->red, color->green, color->blue,
>>> + &data->fb[primary->index]);
>>> +
>>> + igt_plane_set_fb(data->plane[primary->index], &data-
fb[primary->index]);
>>> +
>>> + ret = igt_display_try_commit2(&data->display,
>>> COMMIT_ATOMIC);
>>> + igt_skip_on(ret != 0);
>>> +}
>>> +
>>> +/*
>>> + * Multiple plane position test.
>>> + * - We start by grabbing a reference CRC of a full blue fb
>>> being scanned
>>> + * out on the primary plane
>>> + * - Then we scannout number of planes:
>>> + * * the primary plane uses a blue fb with a black rectangle
>>> hole
>>> + * * planes, on top of the primary plane, with a blue fb that
>>> is set-up
>>> + *to cover the black rectangles of the primary plane fb
>>> + * The resulting CRC should be identical to the reference CRC
>>> + */
>>> +
>>> +static void
>>> +create_fb_for_mode_position(data_t *data, drmModeModeInfo *mode,
>>> + color_t *color, int *rect_x, int
>>> *rect_y,
>>> + int *rect_w, int *rect_h, uint64_t
>>> tiling,
>>> + int max_planes)
>>> +{
>>> + unsigned int fb_id;
>>> + cairo_t *cr;
>>> + igt_plane_t *primary;
>>> +
>>> + primary = igt_output_get_plane_type(data->output,
>>> DRM_PLANE_TYPE_PRIMARY);
>>> +
>>> + fb_id = igt_create_fb(data->drm_fd,
>>> + mode->hdisplay, mode->vdisplay,
>>> + DRM_FORMAT_XRGB,
>>> + tiling,
>>> + &data->fb[primary->index]);
>>> + igt_assert(fb_id);
>>> +
>>> + cr = igt_get_cairo_ctx(data->drm_fd, &data->fb[primary-
index]);
>>> + igt_paint_color(cr, rect_x[0], rect_y[0],
>>> + mode->hdisplay, mode->vdisplay,
>>> + color->red, color->green, color->blue);
>>> +
>>> + for (int i = 0; i < max_planes; i++) {
>>> + if (data->plane[i]->type ==
>>> DRM_PLANE_TYPE_PRIMARY)
>>> + continue;
>>> + igt_paint_color(cr, rect_x[i], rect_y[i],
>>> + rect_w[i], rect_h[i], 0.0, 0.0,
>>> 0.0);
>>> + }
>>> +
>>> + igt_assert(cairo_status(cr) == 0);
>>> + cairo_destroy(cr);
>>> +}
>>> +
>>> +static void
>>> +prepare_planes(data_t *data, color_t *color, int max_planes)
>>> +{
>>> + drmModeModeInfo *mode;
>>> + igt_pipe_t *pipe;
>>> + igt_plane_t *primary;
>>> + int *x;
>>> + int *y;
>>> + int *size;
>>> + int i;
>>> +
>>> + igt_output_set_pipe(data->output, da
Re: [Intel-gfx] [PATCH] drm: Fix get_property logic fumble
On Mon, Apr 10, 2017 at 01:54:45PM +0200, Daniel Vetter wrote:
> Yet again I've proven that I can't negate conditions :(
>
> Fixes: eb8eb02ed850 ("drm: Drop modeset_lock_all from the getproperty ioctl")
You also get to write the igt/kms_getproperty, starting with a
memset(prop_values, 0xc5, foo);
drmIoctl(GETPROPERTY);
igt_assert(!memchr(prop_values, 0xc5, bar));
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BAT: warning for drm/i915: Don't allow overuse of __intel_wait_for_register_fw()
== Series Details == Series: drm/i915: Don't allow overuse of __intel_wait_for_register_fw() URL : https://patchwork.freedesktop.org/series/22774/ State : warning == Summary == Series 22774v1 drm/i915: Don't allow overuse of __intel_wait_for_register_fw() https://patchwork.freedesktop.org/api/1.0/series/22774/revisions/1/mbox/ Test core_auth: Subgroup basic-auth: pass -> DMESG-WARN (fi-snb-2600) pass -> DMESG-WARN (fi-snb-2520m) Test drv_getparams_basic: Subgroup basic-subslice-total: pass -> DMESG-WARN (fi-snb-2520m) Test drv_module_reload: Subgroup basic-no-display: pass -> DMESG-WARN (fi-snb-2600) pass -> DMESG-WARN (fi-snb-2520m) Subgroup basic-reload: pass -> DMESG-WARN (fi-snb-2600) pass -> DMESG-WARN (fi-snb-2520m) Subgroup basic-reload-final: pass -> DMESG-WARN (fi-snb-2600) pass -> DMESG-WARN (fi-snb-2520m) Test gem_basic: Subgroup create-close: pass -> DMESG-WARN (fi-snb-2520m) Test gem_busy: Subgroup basic-hang-default: pass -> DMESG-WARN (fi-snb-2600) pass -> DMESG-WARN (fi-snb-2520m) Test gem_close_race: Subgroup basic-threads: pass -> DMESG-WARN (fi-snb-2600) pass -> DMESG-WARN (fi-snb-2520m) Test gem_cs_tlb: Subgroup basic-default: pass -> DMESG-WARN (fi-snb-2520m) Test gem_ctx_basic: pass -> DMESG-WARN (fi-snb-2600) pass -> DMESG-WARN (fi-snb-2520m) Test gem_ctx_create: Subgroup basic-files: pass -> DMESG-WARN (fi-snb-2600) pass -> DMESG-WARN (fi-snb-2520m) fdo#100247 Test gem_ctx_param: Subgroup basic-default: pass -> DMESG-WARN (fi-snb-2520m) Test gem_ctx_switch: Subgroup basic-default: pass -> DMESG-WARN (fi-snb-2600) pass -> DMESG-WARN (fi-snb-2520m) Subgroup basic-default-heavy: pass -> DMESG-WARN (fi-snb-2600) pass -> DMESG-WARN (fi-snb-2520m) Test gem_exec_basic: Subgroup basic-render: pass -> DMESG-WARN (fi-snb-2520m) Subgroup gtt-bsd: pass -> DMESG-WARN (fi-snb-2600) pass -> DMESG-WARN (fi-snb-2520m) Subgroup gtt-default: pass -> DMESG-WARN (fi-snb-2520m) Subgroup readonly-blt: pass -> DMESG-WARN (fi-snb-2520m) Test gem_exec_create: Subgroup basic: pass -> DMESG-WARN (fi-snb-2600) pass -> DMESG-WARN (fi-snb-2520m) Test gem_exec_fence: Subgroup await-hang-default: pass -> DMESG-WARN (fi-snb-2600) pass -> DMESG-WARN (fi-snb-2520m) Subgroup basic-await-default: pass -> DMESG-WARN (fi-snb-2600) pass -> DMESG-WARN (fi-snb-2520m) Subgroup basic-busy-default: pass -> DMESG-WARN (fi-snb-2520m) Subgroup nb-await-default: pass -> DMESG-WARN (fi-snb-2600) pass -> DMESG-WARN (fi-snb-2520m) Test gem_exec_flush: Subgroup basic-batch-kernel-default-uc: fail -> DMESG-WARN (fi-snb-2600) fdo#17 pass -> DMESG-WARN (fi-snb-2520m) Subgroup basic-batch-kernel-default-wb: pass -> DMESG-WARN (fi-snb-2600) pass -> DMESG-WARN (fi-snb-2520m) Subgroup basic-uc-pro-default: pass -> DMESG-WARN (fi-snb-2600) pass -> DMESG-WARN (fi-snb-2520m) Subgroup basic-uc-prw-default: pass -> DMESG-WARN (fi-snb-2600) pass -> DMESG-WARN (fi-snb-2520m) Subgroup basic-uc-ro-default: pass -> DMESG-WARN (fi-snb-2600) pass -> DMESG-WARN (fi-snb-2520m) Subgroup basic-uc-rw-default: pass -> DMESG-WARN (fi-snb-2600) pass -> DMESG-WARN (fi-snb-2520m) Subgroup basic-uc-set-default: pass -> DMESG-WARN (fi-snb-2600) pass -> DMESG-WARN (fi-snb-2520m) Subgroup basic-wb-pro-default: WARNING: Long output truncated fi-byt-j1900 failed to collect. IGT log at Patchwork_4459/fi-byt-j1900/igt.log 02f6d3e01f3e1b6b91efeaceabd24e36e0540b49 drm-tip: 2017y-04m-10d-11h-06m-04s UTC integration manifest 5d99864 drm/i915: Don't allow overuse of __intel_wait_for_register_fw() == Logs == For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_4459/ ___
Re: [Intel-gfx] [PATCH] drm/i915: Don't allow overuse of __intel_wait_for_register_fw()
On Mon, Apr 10, 2017 at 12:14:02PM +, Michal Wajdeczko wrote: > This function should not be called with long timeouts in atomic context. > Annotate it as might_sleep if timeout is longer than 10us. > > Signed-off-by: Michal Wajdeczko > Suggested-by: Chris Wilson > Cc: Chris Wilson > --- Please ignore. Review v2 instead. -Michal ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2] drm/i915: Don't allow overuse of __intel_wait_for_register_fw()
This function should not be called with long timeouts in atomic context. Annotate it as might_sleep if timeout is longer than 10us. v2: fix comment (Michal) Signed-off-by: Michal Wajdeczko Suggested-by: Chris Wilson Cc: Chris Wilson --- drivers/gpu/drm/i915/intel_uncore.c | 5 + 1 file changed, 5 insertions(+) diff --git a/drivers/gpu/drm/i915/intel_uncore.c b/drivers/gpu/drm/i915/intel_uncore.c index 1deb1a4..eb38392 100644 --- a/drivers/gpu/drm/i915/intel_uncore.c +++ b/drivers/gpu/drm/i915/intel_uncore.c @@ -1600,6 +1600,8 @@ static int gen6_reset_engines(struct drm_i915_private *dev_priv, * (I915_READ_FW(reg) & mask) == value * * Otherwise, the wait will timeout after @slow_timeout_ms milliseconds. + * For atomic context @slow_timeout_ms must be zero and @fast_timeout_us + * must be not larger than 10 microseconds. * * Note that this routine assumes the caller holds forcewake asserted, it is * not suitable for very long waits. See intel_wait_for_register() if you @@ -1620,6 +1622,9 @@ int __intel_wait_for_register_fw(struct drm_i915_private *dev_priv, #define done (((reg_value = I915_READ_FW(reg)) & mask) == value) int ret; + /* Catch any overuse of this function */ + might_sleep_if(fast_timeout_us > 10 || slow_timeout_ms); + if (fast_timeout_us > 10) ret = _wait_for(done, fast_timeout_us, 10); else -- 2.7.4 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 08/13] drm/i915: Eliminate lots of iterations over the execobjects array
On Tue, Apr 04, 2017 at 05:57:34PM +0300, Joonas Lahtinen wrote:
> On ke, 2017-03-29 at 16:56 +0100, Chris Wilson wrote:
> > The major scaling bottleneck in execbuffer is the processing of the
> > execobjects. Creating an auxiliary list is inefficient when compared to
> > using the execobject array we already have allocated.
> >
> > Reservation is then split into phases. As we lookup up the VMA, we
> > try and bind it back into active location. Only if that fails, do we add
> > it to the unbound list for phase 2. In phase 2, we try and add all those
> > objects that could not fit into their previous location, with fallback
> > to retrying all objects and evicting the VM in case of severe
> > fragmentation. (This is the same as before, except that phase 1 is now
> > done inline with looking up the VMA to avoid an iteration over the
> > execobject array. In the ideal case, we eliminate the separate reservation
> > phase). During the reservation phase, we only evict from the VM between
> > passes (rather than currently as we try to fit every new VMA). In
> > testing with Unreal Engine's Atlantis demo which stresses the eviction
> > logic on gen7 class hardware, this speed up the framerate by a factor of
> > 2.
> >
> > The second loop amalgamation is between move_to_gpu and move_to_active.
> > As we always submit the request, even if incomplete, we can use the
> > current request to track active VMA as we perform the flushes and
> > synchronisation required.
> >
> > The next big advancement is to avoid copying back to the user any
> > execobjects and relocations that are not changed.
> >
> > v2: Add a Theory of Operation spiel.
> > v3: Fall back to slow relocations in preparation for flushing userptrs.
> >
> > Signed-off-by: Chris Wilson
>
>
> > + if ((entry->flags & EXEC_OBJECT_SUPPORTS_48B_ADDRESS) == 0 &&
> > + (vma->node.start + vma->node.size - 1) >> 32)
>
> upper_32_bits for clarity?
Not sure. I'd rather keep it as is for the time being and think of a
macro for this and the one in i915_gem_gtt.c
> > +static void
> > +eb_pin_vma(struct i915_execbuffer *eb,
> > + struct drm_i915_gem_exec_object2 *entry,
> > + struct i915_vma *vma)
> > +{
> > + u64 flags;
> > +
> > + flags = vma->node.start;
>
> I'd be more comfortable if some mask was applied here.
>
> Or at least GEM_BUG_ON(flags & BAD_FLAGS);
BUILD_BUG_ON() already guards against the bits mixing.
> > + if (entry->flags & EXEC_OBJECT_NEEDS_FENCE) {
> > + ret = i915_vma_get_fence(vma);
> > + if (ret)
> > + return ret;
> > +
> > + if (i915_vma_pin_fence(vma))
> > + entry->flags |= __EXEC_OBJECT_HAS_FENCE;
> > + }
>
> Smells like duplicate code with eb_vma_pin.
Close, but the order is intentionally different. :|
Earlier we don't take the error immediately and only fail if the result
doesn't match our requirements. This time, where we are now forced to
bind the vma, we do want to double check each step and unwind.
> > + return __get_user(c, end - 1);
>
> What's the point in this final check?
There's no guarrantee that the loop triggered a read on each page, so we
have to do a second read on the last byte of the address range to be
sure.
> > +static void eb_export_fence(struct drm_i915_gem_object *obj,
> > + struct drm_i915_gem_request *req,
> > + unsigned int flags)
> > +{
> > + struct reservation_object *resv = obj->resv;
> > +
> > + /* Ignore errors from failing to allocate the new fence, we can't
> > + * handle an error right now. Worst case should be missed
> > + * synchronisation leading to rendering corruption.
> > + */
>
> Worthy DRM_DEBUG?
I think the oomkiller emanating from this spot will be instructive
enough. At some point in the future, when we start using ww_mutex for
serializing the objects between execbuf (rather than struct_mutex), we
should be able to do the reservation early and so catch an error before
we commit.
> > @@ -1155,10 +1524,33 @@ eb_move_to_gpu(struct i915_execbuffer *eb)
> > }
> >
> > ret = i915_gem_request_await_object
> > - (eb->request, obj, vma->exec_entry->flags &
> > EXEC_OBJECT_WRITE);
> > + (eb->request, obj, entry->flags & EXEC_OBJECT_WRITE);
> > if (ret)
> > return ret;
> > +
> > +skip_flushes:
> > + obj->base.write_domain = 0;
> > + if (entry->flags & EXEC_OBJECT_WRITE) {
> > + obj->base.read_domains = 0;
> > + if (!obj->cache_dirty && gpu_write_needs_clflush(obj))
> > + obj->cache_dirty = true;
> > + intel_fb_obj_invalidate(obj, ORIGIN_CS);
> > + }
> > + obj->base.read_domains |= I915_GEM_GPU_DOMAINS;
> > +
> > + i915_vma_move_to_active(vma, eb->request, entry->flags);
> > + __eb_unreserve_vma(vma, entry);
> > +
[Intel-gfx] ✓ Fi.CI.BAT: success for drm: Fix get_property logic fumble
== Series Details == Series: drm: Fix get_property logic fumble URL : https://patchwork.freedesktop.org/series/22772/ State : success == Summary == Series 22772v1 drm: Fix get_property logic fumble https://patchwork.freedesktop.org/api/1.0/series/22772/revisions/1/mbox/ Test gem_exec_flush: Subgroup basic-batch-kernel-default-uc: fail -> PASS (fi-snb-2600) fdo#17 Test gem_exec_suspend: Subgroup basic-s4-devices: pass -> DMESG-WARN (fi-bxt-t5700) fdo#100125 pass -> DMESG-WARN (fi-kbl-7560u) fdo#100125 fdo#17 https://bugs.freedesktop.org/show_bug.cgi?id=17 fdo#100125 https://bugs.freedesktop.org/show_bug.cgi?id=100125 fi-bdw-5557u total:278 pass:267 dwarn:0 dfail:0 fail:0 skip:11 time:435s fi-bdw-gvtdvmtotal:278 pass:256 dwarn:8 dfail:0 fail:0 skip:14 time:428s fi-bsw-n3050 total:278 pass:242 dwarn:0 dfail:0 fail:0 skip:36 time:577s fi-bxt-j4205 total:278 pass:259 dwarn:0 dfail:0 fail:0 skip:19 time:508s fi-bxt-t5700 total:278 pass:257 dwarn:1 dfail:0 fail:0 skip:20 time:551s fi-byt-j1900 total:278 pass:254 dwarn:0 dfail:0 fail:0 skip:24 time:480s fi-byt-n2820 total:278 pass:250 dwarn:0 dfail:0 fail:0 skip:28 time:475s fi-hsw-4770 total:278 pass:262 dwarn:0 dfail:0 fail:0 skip:16 time:418s fi-hsw-4770r total:278 pass:262 dwarn:0 dfail:0 fail:0 skip:16 time:402s fi-ilk-650 total:278 pass:228 dwarn:0 dfail:0 fail:0 skip:50 time:424s fi-ivb-3520m total:278 pass:260 dwarn:0 dfail:0 fail:0 skip:18 time:491s fi-ivb-3770 total:278 pass:260 dwarn:0 dfail:0 fail:0 skip:18 time:467s fi-kbl-7500u total:278 pass:260 dwarn:0 dfail:0 fail:0 skip:18 time:452s fi-kbl-7560u total:278 pass:267 dwarn:1 dfail:0 fail:0 skip:10 time:570s fi-skl-6260u total:278 pass:268 dwarn:0 dfail:0 fail:0 skip:10 time:452s fi-skl-6700hqtotal:278 pass:261 dwarn:0 dfail:0 fail:0 skip:17 time:571s fi-skl-6700k total:278 pass:256 dwarn:4 dfail:0 fail:0 skip:18 time:474s fi-skl-6770hqtotal:278 pass:268 dwarn:0 dfail:0 fail:0 skip:10 time:496s fi-skl-gvtdvmtotal:278 pass:265 dwarn:0 dfail:0 fail:0 skip:13 time:433s fi-snb-2520m total:278 pass:250 dwarn:0 dfail:0 fail:0 skip:28 time:530s fi-snb-2600 total:278 pass:249 dwarn:0 dfail:0 fail:0 skip:29 time:398s 02f6d3e01f3e1b6b91efeaceabd24e36e0540b49 drm-tip: 2017y-04m-10d-11h-06m-04s UTC integration manifest a7d1fee drm: Fix get_property logic fumble == Logs == For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_4458/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Don't allow overuse of __intel_wait_for_register_fw()
This function should not be called with long timeouts in atomic context. Annotate it as might_sleep if timeout is longer than 10us. Signed-off-by: Michal Wajdeczko Suggested-by: Chris Wilson Cc: Chris Wilson --- drivers/gpu/drm/i915/intel_uncore.c | 6 ++ 1 file changed, 6 insertions(+) diff --git a/drivers/gpu/drm/i915/intel_uncore.c b/drivers/gpu/drm/i915/intel_uncore.c index 1deb1a4..9cc9e6f 100644 --- a/drivers/gpu/drm/i915/intel_uncore.c +++ b/drivers/gpu/drm/i915/intel_uncore.c @@ -1606,6 +1606,9 @@ static int gen6_reset_engines(struct drm_i915_private *dev_priv, * wish to wait without holding forcewake for the duration (i.e. you expect * the wait to be slow). * + * Only @fast_timeout_us < 10us are allowed in atomic context. + * Note that @fast_timeout_us >= 5us are not allowed at all. + * * Returns 0 if the register matches the desired condition, or -ETIMEOUT. */ int __intel_wait_for_register_fw(struct drm_i915_private *dev_priv, @@ -1620,6 +1623,9 @@ int __intel_wait_for_register_fw(struct drm_i915_private *dev_priv, #define done (((reg_value = I915_READ_FW(reg)) & mask) == value) int ret; + /* Catch any overuse of this function */ + might_sleep_if(fast_timeout_us > 10 || slow_timeout_ms); + if (fast_timeout_us > 10) ret = _wait_for(done, fast_timeout_us, 10); else -- 2.7.4 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH i-g-t v2] tests/kms_concurrent: Concurrent and interruptible subtests for atomic
On Wed, 2017-03-29 at 11:53 +0200, Maarten Lankhorst wrote:
> Op 15-03-17 om 09:43 schreef Mika Kahola:
> >
> > This test case introduces concurrently running test cases for
> > atomic
> > modesetting.
> >
> > The first test or thread draws blue backround with black holes on
> > it.
> > These holes are covered by rectangular, blue planes that are placed
> > randomly like in test case 'kms_plane_multiple'.
> >
> > The second thread changes resolution from higher to lower one and
> > back.
> > The delay between resolution changes is randomly selected between
> > 20 and
> > 50 milliseconds.
> >
> > The test runs by default 32 iterations to increase the coverage.
> >
> > v2: use igt_fork instead of pthreads to create concurrent test runs
> > (Maarten)
> >
> > Signed-off-by: Mika Kahola
> > ---
> > tests/Makefile.sources | 1 +
> > tests/kms_concurrent.c | 630
> > +
> > 2 files changed, 631 insertions(+)
> > create mode 100644 tests/kms_concurrent.c
> >
> >
> > +static int
> > +display_commit_mode(data_t *data, igt_crc_t *crc)
> > +{
> > + char buf[256];
> > + struct drm_event *e = (void *)buf;
> > + int n, ret;
> > + int flags = DRM_MODE_PAGE_FLIP_EVENT |
> > DRM_MODE_ATOMIC_ALLOW_MODESET | DRM_MODE_ATOMIC_NONBLOCK;
> > +
> > + ret = igt_display_try_commit_atomic(&data->display,
> > + flags,
> > + NULL);
> > + igt_skip_on(ret != 0);
> > +
> > + igt_set_timeout(1, "Stuck on page flip");
> > + ret = read(data->display.drm_fd, buf, sizeof(buf));
> > + igt_assert(ret >= 0);
> > +
> > + igt_assert_eq(e->type, DRM_EVENT_FLIP_COMPLETE);
> > + igt_reset_timeout();
> > +
> > + return n;
> > +}
> > +
> > +static void
> > +test_grab_crc(data_t *data, color_t *color, igt_crc_t *crc /* out
> > */)
> > +{
> > + drmModeModeInfo *mode;
> > + igt_plane_t *primary;
> > + int ret;
> > +
> > + igt_output_set_pipe(data->output, data->pipe);
> > +
> > + primary = igt_output_get_plane_type(data->output,
> > DRM_PLANE_TYPE_PRIMARY);
> > + data->plane[primary->index] = primary;
> > +
> > + mode = igt_output_get_mode(data->output);
> > +
> > + igt_create_color_fb(data->drm_fd, mode->hdisplay, mode-
> > >vdisplay,
> > + DRM_FORMAT_XRGB,
> > + LOCAL_I915_FORMAT_MOD_X_TILED,
> > + color->red, color->green, color->blue,
> > + &data->fb[primary->index]);
> > +
> > + igt_plane_set_fb(data->plane[primary->index], &data-
> > >fb[primary->index]);
> > +
> > + ret = igt_display_try_commit2(&data->display,
> > COMMIT_ATOMIC);
> > + igt_skip_on(ret != 0);
> > +}
> > +
> > +/*
> > + * Multiple plane position test.
> > + * - We start by grabbing a reference CRC of a full blue fb
> > being scanned
> > + * out on the primary plane
> > + * - Then we scannout number of planes:
> > + * * the primary plane uses a blue fb with a black rectangle
> > hole
> > + * * planes, on top of the primary plane, with a blue fb that
> > is set-up
> > + *to cover the black rectangles of the primary plane fb
> > + * The resulting CRC should be identical to the reference CRC
> > + */
> > +
> > +static void
> > +create_fb_for_mode_position(data_t *data, drmModeModeInfo *mode,
> > + color_t *color, int *rect_x, int
> > *rect_y,
> > + int *rect_w, int *rect_h, uint64_t
> > tiling,
> > + int max_planes)
> > +{
> > + unsigned int fb_id;
> > + cairo_t *cr;
> > + igt_plane_t *primary;
> > +
> > + primary = igt_output_get_plane_type(data->output,
> > DRM_PLANE_TYPE_PRIMARY);
> > +
> > + fb_id = igt_create_fb(data->drm_fd,
> > + mode->hdisplay, mode->vdisplay,
> > + DRM_FORMAT_XRGB,
> > + tiling,
> > + &data->fb[primary->index]);
> > + igt_assert(fb_id);
> > +
> > + cr = igt_get_cairo_ctx(data->drm_fd, &data->fb[primary-
> > >index]);
> > + igt_paint_color(cr, rect_x[0], rect_y[0],
> > + mode->hdisplay, mode->vdisplay,
> > + color->red, color->green, color->blue);
> > +
> > + for (int i = 0; i < max_planes; i++) {
> > + if (data->plane[i]->type ==
> > DRM_PLANE_TYPE_PRIMARY)
> > + continue;
> > + igt_paint_color(cr, rect_x[i], rect_y[i],
> > + rect_w[i], rect_h[i], 0.0, 0.0,
> > 0.0);
> > + }
> > +
> > + igt_assert(cairo_status(cr) == 0);
> > + cairo_destroy(cr);
> > +}
> > +
> > +static void
> > +prepare_planes(data_t *data, color_t *color, int max_planes)
> > +{
> > + drmModeModeInfo *mode;
> > + igt_pipe_t *pipe;
> > + igt_plane_t *primary;
> > + int *x;
> > + int *y;
> > + int *size;
> > + int i;
> > +
> > + igt_output_set_pipe(data->output, data->pipe);
> > + primary = igt_o
Re: [Intel-gfx] [PATCH 07/18] drm/i915: introduce ppgtt page coloring
On 5 April 2017 at 15:02, Chris Wilson wrote:
> On Wed, Apr 05, 2017 at 02:50:41PM +0100, Matthew Auld wrote:
>> On 5 April 2017 at 14:41, Chris Wilson wrote:
>> > On Tue, Apr 04, 2017 at 11:11:17PM +0100, Matthew Auld wrote:
>> >> To enable 64K pages we need to set the intermediate-page-size(IPS) bit
>> >> of the pde, therefore a page table is said to be either operating in 64K
>> >> or 4K mode. To accommodate this vm placement restriction we introduce a
>> >> color for pages and corresponding color_adjust callback.
>> >>
>> >> Signed-off-by: Matthew Auld
>> >> ---
>> >> drivers/gpu/drm/i915/i915_gem_gtt.c | 25 +
>> >> drivers/gpu/drm/i915/i915_gem_gtt.h | 6 ++
>> >> drivers/gpu/drm/i915/i915_vma.c | 2 ++
>> >> 3 files changed, 33 insertions(+)
>> >>
>> >> diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c
>> >> b/drivers/gpu/drm/i915/i915_gem_gtt.c
>> >> index 0989af4a17e4..ddc3db345b76 100644
>> >> --- a/drivers/gpu/drm/i915/i915_gem_gtt.c
>> >> +++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
>> >> @@ -1332,6 +1332,28 @@ static int gen8_preallocate_top_level_pdp(struct
>> >> i915_hw_ppgtt *ppgtt)
>> >> return -ENOMEM;
>> >> }
>> >>
>> >> +static void i915_page_color_adjust(const struct drm_mm_node *node,
>> >> +unsigned long color,
>> >> +u64 *start,
>> >> +u64 *end)
>> >> +{
>> >> + GEM_BUG_ON(!is_valid_gtt_page_size(color));
>> >> +
>> >> + if (!(color & (I915_GTT_PAGE_SIZE_4K | I915_GTT_PAGE_SIZE_64K)))
>> >> + return;
>> >> +
>> >> + GEM_BUG_ON(node->allocated && !is_valid_gtt_page_size(node->color));
>> >> +
>> >> + if (i915_node_color_differs(node, color))
>> >> + *start = roundup(*start, 1 << GEN8_PDE_SHIFT);
>> >> +
>> >> + node = list_next_entry(node, node_list);
>> >> + if (i915_node_color_differs(node, color))
>> >> + *end = rounddown(*end, 1 << GEN8_PDE_SHIFT);
>> >> +
>> >> + GEM_BUG_ON(node->allocated && !is_valid_gtt_page_size(node->color));
>> >> +}
>> >> +
>> >> /*
>> >> * GEN8 legacy ppgtt programming is accomplished through a max 4 PDP
>> >> registers
>> >> * with a net effect resembling a 2-level page table in normal x86
>> >> terms. Each
>> >> @@ -1372,6 +1394,9 @@ static int gen8_ppgtt_init(struct i915_hw_ppgtt
>> >> *ppgtt)
>> >> ppgtt->base.allocate_va_range = gen8_ppgtt_alloc_4lvl;
>> >> ppgtt->base.insert_entries = gen8_ppgtt_insert_4lvl;
>> >> ppgtt->base.clear_range = gen8_ppgtt_clear_4lvl;
>> >> +
>> >> + if (SUPPORTS_PAGE_SIZE(dev_priv, I915_GTT_PAGE_SIZE_64K))
>> >> + ppgtt->base.mm.color_adjust =
>> >> i915_page_color_adjust;
>> >> } else {
>> >> ret = __pdp_init(&ppgtt->base, &ppgtt->pdp);
>> >> if (ret)
>> >> diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.h
>> >> b/drivers/gpu/drm/i915/i915_gem_gtt.h
>> >> index 9c592e2de516..8d893ddd98f2 100644
>> >> --- a/drivers/gpu/drm/i915/i915_gem_gtt.h
>> >> +++ b/drivers/gpu/drm/i915/i915_gem_gtt.h
>> >> @@ -353,6 +353,12 @@ i915_vm_has_cache_coloring(const struct
>> >> i915_address_space *vm)
>> >> }
>> >>
>> >> static inline bool
>> >> +i915_vm_has_page_coloring(const struct i915_address_space *vm)
>> >> +{
>> >> + return vm->mm.color_adjust && !i915_is_ggtt(vm);
>> >> +}
>> >> +
>> >> +static inline bool
>> >> i915_vm_is_48bit(const struct i915_address_space *vm)
>> >> {
>> >> return (vm->total - 1) >> 32;
>> >> diff --git a/drivers/gpu/drm/i915/i915_vma.c
>> >> b/drivers/gpu/drm/i915/i915_vma.c
>> >> index 8f0041ba328f..4043145b4310 100644
>> >> --- a/drivers/gpu/drm/i915/i915_vma.c
>> >> +++ b/drivers/gpu/drm/i915/i915_vma.c
>> >> @@ -471,6 +471,8 @@ i915_vma_insert(struct i915_vma *vma, u64 size, u64
>> >> alignment, u64 flags)
>> >>
>> >> if (i915_vm_has_cache_coloring(vma->vm))
>> >> color = obj->cache_level;
>> >> + else if (i915_vm_has_page_coloring(vma->vm))
>> >> + color = obj->gtt_page_size;
>> >
>> > This does not need color_adjust since you are just specifying an
>> > alignment and size. Why the extra complications? I remember asking the
>> > same last time.
>> Hmm, are you saying the whole idea of needing a color_adjust for
>> 4K/64K vm placement is completely unnecessary?
>
> As constructed here, yes. Since you just want to request a
> obj->gtt_page_size aligned block:
>
> .size = round_up(size, obj->gtt_page_size),
> .align = max(align, obj->gtt_page_size).
>
> (Hmm, now I think about it you shouldn't round size up unless the
> insert_pages() is careful not to assume that the last page is a full
> superpage. More I think about this, you only want to align the base and
> let insert_pages group up the superpages.)
I feel like I must be missing your point, could you expand on what you
mean my grouping superpages?
>
> Unless I have
Re: [Intel-gfx] [RFC 2/2] drm/i915/bdw: permit make_rpcs execution on BDW to enable slice shutdown
On pe, 2017-04-07 at 06:55 -0700, Dmitry Rogozhkin wrote: > BDW supports RCS slices powering on/off. To do that we need make_rpcs > executed on BDW to flash slices configuration. > > Change-Id: Ia80b1be329bedc57cc61078ea18ecb3d2580c16a > Signed-off-by: Dmitry Rogozhkin > CC: Tvrtko Ursulin > CC: Zhipeng Gong > CC: Joonas Lahtinen > CC: Chris Wilson Maybe this patch should get rid of the "!IS_SKYLAKE(dev_priv)" restriction in the setter function, too? Regards, Joonas -- Joonas Lahtinen Open Source Technology Center Intel Corporation ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm: Fix get_property logic fumble
Yet again I've proven that I can't negate conditions :(
Fixes: eb8eb02ed850 ("drm: Drop modeset_lock_all from the getproperty ioctl")
Cc: Maarten Lankhorst
Cc: Daniel Vetter
Cc: Jani Nikula
Cc: Sean Paul
Reported-by: Tvrtko Ursulin
Cc: Tvrtko Ursulin
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_property.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_property.c b/drivers/gpu/drm/drm_property.c
index 3feef0659940..3e88fa24eab3 100644
--- a/drivers/gpu/drm/drm_property.c
+++ b/drivers/gpu/drm/drm_property.c
@@ -476,7 +476,7 @@ int drm_mode_getproperty_ioctl(struct drm_device *dev,
drm_property_type_is(property, DRM_MODE_PROP_BITMASK)) {
list_for_each_entry(prop_enum, &property->enum_list, head) {
enum_count++;
- if (out_resp->count_enum_blobs <= enum_count)
+ if (out_resp->count_enum_blobs < enum_count)
continue;
if (copy_to_user(&enum_ptr[copied].value,
--
2.11.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2] drm/i915: Use wait_for_register in lpt_reset_fdi_mphy()
On Mon, Apr 10, 2017 at 10:22:00AM +, Michal Wajdeczko wrote: > There is no need to use macros as we can use generic function. > And we can save ~2000 bytes in driver footprint. > > v2: drop ret var, add 10ms fallback (Chris) > > Signed-off-by: Michal Wajdeczko > Cc: Paulo Zanoni > Cc: Chris Wilson Reviewed-by: Chris Wilson -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Use drm_i915_private directly from debugfs
On Mon, Apr 10, 2017 at 01:42:46PM +0300, Joonas Lahtinen wrote: > On pe, 2017-04-07 at 20:42 +0100, Chris Wilson wrote: > > The void *data passed to debugfs callbacks is actually the > > drm_i915_private pointer, so use it thusly and avoid the to_i915(dev) > > indirection. > > > > Signed-off-by: Chris Wilson > > Reviewed-by: Joonas Lahtinen Pushed the trivial patch before drm_device starts making a comeback. -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC 0/2] slice shutdown debugfs interface for Gen8/Gen9
On Fri, Apr 07, 2017 at 06:55:27AM -0700, Dmitry Rogozhkin wrote: > Starting from Gen8 HW supports dynamic power on/off slices. This > permits to free power budget and may dramatically affect performance. > This patch series suggests an interface (debugfs) to permit user to > setup number of active slices. Interface can be used in performance > investigations targeting scalability across hw platforms. > > Dmitry Rogozhkin (2): > drm/i915/skl: add slice shutdown debugfs interface > drm/i915/bdw: permit make_rpcs execution on BDW to enable slice > shutdown Lgtm, but I haven't used the slices extensively myself so I'd like a second opinion on whether this is valid (that we can program the slices to an arbitrary value). And if so, is there any reason why userspace wouldn't want to be able to select its own slices? -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v3 2.5/13] drm/i915: Remove unused dp properties for dp-mst.
Those properties are not hooked up on MST and were ignored. Best not expose
them at all.
Without this the next patch fails to start on X.org, because the DP-MST
properties could
not be read.
Signed-off-by: Maarten Lankhorst
---
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index a146090b651b..42f62dcd2f3e 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -5054,7 +5054,7 @@ bool intel_dp_is_edp(struct drm_i915_private *dev_priv,
enum port port)
return intel_bios_is_port_edp(dev_priv, port);
}
-void
+static void
intel_dp_add_properties(struct intel_dp *intel_dp, struct drm_connector
*connector)
{
intel_attach_force_audio_property(connector);
diff --git a/drivers/gpu/drm/i915/intel_dp_mst.c
b/drivers/gpu/drm/i915/intel_dp_mst.c
index 3fc345a76e6f..fb1cfdfa7fba 100644
--- a/drivers/gpu/drm/i915/intel_dp_mst.c
+++ b/drivers/gpu/drm/i915/intel_dp_mst.c
@@ -450,7 +450,6 @@ static struct drm_connector
*intel_dp_add_mst_connector(struct drm_dp_mst_topolo
drm_mode_connector_attach_encoder(&intel_connector->base,
&intel_dp->mst_encoders[i]->base.base);
}
- intel_dp_add_properties(intel_dp, connector);
drm_object_attach_property(&connector->base,
dev->mode_config.path_property, 0);
drm_object_attach_property(&connector->base,
dev->mode_config.tile_property, 0);
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 1f9e92eb93da..b50196b7237d 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -1503,7 +1503,6 @@ void intel_edp_backlight_off(struct intel_dp *intel_dp);
void intel_edp_panel_vdd_on(struct intel_dp *intel_dp);
void intel_edp_panel_on(struct intel_dp *intel_dp);
void intel_edp_panel_off(struct intel_dp *intel_dp);
-void intel_dp_add_properties(struct intel_dp *intel_dp, struct drm_connector
*connector);
void intel_dp_mst_suspend(struct drm_device *dev);
void intel_dp_mst_resume(struct drm_device *dev);
int intel_dp_max_link_rate(struct intel_dp *intel_dp);
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Use drm_i915_private directly from debugfs
On pe, 2017-04-07 at 20:42 +0100, Chris Wilson wrote: > The void *data passed to debugfs callbacks is actually the > drm_i915_private pointer, so use it thusly and avoid the to_i915(dev) > indirection. > > Signed-off-by: Chris Wilson Reviewed-by: Joonas Lahtinen Regards, Joonas -- Joonas Lahtinen Open Source Technology Center Intel Corporation ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Use wait_for_register in lpt_reset_fdi_mphy() (rev2)
== Series Details == Series: drm/i915: Use wait_for_register in lpt_reset_fdi_mphy() (rev2) URL : https://patchwork.freedesktop.org/series/22758/ State : success == Summary == Series 22758v2 drm/i915: Use wait_for_register in lpt_reset_fdi_mphy() https://patchwork.freedesktop.org/api/1.0/series/22758/revisions/2/mbox/ fi-bdw-5557u total:278 pass:267 dwarn:0 dfail:0 fail:0 skip:11 time:438s fi-bdw-gvtdvmtotal:278 pass:256 dwarn:8 dfail:0 fail:0 skip:14 time:431s fi-bsw-n3050 total:278 pass:242 dwarn:0 dfail:0 fail:0 skip:36 time:576s fi-bxt-j4205 total:278 pass:259 dwarn:0 dfail:0 fail:0 skip:19 time:507s fi-bxt-t5700 total:278 pass:258 dwarn:0 dfail:0 fail:0 skip:20 time:536s fi-byt-j1900 total:278 pass:254 dwarn:0 dfail:0 fail:0 skip:24 time:484s fi-byt-n2820 total:278 pass:250 dwarn:0 dfail:0 fail:0 skip:28 time:482s fi-hsw-4770 total:278 pass:262 dwarn:0 dfail:0 fail:0 skip:16 time:407s fi-hsw-4770r total:278 pass:262 dwarn:0 dfail:0 fail:0 skip:16 time:405s fi-ilk-650 total:278 pass:228 dwarn:0 dfail:0 fail:0 skip:50 time:420s fi-ivb-3520m total:278 pass:260 dwarn:0 dfail:0 fail:0 skip:18 time:490s fi-ivb-3770 total:278 pass:260 dwarn:0 dfail:0 fail:0 skip:18 time:491s fi-kbl-7500u total:278 pass:260 dwarn:0 dfail:0 fail:0 skip:18 time:457s fi-kbl-7560u total:278 pass:268 dwarn:0 dfail:0 fail:0 skip:10 time:567s fi-skl-6260u total:278 pass:268 dwarn:0 dfail:0 fail:0 skip:10 time:451s fi-skl-6700hqtotal:278 pass:261 dwarn:0 dfail:0 fail:0 skip:17 time:571s fi-skl-6700k total:278 pass:256 dwarn:4 dfail:0 fail:0 skip:18 time:459s fi-skl-6770hqtotal:278 pass:268 dwarn:0 dfail:0 fail:0 skip:10 time:493s fi-skl-gvtdvmtotal:278 pass:265 dwarn:0 dfail:0 fail:0 skip:13 time:434s fi-snb-2520m total:278 pass:250 dwarn:0 dfail:0 fail:0 skip:28 time:526s fi-snb-2600 total:278 pass:249 dwarn:0 dfail:0 fail:0 skip:29 time:403s d86f5fa557fdf089bdb5b51f625a7f5967f11015 drm-tip: 2017y-04m-10d-06h-38m-49s UTC integration manifest 8ea821b drm/i915: Use wait_for_register in lpt_reset_fdi_mphy() == Logs == For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_4457/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 04/13] drm/i915: Use vma->exec_entry as our double-entry placeholder
On Fri, Mar 31, 2017 at 12:29:23PM +0300, Joonas Lahtinen wrote: > Did you intend to rename too, or where did the title come from? It's accurate. We have vma->exec_list (later vma->exec_link) that is the vma's location on the execbufer list, and we have vma->exec_entry which is the vma's execobj. Currently we use list_empty(&vma->exec_list) to determine if this vma is already in use in an execbuf ioctl (which is two pointer loads, and two pointer sets to mark as unused) vs just checking !vma->exec_entry which is simply. The caveat is to remember to clear vma->exec_entry -- but that was already taken care of when I rebased a later patch to fix softpinning. -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2] drm/i915: Use wait_for_register in lpt_reset_fdi_mphy()
There is no need to use macros as we can use generic function.
And we can save ~2000 bytes in driver footprint.
v2: drop ret var, add 10ms fallback (Chris)
Signed-off-by: Michal Wajdeczko
Cc: Paulo Zanoni
Cc: Chris Wilson
---
drivers/gpu/drm/i915/intel_display.c | 15 ++-
1 file changed, 10 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index b6b40cd..eeb828c 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -7703,16 +7703,21 @@ static void lpt_reset_fdi_mphy(struct drm_i915_private
*dev_priv)
tmp |= FDI_MPHY_IOSFSB_RESET_CTL;
I915_WRITE(SOUTH_CHICKEN2, tmp);
- if (wait_for_us(I915_READ(SOUTH_CHICKEN2) &
- FDI_MPHY_IOSFSB_RESET_STATUS, 100))
+ if (__intel_wait_for_register_fw(dev_priv,
+SOUTH_CHICKEN2,
+FDI_MPHY_IOSFSB_RESET_STATUS,
+FDI_MPHY_IOSFSB_RESET_STATUS,
+100, 10, &tmp))
DRM_ERROR("FDI mPHY reset assert timeout\n");
- tmp = I915_READ(SOUTH_CHICKEN2);
tmp &= ~FDI_MPHY_IOSFSB_RESET_CTL;
I915_WRITE(SOUTH_CHICKEN2, tmp);
- if (wait_for_us((I915_READ(SOUTH_CHICKEN2) &
-FDI_MPHY_IOSFSB_RESET_STATUS) == 0, 100))
+ if (__intel_wait_for_register_fw(dev_priv,
+SOUTH_CHICKEN2,
+FDI_MPHY_IOSFSB_RESET_STATUS,
+0,
+100, 10, NULL))
DRM_ERROR("FDI mPHY reset de-assert timeout\n");
}
--
2.7.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/5] drm/i915: Lift timeline ordering to await_dma_fence
On ma, 2017-04-10 at 09:55 +0100, Chris Wilson wrote: > Currently we filter out repeated use of the same timeline in the low > level i915_gem_request_await_request(), after having added the > dependency on the old request. However, we can lift this to > i915_gem_request_await_dma_fence() (before the dependency is added) > using the observation that requests along the same timeline are > explicitly ordered via i915_add_request (along with the dependencies). > > Signed-off-by: Chris Wilson > Cc: Joonas Lahtinen Reviewed-by: Joonas Lahtinen Regards, Joonas -- Joonas Lahtinen Open Source Technology Center Intel Corporation ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/5] drm/i915: Mark up clflushes as belonging to an unordered timeline
On ma, 2017-04-10 at 09:55 +0100, Chris Wilson wrote: > 2 clflushes on two different objects are not ordered, and so do not > belong to the same timeline (context). Either we use a unique context > for each, or we reserve a special global context to mean unordered. > Ideally, we would reserve 0 to mean unordered (DMA_FENCE_NO_CONTEXT) to > have the same semantics everywhere. > > Signed-off-by: Chris Wilson > Cc: Daniel Vetter > Cc: Joonas Lahtinen > @@ -157,7 +156,7 @@ void i915_gem_clflush_object(struct drm_i915_gem_object > *obj, > dma_fence_init(&clflush->dma, > &i915_clflush_ops, > &clflush_lock, > - clflush_context, > + to_i915(obj->base.dev)->mm.unordered_timeline, It seems you have high confidence on being able to replace this line with DMA_FENCE_NO_CONTEXT ;) Reviewed-by: Joonas Lahtinen Regards, Joonas -- Joonas Lahtinen Open Source Technology Center Intel Corporation ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/atomic: Acquire connection_mutex lock in drm_helper_probe_single_connector_modes, v4.
Hi Maarteen,
Sorry for the late review, I was on vacation last week.
On Thu, 6 Apr 2017 20:55:20 +0200
Maarten Lankhorst wrote:
> mode_valid() called from drm_helper_probe_single_connector_modes()
> may need to look at connector->state because what a valid mode is may
> depend on connector properties being set. For example some HDMI modes
> might be rejected when a connector property forces the connector
> into DVI mode.
>
> Some implementations of detect() already lock all state,
> so we have to pass an acquire_ctx to them to prevent a deadlock.
>
> This means changing the function signature of detect() slightly,
> and passing the acquire_ctx for locking multiple crtc's.
> For the callbacks, it will always be non-zero. To allow callers
> not to worry about this, drm_helper_probe_detect_ctx is added
> which might handle -EDEADLK for you.
>
> Changes since v1:
> - Always set ctx parameter.
> Changes since v2:
> - Always take connection_mutex when probing.
> Changes since v3:
> - Remove the ctx from intel_dp_long_pulse, and add
> WARN_ON(!connection_mutex) (danvet)
> - Update docs to clarify the locking situation. (danvet)
Maybe this is something DRM-specific, but usually we put the changelog
after the '---' to avoid having it in the final commit.
Same goes for the ", v4" suffix in the commit title, it should be
'[PATCH vX] '.
>
> Signed-off-by: Maarten Lankhorst
> Cc: Boris Brezillon
> Reviewed-by: Daniel Vetter
> ---
> drivers/gpu/drm/drm_probe_helper.c | 100
> ---
> drivers/gpu/drm/i915/intel_crt.c | 25
> drivers/gpu/drm/i915/intel_display.c | 25
> drivers/gpu/drm/i915/intel_dp.c | 21 +++
> drivers/gpu/drm/i915/intel_drv.h | 8 +--
> drivers/gpu/drm/i915/intel_hotplug.c | 3 +-
> drivers/gpu/drm/i915/intel_tv.c | 21 +++
> include/drm/drm_connector.h | 6 ++
> include/drm/drm_crtc_helper.h| 3 +
> include/drm/drm_modeset_helper_vtables.h | 36 +++
> 10 files changed, 187 insertions(+), 61 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_probe_helper.c
> b/drivers/gpu/drm/drm_probe_helper.c
> index efb5e5e8ce62..1b0c14ab3fff 100644
> --- a/drivers/gpu/drm/drm_probe_helper.c
> +++ b/drivers/gpu/drm/drm_probe_helper.c
> @@ -169,12 +169,73 @@ void drm_kms_helper_poll_enable(struct drm_device *dev)
> EXPORT_SYMBOL(drm_kms_helper_poll_enable);
>
> static enum drm_connector_status
> -drm_connector_detect(struct drm_connector *connector, bool force)
> +drm_helper_probe_detect_ctx(struct drm_connector *connector, bool force)
The function name is misleading IMHO. AFAIU, this helper is
instantiating a new context because the caller did not provide one, so
how about renaming it drm_helper_probe_detect_no_ctx()?
> {
> - return connector->funcs->detect ?
> - connector->funcs->detect(connector, force) :
> - connector_status_connected;
> + const struct drm_connector_helper_funcs *funcs =
> connector->helper_private;
> + struct drm_modeset_acquire_ctx ctx;
> + int ret;
> +
> + drm_modeset_acquire_init(&ctx, 0);
> +
> +retry:
> + ret = drm_modeset_lock(&connector->dev->mode_config.connection_mutex,
> &ctx);
> + if (!ret) {
> + if (funcs->detect_ctx)
> + ret = funcs->detect_ctx(connector, &ctx, force);
> + else if (connector->funcs->detect)
> + ret = connector->funcs->detect(connector, force);
> + else
> + ret = connector_status_connected;
> + }
> +
> + if (ret == -EDEADLK) {
> + drm_modeset_backoff(&ctx);
> + goto retry;
> + }
> +
> + if (WARN_ON(ret < 0))
> + ret = connector_status_unknown;
> +
> + drm_modeset_drop_locks(&ctx);
> + drm_modeset_acquire_fini(&ctx);
> +
> + return ret;
> +}
[...]
> /**
> + * @detect_ctx:
> + *
> + * Check to see if anything is attached to the connector. The parameter
> + * force is set to false whilst polling, true when checking the
> + * connector due to a user request. force can be used by the driver to
> + * avoid expensive, destructive operations during automated probing.
> + *
> + * This callback is optional, if not implemented the connector will be
> + * considered as always being attached.
> + *
> + * This is the atomic version of &drm_connector_funcs.detect.
> + *
> + * To avoid races against concurrent connector state updates, the
> + * helper libraries always call this with ctx set to a valid context,
> + * and &drm_mode_config.connection_mutex will always be locked with
> + * the ctx parameter set to this ctx. This allows taking additional
> + * locks as required.
> + *
> + * RETURNS:
> + *
> + * &drm_connector_status indicating the connector's status,
> + * or the error code r
Re: [Intel-gfx] [PATCH 0/5] Re: [BUG][REGRESSION] i915 gpu hangs under load
Am 07.04.2017 01:23 schrieb Andrea Arcangeli: I'm also getting kernel hangs every couple of days. For me it's still not fixed here in 4.11-rc5. It's hard to reproduce, the best reproducer is to build lineageos 14.1 on host while running LTP in a guest to stress the guest VM. Initially I thought it was related to the fact I upgraded the xf86 intel driver just a few weeks ago (I deferred any upgrade of the userland intel driver since last July because of a regression that never got fixed and broke xterm for me). After I found a workaround for the userland regression (appended at the end for reference) I started getting kernel hangs but they are separate issues as far as I can tell. It's not well tested so beware... (it survived a couple of builds and some VM reclaim but that's it). The first patch 1/5 is the potential fix for the i915 kernel hang. The rest are incremental improvements. And I've no great solution for when the shrinker was invoked with the struct_mutex held and and recurse on the lock. I don't think we can possibly wait in such case (other than flush work that the second patch does) but then practically it shouldn't be a big deal, the big RAM eater is unlikely to be i915 when the system is low on memory. FWIW without having insight here, -rc6 seems to be good. No disturbing gpu hangs under load so far. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Drop const qualifiers from params in wait_for_register()
== Series Details == Series: drm/i915: Drop const qualifiers from params in wait_for_register() URL : https://patchwork.freedesktop.org/series/22763/ State : success == Summary == Series 22763v1 drm/i915: Drop const qualifiers from params in wait_for_register() https://patchwork.freedesktop.org/api/1.0/series/22763/revisions/1/mbox/ Test gem_exec_suspend: Subgroup basic-s4-devices: pass -> DMESG-WARN (fi-kbl-7560u) fdo#100125 Test kms_pipe_crc_basic: Subgroup suspend-read-crc-pipe-a: pass -> FAIL (fi-skl-6700k) fdo#100367 fdo#100125 https://bugs.freedesktop.org/show_bug.cgi?id=100125 fdo#100367 https://bugs.freedesktop.org/show_bug.cgi?id=100367 fi-bdw-5557u total:278 pass:267 dwarn:0 dfail:0 fail:0 skip:11 time:437s fi-bdw-gvtdvmtotal:278 pass:256 dwarn:8 dfail:0 fail:0 skip:14 time:426s fi-bsw-n3050 total:278 pass:242 dwarn:0 dfail:0 fail:0 skip:36 time:574s fi-bxt-j4205 total:278 pass:259 dwarn:0 dfail:0 fail:0 skip:19 time:507s fi-bxt-t5700 total:278 pass:258 dwarn:0 dfail:0 fail:0 skip:20 time:560s fi-byt-j1900 total:278 pass:254 dwarn:0 dfail:0 fail:0 skip:24 time:484s fi-byt-n2820 total:278 pass:250 dwarn:0 dfail:0 fail:0 skip:28 time:481s fi-hsw-4770 total:278 pass:262 dwarn:0 dfail:0 fail:0 skip:16 time:410s fi-hsw-4770r total:278 pass:262 dwarn:0 dfail:0 fail:0 skip:16 time:406s fi-ilk-650 total:278 pass:228 dwarn:0 dfail:0 fail:0 skip:50 time:426s fi-ivb-3520m total:278 pass:260 dwarn:0 dfail:0 fail:0 skip:18 time:484s fi-ivb-3770 total:278 pass:260 dwarn:0 dfail:0 fail:0 skip:18 time:471s fi-kbl-7500u total:278 pass:260 dwarn:0 dfail:0 fail:0 skip:18 time:459s fi-kbl-7560u total:278 pass:267 dwarn:1 dfail:0 fail:0 skip:10 time:566s fi-skl-6260u total:278 pass:268 dwarn:0 dfail:0 fail:0 skip:10 time:451s fi-skl-6700hqtotal:278 pass:261 dwarn:0 dfail:0 fail:0 skip:17 time:572s fi-skl-6700k total:278 pass:255 dwarn:4 dfail:0 fail:1 skip:18 time:459s fi-skl-6770hqtotal:278 pass:268 dwarn:0 dfail:0 fail:0 skip:10 time:499s fi-skl-gvtdvmtotal:278 pass:265 dwarn:0 dfail:0 fail:0 skip:13 time:431s fi-snb-2520m total:278 pass:250 dwarn:0 dfail:0 fail:0 skip:28 time:531s fi-snb-2600 total:278 pass:249 dwarn:0 dfail:0 fail:0 skip:29 time:400s d86f5fa557fdf089bdb5b51f625a7f5967f11015 drm-tip: 2017y-04m-10d-06h-38m-49s UTC integration manifest a5fcad1 drm/i915: Drop const qualifiers from params in wait_for_register() == Logs == For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_4456/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3 01/13] drm/i915: Remove unused members from intel_tv.c
On Mon, Apr 10, 2017 at 11:07:07AM +0200, Maarten Lankhorst wrote: > They have been unused since 2010, after the code for > intel_tv_save/restore was removed. > > Signed-off-by: Maarten Lankhorst Reviewed-by: Chris Wilson (I pick the easy ones ;) -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Use wait_for_register in lpt_reset_fdi_mphy()
On Mon, Apr 10, 2017 at 08:53:25AM +, Michal Wajdeczko wrote:
> There is no need to use macros as we can use generic function.
> And we can save ~2000 bytes in driver footprint.
>
> Signed-off-by: Michal Wajdeczko
> Cc: Paulo Zanoni
> Cc: Chris Wilson
> ---
> drivers/gpu/drm/i915/intel_display.c | 18 +-
> 1 file changed, 13 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index b6b40cd..63f9dae4 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -7697,22 +7697,30 @@ static void ironlake_init_pch_refclk(struct
> drm_i915_private *dev_priv)
>
> static void lpt_reset_fdi_mphy(struct drm_i915_private *dev_priv)
> {
> + int ret;
> uint32_t tmp;
>
> tmp = I915_READ(SOUTH_CHICKEN2);
> tmp |= FDI_MPHY_IOSFSB_RESET_CTL;
> I915_WRITE(SOUTH_CHICKEN2, tmp);
>
> - if (wait_for_us(I915_READ(SOUTH_CHICKEN2) &
> - FDI_MPHY_IOSFSB_RESET_STATUS, 100))
> + ret = __intel_wait_for_register_fw(dev_priv,
> +SOUTH_CHICKEN2,
> +FDI_MPHY_IOSFSB_RESET_STATUS,
> +FDI_MPHY_IOSFSB_RESET_STATUS,
> +100, 0, &tmp);
> + if (ret)
> DRM_ERROR("FDI mPHY reset assert timeout\n");
If we aren't using ret, and if the function remains neatly aligned I
would have just done
if ( __intel_wait_for_register_fw(dev_priv, ...))
DRM_ERROR("FDI mPHY reset assert timeout\n");
I would also let it have a 10ms max timeout - there's no downside. We
didn't before because of the expense of the wait_for() loops, and this
must be a waitable context.
Hmm. We do want __inte_wait_for_register_fw:
might_sleep_if(fast_timeout_us > 10 || slow_timeout_ms);
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 01/11] drm: Add HDMI 2.0 VIC support for AVI info-frames
On 07.04.2017 18:39, Shashank Sharma wrote:
> HDMI 1.4b support the CEA video modes as per range of CEA-861-D (VIC 1-64).
> For any other mode, the VIC filed in AVI infoframes should be 0.
> HDMI 2.0 sinks, support video modes range as per CEA-861-F spec, which is
> extended to (VIC 1-107).
>
> This patch adds a bool input variable, which indicates if the connected
> sink is a HDMI 2.0 sink or not. This will make sure that we don't pass a
> HDMI 2.0 VIC to a HDMI 1.4 sink.
>
> This patch touches all drm drivers, who are callers of this function
> drm_hdmi_avi_infoframe_from_display_mode but to make sure there is
> no change in current behavior, is_hdmi2 is kept as false.
>
> In case of I915 driver, this patch checks the connector->display_info
> to check if the connected display is HDMI 2.0.
>
> Cc: Ville Syrjala
> Cc: Jose Abreu
> Cc: Andrzej Hajda
> Cc: Alex Deucher
> Cc: Daniel Vetter
>
> PS: This patch touches a few lines in few files, which were
> already above 80 char, so checkpatch gives 80 char warning again.
> - gpu/drm/omapdrm/omap_encoder.c
> - gpu/drm/i915/intel_sdvo.c
>
> Signed-off-by: Shashank Sharma
Finally I have chances to look at the specs and I am not sure if this
solution fully reflects the specs and is scalable. According to specs
VIC set to 0 in AVIF means "Video Format not documented in CTA-861", ie
it is described by vendor specific data block and vendor specific
infoframe, maybe something else(???). I suppose ideally during EDID read
there should be recorded info for every mode if it was defined by vendor
extension, or not. This info could be later used by drivers to configure
AVIF and VSIF accordingly.
Anyway as a short-term initial solution it could work.
So:
Reviewed-by: Andrzej Hajda
--
Regards
Andrzej
> ---
> drivers/gpu/drm/amd/amdgpu/dce_v10_0.c| 2 +-
> drivers/gpu/drm/amd/amdgpu/dce_v11_0.c| 2 +-
> drivers/gpu/drm/amd/amdgpu/dce_v8_0.c | 2 +-
> drivers/gpu/drm/bridge/analogix-anx78xx.c | 3 ++-
> drivers/gpu/drm/bridge/sii902x.c | 2 +-
> drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 2 +-
> drivers/gpu/drm/drm_edid.c| 12 +++-
> drivers/gpu/drm/exynos/exynos_hdmi.c | 2 +-
> drivers/gpu/drm/i2c/tda998x_drv.c | 2 +-
> drivers/gpu/drm/i915/intel_hdmi.c | 5 -
> drivers/gpu/drm/i915/intel_sdvo.c | 3 ++-
> drivers/gpu/drm/mediatek/mtk_hdmi.c | 2 +-
> drivers/gpu/drm/omapdrm/omap_encoder.c| 3 ++-
> drivers/gpu/drm/radeon/radeon_audio.c | 2 +-
> drivers/gpu/drm/rockchip/inno_hdmi.c | 2 +-
> drivers/gpu/drm/sti/sti_hdmi.c| 2 +-
> drivers/gpu/drm/tegra/hdmi.c | 2 +-
> drivers/gpu/drm/tegra/sor.c | 2 +-
> drivers/gpu/drm/vc4/vc4_hdmi.c| 2 +-
> drivers/gpu/drm/zte/zx_hdmi.c | 2 +-
> include/drm/drm_edid.h| 3 ++-
> 21 files changed, 38 insertions(+), 21 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c
> b/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c
> index daf003d..5dc3e95 100644
> --- a/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c
> +++ b/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c
> @@ -1877,7 +1877,7 @@ static void dce_v10_0_afmt_setmode(struct drm_encoder
> *encoder,
> dce_v10_0_audio_write_sad_regs(encoder);
> dce_v10_0_audio_write_latency_fields(encoder, mode);
>
> - err = drm_hdmi_avi_infoframe_from_display_mode(&frame, mode);
> + err = drm_hdmi_avi_infoframe_from_display_mode(&frame, mode, false);
> if (err < 0) {
> DRM_ERROR("failed to setup AVI infoframe: %zd\n", err);
> return;
> diff --git a/drivers/gpu/drm/amd/amdgpu/dce_v11_0.c
> b/drivers/gpu/drm/amd/amdgpu/dce_v11_0.c
> index 3a72967..b70f077 100644
> --- a/drivers/gpu/drm/amd/amdgpu/dce_v11_0.c
> +++ b/drivers/gpu/drm/amd/amdgpu/dce_v11_0.c
> @@ -1861,7 +1861,7 @@ static void dce_v11_0_afmt_setmode(struct drm_encoder
> *encoder,
> dce_v11_0_audio_write_sad_regs(encoder);
> dce_v11_0_audio_write_latency_fields(encoder, mode);
>
> - err = drm_hdmi_avi_infoframe_from_display_mode(&frame, mode);
> + err = drm_hdmi_avi_infoframe_from_display_mode(&frame, mode, false);
> if (err < 0) {
> DRM_ERROR("failed to setup AVI infoframe: %zd\n", err);
> return;
> diff --git a/drivers/gpu/drm/amd/amdgpu/dce_v8_0.c
> b/drivers/gpu/drm/amd/amdgpu/dce_v8_0.c
> index 6943f26..bcf9c75 100644
> --- a/drivers/gpu/drm/amd/amdgpu/dce_v8_0.c
> +++ b/drivers/gpu/drm/amd/amdgpu/dce_v8_0.c
> @@ -1760,7 +1760,7 @@ static void dce_v8_0_afmt_setmode(struct drm_encoder
> *encoder,
> dce_v8_0_audio_write_sad_regs(encoder);
> dce_v8_0_audio_write_latency_fields(encoder, mode);
>
> - err = drm_hdmi_avi_infoframe_from_display_mode(&frame, mode);
> + err = drm_hdmi_avi_infoframe_from_display_mode(&frame, mode, false);
> if (err < 0) {
> DRM_ERROR("failed to setup AVI inf
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Convert connector properties to atomic. (rev2)
== Series Details == Series: drm/i915: Convert connector properties to atomic. (rev2) URL : https://patchwork.freedesktop.org/series/22634/ State : success == Summary == Series 22634v2 drm/i915: Convert connector properties to atomic. https://patchwork.freedesktop.org/api/1.0/series/22634/revisions/2/mbox/ Test gem_exec_flush: Subgroup basic-batch-kernel-default-uc: pass -> FAIL (fi-snb-2600) fdo#17 Test gem_exec_suspend: Subgroup basic-s4-devices: pass -> DMESG-WARN (fi-kbl-7560u) fdo#100125 fdo#17 https://bugs.freedesktop.org/show_bug.cgi?id=17 fdo#100125 https://bugs.freedesktop.org/show_bug.cgi?id=100125 fi-bdw-5557u total:278 pass:267 dwarn:0 dfail:0 fail:0 skip:11 time:430s fi-bdw-gvtdvmtotal:278 pass:256 dwarn:8 dfail:0 fail:0 skip:14 time:423s fi-bsw-n3050 total:278 pass:242 dwarn:0 dfail:0 fail:0 skip:36 time:568s fi-bxt-j4205 total:278 pass:259 dwarn:0 dfail:0 fail:0 skip:19 time:510s fi-bxt-t5700 total:278 pass:258 dwarn:0 dfail:0 fail:0 skip:20 time:543s fi-byt-j1900 total:278 pass:254 dwarn:0 dfail:0 fail:0 skip:24 time:484s fi-byt-n2820 total:278 pass:250 dwarn:0 dfail:0 fail:0 skip:28 time:477s fi-hsw-4770 total:278 pass:262 dwarn:0 dfail:0 fail:0 skip:16 time:411s fi-hsw-4770r total:278 pass:262 dwarn:0 dfail:0 fail:0 skip:16 time:404s fi-ilk-650 total:278 pass:228 dwarn:0 dfail:0 fail:0 skip:50 time:420s fi-ivb-3520m total:278 pass:260 dwarn:0 dfail:0 fail:0 skip:18 time:479s fi-ivb-3770 total:278 pass:260 dwarn:0 dfail:0 fail:0 skip:18 time:473s fi-kbl-7500u total:278 pass:260 dwarn:0 dfail:0 fail:0 skip:18 time:465s fi-kbl-7560u total:278 pass:267 dwarn:1 dfail:0 fail:0 skip:10 time:568s fi-skl-6260u total:278 pass:268 dwarn:0 dfail:0 fail:0 skip:10 time:452s fi-skl-6700hqtotal:278 pass:261 dwarn:0 dfail:0 fail:0 skip:17 time:569s fi-skl-6700k total:278 pass:256 dwarn:4 dfail:0 fail:0 skip:18 time:463s fi-skl-6770hqtotal:278 pass:268 dwarn:0 dfail:0 fail:0 skip:10 time:488s fi-skl-gvtdvmtotal:278 pass:265 dwarn:0 dfail:0 fail:0 skip:13 time:431s fi-snb-2520m total:278 pass:250 dwarn:0 dfail:0 fail:0 skip:28 time:530s fi-snb-2600 total:278 pass:248 dwarn:0 dfail:0 fail:1 skip:29 time:399s d86f5fa557fdf089bdb5b51f625a7f5967f11015 drm-tip: 2017y-04m-10d-06h-38m-49s UTC integration manifest 21ca0a9 drm/i915: Convert intel_sdvo connector properties to atomic. d0e2017 drm/i915: Handle force_audio correctly in intel_sdvo 1075b60 drm/i915: Convert intel_hdmi connector properties to atomic aef458e drm/i915: Convert intel_dp properties to atomic. 5f05523 drm/i915: Make intel_dp->has_audio reflect hw state only 6fd8b7a drm/i915: Convert LVDS connector properties to atomic. bd25e9e drm/i915: Convert DSI connector properties to atomic. 6118531 drm/i915: Add plumbing for digital connector state. ff6cdcf drm/i915: Convert intel DVO connector to atomic 339b1de drm/i915: Convert intel_crt connector properties to atomic. 16bc770 drm/i915: Convert intel_dp_mst connector properties to atomic. da10d10 drm/i915: Convert intel_tv connector properties to atomic, v5. d5fb4ab drm/i915: Remove unused members from intel_tv.c == Logs == For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_4455/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Drop const qualifiers from params in wait_for_register()
On Mon, Apr 10, 2017 at 09:38:17AM +, Michal Wajdeczko wrote: > These params are passed by value, const qualifiers are ignored any way. They are not completely ignored, it just means you are not allowed to alter the value inside the function. But it doesn't improve code generation. > While around, unify timeout_ms type from long to int. > > Signed-off-by: Michal Wajdeczko > Suggested-by: Joonas Lahtinen > Cc: Joonas Lahtinen > Cc: Chris Wilson Reviewed-by: Chris Wilson -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/5] i915: flush gem obj freeing workqueues to add accuracy to the i915 shrinker
On Fri, Apr 07, 2017 at 06:48:58PM +0200, Andrea Arcangeli wrote:
> On Fri, Apr 07, 2017 at 04:30:11PM +0100, Chris Wilson wrote:
> > Not getting hangs is a good sign, but lockdep doesn't like it:
> >
> > [ 460.684901] WARNING: CPU: 1 PID: 172 at kernel/workqueue.c:2418
> > check_flush_dependency+0x92/0x130
> > [ 460.684924] workqueue: PF_MEMALLOC task 172(kworker/1:1H) is flushing
> > !WQ_MEM_RECLAIM events:__i915_gem_free_work [i915]
> >
> > If I allocated the workqueue with WQ_MEM_RELCAIM, it complains bitterly
> > as well.
>
> So in PF_MEMALLOC context we can't flush a workqueue with
> !WQ_MEM_RECLAIM.
>
> system_wq = alloc_workqueue("events", 0, 0);
>
> My point is synchronize_rcu_expedited will still push its work in
> the same system_wq workqueue...
>
> /* Marshall arguments & schedule the expedited grace period. */
> rew.rew_func = func;
> rew.rew_rsp = rsp;
> rew.rew_s = s;
> INIT_WORK_ONSTACK(&rew.rew_work, wait_rcu_exp_gp);
> schedule_work(&rew.rew_work);
>
> It's also using schedule_work, so either the above is a false
> positive, or we've still a problem with synchronize_rcu_expedited,
> just a reproducible issue anymore after we stop running it under the
> struct_mutex.
We still do have a problem with using synchronize_rcu_expedited() from
the shrinker as we maybe under someone else's mutex is that involved in
its own RCU dance.
> Even synchronize_sched will wait on the system_wq if
> synchronize_rcu_expedited has been issued in parallel by some other
> code, it's just there's no check for it because it's not invoking
> flush_work to wait.
Right.
> The deadlock happens if we flush_work() while holding any lock that
> may be taken by any of the workqueues that could be queued there. i915
> makes sure to flush_work only if the struct_mutex was released (not
> my initial version) but we're not checking if any of the other
> system_wq workqueues could possibly taking a lock that may have been
> hold during the allocation that invoked reclaim, I suppose that is the
> problem left, but I don't see how flush_work is special about it,
> synchronize_rcu_expedited would still have the same issue no? (despite
> no lockdep warning)
>
> I suspect this means synchronize_rcu_expedited() is not usable in
> reclaim context and lockdep should warn if PF_MEMALLOC is set when
> synchronize_rcu_expedited/synchronize_sched/synchronize_rcu are
> called.
Yes.
> Probably to fix this we should create a private workqueue for both RCU
> and i915 and stop sharing the system_wq with the rest of the system
> (and of course set WQ_MEM_RECLAIM in both workqueues). This makes sure
> when we call synchronize_rcu_expedited; flush_work from the shrinker,
> we won't risk waiting on other random work that may be taking locks
> that are hold by the code that invoked reclaim during an allocation.
We simply do not need to do our own synchronize_rcu* -- it's only used
to flush our slab frees on the off chance that (a) we have any and (b)
we do manage to free a whole slab. It is not the bulk of the memory that
we return to the system from the shrinker.
In the other thread, I stated that we should simply remove it. The
kswapd reclaim path should try to reclaim RCU slabs (by doing a
synhronize_sched or equivalent).
> The macro bug of waiting on system_wq 100% of the time while always
> holding the struct_mutex is gone, but we need to perfect this further
> and stop using the system_wq for RCU and i915 shrinker work.
Agreed. My preference is to simply not do it and leave the dangling RCU
to the core reclaim paths.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Drop const qualifiers from params in wait_for_register()
These params are passed by value, const qualifiers are ignored any way.
While around, unify timeout_ms type from long to int.
Signed-off-by: Michal Wajdeczko
Suggested-by: Joonas Lahtinen
Cc: Joonas Lahtinen
Cc: Chris Wilson
---
drivers/gpu/drm/i915/i915_drv.h | 20 ++--
drivers/gpu/drm/i915/intel_uncore.c | 14 +++---
2 files changed, 17 insertions(+), 17 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index bb6fc1e..ed079c2 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -3085,22 +3085,22 @@ void assert_forcewakes_inactive(struct drm_i915_private
*dev_priv);
int intel_wait_for_register(struct drm_i915_private *dev_priv,
i915_reg_t reg,
- const u32 mask,
- const u32 value,
- const unsigned long timeout_ms);
+ u32 mask,
+ u32 value,
+ unsigned int timeout_ms);
int __intel_wait_for_register_fw(struct drm_i915_private *dev_priv,
i915_reg_t reg,
-const u32 mask,
-const u32 value,
-const unsigned int fast_timeout_us,
-const unsigned int slow_timeout_ms,
+u32 mask,
+u32 value,
+unsigned int fast_timeout_us,
+unsigned int slow_timeout_ms,
u32 *out_value);
static inline
int intel_wait_for_register_fw(struct drm_i915_private *dev_priv,
i915_reg_t reg,
- const u32 mask,
- const u32 value,
- const unsigned int timeout_ms)
+ u32 mask,
+ u32 value,
+ unsigned int timeout_ms)
{
return __intel_wait_for_register_fw(dev_priv, reg, mask, value,
2, timeout_ms, NULL);
diff --git a/drivers/gpu/drm/i915/intel_uncore.c
b/drivers/gpu/drm/i915/intel_uncore.c
index ace0993..1deb1a4 100644
--- a/drivers/gpu/drm/i915/intel_uncore.c
+++ b/drivers/gpu/drm/i915/intel_uncore.c
@@ -1610,10 +1610,10 @@ static int gen6_reset_engines(struct drm_i915_private
*dev_priv,
*/
int __intel_wait_for_register_fw(struct drm_i915_private *dev_priv,
i915_reg_t reg,
-const u32 mask,
-const u32 value,
-const unsigned int fast_timeout_us,
-const unsigned int slow_timeout_ms,
+u32 mask,
+u32 value,
+unsigned int fast_timeout_us,
+unsigned int slow_timeout_ms,
u32 *out_value)
{
u32 reg_value;
@@ -1651,9 +1651,9 @@ int __intel_wait_for_register_fw(struct drm_i915_private
*dev_priv,
*/
int intel_wait_for_register(struct drm_i915_private *dev_priv,
i915_reg_t reg,
- const u32 mask,
- const u32 value,
- const unsigned long timeout_ms)
+ u32 mask,
+ u32 value,
+ unsigned int timeout_ms)
{
unsigned fw =
--
2.7.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/5] drm/i915: Mark up clflushes as belonging to an unordered timeline
== Series Details == Series: series starting with [1/5] drm/i915: Mark up clflushes as belonging to an unordered timeline URL : https://patchwork.freedesktop.org/series/22759/ State : success == Summary == Series 22759v1 Series without cover letter https://patchwork.freedesktop.org/api/1.0/series/22759/revisions/1/mbox/ Test gem_exec_suspend: Subgroup basic-s4-devices: pass -> DMESG-WARN (fi-snb-2600) fdo#100125 fdo#100125 https://bugs.freedesktop.org/show_bug.cgi?id=100125 fi-bdw-5557u total:278 pass:267 dwarn:0 dfail:0 fail:0 skip:11 time:427s fi-bdw-gvtdvmtotal:278 pass:256 dwarn:8 dfail:0 fail:0 skip:14 time:429s fi-bsw-n3050 total:278 pass:242 dwarn:0 dfail:0 fail:0 skip:36 time:585s fi-bxt-j4205 total:278 pass:259 dwarn:0 dfail:0 fail:0 skip:19 time:500s fi-bxt-t5700 total:278 pass:258 dwarn:0 dfail:0 fail:0 skip:20 time:539s fi-byt-j1900 total:278 pass:254 dwarn:0 dfail:0 fail:0 skip:24 time:487s fi-byt-n2820 total:278 pass:250 dwarn:0 dfail:0 fail:0 skip:28 time:484s fi-hsw-4770 total:278 pass:262 dwarn:0 dfail:0 fail:0 skip:16 time:407s fi-hsw-4770r total:278 pass:262 dwarn:0 dfail:0 fail:0 skip:16 time:405s fi-ilk-650 total:278 pass:228 dwarn:0 dfail:0 fail:0 skip:50 time:420s fi-ivb-3520m total:278 pass:260 dwarn:0 dfail:0 fail:0 skip:18 time:490s fi-ivb-3770 total:278 pass:260 dwarn:0 dfail:0 fail:0 skip:18 time:463s fi-kbl-7500u total:278 pass:260 dwarn:0 dfail:0 fail:0 skip:18 time:457s fi-kbl-7560u total:278 pass:268 dwarn:0 dfail:0 fail:0 skip:10 time:567s fi-skl-6260u total:278 pass:268 dwarn:0 dfail:0 fail:0 skip:10 time:449s fi-skl-6700hqtotal:278 pass:261 dwarn:0 dfail:0 fail:0 skip:17 time:572s fi-skl-6700k total:278 pass:256 dwarn:4 dfail:0 fail:0 skip:18 time:457s fi-skl-6770hqtotal:278 pass:268 dwarn:0 dfail:0 fail:0 skip:10 time:496s fi-skl-gvtdvmtotal:278 pass:265 dwarn:0 dfail:0 fail:0 skip:13 time:433s fi-snb-2520m total:278 pass:250 dwarn:0 dfail:0 fail:0 skip:28 time:530s fi-snb-2600 total:278 pass:248 dwarn:1 dfail:0 fail:0 skip:29 time:417s d86f5fa557fdf089bdb5b51f625a7f5967f11015 drm-tip: 2017y-04m-10d-06h-38m-49s UTC integration manifest 2788baf drm/i915: Squash repeated awaits on the same fence 926bcad drm/i915: Redefine ptr_pack_bits() and friends 5a4ed59 drm/i915: Make ptr_unpack_bits() more function-like 71fdbdc drm/i915: Lift timeline ordering to await_dma_fence a64db54 drm/i915: Mark up clflushes as belonging to an unordered timeline == Logs == For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_4454/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Use wait_for_register in lpt_reset_fdi_mphy()
== Series Details == Series: drm/i915: Use wait_for_register in lpt_reset_fdi_mphy() URL : https://patchwork.freedesktop.org/series/22758/ State : success == Summary == Series 22758v1 drm/i915: Use wait_for_register in lpt_reset_fdi_mphy() https://patchwork.freedesktop.org/api/1.0/series/22758/revisions/1/mbox/ Test gem_exec_flush: Subgroup basic-batch-kernel-default-uc: pass -> FAIL (fi-snb-2600) fdo#17 fdo#17 https://bugs.freedesktop.org/show_bug.cgi?id=17 fi-bdw-5557u total:278 pass:267 dwarn:0 dfail:0 fail:0 skip:11 time:427s fi-bdw-gvtdvmtotal:278 pass:256 dwarn:8 dfail:0 fail:0 skip:14 time:428s fi-bsw-n3050 total:278 pass:242 dwarn:0 dfail:0 fail:0 skip:36 time:567s fi-bxt-j4205 total:278 pass:259 dwarn:0 dfail:0 fail:0 skip:19 time:514s fi-bxt-t5700 total:278 pass:258 dwarn:0 dfail:0 fail:0 skip:20 time:544s fi-byt-j1900 total:278 pass:254 dwarn:0 dfail:0 fail:0 skip:24 time:492s fi-byt-n2820 total:278 pass:250 dwarn:0 dfail:0 fail:0 skip:28 time:483s fi-hsw-4770 total:278 pass:262 dwarn:0 dfail:0 fail:0 skip:16 time:407s fi-hsw-4770r total:278 pass:262 dwarn:0 dfail:0 fail:0 skip:16 time:408s fi-ilk-650 total:278 pass:228 dwarn:0 dfail:0 fail:0 skip:50 time:425s fi-ivb-3520m total:278 pass:260 dwarn:0 dfail:0 fail:0 skip:18 time:489s fi-ivb-3770 total:278 pass:260 dwarn:0 dfail:0 fail:0 skip:18 time:470s fi-kbl-7500u total:278 pass:260 dwarn:0 dfail:0 fail:0 skip:18 time:450s fi-kbl-7560u total:278 pass:268 dwarn:0 dfail:0 fail:0 skip:10 time:568s fi-skl-6260u total:278 pass:268 dwarn:0 dfail:0 fail:0 skip:10 time:460s fi-skl-6700hqtotal:278 pass:261 dwarn:0 dfail:0 fail:0 skip:17 time:567s fi-skl-6700k total:278 pass:256 dwarn:4 dfail:0 fail:0 skip:18 time:461s fi-skl-6770hqtotal:278 pass:268 dwarn:0 dfail:0 fail:0 skip:10 time:487s fi-skl-gvtdvmtotal:278 pass:265 dwarn:0 dfail:0 fail:0 skip:13 time:433s fi-snb-2520m total:278 pass:250 dwarn:0 dfail:0 fail:0 skip:28 time:533s fi-snb-2600 total:278 pass:248 dwarn:0 dfail:0 fail:1 skip:29 time:402s d86f5fa557fdf089bdb5b51f625a7f5967f11015 drm-tip: 2017y-04m-10d-06h-38m-49s UTC integration manifest bb5c4e4 drm/i915: Use wait_for_register in lpt_reset_fdi_mphy() == Logs == For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_4453/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v3 13/13] drm/i915: Convert intel_sdvo connector properties to atomic.
SDVO was the last connector that's still using the legacy paths
for properties, and this is with a reason!
This connector implements a lot of properties dynamically,
and some of them shared with the digital connector state,
so sdvo_connector_state subclasses intel_digital_connector_state.
set_property had a lot of validation, but this is handled in the
drm core, so most of the validation can die off. The properties
are written right before enabling the connector, since there is no
good way to update the properties without crtc.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/intel_atomic.c | 40 ---
drivers/gpu/drm/i915/intel_display.c | 37 ---
drivers/gpu/drm/i915/intel_drv.h | 6 -
drivers/gpu/drm/i915/intel_sdvo.c| 538 ++-
4 files changed, 281 insertions(+), 340 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_atomic.c
b/drivers/gpu/drm/i915/intel_atomic.c
index 27d5c4a16bcb..5386107440b5 100644
--- a/drivers/gpu/drm/i915/intel_atomic.c
+++ b/drivers/gpu/drm/i915/intel_atomic.c
@@ -36,46 +36,6 @@
#include "intel_drv.h"
/**
- * intel_connector_atomic_get_property - fetch legacy connector property value
- * @connector: connector to fetch property for
- * @state: state containing the property value
- * @property: property to look up
- * @val: pointer to write property value into
- *
- * The DRM core does not store shadow copies of properties for
- * atomic-capable drivers. This entrypoint is used to fetch
- * the current value of a driver-specific connector property.
- *
- * This is a intermediary solution until all connectors are
- * converted to support full atomic properties.
- */
-int intel_connector_atomic_get_property(struct drm_connector *connector,
- const struct drm_connector_state *state,
- struct drm_property *property,
- uint64_t *val)
-{
- int i;
-
- /*
-* TODO: We only have atomic modeset for planes at the moment, so the
-* crtc/connector code isn't quite ready yet. Until it's ready,
-* continue to look up all property values in the DRM's shadow copy
-* in obj->properties->values[].
-*
-* When the crtc/connector state work matures, this function should
-* be updated to read the values out of the state structure instead.
-*/
- for (i = 0; i < connector->base.properties->count; i++) {
- if (connector->base.properties->properties[i] == property) {
- *val = connector->base.properties->values[i];
- return 0;
- }
- }
-
- return -EINVAL;
-}
-
-/**
* intel_digital_connector_atomic_get_property - hook for
connector->atomic_get_property.
* @connector: Connector to get the property for.
* @state: Connector state to retrieve the property from.
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 5eb4ddb04797..c2c367b90c0a 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -13075,43 +13075,6 @@ static int intel_atomic_commit(struct drm_device *dev,
return 0;
}
-void intel_crtc_restore_mode(struct drm_crtc *crtc)
-{
- struct drm_device *dev = crtc->dev;
- struct drm_atomic_state *state;
- struct drm_crtc_state *crtc_state;
- int ret;
-
- state = drm_atomic_state_alloc(dev);
- if (!state) {
- DRM_DEBUG_KMS("[CRTC:%d:%s] crtc restore failed, out of memory",
- crtc->base.id, crtc->name);
- return;
- }
-
- state->acquire_ctx = crtc->dev->mode_config.acquire_ctx;
-
-retry:
- crtc_state = drm_atomic_get_crtc_state(state, crtc);
- ret = PTR_ERR_OR_ZERO(crtc_state);
- if (!ret) {
- if (!crtc_state->active)
- goto out;
-
- crtc_state->mode_changed = true;
- ret = drm_atomic_commit(state);
- }
-
- if (ret == -EDEADLK) {
- drm_atomic_state_clear(state);
- drm_modeset_backoff(state->acquire_ctx);
- goto retry;
- }
-
-out:
- drm_atomic_state_put(state);
-}
-
static const struct drm_crtc_funcs intel_crtc_funcs = {
.gamma_set = drm_atomic_helper_legacy_gamma_set,
.set_config = drm_atomic_helper_set_config,
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 3d083fb54ec4..1f9e92eb93da 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -1320,7 +1320,6 @@ unsigned int intel_rotation_info_size(const struct
intel_rotation_info *rot_info
bool intel_has_pending_fb_unpin(struct drm_i915_private *dev_priv);
void intel_mark_busy(struct drm_i915_private *dev_priv);
void intel_mark_idle(struct drm_i915_private *dev_priv);
-void intel_crtc_rest
[Intel-gfx] [PATCH v3 09/13] drm/i915: Make intel_dp->has_audio reflect hw state only
Always detect if audio is available during edid detection.
With less magic switching it's easier to convert the dp connector
properties to atomic.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/intel_dp.c | 38 --
1 file changed, 16 insertions(+), 22 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 312a39038dad..3e51202d0338 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -1665,7 +1665,12 @@ intel_dp_compute_config(struct intel_encoder *encoder,
pipe_config->has_pch_encoder = true;
pipe_config->has_drrs = false;
- pipe_config->has_audio = intel_dp->has_audio && port != PORT_A;
+ if (port == PORT_A)
+ pipe_config->has_audio = false;
+ else if (intel_dp->force_audio == HDMI_AUDIO_AUTO)
+ pipe_config->has_audio = intel_dp->has_audio;
+ else
+ pipe_config->has_audio = intel_dp->force_audio == HDMI_AUDIO_ON;
if (is_edp(intel_dp) && intel_connector->panel.fixed_mode) {
intel_fixed_panel_mode(intel_connector->panel.fixed_mode,
@@ -4587,10 +4592,7 @@ intel_dp_set_edid(struct intel_dp *intel_dp)
edid = intel_dp_get_edid(intel_dp);
intel_connector->detect_edid = edid;
- if (intel_dp->force_audio != HDMI_AUDIO_AUTO)
- intel_dp->has_audio = intel_dp->force_audio == HDMI_AUDIO_ON;
- else
- intel_dp->has_audio = drm_detect_monitor_audio(edid);
+ intel_dp->has_audio = drm_detect_monitor_audio(edid);
}
static void
@@ -4787,19 +4789,6 @@ static int intel_dp_get_modes(struct drm_connector
*connector)
return 0;
}
-static bool
-intel_dp_detect_audio(struct drm_connector *connector)
-{
- bool has_audio = false;
- struct edid *edid;
-
- edid = to_intel_connector(connector)->detect_edid;
- if (edid)
- has_audio = drm_detect_monitor_audio(edid);
-
- return has_audio;
-}
-
static int
intel_dp_set_property(struct drm_connector *connector,
struct drm_property *property,
@@ -4817,22 +4806,27 @@ intel_dp_set_property(struct drm_connector *connector,
if (property == dev_priv->force_audio_property) {
int i = val;
- bool has_audio;
+ bool has_audio, old_has_audio;
+ int old_force_audio = intel_dp->force_audio;
if (i == intel_dp->force_audio)
return 0;
+ if (old_force_audio == HDMI_AUDIO_AUTO)
+ old_has_audio = intel_dp->has_audio;
+ else
+ old_has_audio = old_force_audio;
+
intel_dp->force_audio = i;
if (i == HDMI_AUDIO_AUTO)
- has_audio = intel_dp_detect_audio(connector);
+ has_audio = intel_dp->has_audio;
else
has_audio = (i == HDMI_AUDIO_ON);
- if (has_audio == intel_dp->has_audio)
+ if (has_audio == old_has_audio)
return 0;
- intel_dp->has_audio = has_audio;
goto done;
}
--
2.7.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v3 07/13] drm/i915: Convert DSI connector properties to atomic.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/intel_dsi.c | 61 +---
1 file changed, 13 insertions(+), 48 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dsi.c b/drivers/gpu/drm/i915/intel_dsi.c
index e787142025ac..f4517de69ab3 100644
--- a/drivers/gpu/drm/i915/intel_dsi.c
+++ b/drivers/gpu/drm/i915/intel_dsi.c
@@ -311,6 +311,8 @@ static bool intel_dsi_compute_config(struct intel_encoder
*encoder,
struct intel_crtc *crtc = to_intel_crtc(pipe_config->base.crtc);
const struct drm_display_mode *fixed_mode =
intel_connector->panel.fixed_mode;
struct drm_display_mode *adjusted_mode =
&pipe_config->base.adjusted_mode;
+ struct intel_digital_connector_state *intel_conn_state =
+ to_intel_digital_connector_state(conn_state);
int ret;
DRM_DEBUG_KMS("\n");
@@ -320,10 +322,10 @@ static bool intel_dsi_compute_config(struct intel_encoder
*encoder,
if (HAS_GMCH_DISPLAY(dev_priv))
intel_gmch_panel_fitting(crtc, pipe_config,
-
intel_connector->panel.fitting_mode);
+
intel_conn_state->panel.fitting_mode);
else
intel_pch_panel_fitting(crtc, pipe_config,
-
intel_connector->panel.fitting_mode);
+
intel_conn_state->panel.fitting_mode);
}
/* DSI uses short packets for sync events, so clear mode flags for DSI
*/
@@ -1588,48 +1590,6 @@ static int intel_dsi_get_modes(struct drm_connector
*connector)
return 1;
}
-static int intel_dsi_set_property(struct drm_connector *connector,
- struct drm_property *property,
- uint64_t val)
-{
- struct drm_device *dev = connector->dev;
- struct intel_connector *intel_connector = to_intel_connector(connector);
- struct drm_crtc *crtc;
- int ret;
-
- ret = drm_object_property_set_value(&connector->base, property, val);
- if (ret)
- return ret;
-
- if (property == dev->mode_config.scaling_mode_property) {
- if (val == DRM_MODE_SCALE_NONE) {
- DRM_DEBUG_KMS("no scaling not supported\n");
- return -EINVAL;
- }
- if (HAS_GMCH_DISPLAY(to_i915(dev)) &&
- val == DRM_MODE_SCALE_CENTER) {
- DRM_DEBUG_KMS("centering not supported\n");
- return -EINVAL;
- }
-
- if (intel_connector->panel.fitting_mode == val)
- return 0;
-
- intel_connector->panel.fitting_mode = val;
- }
-
- crtc = connector->state->crtc;
- if (crtc && crtc->state->enable) {
- /*
-* If the CRTC is enabled, the display will be changed
-* according to the new panel fitting mode.
-*/
- intel_crtc_restore_mode(crtc);
- }
-
- return 0;
-}
-
static void intel_dsi_connector_destroy(struct drm_connector *connector)
{
struct intel_connector *intel_connector = to_intel_connector(connector);
@@ -1658,6 +1618,7 @@ static const struct drm_encoder_funcs intel_dsi_funcs = {
static const struct drm_connector_helper_funcs
intel_dsi_connector_helper_funcs = {
.get_modes = intel_dsi_get_modes,
.mode_valid = intel_dsi_mode_valid,
+ .atomic_check = intel_digital_connector_atomic_check,
};
static const struct drm_connector_funcs intel_dsi_connector_funcs = {
@@ -1666,10 +1627,11 @@ static const struct drm_connector_funcs
intel_dsi_connector_funcs = {
.early_unregister = intel_connector_unregister,
.destroy = intel_dsi_connector_destroy,
.fill_modes = drm_helper_probe_single_connector_modes,
- .set_property = intel_dsi_set_property,
- .atomic_get_property = intel_connector_atomic_get_property,
+ .set_property = drm_atomic_helper_connector_set_property,
+ .atomic_get_property = intel_digital_connector_atomic_get_property,
+ .atomic_set_property = intel_digital_connector_atomic_set_property,
.atomic_destroy_state = drm_atomic_helper_connector_destroy_state,
- .atomic_duplicate_state = drm_atomic_helper_connector_duplicate_state,
+ .atomic_duplicate_state = intel_digital_connector_duplicate_state,
};
static void intel_dsi_add_properties(struct intel_connector *connector)
@@ -1677,11 +1639,14 @@ static void intel_dsi_add_properties(struct
intel_connector *connector)
struct drm_device *dev = connector->base.dev;
if (connector->panel.fixed_mode) {
+ struct intel_digital_connector_state *conn_state =
+ to_intel_digital_connector_state(connector->base.state)
[Intel-gfx] [PATCH v3 12/13] drm/i915: Handle force_audio correctly in intel_sdvo
Do the same as other connectors, attempt to detect hdmi audio in
the detect() callback, and only use the force_audio property as
override. Compute has_audio in pipe_config, and use that value
instead of the probed value directly.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/intel_sdvo.c | 51 ++-
1 file changed, 18 insertions(+), 33 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_sdvo.c
b/drivers/gpu/drm/i915/intel_sdvo.c
index 816a6f5a3fd9..9855e4d48542 100644
--- a/drivers/gpu/drm/i915/intel_sdvo.c
+++ b/drivers/gpu/drm/i915/intel_sdvo.c
@@ -1127,6 +1127,8 @@ static bool intel_sdvo_compute_config(struct
intel_encoder *encoder,
struct drm_connector_state *conn_state)
{
struct intel_sdvo *intel_sdvo = to_sdvo(encoder);
+ struct intel_sdvo_connector *intel_sdvo_connector =
+ to_intel_sdvo_connector(conn_state->connector);
struct drm_display_mode *adjusted_mode =
&pipe_config->base.adjusted_mode;
struct drm_display_mode *mode = &pipe_config->base.mode;
@@ -1165,7 +1167,12 @@ static bool intel_sdvo_compute_config(struct
intel_encoder *encoder,
pipe_config->pixel_multiplier =
intel_sdvo_get_pixel_multiplier(adjusted_mode);
- pipe_config->has_hdmi_sink = intel_sdvo->has_hdmi_monitor;
+ if (intel_sdvo_connector->force_audio != HDMI_AUDIO_OFF_DVI)
+ pipe_config->has_hdmi_sink = intel_sdvo->has_hdmi_monitor;
+
+ if (intel_sdvo_connector->force_audio == HDMI_AUDIO_ON ||
+ (intel_sdvo_connector->force_audio == HDMI_AUDIO_AUTO &&
intel_sdvo->has_hdmi_audio))
+ pipe_config->has_audio = true;
if (intel_sdvo->color_range_auto) {
/* See CEA-861-E - 5.1 Default Encoding Parameters */
@@ -1290,7 +1297,7 @@ static void intel_sdvo_pre_enable(struct intel_encoder
*intel_encoder,
else
sdvox |= SDVO_PIPE_SEL(crtc->pipe);
- if (intel_sdvo->has_hdmi_audio)
+ if (crtc_state->has_audio)
sdvox |= SDVO_AUDIO_ENABLE;
if (INTEL_GEN(dev_priv) >= 4) {
@@ -1699,12 +1706,6 @@ intel_sdvo_tmds_sink_detect(struct drm_connector
*connector)
kfree(edid);
}
- if (status == connector_status_connected) {
- struct intel_sdvo_connector *intel_sdvo_connector =
to_intel_sdvo_connector(connector);
- if (intel_sdvo_connector->force_audio != HDMI_AUDIO_AUTO)
- intel_sdvo->has_hdmi_audio =
(intel_sdvo_connector->force_audio == HDMI_AUDIO_ON);
- }
-
return status;
}
@@ -1983,23 +1984,6 @@ static void intel_sdvo_destroy(struct drm_connector
*connector)
kfree(intel_sdvo_connector);
}
-static bool intel_sdvo_detect_hdmi_audio(struct drm_connector *connector)
-{
- struct intel_sdvo *intel_sdvo = intel_attached_sdvo(connector);
- struct edid *edid;
- bool has_audio = false;
-
- if (!intel_sdvo->is_hdmi)
- return false;
-
- edid = intel_sdvo_get_edid(connector);
- if (edid != NULL && edid->input & DRM_EDID_INPUT_DIGITAL)
- has_audio = drm_detect_monitor_audio(edid);
- kfree(edid);
-
- return has_audio;
-}
-
static int
intel_sdvo_set_property(struct drm_connector *connector,
struct drm_property *property,
@@ -2018,22 +2002,23 @@ intel_sdvo_set_property(struct drm_connector *connector,
if (property == dev_priv->force_audio_property) {
int i = val;
- bool has_audio;
-
- if (i == intel_sdvo_connector->force_audio)
- return 0;
+ bool has_audio, old_audio;
- intel_sdvo_connector->force_audio = i;
+ if (intel_sdvo_connector->force_audio == HDMI_AUDIO_AUTO)
+ old_audio = intel_sdvo->has_hdmi_audio;
+ else
+ old_audio = intel_sdvo_connector->force_audio ==
HDMI_AUDIO_ON;
if (i == HDMI_AUDIO_AUTO)
- has_audio = intel_sdvo_detect_hdmi_audio(connector);
+ has_audio = intel_sdvo->has_hdmi_audio;
else
has_audio = (i == HDMI_AUDIO_ON);
- if (has_audio == intel_sdvo->has_hdmi_audio)
+ intel_sdvo_connector->force_audio = i;
+
+ if (has_audio == old_audio)
return 0;
- intel_sdvo->has_hdmi_audio = has_audio;
goto done;
}
--
2.7.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v3 08/13] drm/i915: Convert LVDS connector properties to atomic.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/intel_lvds.c | 60 +--
1 file changed, 19 insertions(+), 41 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_lvds.c
b/drivers/gpu/drm/i915/intel_lvds.c
index 919d84290774..6bed3827411e 100644
--- a/drivers/gpu/drm/i915/intel_lvds.c
+++ b/drivers/gpu/drm/i915/intel_lvds.c
@@ -401,6 +401,9 @@ static bool intel_lvds_compute_config(struct intel_encoder
*intel_encoder,
&lvds_encoder->attached_connector->base;
struct drm_display_mode *adjusted_mode =
&pipe_config->base.adjusted_mode;
struct intel_crtc *intel_crtc = to_intel_crtc(pipe_config->base.crtc);
+ struct intel_digital_connector_state *intel_conn_state =
+ to_intel_digital_connector_state(conn_state);
+
unsigned int lvds_bpp;
/* Should never happen!! */
@@ -433,10 +436,10 @@ static bool intel_lvds_compute_config(struct
intel_encoder *intel_encoder,
pipe_config->has_pch_encoder = true;
intel_pch_panel_fitting(intel_crtc, pipe_config,
- intel_connector->panel.fitting_mode);
+ intel_conn_state->panel.fitting_mode);
} else {
intel_gmch_panel_fitting(intel_crtc, pipe_config,
-intel_connector->panel.fitting_mode);
+intel_conn_state->panel.fitting_mode);
}
@@ -598,56 +601,24 @@ static void intel_lvds_destroy(struct drm_connector
*connector)
kfree(connector);
}
-static int intel_lvds_set_property(struct drm_connector *connector,
- struct drm_property *property,
- uint64_t value)
-{
- struct intel_connector *intel_connector = to_intel_connector(connector);
- struct drm_device *dev = connector->dev;
-
- if (property == dev->mode_config.scaling_mode_property) {
- struct drm_crtc *crtc;
-
- if (value == DRM_MODE_SCALE_NONE) {
- DRM_DEBUG_KMS("no scaling not supported\n");
- return -EINVAL;
- }
-
- if (intel_connector->panel.fitting_mode == value) {
- /* the LVDS scaling property is not changed */
- return 0;
- }
- intel_connector->panel.fitting_mode = value;
-
- crtc = intel_attached_encoder(connector)->base.crtc;
- if (crtc && crtc->state->enable) {
- /*
-* If the CRTC is enabled, the display will be changed
-* according to the new panel fitting mode.
-*/
- intel_crtc_restore_mode(crtc);
- }
- }
-
- return 0;
-}
-
static const struct drm_connector_helper_funcs
intel_lvds_connector_helper_funcs = {
.get_modes = intel_lvds_get_modes,
.mode_valid = intel_lvds_mode_valid,
+ .atomic_check = intel_digital_connector_atomic_check,
};
static const struct drm_connector_funcs intel_lvds_connector_funcs = {
.dpms = drm_atomic_helper_connector_dpms,
.detect = intel_lvds_detect,
.fill_modes = drm_helper_probe_single_connector_modes,
- .set_property = intel_lvds_set_property,
- .atomic_get_property = intel_connector_atomic_get_property,
+ .set_property = drm_atomic_helper_connector_set_property,
+ .atomic_get_property = intel_digital_connector_atomic_get_property,
+ .atomic_set_property = intel_digital_connector_atomic_set_property,
.late_register = intel_connector_register,
.early_unregister = intel_connector_unregister,
.destroy = intel_lvds_destroy,
.atomic_destroy_state = drm_atomic_helper_connector_destroy_state,
- .atomic_duplicate_state = drm_atomic_helper_connector_duplicate_state,
+ .atomic_duplicate_state = intel_digital_connector_duplicate_state,
};
static const struct drm_encoder_funcs intel_lvds_enc_funcs = {
@@ -988,6 +959,8 @@ void intel_lvds_init(struct drm_i915_private *dev_priv)
u32 lvds;
int pipe;
u8 pin;
+ unsigned allowed_fittings;
+ struct intel_digital_connector_state *conn_state;
if (!intel_lvds_supported(dev_priv))
return;
@@ -1087,7 +1060,8 @@ void intel_lvds_init(struct drm_i915_private *dev_priv)
drm_object_attach_property(&connector->base,
dev->mode_config.scaling_mode_property,
DRM_MODE_SCALE_ASPECT);
- intel_connector->panel.fitting_mode = DRM_MODE_SCALE_ASPECT;
+ conn_state = to_intel_digital_connector_state(connector->state);
+ conn_state->panel.fitting_mode = DRM_MODE_SCALE_ASPECT;
intel_lvds_pps_get_hw_state(dev_priv, &lvds_e
[Intel-gfx] [PATCH v3 02/13] drm/i915: Convert intel_tv connector properties to atomic, v5.
intel_tv has properties that are handled in the atomic core, but
needs a modeset to update the properties inside the connector.
The detect(), get_mode() and mode_valid() probe callbacks also
depend on the connector state, which made this a good connector
to convert first. It helped find all the issues when converting
connectors to atomic.
Because of these requirements, connector atomic_check() was added
and connection_mutex is held during probing. The diffstat looks
more favorable now. :)
Changes since v1:
- Add intel_encoder->swap_state to allow updating connector state.
- Add intel_tv->format for detect_mode and mode_valid, updated on atomic commit.
Changes since v2:
- Fix typo in tv_choose_preferred modes function name.
- Assignment of tv properties is done in core, so intel_tv only needs
a atomic_check function. Thanks Ville!
Changes since v3:
- connection_mutex is now held in mode_valid() and get_modes(),
this removes the need for caching parts of the connector_state.
Changes since v4:
- Use the new atomic connector check function.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/intel_tv.c | 175 +++-
1 file changed, 63 insertions(+), 112 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_tv.c b/drivers/gpu/drm/i915/intel_tv.c
index 3af857a75fab..784df024e230 100644
--- a/drivers/gpu/drm/i915/intel_tv.c
+++ b/drivers/gpu/drm/i915/intel_tv.c
@@ -48,8 +48,6 @@ struct intel_tv {
struct intel_encoder base;
int type;
- const char *tv_format;
- int margin[4];
};
struct video_levels {
@@ -840,32 +838,18 @@ intel_disable_tv(struct intel_encoder *encoder,
I915_WRITE(TV_CTL, I915_READ(TV_CTL) & ~TV_ENC_ENABLE);
}
-static const struct tv_mode *
-intel_tv_mode_lookup(const char *tv_format)
+static const struct tv_mode *intel_tv_mode_find(struct drm_connector_state
*conn_state)
{
- int i;
-
- for (i = 0; i < ARRAY_SIZE(tv_modes); i++) {
- const struct tv_mode *tv_mode = &tv_modes[i];
+ int format = conn_state->tv.mode;
- if (!strcmp(tv_format, tv_mode->name))
- return tv_mode;
- }
- return NULL;
-}
-
-static const struct tv_mode *
-intel_tv_mode_find(struct intel_tv *intel_tv)
-{
- return intel_tv_mode_lookup(intel_tv->tv_format);
+ return &tv_modes[format];
}
static enum drm_mode_status
intel_tv_mode_valid(struct drm_connector *connector,
struct drm_display_mode *mode)
{
- struct intel_tv *intel_tv = intel_attached_tv(connector);
- const struct tv_mode *tv_mode = intel_tv_mode_find(intel_tv);
+ const struct tv_mode *tv_mode = intel_tv_mode_find(connector->state);
int max_dotclk = to_i915(connector->dev)->max_dotclk_freq;
if (mode->clock > max_dotclk)
@@ -892,8 +876,7 @@ intel_tv_compute_config(struct intel_encoder *encoder,
struct intel_crtc_state *pipe_config,
struct drm_connector_state *conn_state)
{
- struct intel_tv *intel_tv = enc_to_tv(encoder);
- const struct tv_mode *tv_mode = intel_tv_mode_find(intel_tv);
+ const struct tv_mode *tv_mode = intel_tv_mode_find(conn_state);
if (!tv_mode)
return false;
@@ -999,7 +982,7 @@ static void intel_tv_pre_enable(struct intel_encoder
*encoder,
struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
struct intel_crtc *intel_crtc = to_intel_crtc(encoder->base.crtc);
struct intel_tv *intel_tv = enc_to_tv(encoder);
- const struct tv_mode *tv_mode = intel_tv_mode_find(intel_tv);
+ const struct tv_mode *tv_mode = intel_tv_mode_find(conn_state);
u32 tv_ctl;
u32 scctl1, scctl2, scctl3;
int i, j;
@@ -1102,12 +1085,12 @@ static void intel_tv_pre_enable(struct intel_encoder
*encoder,
else
ysize = 2*tv_mode->nbr_end + 1;
- xpos += intel_tv->margin[TV_MARGIN_LEFT];
- ypos += intel_tv->margin[TV_MARGIN_TOP];
- xsize -= (intel_tv->margin[TV_MARGIN_LEFT] +
- intel_tv->margin[TV_MARGIN_RIGHT]);
- ysize -= (intel_tv->margin[TV_MARGIN_TOP] +
- intel_tv->margin[TV_MARGIN_BOTTOM]);
+ xpos += conn_state->tv.margins.left;
+ ypos += conn_state->tv.margins.top;
+ xsize -= (conn_state->tv.margins.left +
+ conn_state->tv.margins.right);
+ ysize -= (conn_state->tv.margins.top +
+ conn_state->tv.margins.bottom);
I915_WRITE(TV_WIN_POS, (xpos<<16)|ypos);
I915_WRITE(TV_WIN_SIZE, (xsize<<16)|ysize);
@@ -1255,7 +1238,7 @@ intel_tv_detect_type(struct intel_tv *intel_tv,
static void intel_tv_find_better_format(struct drm_connector *connector)
{
struct intel_tv *intel_tv = intel_attached_tv(connector);
- const struct tv_mode *tv_mode = intel_tv_mode_find(intel_tv);
+ const struct tv_mode *tv_mode = intel_tv_mode_f
[Intel-gfx] [PATCH v3 06/13] drm/i915: Add plumbing for digital connector state.
Some atomic properties are common between the various kinds of
connectors, for example a lot of them use panel fitting mode.
It makes sense to put a lot of it in a common place, so each
connector can use it while they're being converted.
Implement the properties required for the connectors:
- scaling mode property
- force audio property
- broadcast rgb
- aspect ratio
While at it, make clear that intel_digital_connector_atomic_get_property
is a hack that has to be removed when all connector properties
are converted to atomic.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/intel_atomic.c | 175 +--
drivers/gpu/drm/i915/intel_display.c | 14 ++-
drivers/gpu/drm/i915/intel_dp.c | 2 +-
drivers/gpu/drm/i915/intel_drv.h | 32 ++-
drivers/gpu/drm/i915/intel_dsi.c | 2 +-
drivers/gpu/drm/i915/intel_dvo.c | 2 +-
drivers/gpu/drm/i915/intel_lvds.c| 2 +-
drivers/gpu/drm/i915/intel_panel.c | 4 +-
8 files changed, 218 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_atomic.c
b/drivers/gpu/drm/i915/intel_atomic.c
index 50fb1f76cc5f..27d5c4a16bcb 100644
--- a/drivers/gpu/drm/i915/intel_atomic.c
+++ b/drivers/gpu/drm/i915/intel_atomic.c
@@ -36,7 +36,7 @@
#include "intel_drv.h"
/**
- * intel_connector_atomic_get_property - fetch connector property value
+ * intel_connector_atomic_get_property - fetch legacy connector property value
* @connector: connector to fetch property for
* @state: state containing the property value
* @property: property to look up
@@ -45,12 +45,14 @@
* The DRM core does not store shadow copies of properties for
* atomic-capable drivers. This entrypoint is used to fetch
* the current value of a driver-specific connector property.
+ *
+ * This is a intermediary solution until all connectors are
+ * converted to support full atomic properties.
*/
-int
-intel_connector_atomic_get_property(struct drm_connector *connector,
- const struct drm_connector_state *state,
- struct drm_property *property,
- uint64_t *val)
+int intel_connector_atomic_get_property(struct drm_connector *connector,
+ const struct drm_connector_state *state,
+ struct drm_property *property,
+ uint64_t *val)
{
int i;
@@ -73,7 +75,166 @@ intel_connector_atomic_get_property(struct drm_connector
*connector,
return -EINVAL;
}
-/*
+/**
+ * intel_digital_connector_atomic_get_property - hook for
connector->atomic_get_property.
+ * @connector: Connector to get the property for.
+ * @state: Connector state to retrieve the property from.
+ * @property: Property to retrieve.
+ * @val: Return value for the property.
+ *
+ * Returns the atomic property value for a digital connector.
+ */
+int intel_digital_connector_atomic_get_property(struct drm_connector
*connector,
+ const struct
drm_connector_state *state,
+ struct drm_property *property,
+ uint64_t *val)
+{
+ struct drm_device *dev = connector->dev;
+ struct drm_i915_private *dev_priv = to_i915(dev);
+ struct intel_digital_connector_state *intel_conn_state =
+ to_intel_digital_connector_state(state);
+
+ if (property == dev->mode_config.scaling_mode_property)
+ *val = intel_conn_state->panel.fitting_mode;
+ else if (property == dev_priv->force_audio_property)
+ *val = intel_conn_state->force_audio;
+ else if (property == dev_priv->broadcast_rgb_property)
+ *val = intel_conn_state->broadcast_rgb;
+ else if (property == dev->mode_config.aspect_ratio_property) {
+ switch (intel_conn_state->aspect_ratio) {
+ case HDMI_PICTURE_ASPECT_NONE: *val =
DRM_MODE_PICTURE_ASPECT_NONE; break;
+ case HDMI_PICTURE_ASPECT_4_3: *val =
DRM_MODE_PICTURE_ASPECT_4_3; break;
+ case HDMI_PICTURE_ASPECT_16_9: *val =
DRM_MODE_PICTURE_ASPECT_16_9; break;
+ default:
+ MISSING_CASE(intel_conn_state->aspect_ratio);
+ return -EINVAL;
+ }
+ } else {
+ DRM_DEBUG_ATOMIC("Unknown property %s\n", property->name);
+ return -EINVAL;
+ }
+
+ return 0;
+}
+
+/**
+ * intel_digital_connector_atomic_set_property - hook for
connector->atomic_set_property.
+ * @connector: Connector to set the property for.
+ * @state: Connector state to set the property on.
+ * @property: Property to set.
+ * @val: New value for the property.
+ *
+ * Sets the atomic property value for a digital connector.
+ */
+int intel_digital_connector_atomic_set_property(struct drm_connector
*
[Intel-gfx] [PATCH v3 10/13] drm/i915: Convert intel_dp properties to atomic.
intel_dp supports 3 properties, scaling mode, broadcast rgb and
force_audio. intel_digital_connector handles the plumbing,
so we only have to hook this up in compute_config and init.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/intel_dp.c | 138 ---
drivers/gpu/drm/i915/intel_drv.h | 3 -
2 files changed, 26 insertions(+), 115 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 3e51202d0338..a146090b651b 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -1641,6 +1641,8 @@ intel_dp_compute_config(struct intel_encoder *encoder,
enum port port = dp_to_dig_port(intel_dp)->port;
struct intel_crtc *intel_crtc = to_intel_crtc(pipe_config->base.crtc);
struct intel_connector *intel_connector = intel_dp->attached_connector;
+ struct intel_digital_connector_state *intel_conn_state =
+ to_intel_digital_connector_state(conn_state);
int lane_count, clock;
int min_lane_count = 1;
int max_lane_count = intel_dp_max_lane_count(intel_dp);
@@ -1667,10 +1669,10 @@ intel_dp_compute_config(struct intel_encoder *encoder,
pipe_config->has_drrs = false;
if (port == PORT_A)
pipe_config->has_audio = false;
- else if (intel_dp->force_audio == HDMI_AUDIO_AUTO)
+ else if (intel_conn_state->force_audio == HDMI_AUDIO_AUTO)
pipe_config->has_audio = intel_dp->has_audio;
else
- pipe_config->has_audio = intel_dp->force_audio == HDMI_AUDIO_ON;
+ pipe_config->has_audio = intel_conn_state->force_audio ==
HDMI_AUDIO_ON;
if (is_edp(intel_dp) && intel_connector->panel.fixed_mode) {
intel_fixed_panel_mode(intel_connector->panel.fixed_mode,
@@ -1685,10 +1687,10 @@ intel_dp_compute_config(struct intel_encoder *encoder,
if (HAS_GMCH_DISPLAY(dev_priv))
intel_gmch_panel_fitting(intel_crtc, pipe_config,
-
intel_connector->panel.fitting_mode);
+
intel_conn_state->panel.fitting_mode);
else
intel_pch_panel_fitting(intel_crtc, pipe_config,
-
intel_connector->panel.fitting_mode);
+
intel_conn_state->panel.fitting_mode);
}
if (adjusted_mode->flags & DRM_MODE_FLAG_DBLCLK)
@@ -1755,7 +1757,7 @@ intel_dp_compute_config(struct intel_encoder *encoder,
return false;
found:
- if (intel_dp->color_range_auto) {
+ if (intel_conn_state->broadcast_rgb == INTEL_BROADCAST_RGB_AUTO) {
/*
* See:
* CEA-861-E - 5.1 Default Encoding Parameters
@@ -1767,7 +1769,7 @@ intel_dp_compute_config(struct intel_encoder *encoder,
HDMI_QUANTIZATION_RANGE_LIMITED;
} else {
pipe_config->limited_color_range =
- intel_dp->limited_color_range;
+ intel_conn_state->broadcast_rgb ==
INTEL_BROADCAST_RGB_LIMITED;
}
pipe_config->lane_count = lane_count;
@@ -4790,104 +4792,6 @@ static int intel_dp_get_modes(struct drm_connector
*connector)
}
static int
-intel_dp_set_property(struct drm_connector *connector,
- struct drm_property *property,
- uint64_t val)
-{
- struct drm_i915_private *dev_priv = to_i915(connector->dev);
- struct intel_connector *intel_connector = to_intel_connector(connector);
- struct intel_encoder *intel_encoder = intel_attached_encoder(connector);
- struct intel_dp *intel_dp = enc_to_intel_dp(&intel_encoder->base);
- int ret;
-
- ret = drm_object_property_set_value(&connector->base, property, val);
- if (ret)
- return ret;
-
- if (property == dev_priv->force_audio_property) {
- int i = val;
- bool has_audio, old_has_audio;
- int old_force_audio = intel_dp->force_audio;
-
- if (i == intel_dp->force_audio)
- return 0;
-
- if (old_force_audio == HDMI_AUDIO_AUTO)
- old_has_audio = intel_dp->has_audio;
- else
- old_has_audio = old_force_audio;
-
- intel_dp->force_audio = i;
-
- if (i == HDMI_AUDIO_AUTO)
- has_audio = intel_dp->has_audio;
- else
- has_audio = (i == HDMI_AUDIO_ON);
-
- if (has_audio == old_has_audio)
- return 0;
-
- goto done;
- }
-
- if (property == dev_priv->broadcast_rgb_property) {
- bool old_auto = intel_dp->color_range_auto;
- bool old_range = intel_dp->li
[Intel-gfx] [PATCH v3 00/13] drm/i915: Convert connector properties to atomic.
Now that we solved all outstanding issues I think it's time to resubmit this. We now have a connector atomic_check() function which is great for validating properties, and connection_mutex that's held during the validation callbacks. This will make all connector properties work correctly when using the atomic ioctl to update the properties. This patch requires a backmerge of drm-misc to apply on dinq, but for reviewing it can be applied on top of drm-tip. :) Maarten Lankhorst (13): drm/i915: Remove unused members from intel_tv.c drm/i915: Convert intel_tv connector properties to atomic, v5. drm/i915: Convert intel_dp_mst connector properties to atomic. drm/i915: Convert intel_crt connector properties to atomic. drm/i915: Convert intel DVO connector to atomic drm/i915: Add plumbing for digital connector state. drm/i915: Convert DSI connector properties to atomic. drm/i915: Convert LVDS connector properties to atomic. drm/i915: Make intel_dp->has_audio reflect hw state only drm/i915: Convert intel_dp properties to atomic. drm/i915: Convert intel_hdmi connector properties to atomic drm/i915: Handle force_audio correctly in intel_sdvo drm/i915: Convert intel_sdvo connector properties to atomic. drivers/gpu/drm/i915/intel_atomic.c | 177 +-- drivers/gpu/drm/i915/intel_crt.c | 10 +- drivers/gpu/drm/i915/intel_display.c | 51 +--- drivers/gpu/drm/i915/intel_dp.c | 154 ++ drivers/gpu/drm/i915/intel_dp_mst.c | 11 +- drivers/gpu/drm/i915/intel_drv.h | 43 ++- drivers/gpu/drm/i915/intel_dsi.c | 63 +--- drivers/gpu/drm/i915/intel_dvo.c | 4 +- drivers/gpu/drm/i915/intel_hdmi.c| 164 +++--- drivers/gpu/drm/i915/intel_lvds.c| 60 ++-- drivers/gpu/drm/i915/intel_panel.c | 4 +- drivers/gpu/drm/i915/intel_sdvo.c| 561 ++- drivers/gpu/drm/i915/intel_tv.c | 208 - 13 files changed, 644 insertions(+), 866 deletions(-) -- 2.7.4 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v3 04/13] drm/i915: Convert intel_crt connector properties to atomic.
No properties are supported, so just use the helper and reject
everything.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/intel_crt.c | 10 +-
1 file changed, 1 insertion(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_crt.c b/drivers/gpu/drm/i915/intel_crt.c
index 2797bf37c3ac..84a1f5e85153 100644
--- a/drivers/gpu/drm/i915/intel_crt.c
+++ b/drivers/gpu/drm/i915/intel_crt.c
@@ -777,13 +777,6 @@ static int intel_crt_get_modes(struct drm_connector
*connector)
return ret;
}
-static int intel_crt_set_property(struct drm_connector *connector,
- struct drm_property *property,
- uint64_t value)
-{
- return 0;
-}
-
void intel_crt_reset(struct drm_encoder *encoder)
{
struct drm_i915_private *dev_priv = to_i915(encoder->dev);
@@ -814,10 +807,9 @@ static const struct drm_connector_funcs
intel_crt_connector_funcs = {
.late_register = intel_connector_register,
.early_unregister = intel_connector_unregister,
.destroy = intel_crt_destroy,
- .set_property = intel_crt_set_property,
+ .set_property = drm_atomic_helper_connector_set_property,
.atomic_destroy_state = drm_atomic_helper_connector_destroy_state,
.atomic_duplicate_state = drm_atomic_helper_connector_duplicate_state,
- .atomic_get_property = intel_connector_atomic_get_property,
};
static const struct drm_connector_helper_funcs
intel_crt_connector_helper_funcs = {
--
2.7.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v3 03/13] drm/i915: Convert intel_dp_mst connector properties to atomic.
MST doesn't support setting any properties, but it should still
use the atomic helper for setting properties.
Only path and tile properties are supported (read-only).
Those are immutable, and handled by drm core.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/intel_dp_mst.c | 11 +--
1 file changed, 1 insertion(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp_mst.c
b/drivers/gpu/drm/i915/intel_dp_mst.c
index c1f62eb07c07..3fc345a76e6f 100644
--- a/drivers/gpu/drm/i915/intel_dp_mst.c
+++ b/drivers/gpu/drm/i915/intel_dp_mst.c
@@ -294,14 +294,6 @@ intel_dp_mst_detect(struct drm_connector *connector, bool
force)
return drm_dp_mst_detect_port(connector, &intel_dp->mst_mgr,
intel_connector->port);
}
-static int
-intel_dp_mst_set_property(struct drm_connector *connector,
- struct drm_property *property,
- uint64_t val)
-{
- return 0;
-}
-
static void
intel_dp_mst_connector_destroy(struct drm_connector *connector)
{
@@ -318,8 +310,7 @@ static const struct drm_connector_funcs
intel_dp_mst_connector_funcs = {
.dpms = drm_atomic_helper_connector_dpms,
.detect = intel_dp_mst_detect,
.fill_modes = drm_helper_probe_single_connector_modes,
- .set_property = intel_dp_mst_set_property,
- .atomic_get_property = intel_connector_atomic_get_property,
+ .set_property = drm_atomic_helper_connector_set_property,
.late_register = intel_connector_register,
.early_unregister = intel_connector_unregister,
.destroy = intel_dp_mst_connector_destroy,
--
2.7.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v3 11/13] drm/i915: Convert intel_hdmi connector properties to atomic
intel_hdmi supports 3 properties, force_audio, broadcast rgb and
scaling mode. The last one is only created for eDP, so the is_eDP
in set_property is not required.
panel fitting and broadcast rgb are straightforward and only requires
changing compute_config.
force_audio is also used to force DVI mode, which means changes to
compute_config and mode_valid. mode_valid is called with
connection_mutex held, so it can safely dereference connector->state.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/intel_drv.h | 4 -
drivers/gpu/drm/i915/intel_hdmi.c | 164 --
2 files changed, 34 insertions(+), 134 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index afda03e0bb02..3d083fb54ec4 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -877,13 +877,9 @@ struct intel_hdmi {
enum drm_dp_dual_mode_type type;
int max_tmds_clock;
} dp_dual_mode;
- bool limited_color_range;
- bool color_range_auto;
bool has_hdmi_sink;
bool has_audio;
- enum hdmi_force_audio force_audio;
bool rgb_quant_range_selectable;
- enum hdmi_picture_aspect aspect_ratio;
struct intel_connector *attached_connector;
void (*write_infoframe)(struct drm_encoder *encoder,
const struct intel_crtc_state *crtc_state,
diff --git a/drivers/gpu/drm/i915/intel_hdmi.c
b/drivers/gpu/drm/i915/intel_hdmi.c
index 6efc3cb8c471..419c8aa52b0f 100644
--- a/drivers/gpu/drm/i915/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/intel_hdmi.c
@@ -1218,7 +1218,8 @@ static int intel_hdmi_source_max_tmds_clock(struct
drm_i915_private *dev_priv)
}
static int hdmi_port_clock_limit(struct intel_hdmi *hdmi,
-bool respect_downstream_limits)
+bool respect_downstream_limits,
+bool force_dvi)
{
struct drm_device *dev = intel_hdmi_to_dev(hdmi);
int max_tmds_clock = intel_hdmi_source_max_tmds_clock(to_i915(dev));
@@ -1234,7 +1235,7 @@ static int hdmi_port_clock_limit(struct intel_hdmi *hdmi,
if (info->max_tmds_clock)
max_tmds_clock = min(max_tmds_clock,
info->max_tmds_clock);
- else if (!hdmi->has_hdmi_sink)
+ else if (!hdmi->has_hdmi_sink || force_dvi)
max_tmds_clock = min(max_tmds_clock, 165000);
}
@@ -1243,13 +1244,14 @@ static int hdmi_port_clock_limit(struct intel_hdmi
*hdmi,
static enum drm_mode_status
hdmi_port_clock_valid(struct intel_hdmi *hdmi,
- int clock, bool respect_downstream_limits)
+ int clock, bool respect_downstream_limits,
+ bool force_dvi)
{
struct drm_i915_private *dev_priv = to_i915(intel_hdmi_to_dev(hdmi));
if (clock < 25000)
return MODE_CLOCK_LOW;
- if (clock > hdmi_port_clock_limit(hdmi, respect_downstream_limits))
+ if (clock > hdmi_port_clock_limit(hdmi, respect_downstream_limits,
force_dvi))
return MODE_CLOCK_HIGH;
/* BXT DPLL can't generate 223-240 MHz */
@@ -1273,6 +1275,8 @@ intel_hdmi_mode_valid(struct drm_connector *connector,
enum drm_mode_status status;
int clock;
int max_dotclk = to_i915(connector->dev)->max_dotclk_freq;
+ bool force_dvi =
+
READ_ONCE(to_intel_digital_connector_state(connector->state)->force_audio) ==
HDMI_AUDIO_OFF_DVI;
if (mode->flags & DRM_MODE_FLAG_DBLSCAN)
return MODE_NO_DBLESCAN;
@@ -1289,11 +1293,11 @@ intel_hdmi_mode_valid(struct drm_connector *connector,
clock *= 2;
/* check if we can do 8bpc */
- status = hdmi_port_clock_valid(hdmi, clock, true);
+ status = hdmi_port_clock_valid(hdmi, clock, true, force_dvi);
/* if we can't do 8bpc we may still be able to do 12bpc */
- if (!HAS_GMCH_DISPLAY(dev_priv) && status != MODE_OK)
- status = hdmi_port_clock_valid(hdmi, clock * 3 / 2, true);
+ if (!HAS_GMCH_DISPLAY(dev_priv) && status != MODE_OK &&
hdmi->has_hdmi_sink && !force_dvi)
+ status = hdmi_port_clock_valid(hdmi, clock * 3 / 2, true,
force_dvi);
return status;
}
@@ -1338,16 +1342,19 @@ bool intel_hdmi_compute_config(struct intel_encoder
*encoder,
struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
struct drm_display_mode *adjusted_mode =
&pipe_config->base.adjusted_mode;
struct drm_scdc *scdc = &conn_state->connector->display_info.hdmi.scdc;
+ struct intel_digital_connector_state *intel_conn_state =
+ to_intel_digital_connector_state(conn_state);
int clock_8bpc = pipe_config->base.adjusted_mode.crtc_clock;
int clock_12bpc = clock_
[Intel-gfx] [PATCH v3 05/13] drm/i915: Convert intel DVO connector to atomic
No properties are supported, so just use the helper and reject everything.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/intel_dvo.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_dvo.c b/drivers/gpu/drm/i915/intel_dvo.c
index 6025839ed3b7..c1544a53095d 100644
--- a/drivers/gpu/drm/i915/intel_dvo.c
+++ b/drivers/gpu/drm/i915/intel_dvo.c
@@ -350,7 +350,7 @@ static const struct drm_connector_funcs
intel_dvo_connector_funcs = {
.early_unregister = intel_connector_unregister,
.destroy = intel_dvo_destroy,
.fill_modes = drm_helper_probe_single_connector_modes,
- .atomic_get_property = intel_connector_atomic_get_property,
+ .set_property = drm_atomic_helper_connector_set_property,
.atomic_destroy_state = drm_atomic_helper_connector_destroy_state,
.atomic_duplicate_state = drm_atomic_helper_connector_duplicate_state,
};
--
2.7.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v3 01/13] drm/i915: Remove unused members from intel_tv.c
They have been unused since 2010, after the code for
intel_tv_save/restore was removed.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/intel_tv.c | 33 -
1 file changed, 33 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_tv.c b/drivers/gpu/drm/i915/intel_tv.c
index e077c2a9e694..3af857a75fab 100644
--- a/drivers/gpu/drm/i915/intel_tv.c
+++ b/drivers/gpu/drm/i915/intel_tv.c
@@ -50,39 +50,6 @@ struct intel_tv {
int type;
const char *tv_format;
int margin[4];
- u32 save_TV_H_CTL_1;
- u32 save_TV_H_CTL_2;
- u32 save_TV_H_CTL_3;
- u32 save_TV_V_CTL_1;
- u32 save_TV_V_CTL_2;
- u32 save_TV_V_CTL_3;
- u32 save_TV_V_CTL_4;
- u32 save_TV_V_CTL_5;
- u32 save_TV_V_CTL_6;
- u32 save_TV_V_CTL_7;
- u32 save_TV_SC_CTL_1, save_TV_SC_CTL_2, save_TV_SC_CTL_3;
-
- u32 save_TV_CSC_Y;
- u32 save_TV_CSC_Y2;
- u32 save_TV_CSC_U;
- u32 save_TV_CSC_U2;
- u32 save_TV_CSC_V;
- u32 save_TV_CSC_V2;
- u32 save_TV_CLR_KNOBS;
- u32 save_TV_CLR_LEVEL;
- u32 save_TV_WIN_POS;
- u32 save_TV_WIN_SIZE;
- u32 save_TV_FILTER_CTL_1;
- u32 save_TV_FILTER_CTL_2;
- u32 save_TV_FILTER_CTL_3;
-
- u32 save_TV_H_LUMA[60];
- u32 save_TV_H_CHROMA[60];
- u32 save_TV_V_LUMA[43];
- u32 save_TV_V_CHROMA[43];
-
- u32 save_TV_DAC;
- u32 save_TV_CTL;
};
struct video_levels {
--
2.7.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 5/5] drm/i915: Squash repeated awaits on the same fence
Track the latest fence waited upon on each context, and only add a new
asynchronous wait if the new fence is more recent than the recorded
fence for that context. This requires us to filter out unordered
timelines, which are noted by DMA_FENCE_NO_CONTEXT. However, in the
absence of a universal identifier, we have to use our own
i915->mm.unordered_timeline token.
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
Cc: Joonas Lahtinen
---
drivers/gpu/drm/i915/i915_gem_request.c| 72 +++---
drivers/gpu/drm/i915/i915_gem_timeline.c | 255 +
drivers/gpu/drm/i915/i915_gem_timeline.h | 23 ++
drivers/gpu/drm/i915/selftests/i915_gem_timeline.c | 127 ++
.../gpu/drm/i915/selftests/i915_mock_selftests.h | 1 +
lib/radix-tree.c | 1 +
6 files changed, 452 insertions(+), 27 deletions(-)
create mode 100644 drivers/gpu/drm/i915/selftests/i915_gem_timeline.c
diff --git a/drivers/gpu/drm/i915/i915_gem_request.c
b/drivers/gpu/drm/i915/i915_gem_request.c
index 31874a38752e..6e68387aa097 100644
--- a/drivers/gpu/drm/i915/i915_gem_request.c
+++ b/drivers/gpu/drm/i915/i915_gem_request.c
@@ -714,9 +714,7 @@ int
i915_gem_request_await_dma_fence(struct drm_i915_gem_request *req,
struct dma_fence *fence)
{
- struct dma_fence_array *array;
int ret;
- int i;
if (test_bit(DMA_FENCE_FLAG_SIGNALED_BIT, &fence->flags))
return 0;
@@ -728,39 +726,59 @@ i915_gem_request_await_dma_fence(struct
drm_i915_gem_request *req,
if (fence->context == req->fence.context)
return 0;
- if (dma_fence_is_i915(fence))
- return i915_gem_request_await_request(req, to_request(fence));
+ /* Squash repeated waits to the same timelines, picking the latest */
+ if (fence->context != req->i915->mm.unordered_timeline) {
+ if (intel_timeline_sync_get(req->timeline,
+ fence->context,
+ fence->seqno))
+ return 0;
- if (!dma_fence_is_array(fence)) {
+ ret = intel_timeline_sync_reserve(req->timeline);
+ if (unlikely(ret))
+ return ret;
+ }
+
+ if (dma_fence_is_i915(fence)) {
+ ret = i915_gem_request_await_request(req, to_request(fence));
+ if (ret < 0)
+ return ret;
+ } else if (!dma_fence_is_array(fence)) {
ret = i915_sw_fence_await_dma_fence(&req->submit,
fence, I915_FENCE_TIMEOUT,
GFP_KERNEL);
- return ret < 0 ? ret : 0;
- }
-
- /* Note that if the fence-array was created in signal-on-any mode,
-* we should *not* decompose it into its individual fences. However,
-* we don't currently store which mode the fence-array is operating
-* in. Fortunately, the only user of signal-on-any is private to
-* amdgpu and we should not see any incoming fence-array from
-* sync-file being in signal-on-any mode.
-*/
-
- array = to_dma_fence_array(fence);
- for (i = 0; i < array->num_fences; i++) {
- struct dma_fence *child = array->fences[i];
-
- if (dma_fence_is_i915(child))
- ret = i915_gem_request_await_request(req,
-to_request(child));
- else
- ret = i915_sw_fence_await_dma_fence(&req->submit,
- child,
I915_FENCE_TIMEOUT,
- GFP_KERNEL);
if (ret < 0)
return ret;
+ } else {
+ struct dma_fence_array *array = to_dma_fence_array(fence);
+ int i;
+
+ /* Note that if the fence-array was created in signal-on-any
mode,
+* we should *not* decompose it into its individual fences.
However,
+* we don't currently store which mode the fence-array is
operating
+* in. Fortunately, the only user of signal-on-any is private to
+* amdgpu and we should not see any incoming fence-array from
+* sync-file being in signal-on-any mode.
+*/
+
+ for (i = 0; i < array->num_fences; i++) {
+ struct dma_fence *child = array->fences[i];
+
+ if (dma_fence_is_i915(child))
+ ret = i915_gem_request_await_request(req,
+
to_request(child));
+ else
+ ret =
i915_sw_fence_await_dma_fence(&req
[Intel-gfx] [PATCH 3/5] drm/i915: Make ptr_unpack_bits() more function-like
ptr_unpack_bits() is a function-like macro, as such it is meant to be
replaceable by a function. In this case, we should be passing in the
out-param as a pointer.
Bizarrely this does affect code generation:
function old new delta
i915_gem_object_pin_map 409 389 -20
An improvement(?) in this case, but one can't help wonder what
strict-aliasing optimisations we are preventing.
The generated code looks identical in using ptr_unpack_bits (no extra
motions to stack, the pointer and bits appear to be kept in registers),
the difference appears to be code ordering and with a reorder it is able
to use smaller forward jumps.
Signed-off-by: Chris Wilson
Reviewed-by: Joonas Lahtinen
---
drivers/gpu/drm/i915/i915_gem.c | 2 +-
drivers/gpu/drm/i915/i915_utils.h | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 79b5eab5ae83..f39b36a8622a 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -2560,7 +2560,7 @@ void *i915_gem_object_pin_map(struct drm_i915_gem_object
*obj,
}
GEM_BUG_ON(!obj->mm.pages);
- ptr = ptr_unpack_bits(obj->mm.mapping, has_type);
+ ptr = ptr_unpack_bits(obj->mm.mapping, &has_type);
if (ptr && has_type != type) {
if (pinned) {
ret = -EBUSY;
diff --git a/drivers/gpu/drm/i915/i915_utils.h
b/drivers/gpu/drm/i915/i915_utils.h
index c5455d36b617..aca11aad5da7 100644
--- a/drivers/gpu/drm/i915/i915_utils.h
+++ b/drivers/gpu/drm/i915/i915_utils.h
@@ -77,7 +77,7 @@
#define ptr_unpack_bits(ptr, bits) ({ \
unsigned long __v = (unsigned long)(ptr); \
- (bits) = __v & ~PAGE_MASK; \
+ *(bits) = __v & ~PAGE_MASK; \
(typeof(ptr))(__v & PAGE_MASK); \
})
--
2.11.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 4/5] drm/i915: Redefine ptr_pack_bits() and friends
Rebrand the current (pointer | bits) pack/unpack utility macros as
explicit bit twiddling for PAGE_SIZE so that we can use the more
flexible underlying macros for different bits.
Signed-off-by: Chris Wilson
Reviewed-by: Joonas Lahtinen
---
drivers/gpu/drm/i915/i915_cmd_parser.c | 2 +-
drivers/gpu/drm/i915/i915_gem.c| 6 +++---
drivers/gpu/drm/i915/i915_utils.h | 19 +--
3 files changed, 17 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_cmd_parser.c
b/drivers/gpu/drm/i915/i915_cmd_parser.c
index 7af100f84410..1b69a1f9a1ea 100644
--- a/drivers/gpu/drm/i915/i915_cmd_parser.c
+++ b/drivers/gpu/drm/i915/i915_cmd_parser.c
@@ -1284,7 +1284,7 @@ int intel_engine_cmd_parser(struct intel_engine_cs
*engine,
if (*cmd == MI_BATCH_BUFFER_END) {
if (needs_clflush_after) {
- void *ptr =
ptr_mask_bits(shadow_batch_obj->mm.mapping);
+ void *ptr =
page_mask_bits(shadow_batch_obj->mm.mapping);
drm_clflush_virt_range(ptr,
(void *)(cmd + 1) - ptr);
}
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index f39b36a8622a..3c0e63234021 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -2228,7 +2228,7 @@ void __i915_gem_object_put_pages(struct
drm_i915_gem_object *obj,
if (obj->mm.mapping) {
void *ptr;
- ptr = ptr_mask_bits(obj->mm.mapping);
+ ptr = page_mask_bits(obj->mm.mapping);
if (is_vmalloc_addr(ptr))
vunmap(ptr);
else
@@ -2560,7 +2560,7 @@ void *i915_gem_object_pin_map(struct drm_i915_gem_object
*obj,
}
GEM_BUG_ON(!obj->mm.pages);
- ptr = ptr_unpack_bits(obj->mm.mapping, &has_type);
+ ptr = page_unpack_bits(obj->mm.mapping, &has_type);
if (ptr && has_type != type) {
if (pinned) {
ret = -EBUSY;
@@ -2582,7 +2582,7 @@ void *i915_gem_object_pin_map(struct drm_i915_gem_object
*obj,
goto err_unpin;
}
- obj->mm.mapping = ptr_pack_bits(ptr, type);
+ obj->mm.mapping = page_pack_bits(ptr, type);
}
out_unlock:
diff --git a/drivers/gpu/drm/i915/i915_utils.h
b/drivers/gpu/drm/i915/i915_utils.h
index aca11aad5da7..f0500c65726d 100644
--- a/drivers/gpu/drm/i915/i915_utils.h
+++ b/drivers/gpu/drm/i915/i915_utils.h
@@ -70,20 +70,27 @@
#define overflows_type(x, T) \
(sizeof(x) > sizeof(T) && (x) >> (sizeof(T) * BITS_PER_BYTE))
-#define ptr_mask_bits(ptr) ({ \
+#define ptr_mask_bits(ptr, n) ({ \
unsigned long __v = (unsigned long)(ptr); \
- (typeof(ptr))(__v & PAGE_MASK); \
+ (typeof(ptr))(__v & -BIT(n)); \
})
-#define ptr_unpack_bits(ptr, bits) ({ \
+#define ptr_unmask_bits(ptr, n) ((unsigned long)(ptr) & (BIT(n) - 1))
+
+#define ptr_unpack_bits(ptr, bits, n) ({ \
unsigned long __v = (unsigned long)(ptr); \
- *(bits) = __v & ~PAGE_MASK; \
- (typeof(ptr))(__v & PAGE_MASK); \
+ *(bits) = __v & (BIT(n) - 1); \
+ (typeof(ptr))(__v & -BIT(n)); \
})
-#define ptr_pack_bits(ptr, bits) \
+#define ptr_pack_bits(ptr, bits, n)\
((typeof(ptr))((unsigned long)(ptr) | (bits)))
+#define page_mask_bits(ptr) ptr_mask_bits(ptr, PAGE_SHIFT)
+#define page_unmask_bits(ptr) ptr_unmask_bits(ptr, PAGE_SHIFT)
+#define page_pack_bits(ptr, bits) ptr_pack_bits(ptr, bits, PAGE_SHIFT)
+#define page_unpack_bits(ptr, bits) ptr_unpack_bits(ptr, bits, PAGE_SHIFT)
+
#define ptr_offset(ptr, member) offsetof(typeof(*(ptr)), member)
#define fetch_and_zero(ptr) ({ \
--
2.11.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
