Re: [Intel-gfx] [PATCH 37/37] drm/i915: Implement .get_format_info() hook for CCS
Hi,
On 18/11/2016 19:53, ville.syrj...@linux.intel.com wrote:
From: Ville Syrjälä
By providing our own format information for the CCS formats, we should
be able to make framebuffer_check() do the right thing for the CCS
surface as well.
Note that we'll return the same format info for both Y and Yf tiled
format as that's what happens with the non-CCS Y vs. Yf as well. If
desired, we could potentially return a unique pointer for each
pixel_format+tiling+ccs combination, in which case we immediately be
able to tell if any of that stuff changed by just comparing the
pointers. But that does sound a bit wasteful space wise.
Cc: Ben Widawsky
Cc: intel-gfx@lists.freedesktop.org
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_display.c | 37
include/uapi/drm/drm_fourcc.h| 3 +++
2 files changed, 40 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 7b7135be3b9e..de6909770c68 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -2488,6 +2488,42 @@ static unsigned int intel_fb_modifier_to_tiling(uint64_t
fb_modifier)
}
}
+static const struct drm_format_info ccs_formats[] = {
+ { .format = DRM_FORMAT_XRGB, .depth = 24, .num_planes = 2, .cpp = {
4, 1, }, .hsub = 16, .vsub = 8, },
+ { .format = DRM_FORMAT_XBGR, .depth = 24, .num_planes = 2, .cpp = {
4, 1, }, .hsub = 16, .vsub = 8, },
+ { .format = DRM_FORMAT_ARGB, .depth = 32, .num_planes = 2, .cpp = {
4, 1, }, .hsub = 16, .vsub = 8, },
+ { .format = DRM_FORMAT_ABGR, .depth = 32, .num_planes = 2, .cpp = {
4, 1, }, .hsub = 16, .vsub = 8, },
+};
+
+static const struct drm_format_info *
+lookup_format_info(const struct drm_format_info formats[],
+ int num_formats, u32 format)
+{
+ int i;
+
+ for (i = 0; i < num_formats; i++) {
+ if (formats[i].format == format)
+ return &formats[i];
+ }
+
+ return NULL;
+}
+
+static const struct drm_format_info *
+intel_get_format_info(struct drm_device *dev,
+ const struct drm_mode_fb_cmd2 *cmd)
+{
+ switch (cmd->modifier[0]) {
+ case I915_FORMAT_MOD_Y_TILED_CCS:
+ case I915_FORMAT_MOD_Yf_TILED_CCS:
+ return lookup_format_info(ccs_formats,
+ ARRAY_SIZE(ccs_formats),
+ cmd->pixel_format);
+ default:
+ return NULL;
+ }
+}
+
static int
intel_fill_fb_info(struct drm_i915_private *dev_priv,
struct drm_framebuffer *fb)
@@ -15922,6 +15958,7 @@ intel_user_framebuffer_create(struct drm_device *dev,
static const struct drm_mode_config_funcs intel_mode_funcs = {
.fb_create = intel_user_framebuffer_create,
+ .get_format_info = intel_get_format_info,
.output_poll_changed = intel_fbdev_output_poll_changed,
.atomic_check = intel_atomic_check,
.atomic_commit = intel_atomic_commit,
diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
index a5890bf44c0a..2926d916f199 100644
--- a/include/uapi/drm/drm_fourcc.h
+++ b/include/uapi/drm/drm_fourcc.h
@@ -218,6 +218,9 @@ extern "C" {
*/
#define I915_FORMAT_MOD_Yf_TILED fourcc_mod_code(INTEL, 3)
+#define I915_FORMAT_MOD_Y_TILED_CCSfourcc_mod_code(INTEL, 4)
+#define I915_FORMAT_MOD_Yf_TILED_CCS fourcc_mod_code(INTEL, 5)
+
I think when fb modifiers were started the idea was that we would later
partition our vendor bit space for different classes of things and have
helper functions to extract the tiling, etc, from them.
For example have first 3-4 bits represent the tiling, then in this case
one bit for CCS, etc.
Have you considered that when adding these ones, and concluded this
different scheme is better for some reason?
Regards,
Tvrtko
___
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/dp: Fail DP MST config when there are not enough vcpi slots
On Sat, Nov 19, 2016 at 12:04:32AM +, Pandiyan, Dhinakaran wrote:
> On Fri, 2016-11-18 at 09:43 +0100, Daniel Vetter wrote:
> > On Thu, Nov 17, 2016 at 06:03:46PM -0800, Dhinakaran Pandiyan wrote:
> > > drm_dp_find_vcpi_slots() returns an error when there is not enough
> > > available bandwidth on a link to support a mode. This error should make
> > > compute_config() to fail. Not returning false could end up in a modeset
> > > which will not work.
> > >
> > > Signed-off-by: Dhinakaran Pandiyan
> > > ---
> > > drivers/gpu/drm/i915/intel_dp_mst.c | 4
> > > 1 file changed, 4 insertions(+)
> > >
> > > diff --git a/drivers/gpu/drm/i915/intel_dp_mst.c
> > > b/drivers/gpu/drm/i915/intel_dp_mst.c
> > > index e21cf08..4280a83 100644
> > > --- a/drivers/gpu/drm/i915/intel_dp_mst.c
> > > +++ b/drivers/gpu/drm/i915/intel_dp_mst.c
> > > @@ -63,6 +63,10 @@ static bool intel_dp_mst_compute_config(struct
> > > intel_encoder *encoder,
> > >
> > > pipe_config->pbn = mst_pbn;
> > > slots = drm_dp_find_vcpi_slots(&intel_dp->mst_mgr, mst_pbn);
> > > + if (slots < 0) {
> > > + DRM_ERROR("not enough available time slots for pbn=%d",
> > > mst_pbn);
> >
> > No DRM_ERROR for cases that are expected to fail, i.e. DRM_DEBUG_KMS is
> > the right level.
> >
> It'd be nice to document the usage somewhere. There seems to be several
> not very obvious reasons to choose one over the other. I can volunteer
> to write it but I am not getting it right as it's evident here.
Aw yes! I definitely want this better documented, and I can help out with
it for sure. Probably best we discuss this over irc, but would be really
awesome if you volunteer here (if just for the learning experience).
> > And I don't think this works correctly either. Assume you do an atomic
> > modeset where you enable 2 mst sinks at the same time, and the following
> > happens:
> > - mst connector 1 can be allocated, and passes
> > intel_dp_mst_compute_config.
> > - mst connector 2 can be allocated, but not together with connector 1.
> > But drm_dp_find_vcpi_slots only checks what's available, it doesn't do a
> > temporary reservation.
> >
> > And we can just reserve the slot in drm_dp_find_vcpi_slots, because then
> > in the above case (when connector 2 doesn't have enough slots anymore)
> > we'd leak the vcpi allocation for connector 1.
> >
> > Even worse, when we do a TEST_ONLY atomic commit (i.e. only run
> > atomic_check/compute_config code, but not commit anything) this can even
> > happen for a successful commit.
> >
> > Long story short: To fix this properly we need to rewrite the dp helpers
> > to be compliant with atomic design. I think for that we roughly need:
> >
> > - Exract vcpi allocations into a free-standing state structure. I'd call
> > it drm_dp_mst_state or similar. Provide duplicate(get_state)/release
> > functions like we already have for plane, connector and crtc states in
> > the core, and e.g. dpll configuration in i915/intel_dpll_mgr.c. Ander
> > Conselvan can help you with this. I'm also planning to write better
> > documentation for how to do this exactly (since you also need a ww_mutex
> > to protect this state), and I'll prioritize that work.
> >
> > - Wire up that dp mst state at the right places globally (we need one slot
> > per drm_dp_mst_topology_mgr, i.e. per port), and duplicate that state in
> > intel_dp_mst_compute_config. We can't wire this up anywhere in the core
> > since the dp mst library is a helper library, so all the integration
> > points need to be done explicitly in drivers.
> >
> > - Do the same for nouveau - nouveau is now also atomic, and it also is
> > atomic with mst support.
> >
> > - While doing all that make sure that the existing (non-atomic-compliant)
> > functions in the dp mst helpers keep working, we need those for amggpu.
> >
> > - Create a new drm_dp_state_allocate_vcpi_slots, which only touches the
> > new drm_dp_mst_state structure and allocats the vcpi slots there. Also
> > add some function to find the allocation for each sink again (we need
> > that in the modeset commit functions).
> >
>
> Let me rephrase so that I am sure I understand this.
> With the way that I am doing this (assuming the mutex bug in Patch 3/3
> is fixed), we'll still end up passing compute_config() but fail modeset
> in the scenario you pointed out. This is because the slots are not
> reserved in drm_dp_find_vcpi_slots().
>
> However, if we do reserve the slots for connector1 in
> drm_dp_find_vcpi_slots() and fail compute_config() for connector2, then
> the vcpi slots that were assigned to connector1 are not released.
>
> But, by having drm_dp_mst_state, we can simulate vcpi slot allocation in
> the atomic_check()/compute_config() phase and fail without committing,
> while also releasing the slots.
Yup, that's the idea. And like I promised I'll try to document the general
principles of atomic a bit better, so that's it's easier to extend this
stat
[Intel-gfx] i-g-t dummyload/spin batch v8
Changes: * lib/dummyload: Add a helper to terminate recursive batch manually. * gem_wait: Restore sanitycheck wait on the recursive batch and avoid using C99 locals. * kms_flip: Don't wait on the fb - should be busy. Exit the spin batch when flip is queued * kms_busy: Tidy up finish_fb_busy - Abdiel ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [i-g-t PATCH v9 2/5] lib: add igt_dummyload
A lot of igt testcases need some GPU workload to make sure a race window is big enough. Unfortunately having a fixed amount of workload leads to spurious test failures or overly long runtimes on some fast/slow platforms. This library contains functionality to submit GPU workloads that should consume exactly a specific amount of time. v2 : Add recursive batch feature from Chris v3 : Drop auto-tuned stuff. Add bo dependecy to recursive batch by adding a dummy reloc to the bo as suggested by Ville. v4: Fix dependency reloc as write instead of read (Ville). Fix wrong handling of batchbuffer start on ILK causing test failure v5: Convert kms_busy to use this api v6: Add this library to docs v7: Document global use of batch, reuse defines Minor code cleanups. Rename igt_spin_batch and igt_post_spin_batch to igt_spin_batch_new and igt_spin_batch_free respectively (Tomeu Vizoso). Fix error in dependency relocation handling in HSW causing tests to fail. v8: Restore correct order of objects in the execbuffer. Batch object should always be last. v9 : Add helper to terminate batch manually Cc: Daniel Vetter Cc: Ville Syrjälä Cc: Chris Wilson Cc: to...@tomeuvizoso.net Signed-off-by: Abdiel Janulgue --- .../intel-gpu-tools/intel-gpu-tools-docs.xml | 1 + lib/Makefile.sources | 2 + lib/igt.h | 1 + lib/igt_dummyload.c| 295 + lib/igt_dummyload.h| 45 5 files changed, 344 insertions(+) create mode 100644 lib/igt_dummyload.c create mode 100644 lib/igt_dummyload.h diff --git a/docs/reference/intel-gpu-tools/intel-gpu-tools-docs.xml b/docs/reference/intel-gpu-tools/intel-gpu-tools-docs.xml index c862f2a..55902ab 100644 --- a/docs/reference/intel-gpu-tools/intel-gpu-tools-docs.xml +++ b/docs/reference/intel-gpu-tools/intel-gpu-tools-docs.xml @@ -32,6 +32,7 @@ + diff --git a/lib/Makefile.sources b/lib/Makefile.sources index e8e277b..7fc5ec2 100644 --- a/lib/Makefile.sources +++ b/lib/Makefile.sources @@ -75,6 +75,8 @@ lib_source_list = \ igt_draw.h \ igt_pm.c\ igt_pm.h\ + igt_dummyload.c \ + igt_dummyload.h \ uwildmat/uwildmat.h \ uwildmat/uwildmat.c \ $(NULL) diff --git a/lib/igt.h b/lib/igt.h index d751f24..a0028d5 100644 --- a/lib/igt.h +++ b/lib/igt.h @@ -32,6 +32,7 @@ #include "igt_core.h" #include "igt_debugfs.h" #include "igt_draw.h" +#include "igt_dummyload.h" #include "igt_fb.h" #include "igt_gt.h" #include "igt_kms.h" diff --git a/lib/igt_dummyload.c b/lib/igt_dummyload.c new file mode 100644 index 000..c3be8fa --- /dev/null +++ b/lib/igt_dummyload.c @@ -0,0 +1,295 @@ +/* + * Copyright © 2016 Intel Corporation + * + * Permission is hereby granted, free of charge, to any person obtaining a + * copy of this software and associated documentation files (the "Software"), + * to deal in the Software without restriction, including without limitation + * the rights to use, copy, modify, merge, publish, distribute, sublicense, + * and/or sell copies of the Software, and to permit persons to whom the + * Software is furnished to do so, subject to the following conditions: + * + * The above copyright notice and this permission notice (including the next + * paragraph) shall be included in all copies or substantial portions of the + * Software. + * + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL + * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS + * IN THE SOFTWARE. + * + */ + +#include "igt.h" +#include "igt_dummyload.h" +#include +#include +#include + +/** + * SECTION:igt_dummyload + * @short_description: Library for submitting GPU workloads + * @title: Dummyload + * @include: igt.h + * + * A lot of igt testcases need some GPU workload to make sure a race window is + * big enough. Unfortunately having a fixed amount of workload leads to + * spurious test failures or overly long runtimes on some fast/slow platforms. + * This library contains functionality to submit GPU workloads that should + * consume exactly a specific amount of time. + */ + +#define LOCAL_I915_EXEC_BSD_SHIFT (13) +#define LOCAL_I915_EXEC_BSD_MASK (3 << LOCAL_I915_EXEC_BSD_SHIFT) + +#define ENGINE_MASK (I915_EXEC_RING_MASK | LOCAL_I915_EXEC_BSD_MASK) + +static const int bo_size = 4096; + +static void +fill_object(struct drm_i915_gem_exec_object2 *obj, uint32_t gem_han
[Intel-gfx] [i-g-t PATCH v7 1/5] lib: Make signal helper definitions reusable
More and more test-cases are using this.
Signed-off-by: Abdiel Janulgue
---
lib/igt_aux.c | 11 ---
lib/igt_aux.h | 10 ++
lib/igt_core.c | 3 ---
tests/drv_hangman.c | 1 -
4 files changed, 10 insertions(+), 15 deletions(-)
diff --git a/lib/igt_aux.c b/lib/igt_aux.c
index 421f6d4..b5ae854 100644
--- a/lib/igt_aux.c
+++ b/lib/igt_aux.c
@@ -75,17 +75,6 @@
* fit into any other topic.
*/
-
-/* signal interrupt helpers */
-
-#define MSEC_PER_SEC (1000)
-#define USEC_PER_SEC (1000*MSEC_PER_SEC)
-#define NSEC_PER_SEC (1000*USEC_PER_SEC)
-
-/* signal interrupt helpers */
-#define gettid() syscall(__NR_gettid)
-#define sigev_notify_thread_id _sigev_un._tid
-
static struct __igt_sigiter_global {
pid_t tid;
timer_t timer;
diff --git a/lib/igt_aux.h b/lib/igt_aux.h
index d30196b..d4da499 100644
--- a/lib/igt_aux.h
+++ b/lib/igt_aux.h
@@ -35,6 +35,16 @@
extern drm_intel_bo **trash_bos;
extern int num_trash_bos;
+/* signal interrupt helpers */
+
+#define MSEC_PER_SEC (1000)
+#define USEC_PER_SEC (1000*MSEC_PER_SEC)
+#define NSEC_PER_SEC (1000*USEC_PER_SEC)
+
+/* signal interrupt helpers */
+#define gettid() syscall(__NR_gettid)
+#define sigev_notify_thread_id _sigev_un._tid
+
/* auxialiary igt helpers from igt_aux.c */
/* generally useful helpers */
void igt_fork_signal_helper(void);
diff --git a/lib/igt_core.c b/lib/igt_core.c
index 9cd5f98..f64c809 100644
--- a/lib/igt_core.c
+++ b/lib/igt_core.c
@@ -398,9 +398,6 @@ error:
return -errno;
}
-#define MSEC_PER_SEC (1000)
-#define USEC_PER_SEC (1000*MSEC_PER_SEC)
-#define NSEC_PER_SEC (1000*USEC_PER_SEC)
uint64_t igt_nsec_elapsed(struct timespec *start)
{
struct timespec now;
diff --git a/tests/drv_hangman.c b/tests/drv_hangman.c
index f80d65d..db0a077 100644
--- a/tests/drv_hangman.c
+++ b/tests/drv_hangman.c
@@ -293,7 +293,6 @@ static void test_error_state_capture(unsigned ring_id,
* case and it takes a lot more time to wrap, so the acthd can potentially keep
* increasing for a long time
*/
-#define NSEC_PER_SEC 10LL
static void hangcheck_unterminated(void)
{
int fd;
--
2.7.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [i-g-t PATCH v8 3/5] igt/gem_wait: Use new igt_spin_batch
v7: Adapt to api rename
v8: Restore sanitycheck wait on the recursive batch and
avoid using C99 locals (Chris Wilson)
Cc: Chris Wilson
Cc: Daniel Vetter
Signed-off-by: Abdiel Janulgue
---
tests/gem_wait.c | 128 ---
1 file changed, 8 insertions(+), 120 deletions(-)
diff --git a/tests/gem_wait.c b/tests/gem_wait.c
index b4127de..6332e76 100644
--- a/tests/gem_wait.c
+++ b/tests/gem_wait.c
@@ -27,18 +27,6 @@
#include "igt.h"
-#include
-#include
-#include
-
-#define gettid() syscall(__NR_gettid)
-#define sigev_notify_thread_id _sigev_un._tid
-
-#define LOCAL_I915_EXEC_BSD_SHIFT (13)
-#define LOCAL_I915_EXEC_BSD_MASK (3 << LOCAL_I915_EXEC_BSD_SHIFT)
-
-#define ENGINE_MASK (I915_EXEC_RING_MASK | LOCAL_I915_EXEC_BSD_MASK)
-
static int __gem_wait(int fd, struct drm_i915_gem_wait *w)
{
int err;
@@ -75,129 +63,33 @@ static void invalid_buf(int fd)
igt_assert_eq(__gem_wait(fd, &wait), -ENOENT);
}
-static uint32_t *batch;
-
-static void sigiter(int sig, siginfo_t *info, void *arg)
-{
- *batch = MI_BATCH_BUFFER_END;
- __sync_synchronize();
-}
-
-#define MSEC_PER_SEC (1000)
-#define USEC_PER_SEC (1000 * MSEC_PER_SEC)
-#define NSEC_PER_SEC (1000 * USEC_PER_SEC)
-
#define BUSY 1
#define HANG 2
static void basic(int fd, unsigned engine, unsigned flags)
{
- const int gen = intel_gen(intel_get_drm_devid(fd));
- struct drm_i915_gem_exec_object2 obj;
- struct drm_i915_gem_relocation_entry reloc;
- struct drm_i915_gem_execbuffer2 execbuf;
struct drm_i915_gem_wait wait;
- unsigned engines[16];
- unsigned nengine;
- int i, timeout;
-
- nengine = 0;
- if (engine == -1) {
- for_each_engine(fd, engine)
- if (engine) engines[nengine++] = engine;
- } else {
- igt_require(gem_has_ring(fd, engine));
- engines[nengine++] = engine;
- }
- igt_require(nengine);
-
- memset(&execbuf, 0, sizeof(execbuf));
- execbuf.buffers_ptr = (uintptr_t)&obj;
- execbuf.buffer_count = 1;
-
- memset(&obj, 0, sizeof(obj));
- obj.handle = gem_create(fd, 4096);
-
- obj.relocs_ptr = (uintptr_t)&reloc;
- obj.relocation_count = 1;
- memset(&reloc, 0, sizeof(reloc));
-
- batch = gem_mmap__gtt(fd, obj.handle, 4096, PROT_WRITE);
- gem_set_domain(fd, obj.handle,
- I915_GEM_DOMAIN_GTT, I915_GEM_DOMAIN_GTT);
-
- reloc.target_handle = obj.handle; /* recurse */
- reloc.presumed_offset = 0;
- reloc.offset = sizeof(uint32_t);
- reloc.delta = 0;
- reloc.read_domains = I915_GEM_DOMAIN_COMMAND;
- reloc.write_domain = 0;
-
- i = 0;
- batch[i] = MI_BATCH_BUFFER_START;
- if (gen >= 8) {
- batch[i] |= 1 << 8 | 1;
- batch[++i] = 0;
- batch[++i] = 0;
- } else if (gen >= 6) {
- batch[i] |= 1 << 8;
- batch[++i] = 0;
- } else {
- batch[i] |= 2 << 6;
- batch[++i] = 0;
- if (gen < 4) {
- batch[i] |= 1;
- reloc.delta = 1;
- }
- }
+ igt_spin_t *spin;
+ int timeout;
+ int wait_s = (flags == 0) ? NSEC_PER_SEC : 0;
- for (i = 0; i < nengine; i++) {
- execbuf.flags &= ~ENGINE_MASK;
- execbuf.flags |= engines[i];
- gem_execbuf(fd, &execbuf);
- }
+ wait_s = ((flags & HANG) == 0) ? wait_s : -1;
+ spin = igt_spin_batch_new(fd, wait_s, engine, 0);
memset(&wait, 0, sizeof(wait));
- wait.bo_handle = obj.handle;
+ wait.bo_handle = spin->handle;
igt_assert_eq(__gem_wait(fd, &wait), -ETIME);
if (flags & BUSY) {
struct timespec tv;
timeout = 120;
- if ((flags & HANG) == 0) {
- *batch = MI_BATCH_BUFFER_END;
- __sync_synchronize();
+ if ((flags & HANG) == 0)
timeout = 1;
- }
memset(&tv, 0, sizeof(tv));
while (__gem_wait(fd, &wait) == -ETIME)
igt_assert(igt_seconds_elapsed(&tv) < timeout);
} else {
- timer_t timer;
-
- if ((flags & HANG) == 0) {
- struct sigevent sev;
- struct sigaction act;
- struct itimerspec its;
-
- memset(&sev, 0, sizeof(sev));
- sev.sigev_notify = SIGEV_SIGNAL | SIGEV_THREAD_ID;
- sev.sigev_notify_thread_id = gettid();
- sev.sigev_signo = SIGRTMIN + 1;
- igt_assert(timer_create(CLOCK_MONOTONIC, &sev, &timer)
== 0);
-
- memset(&act, 0, sizeof(act));
-
[Intel-gfx] [i-g-t PATCH v8 4/5] igt/kms_flip: Use new igt_spin_batch
v7: Reuse NSEC_PER_SEC defines
v8: Don't wait on the fb, it must be busy. Exit the spin batch
when flip is queued (Chris Wilson)
Cc: Chris Wilson
Cc: Daniel Vetter
Signed-off-by: Abdiel Janulgue
---
tests/kms_flip.c | 212 +++
1 file changed, 26 insertions(+), 186 deletions(-)
diff --git a/tests/kms_flip.c b/tests/kms_flip.c
index 2a9fe2e..437c564 100644
--- a/tests/kms_flip.c
+++ b/tests/kms_flip.c
@@ -85,9 +85,6 @@
#define DRM_CAP_TIMESTAMP_MONOTONIC 6
#endif
-#define USEC_PER_SEC 100L
-#define NSEC_PER_SEC 10L
-
drmModeRes *resources;
int drm_fd;
static drm_intel_bufmgr *bufmgr;
@@ -191,109 +188,6 @@ static unsigned long gettime_us(void)
return ts.tv_sec * 100 + ts.tv_nsec / 1000;
}
-static int calibrate_dummy_load(struct test_output *o,
- const char *ring_name,
- int (*emit)(struct test_output *o, int limit,
int timeout))
-{
- unsigned long start;
- int ops = 1;
-
- start = gettime_us();
-
- do {
- unsigned long diff;
- int ret;
-
- ret = emit(o, (ops+1)/2, 10);
- diff = gettime_us() - start;
-
- if (ret || diff / USEC_PER_SEC >= 1)
- break;
-
- ops += ops;
- } while (ops < 10);
-
- igt_debug("%s dummy load calibrated: %d operations / second\n",
- ring_name, ops);
-
- return ops;
-}
-
-static void blit_copy(drm_intel_bo *dst, drm_intel_bo *src,
- unsigned int width, unsigned int height,
- unsigned int dst_pitch, unsigned int src_pitch)
-{
- BLIT_COPY_BATCH_START(0);
- OUT_BATCH((3 << 24) | /* 32 bits */
- (0xcc << 16) | /* copy ROP */
- dst_pitch);
- OUT_BATCH(0 << 16 | 0);
- OUT_BATCH(height << 16 | width);
- OUT_RELOC_FENCED(dst, I915_GEM_DOMAIN_RENDER, I915_GEM_DOMAIN_RENDER,
0);
- OUT_BATCH(0 << 16 | 0);
- OUT_BATCH(src_pitch);
- OUT_RELOC_FENCED(src, I915_GEM_DOMAIN_RENDER, 0, 0);
- ADVANCE_BATCH();
-
- if (batch->gen >= 6) {
- BEGIN_BATCH(3, 0);
- OUT_BATCH(XY_SETUP_CLIP_BLT_CMD);
- OUT_BATCH(0);
- OUT_BATCH(0);
- ADVANCE_BATCH();
- }
-}
-
-static int _emit_dummy_load__bcs(struct test_output *o, int limit, int timeout)
-{
- int i, ret = 0;
- drm_intel_bo *src_bo, *dst_bo, *fb_bo;
- struct igt_fb *fb_info = &o->fb_info[o->current_fb_id];
-
- igt_require(bufmgr);
-
- src_bo = drm_intel_bo_alloc(bufmgr, "dummy_bo", 2048*2048*4, 4096);
- igt_assert(src_bo);
-
- dst_bo = drm_intel_bo_alloc(bufmgr, "dummy_bo", 2048*2048*4, 4096);
- igt_assert(dst_bo);
-
- fb_bo = gem_handle_to_libdrm_bo(bufmgr, drm_fd, "imported",
fb_info->gem_handle);
- igt_assert(fb_bo);
-
- for (i = 0; i < limit; i++) {
- blit_copy(dst_bo, src_bo,
- 2048, 2048,
- 2048*4, 2048*4);
-
- igt_swap(src_bo, dst_bo);
- }
- blit_copy(fb_bo, src_bo,
- min(o->fb_width, 2048), min(o->fb_height, 2048),
- fb_info->stride, 2048*4);
- intel_batchbuffer_flush(batch);
-
- if (timeout > 0)
- ret = drm_intel_gem_bo_wait(fb_bo, timeout * NSEC_PER_SEC);
-
- drm_intel_bo_unreference(src_bo);
- drm_intel_bo_unreference(dst_bo);
- drm_intel_bo_unreference(fb_bo);
-
- return ret;
-}
-
-static void emit_dummy_load__bcs(struct test_output *o, int seconds)
-{
- static int ops_per_sec;
-
- if (ops_per_sec == 0)
- ops_per_sec = calibrate_dummy_load(o, "bcs",
- _emit_dummy_load__bcs);
-
- _emit_dummy_load__bcs(o, seconds * ops_per_sec, 0);
-}
-
static void emit_fence_stress(struct test_output *o)
{
const int num_fences = gem_available_fences(drm_fd);
@@ -338,82 +232,6 @@ static void emit_fence_stress(struct test_output *o)
free(exec);
}
-static int _emit_dummy_load__rcs(struct test_output *o, int limit, int timeout)
-{
- const struct igt_fb *fb_info = &o->fb_info[o->current_fb_id];
- igt_render_copyfunc_t copyfunc;
- struct igt_buf sb[3], *src, *dst, *fb;
- int i, ret = 0;
-
- igt_require(bufmgr);
-
- copyfunc = igt_get_render_copyfunc(devid);
- if (copyfunc == NULL)
- return _emit_dummy_load__bcs(o, limit, timeout);
-
- sb[0].bo = drm_intel_bo_alloc(bufmgr, "dummy_bo", 2048*2048*4, 4096);
- igt_assert(sb[0].bo);
- sb[0].size = sb[0].bo->size;
- sb[0].tiling = I915_TILING_NONE;
- sb[0].data = NULL;
- sb[0].num_tiles = sb[0].bo->size;
- sb[0].stride = 4 * 2048;
-
- sb[1].bo = drm_intel_bo_alloc(bufmgr, "dum
[Intel-gfx] [i-g-t PATCH v8 5/5] igt/kms_busy.c: Use new igt_spin_batch
v7: Adapt to api rename
v8: Tidy up finish_fb_busy (Chris Wilson)
Cc: Chris Wilson
Cc: Daniel Vetter
Signed-off-by: Abdiel Janulgue
---
tests/kms_busy.c | 81 +---
1 file changed, 6 insertions(+), 75 deletions(-)
diff --git a/tests/kms_busy.c b/tests/kms_busy.c
index b555f99..8a8a3eb 100644
--- a/tests/kms_busy.c
+++ b/tests/kms_busy.c
@@ -78,80 +78,11 @@ static void do_cleanup_display(igt_display_t *dpy)
igt_display_commit2(dpy, dpy->is_atomic ? COMMIT_ATOMIC :
COMMIT_LEGACY);
}
-static uint32_t *
-make_fb_busy(igt_display_t *dpy, unsigned ring, const struct igt_fb *fb)
-{
- const int gen = intel_gen(intel_get_drm_devid(dpy->drm_fd));
- struct drm_i915_gem_exec_object2 obj[2];
-#define SCRATCH 0
-#define BATCH 1
- struct drm_i915_gem_relocation_entry reloc[2];
- struct drm_i915_gem_execbuffer2 execbuf;
- uint32_t *batch;
- int i;
-
- memset(&execbuf, 0, sizeof(execbuf));
- execbuf.buffers_ptr = (uintptr_t)obj;
- execbuf.buffer_count = 2;
- execbuf.flags = ring;
-
- memset(obj, 0, sizeof(obj));
- obj[SCRATCH].handle = fb->gem_handle;
-
- obj[BATCH].handle = gem_create(dpy->drm_fd, 4096);
- obj[BATCH].relocs_ptr = (uintptr_t)reloc;
- obj[BATCH].relocation_count = 2;
- memset(reloc, 0, sizeof(reloc));
- reloc[0].target_handle = obj[BATCH].handle; /* recurse */
- reloc[0].presumed_offset = 0;
- reloc[0].offset = sizeof(uint32_t);
- reloc[0].delta = 0;
- reloc[0].read_domains = I915_GEM_DOMAIN_COMMAND;
- reloc[0].write_domain = 0;
-
- batch = gem_mmap__wc(dpy->drm_fd,
-obj[BATCH].handle, 0, 4096, PROT_WRITE);
- gem_set_domain(dpy->drm_fd, obj[BATCH].handle,
- I915_GEM_DOMAIN_GTT, I915_GEM_DOMAIN_GTT);
-
- batch[i = 0] = MI_BATCH_BUFFER_START;
- if (gen >= 8) {
- batch[i] |= 1 << 8 | 1;
- batch[++i] = 0;
- batch[++i] = 0;
- } else if (gen >= 6) {
- batch[i] |= 1 << 8;
- batch[++i] = 0;
- } else {
- batch[i] |= 2 << 6;
- batch[++i] = 0;
- if (gen < 4) {
- batch[i] |= 1;
- reloc[0].delta = 1;
- }
- }
-
- /* dummy write to fb */
- reloc[1].target_handle = obj[SCRATCH].handle;
- reloc[1].presumed_offset = 0;
- reloc[1].offset = 1024;
- reloc[1].delta = 0;
- reloc[1].read_domains = I915_GEM_DOMAIN_RENDER;
- reloc[1].write_domain = I915_GEM_DOMAIN_RENDER;
-
- gem_execbuf(dpy->drm_fd, &execbuf);
- gem_close(dpy->drm_fd, obj[BATCH].handle);
-
- return batch;
-}
-
-static void finish_fb_busy(uint32_t *batch, int msecs)
+static void finish_fb_busy(igt_spin_t *spin, int msecs)
{
struct timespec tv = { 0, msecs * 1000 * 1000 };
nanosleep(&tv, NULL);
- batch[0] = MI_BATCH_BUFFER_END;
- __sync_synchronize();
- munmap(batch, 4096);
+ igt_spin_batch_exit(spin);
}
static void sighandler(int sig)
@@ -165,9 +96,8 @@ static void flip_to_fb(igt_display_t *dpy, int pipe,
struct pollfd pfd = { .fd = dpy->drm_fd, .events = POLLIN };
struct timespec tv = { 1, 0 };
struct drm_event_vblank ev;
- uint32_t *batch;
-
- batch = make_fb_busy(dpy, ring, fb);
+ igt_spin_t *t = igt_spin_batch_new(dpy->drm_fd, -1,
+ ring, fb->gem_handle);
igt_fork(child, 1) {
igt_assert(gem_bo_busy(dpy->drm_fd, fb->gem_handle));
do_or_die(drmModePageFlip(dpy->drm_fd,
@@ -179,7 +109,8 @@ static void flip_to_fb(igt_display_t *dpy, int pipe,
}
igt_assert_f(nanosleep(&tv, NULL) == -1,
"flip to %s blocked waiting for busy fb", name);
- finish_fb_busy(batch, 2*TIMEOUT);
+ finish_fb_busy(t, 2*TIMEOUT);
+ igt_spin_batch_free(dpy->drm_fd, t);
igt_waitchildren();
igt_assert(read(dpy->drm_fd, &ev, sizeof(ev)) == sizeof(ev));
igt_assert(poll(&pfd, 1, 0) == 0);
--
2.7.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC PATCH] drm/i915: replace platform flags with a platform enum
On Fri, 18 Nov 2016, Tvrtko Ursulin wrote:
> On 18/11/2016 14:20, Jani Nikula wrote:
>> The platform flags in device info are (mostly) mutually
>> exclusive. Replace the flags with an enum. Add the platform enum also
>> for platforms that previously didn't have a flag, and give them codename
>> logging in dmesg.
>
> It just saddens me a bit that it prevents the compiler optimisation of
> our IS_THIS || IS_THAT || IS_TAT ugliness. :I On the basis on that I
> cannot quite make myself to support it, although it conceptually does
> make more sense.
Personally I think making more sense conceptually trumps possible
compiler optimizations, especially when the code paths where this
actually matters are extremely rare. (Can you even point me at an
example where this makes a difference?)
That said, does doing something silly like this make a difference:
enum intel_platform {
INTEL_PLATFORM_UNINITIALIZED = 0,
INTEL_I830 = BIT(0),
INTEL_I845G = BIT(1),
INTEL_I85X = BIT(2),
INTEL_I865G = BIT(3),
INTEL_I915G = BIT(4),
INTEL_I915GM= BIT(5),
INTEL_I945G = BIT(6),
INTEL_I945GM= BIT(7),
INTEL_G33 = BIT(8),
INTEL_G4X = BIT(9),
INTEL_PINEVIEW = BIT(10),
INTEL_BROADWATER= BIT(11),
INTEL_CRESTLINE = BIT(12),
INTEL_IRONLAKE = BIT(13),
INTEL_SANDYBRIDGE = BIT(14),
INTEL_IVYBRIDGE = BIT(15),
INTEL_VALLEYVIEW= BIT(16),
INTEL_CHERRYVIEW= BIT(17),
INTEL_HASWELL = BIT(18),
INTEL_BROADWELL = BIT(19),
INTEL_SKYLAKE = BIT(20),
INTEL_BROXTON = BIT(21),
INTEL_KABYLAKE = BIT(22),
};
BR,
Jani.
--
Jani Nikula, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v5 1/5] drm: Add a new connector property for link status
On Fri, Nov 18, 2016 at 06:50:35PM -0800, Manasi Navare wrote:
> At the time userspace does setcrtc, we've already promised the mode
> would work. The promise is based on the theoretical capabilities of the
> link, but it's possible we can't reach this in practice. The DP spec
> describes how the link should be reduced, but we can't reduce the link
> below the requirements of the mode. Black screen follows.
>
> One idea would be to have setcrtc return a failure. However, it
> already should not fail as the atomic checks have passed. It would also
> conflict with the idea of making setcrtc asynchronous in the future,
> returning before the actual mode setting and link training.
>
> Another idea is to train the link "upfront" at hotplug time, before
> pruning the mode list, so that we can do the pruning based on practical
> not theoretical capabilities. However, the changes for link training are
> pretty drastic, all for the sake of error handling and DP compliance,
> when the most common happy day scenario is the current approach of link
> training at mode setting time, using the optimal parameters for the
> mode. It is also not certain all hardware could do this without the pipe
> on; not even all our hardware can do this. Some of this can be solved,
> but not trivially.
>
> Both of the above ideas also fail to address link degradation *during*
> operation.
>
> The solution is to add a new "link-status" connector property in order
> to address link training failure in a way that:
> a) changes the current happy day scenario as little as possible, to avoid
> regressions, b) can be implemented the same way by all drm drivers, c)
> is still opt-in for the drivers and userspace, and opting out doesn't
> regress the user experience, d) doesn't prevent drivers from
> implementing better or alternate approaches, possibly without userspace
> involvement. And, of course, handles all the issues presented.
> In the usual happy day scenario, this is always "good". If something fails
> during or after a mode set, the kernel driver can set the link status to "bad"
> , prune the mode list based on new information as necessary and send a
> hotplug uevent for userspace to have it re-check the valid modes
> through GET_CONNECTOR IOCTL, and try again. If the theoretical capabilities of
> the link can't be reached, the mode list is trimmed based on that.
>
> The reason for adding the property is to handle link training failures,
> but it is not limited to DP or link training. For example, if we
> implement asynchronous setcrtc, we can use this to report any failures
> in that.
>
> v5:
> * Added kernel doc for connector standard properties (Daniel Vetter)
> v4:
> * Rebase on drm-nightly
> * Add a detailed commit message (Jani Nikula)
> v3:
> * Drop "link training" from description since this is
> not specific to DP (Jani Nikula)
> * Add link status member to store property value locally
> (Ville Syrjala)
> v2:
> * Make this a default connector property (Daniel Vetter)
>
> Reviewed-by: Harry Wentland
> Cc: dri-de...@lists.freedesktop.org
> Cc: Jani Nikula
> Cc: Daniel Vetter
> Cc: Ville Syrjala
> Cc: Chris Wilson
> Signed-off-by: Manasi Navare
> ---
> drivers/gpu/drm/drm_connector.c | 28 ++--
> include/drm/drm_connector.h | 7 ++-
> include/drm/drm_mode_config.h | 5 +
> include/uapi/drm/drm_mode.h | 4
> 4 files changed, 41 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
> index 5a45262..cfb5cf7 100644
> --- a/drivers/gpu/drm/drm_connector.c
> +++ b/drivers/gpu/drm/drm_connector.c
> @@ -243,6 +243,10 @@ int drm_connector_init(struct drm_device *dev,
> drm_object_attach_property(&connector->base,
> config->dpms_property, 0);
>
> + drm_object_attach_property(&connector->base,
> +config->link_status_property,
> +0);
> +
> if (drm_core_check_feature(dev, DRIVER_ATOMIC)) {
> drm_object_attach_property(&connector->base,
> config->prop_crtc_id, 0);
> }
> @@ -506,6 +510,12 @@ const char *drm_get_subpixel_order_name(enum
> subpixel_order order)
> };
> DRM_ENUM_NAME_FN(drm_get_dpms_name, drm_dpms_enum_list)
>
> +static const struct drm_prop_enum_list drm_link_status_enum_list[] = {
> + { DRM_MODE_LINK_STATUS_GOOD, "Good" },
> + { DRM_MODE_LINK_STATUS_BAD, "Bad" },
> +};
> +DRM_ENUM_NAME_FN(drm_get_link_status_name, drm_link_status_enum_list)
> +
> /**
> * drm_display_info_set_bus_formats - set the supported bus formats
> * @info: display info to store bus formats in
> @@ -616,7 +626,7 @@ int drm_display_info_set_bus_formats(struct
> drm_display_info *info,
> * path property the MST manager created. Userspace cannot change this
> * property.
> * TILE:
> - * Connector tile group property to indicate how a set of DRM connector
> + * Connect
Re: [Intel-gfx] [PATCH 0/3] drm/i915/opregion: proper handling of DIDL, and some hacks on CADL
Hi Jani, I can also confirm that patches 1+2 (applied in top of v4.9-rc5ish) fixes it for me (Clevo P651RA). The previous issue where the keys broke with PRIME/monitor hotplugging is also gone. After system suspend/resume stuff is also still working. Thanks! Kind regards, Peter https://lekensteyn.nl (pardon my brevity, top-posting and formatting, sent from my phone) On 18 November 2016 09:27:07 CET, Jani Nikula wrote: >On Thu, 17 Nov 2016, Paolo Stivanin wrote: >> Hello, >> I can confirm that patch 3 is not needed. >> I applied only patch 1 and 2 and everything works super fine! > >Thanks for confirming this. > >BR, >Jani. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 3/5] drm/i915: Update CRTC state if connector link status property changed
On Fri, Nov 18, 2016 at 09:44:49AM -0800, Manasi Navare wrote:
> On Fri, Nov 18, 2016 at 06:21:21PM +0200, Ville Syrjälä wrote:
> > On Fri, Nov 18, 2016 at 04:35:25PM +0100, Daniel Vetter wrote:
> > > On Fri, Nov 18, 2016 at 05:28:54PM +0200, Ville Syrjälä wrote:
> > > > On Fri, Nov 18, 2016 at 03:18:06PM +0100, Maarten Lankhorst wrote:
> > > > > Op 18-11-16 om 15:11 schreef Ville Syrjälä:
> > > > > > On Fri, Nov 18, 2016 at 02:50:52PM +0100, Maarten Lankhorst wrote:
> > > > > >> Op 18-11-16 om 08:13 schreef Manasi Navare:
> > > > > >>> CRTC state connector_changed needs to be set to true
> > > > > >>> if connector link status property has changed. This will tell the
> > > > > >>> driver to do a complete modeset due to change in connector
> > > > > >>> property.
> > > > > >>>
> > > > > >>> Acked-by: Harry Wentland
> > > > > >>> Acked-by: Tony Cheng
> > > > > >>> Cc: dri-de...@lists.freedesktop.org
> > > > > >>> Cc: Jani Nikula
> > > > > >>> Cc: Daniel Vetter
> > > > > >>> Cc: Ville Syrjala
> > > > > >>> Signed-off-by: Manasi Navare
> > > > > >>> ---
> > > > > >>> drivers/gpu/drm/drm_atomic_helper.c | 7 +++
> > > > > >>> 1 file changed, 7 insertions(+)
> > > > > >>>
> > > > > >>> diff --git a/drivers/gpu/drm/drm_atomic_helper.c
> > > > > >>> b/drivers/gpu/drm/drm_atomic_helper.c
> > > > > >>> index 0b16587..2125fd1 100644
> > > > > >>> --- a/drivers/gpu/drm/drm_atomic_helper.c
> > > > > >>> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> > > > > >>> @@ -519,6 +519,13 @@ static int
> > > > > >>> handle_conflicting_encoders(struct drm_atomic_state *state,
> > > > > >>> connector_state);
> > > > > >>> if (ret)
> > > > > >>> return ret;
> > > > > >>> +
> > > > > >>> + if (connector->state->crtc) {
> > > > > >>> + crtc_state =
> > > > > >>> drm_atomic_get_existing_crtc_state(state,
> > > > > >>> +
> > > > > >>> connector->state->crtc);
> > > > > >>> + if (connector->link_status ==
> > > > > >>> DRM_MODE_LINK_STATUS_BAD)
> > > > > >>> + crtc_state->connectors_changed = true;
> > > > > >>> + }
> > > > > >>> }
> > > > > >>>
> > > > > >>> /*
> > > > > >> This will cause ordinary atomic commits that happen to change
> > > > > >> connector flags to potentially fail with -EINVAL if ALLOW_MODESET
> > > > > >> is not set.
> > > > > >> For this reason I'm not sure this flag should be set automatically
> > > > > >> by the kernel. Could we add add a retrain link property instead,
> > > > > >> that
> > > > > >> always return 0 when queried, but writing a 1 causing
> > > > > >> connectors_changed to be set on bad link status?
> > > > > > Or just check for allow_modeset before setting
> > > > > > connectors_changed=true here?
> > > > >
> > > > > I don't think modesets should be done automatically like that, even
> > > > > if ALLOW_MODESET is set a modeset may not be expected by userspace.
> > > >
> > > > Presumably userspace would want a picture on the screen using any means
> > > > if it said ALLOW_MODESET. So if it can't tolerate the modeset it should
> > > > probably say as much?
> > >
> > > Yeah, agreed. Also, if the link is bad then we pretty much have to do a
> > > modeset to recover it, otherwise you'll be forever stuck with a bad
> > > screen.
> > >
> > > What we could try is to gate this of whether userspace touches the mode
> > > property on the corresponding CRTC. I.e. if that's touched (even if it's
> > > the same mode), and a link is bad in one of the connectors in the state
> > > then we do a full modeset to recover.
> > >
> > > Another option would be to make the link status writeable. Trying to
> > > change it from bad->good would force the modeset. That would be 100% clear
> > > to userspace, not special hacks needed with checking for allow_modeset,
> > > no magic property that auto-changes its value. And 100% backwards compat
> > > because existing userspace should never touch properties it doesn't
> > > understand (except when restoring a mode, and then it should allow a full
> > > modeset). And if someone does try a good->bad transition, we just silently
> > > keep it at good.
> > >
> > > Definitely need to document this properly in the property docs, no matter
> > > what we decide.
> >
> > Hmm. I think I kinda like this idea of userspace clear the state back
> > to good explicitly, if it happens with the same prop. So it's like
> > Maarten's retrain_link prop idea, but without having to add the second
> > prop to the mix.
> >
> > It would also save me from pointing out (for the nth time) that the
> > link status should really be cleared to good during the commit state
> > swap and not at some random point during the commit ;)
> >
>
> Okay, so change 1 is to make the userspace clear the state back to Good for
> the property..
> Then Change 2 is to set connector_changed
[Intel-gfx] [PATCH] drm/i915: Add a warning on shutdown if signal threads still active
When unloading the module, it is expected that we have finished
executing all requests and so the signal threads should be idle. Add a
warning in case there are any residual requests in the signaler rbtrees
at that point.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/intel_breadcrumbs.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_breadcrumbs.c
b/drivers/gpu/drm/i915/intel_breadcrumbs.c
index c9c46a538edb..b7006e90a167 100644
--- a/drivers/gpu/drm/i915/intel_breadcrumbs.c
+++ b/drivers/gpu/drm/i915/intel_breadcrumbs.c
@@ -623,6 +623,8 @@ void intel_engine_fini_breadcrumbs(struct intel_engine_cs
*engine)
{
struct intel_breadcrumbs *b = &engine->breadcrumbs;
+ WARN_ON(READ_ONCE(b->first_signal));
+ WARN_ON(!RB_EMPTY_ROOT(&b->signals));
if (!IS_ERR_OR_NULL(b->signaler))
kthread_stop(b->signaler);
--
2.10.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] Updated drm-intel-testing
Hi all, New -testing cycle with cool stuff: Final 4.10 updates: - fine-tune fb flushing and tracking (Chris Wilson) - refactor state check dumper code for more conciseness (Tvrtko) - roll out dev_priv all over the place (Tvrkto) - finally remove __i915__ magic macro (Tvrtko) - more gvt bugfixes (Zhenyu&team) - better opregion CADL handling (Jani) - refactor/clean up wm programming (Maarten) - gpu scheduler + priority boosting for flips as first user (Chris Wilson) - make fbc use more atomic (Paulo) - initial kvm-gvt framework, but not yet complete (Zhenyu&team) Happy testing! Cheers, Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 3/5] drm/i915: Update CRTC state if connector link status property changed
On Mon, Nov 21, 2016 at 10:38:20AM +0100, Daniel Vetter wrote:
> On Fri, Nov 18, 2016 at 09:44:49AM -0800, Manasi Navare wrote:
> > On Fri, Nov 18, 2016 at 06:21:21PM +0200, Ville Syrjälä wrote:
> > > On Fri, Nov 18, 2016 at 04:35:25PM +0100, Daniel Vetter wrote:
> > > > On Fri, Nov 18, 2016 at 05:28:54PM +0200, Ville Syrjälä wrote:
> > > > > On Fri, Nov 18, 2016 at 03:18:06PM +0100, Maarten Lankhorst wrote:
> > > > > > Op 18-11-16 om 15:11 schreef Ville Syrjälä:
> > > > > > > On Fri, Nov 18, 2016 at 02:50:52PM +0100, Maarten Lankhorst wrote:
> > > > > > >> Op 18-11-16 om 08:13 schreef Manasi Navare:
> > > > > > >>> CRTC state connector_changed needs to be set to true
> > > > > > >>> if connector link status property has changed. This will tell
> > > > > > >>> the
> > > > > > >>> driver to do a complete modeset due to change in connector
> > > > > > >>> property.
> > > > > > >>>
> > > > > > >>> Acked-by: Harry Wentland
> > > > > > >>> Acked-by: Tony Cheng
> > > > > > >>> Cc: dri-de...@lists.freedesktop.org
> > > > > > >>> Cc: Jani Nikula
> > > > > > >>> Cc: Daniel Vetter
> > > > > > >>> Cc: Ville Syrjala
> > > > > > >>> Signed-off-by: Manasi Navare
> > > > > > >>> ---
> > > > > > >>> drivers/gpu/drm/drm_atomic_helper.c | 7 +++
> > > > > > >>> 1 file changed, 7 insertions(+)
> > > > > > >>>
> > > > > > >>> diff --git a/drivers/gpu/drm/drm_atomic_helper.c
> > > > > > >>> b/drivers/gpu/drm/drm_atomic_helper.c
> > > > > > >>> index 0b16587..2125fd1 100644
> > > > > > >>> --- a/drivers/gpu/drm/drm_atomic_helper.c
> > > > > > >>> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> > > > > > >>> @@ -519,6 +519,13 @@ static int
> > > > > > >>> handle_conflicting_encoders(struct drm_atomic_state *state,
> > > > > > >>>connector_state);
> > > > > > >>> if (ret)
> > > > > > >>> return ret;
> > > > > > >>> +
> > > > > > >>> + if (connector->state->crtc) {
> > > > > > >>> + crtc_state =
> > > > > > >>> drm_atomic_get_existing_crtc_state(state,
> > > > > > >>> +
> > > > > > >>> connector->state->crtc);
> > > > > > >>> + if (connector->link_status ==
> > > > > > >>> DRM_MODE_LINK_STATUS_BAD)
> > > > > > >>> + crtc_state->connectors_changed
> > > > > > >>> = true;
> > > > > > >>> + }
> > > > > > >>> }
> > > > > > >>>
> > > > > > >>> /*
> > > > > > >> This will cause ordinary atomic commits that happen to change
> > > > > > >> connector flags to potentially fail with -EINVAL if
> > > > > > >> ALLOW_MODESET is not set.
> > > > > > >> For this reason I'm not sure this flag should be set
> > > > > > >> automatically by the kernel. Could we add add a retrain link
> > > > > > >> property instead, that
> > > > > > >> always return 0 when queried, but writing a 1 causing
> > > > > > >> connectors_changed to be set on bad link status?
> > > > > > > Or just check for allow_modeset before setting
> > > > > > > connectors_changed=true here?
> > > > > >
> > > > > > I don't think modesets should be done automatically like that, even
> > > > > > if ALLOW_MODESET is set a modeset may not be expected by userspace.
> > > > >
> > > > > Presumably userspace would want a picture on the screen using any
> > > > > means
> > > > > if it said ALLOW_MODESET. So if it can't tolerate the modeset it
> > > > > should
> > > > > probably say as much?
> > > >
> > > > Yeah, agreed. Also, if the link is bad then we pretty much have to do a
> > > > modeset to recover it, otherwise you'll be forever stuck with a bad
> > > > screen.
> > > >
> > > > What we could try is to gate this of whether userspace touches the mode
> > > > property on the corresponding CRTC. I.e. if that's touched (even if it's
> > > > the same mode), and a link is bad in one of the connectors in the state
> > > > then we do a full modeset to recover.
> > > >
> > > > Another option would be to make the link status writeable. Trying to
> > > > change it from bad->good would force the modeset. That would be 100%
> > > > clear
> > > > to userspace, not special hacks needed with checking for allow_modeset,
> > > > no magic property that auto-changes its value. And 100% backwards compat
> > > > because existing userspace should never touch properties it doesn't
> > > > understand (except when restoring a mode, and then it should allow a
> > > > full
> > > > modeset). And if someone does try a good->bad transition, we just
> > > > silently
> > > > keep it at good.
> > > >
> > > > Definitely need to document this properly in the property docs, no
> > > > matter
> > > > what we decide.
> > >
> > > Hmm. I think I kinda like this idea of userspace clear the state back
> > > to good explicitly, if it happens with the same prop. So it's like
> > > Maarten's retrain_link prop idea, but without hav
Re: [Intel-gfx] [RFC PATCH] drm/i915: replace platform flags with a platform enum
On 21/11/2016 09:27, Jani Nikula wrote:
On Fri, 18 Nov 2016, Tvrtko Ursulin wrote:
On 18/11/2016 14:20, Jani Nikula wrote:
The platform flags in device info are (mostly) mutually
exclusive. Replace the flags with an enum. Add the platform enum also
for platforms that previously didn't have a flag, and give them codename
logging in dmesg.
It just saddens me a bit that it prevents the compiler optimisation of
our IS_THIS || IS_THAT || IS_TAT ugliness. :I On the basis on that I
cannot quite make myself to support it, although it conceptually does
make more sense.
Personally I think making more sense conceptually trumps possible
compiler optimizations, especially when the code paths where this
actually matters are extremely rare. (Can you even point me at an
example where this makes a difference?)
Without thinking deeply, all instances like IS_HASWELL || IS_BROADWELL,
IS_SKYLAKE || IS_KABYLAKE, or IS_VALLEYVIEW || IS_CHERRYVIEW. Quick grep
shows that there is at least around 170 instances of those. There might
be more, I don't know. At least the ones I listed all currently
translate to a single conditional in the generated code.
I am not saying these are all on performance critical paths or anything,
just that on balance, for me the sweetness of the optimisation cancels
out the ugliness of the code (which is often unavoidable). Losing that
and ending up with compare ladders in the code would just be a bit sad.
That said, does doing something silly like this make a difference:
enum intel_platform {
INTEL_PLATFORM_UNINITIALIZED = 0,
INTEL_I830 = BIT(0),
INTEL_I845G = BIT(1),
INTEL_I85X = BIT(2),
INTEL_I865G = BIT(3),
INTEL_I915G = BIT(4),
INTEL_I915GM= BIT(5),
INTEL_I945G = BIT(6),
INTEL_I945GM= BIT(7),
INTEL_G33 = BIT(8),
INTEL_G4X = BIT(9),
INTEL_PINEVIEW = BIT(10),
INTEL_BROADWATER= BIT(11),
INTEL_CRESTLINE = BIT(12),
INTEL_IRONLAKE = BIT(13),
INTEL_SANDYBRIDGE = BIT(14),
INTEL_IVYBRIDGE = BIT(15),
INTEL_VALLEYVIEW= BIT(16),
INTEL_CHERRYVIEW= BIT(17),
INTEL_HASWELL = BIT(18),
INTEL_BROADWELL = BIT(19),
INTEL_SKYLAKE = BIT(20),
INTEL_BROXTON = BIT(21),
INTEL_KABYLAKE = BIT(22),
};
I could live with that. Probably best to compare the code size before
and after just to verify there are no surprises.
Regards,
Tvrtko
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 3/5] drm/i915: Update CRTC state if connector link status property changed
On Mon, Nov 21, 2016 at 09:42:57AM +, Chris Wilson wrote:
> On Mon, Nov 21, 2016 at 10:38:20AM +0100, Daniel Vetter wrote:
> > On Fri, Nov 18, 2016 at 09:44:49AM -0800, Manasi Navare wrote:
> > > On Fri, Nov 18, 2016 at 06:21:21PM +0200, Ville Syrjälä wrote:
> > > > On Fri, Nov 18, 2016 at 04:35:25PM +0100, Daniel Vetter wrote:
> > > > > On Fri, Nov 18, 2016 at 05:28:54PM +0200, Ville Syrjälä wrote:
> > > > > > On Fri, Nov 18, 2016 at 03:18:06PM +0100, Maarten Lankhorst wrote:
> > > > > > > Op 18-11-16 om 15:11 schreef Ville Syrjälä:
> > > > > > > > On Fri, Nov 18, 2016 at 02:50:52PM +0100, Maarten Lankhorst
> > > > > > > > wrote:
> > > > > > > >> Op 18-11-16 om 08:13 schreef Manasi Navare:
> > > > > > > >>> CRTC state connector_changed needs to be set to true
> > > > > > > >>> if connector link status property has changed. This will tell
> > > > > > > >>> the
> > > > > > > >>> driver to do a complete modeset due to change in connector
> > > > > > > >>> property.
> > > > > > > >>>
> > > > > > > >>> Acked-by: Harry Wentland
> > > > > > > >>> Acked-by: Tony Cheng
> > > > > > > >>> Cc: dri-de...@lists.freedesktop.org
> > > > > > > >>> Cc: Jani Nikula
> > > > > > > >>> Cc: Daniel Vetter
> > > > > > > >>> Cc: Ville Syrjala
> > > > > > > >>> Signed-off-by: Manasi Navare
> > > > > > > >>> ---
> > > > > > > >>> drivers/gpu/drm/drm_atomic_helper.c | 7 +++
> > > > > > > >>> 1 file changed, 7 insertions(+)
> > > > > > > >>>
> > > > > > > >>> diff --git a/drivers/gpu/drm/drm_atomic_helper.c
> > > > > > > >>> b/drivers/gpu/drm/drm_atomic_helper.c
> > > > > > > >>> index 0b16587..2125fd1 100644
> > > > > > > >>> --- a/drivers/gpu/drm/drm_atomic_helper.c
> > > > > > > >>> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> > > > > > > >>> @@ -519,6 +519,13 @@ static int
> > > > > > > >>> handle_conflicting_encoders(struct drm_atomic_state *state,
> > > > > > > >>> connector_state);
> > > > > > > >>> if (ret)
> > > > > > > >>> return ret;
> > > > > > > >>> +
> > > > > > > >>> + if (connector->state->crtc) {
> > > > > > > >>> + crtc_state =
> > > > > > > >>> drm_atomic_get_existing_crtc_state(state,
> > > > > > > >>> +
> > > > > > > >>> connector->state->crtc);
> > > > > > > >>> + if (connector->link_status ==
> > > > > > > >>> DRM_MODE_LINK_STATUS_BAD)
> > > > > > > >>> + crtc_state->connectors_changed
> > > > > > > >>> = true;
> > > > > > > >>> + }
> > > > > > > >>> }
> > > > > > > >>>
> > > > > > > >>> /*
> > > > > > > >> This will cause ordinary atomic commits that happen to change
> > > > > > > >> connector flags to potentially fail with -EINVAL if
> > > > > > > >> ALLOW_MODESET is not set.
> > > > > > > >> For this reason I'm not sure this flag should be set
> > > > > > > >> automatically by the kernel. Could we add add a retrain link
> > > > > > > >> property instead, that
> > > > > > > >> always return 0 when queried, but writing a 1 causing
> > > > > > > >> connectors_changed to be set on bad link status?
> > > > > > > > Or just check for allow_modeset before setting
> > > > > > > > connectors_changed=true here?
> > > > > > >
> > > > > > > I don't think modesets should be done automatically like that,
> > > > > > > even if ALLOW_MODESET is set a modeset may not be expected by
> > > > > > > userspace.
> > > > > >
> > > > > > Presumably userspace would want a picture on the screen using any
> > > > > > means
> > > > > > if it said ALLOW_MODESET. So if it can't tolerate the modeset it
> > > > > > should
> > > > > > probably say as much?
> > > > >
> > > > > Yeah, agreed. Also, if the link is bad then we pretty much have to do
> > > > > a
> > > > > modeset to recover it, otherwise you'll be forever stuck with a bad
> > > > > screen.
> > > > >
> > > > > What we could try is to gate this of whether userspace touches the
> > > > > mode
> > > > > property on the corresponding CRTC. I.e. if that's touched (even if
> > > > > it's
> > > > > the same mode), and a link is bad in one of the connectors in the
> > > > > state
> > > > > then we do a full modeset to recover.
> > > > >
> > > > > Another option would be to make the link status writeable. Trying to
> > > > > change it from bad->good would force the modeset. That would be 100%
> > > > > clear
> > > > > to userspace, not special hacks needed with checking for
> > > > > allow_modeset,
> > > > > no magic property that auto-changes its value. And 100% backwards
> > > > > compat
> > > > > because existing userspace should never touch properties it doesn't
> > > > > understand (except when restoring a mode, and then it should allow a
> > > > > full
> > > > > modeset). And if someone does try a good->bad transition, we just
> > > > > silently
> > > > > keep it at good.
> > > > >
> > >
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Add a warning on shutdown if signal threads still active
== Series Details == Series: drm/i915: Add a warning on shutdown if signal threads still active URL : https://patchwork.freedesktop.org/series/15641/ State : success == Summary == Series 15641v1 drm/i915: Add a warning on shutdown if signal threads still active https://patchwork.freedesktop.org/api/1.0/series/15641/revisions/1/mbox/ fi-bdw-5557u total:244 pass:229 dwarn:0 dfail:0 fail:0 skip:15 fi-bsw-n3050 total:244 pass:204 dwarn:0 dfail:0 fail:0 skip:40 fi-bxt-t5700 total:244 pass:216 dwarn:0 dfail:0 fail:0 skip:28 fi-byt-j1900 total:244 pass:216 dwarn:0 dfail:0 fail:0 skip:28 fi-byt-n2820 total:244 pass:212 dwarn:0 dfail:0 fail:0 skip:32 fi-hsw-4770 total:244 pass:224 dwarn:0 dfail:0 fail:0 skip:20 fi-hsw-4770r total:244 pass:224 dwarn:0 dfail:0 fail:0 skip:20 fi-ilk-650 total:244 pass:191 dwarn:0 dfail:0 fail:0 skip:53 fi-ivb-3520m total:244 pass:222 dwarn:0 dfail:0 fail:0 skip:22 fi-ivb-3770 total:244 pass:222 dwarn:0 dfail:0 fail:0 skip:22 fi-kbl-7200u total:244 pass:222 dwarn:0 dfail:0 fail:0 skip:22 fi-skl-6260u total:244 pass:230 dwarn:0 dfail:0 fail:0 skip:14 fi-skl-6700hqtotal:244 pass:223 dwarn:0 dfail:0 fail:0 skip:21 fi-skl-6700k total:244 pass:222 dwarn:1 dfail:0 fail:0 skip:21 fi-skl-6770hqtotal:244 pass:230 dwarn:0 dfail:0 fail:0 skip:14 fi-snb-2520m total:244 pass:212 dwarn:0 dfail:0 fail:0 skip:32 fi-snb-2600 total:244 pass:211 dwarn:0 dfail:0 fail:0 skip:33 accd56d36a298219042d84ba9ee1b7bd66d1936c drm-intel-nightly: 2016y-11m-18d-22h-35m-31s UTC integration manifest 9122fd0 drm/i915: Add a warning on shutdown if signal threads still active == Logs == For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_3065/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Add a warning on shutdown if signal threads still active
On 21/11/2016 09:40, Chris Wilson wrote:
When unloading the module, it is expected that we have finished
executing all requests and so the signal threads should be idle. Add a
warning in case there are any residual requests in the signaler rbtrees
at that point.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/intel_breadcrumbs.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_breadcrumbs.c
b/drivers/gpu/drm/i915/intel_breadcrumbs.c
index c9c46a538edb..b7006e90a167 100644
--- a/drivers/gpu/drm/i915/intel_breadcrumbs.c
+++ b/drivers/gpu/drm/i915/intel_breadcrumbs.c
@@ -623,6 +623,8 @@ void intel_engine_fini_breadcrumbs(struct intel_engine_cs
*engine)
{
struct intel_breadcrumbs *b = &engine->breadcrumbs;
+ WARN_ON(READ_ONCE(b->first_signal));
+ WARN_ON(!RB_EMPTY_ROOT(&b->signals));
if (!IS_ERR_OR_NULL(b->signaler))
kthread_stop(b->signaler);
Not sure if you are just testing out theories on the CI, but in any case
looks to me it wouldn't harm to have this in.
Reviewed-by: Tvrtko Ursulin
Regards,
Tvrtko
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Try to group more logically in intel_dump_pipe_config
On 18/11/2016 11:19, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
Keep parameters relating to the pipe and crtc respectively together.
Signed-off-by: Tvrtko Ursulin
Cc: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_display.c | 15 +++
1 file changed, 7 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 200f09778776..155910c93896 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -12739,9 +12739,14 @@ static void intel_dump_pipe_config(struct intel_crtc
*crtc,
DRM_DEBUG_KMS("[CRTC:%d:%s]%s\n",
crtc->base.base.id, crtc->base.name, context);
- DRM_DEBUG_KMS("cpu_transcoder: %s, pipe bpp: %i, dithering: %i\n",
+ DRM_DEBUG_KMS("cpu_transcoder: %s, port clock: %d, ips: %i\n",
transcoder_name(pipe_config->cpu_transcoder),
- pipe_config->pipe_bpp, pipe_config->dither);
+ pipe_config->port_clock, pipe_config->ips_enabled);
+
+ DRM_DEBUG_KMS("pipe src size: %dx%d, bpp: %i, dithering: %i, double wide:
%i\n",
+ pipe_config->pipe_src_w, pipe_config->pipe_src_h,
+ pipe_config->pipe_bpp, pipe_config->dither,
+ pipe_config->double_wide);
Better grouping yay/nay? :)
Regards,
Tvrtko
if (pipe_config->has_pch_encoder)
intel_dump_m_n_config(pipe_config, "fdi",
@@ -12765,9 +12770,6 @@ static void intel_dump_pipe_config(struct intel_crtc
*crtc,
DRM_DEBUG_KMS("adjusted mode:\n");
drm_mode_debug_printmodeline(&pipe_config->base.adjusted_mode);
intel_dump_crtc_timings(&pipe_config->base.adjusted_mode);
- DRM_DEBUG_KMS("port clock: %d, pipe src size: %dx%d\n",
- pipe_config->port_clock,
- pipe_config->pipe_src_w, pipe_config->pipe_src_h);
if (INTEL_GEN(dev_priv) >= 9)
DRM_DEBUG_KMS("num_scalers: %d, scaler_users: 0x%x, scaler_id:
%d\n",
@@ -12786,9 +12788,6 @@ static void intel_dump_pipe_config(struct intel_crtc
*crtc,
pipe_config->pch_pfit.size,
enableddisabled(pipe_config->pch_pfit.enabled));
- DRM_DEBUG_KMS("ips: %i, double wide: %i\n",
- pipe_config->ips_enabled, pipe_config->double_wide);
-
if (IS_BROXTON(dev_priv)) {
DRM_DEBUG_KMS("dpll_hw_state: ebb0: 0x%x, ebb4: 0x%x,"
"pll0: 0x%x, pll1: 0x%x, pll2: 0x%x, pll3: 0x%x, "
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Add a warning on shutdown if signal threads still active
On Mon, Nov 21, 2016 at 10:42:37AM +, Tvrtko Ursulin wrote:
>
> On 21/11/2016 09:40, Chris Wilson wrote:
> >When unloading the module, it is expected that we have finished
> >executing all requests and so the signal threads should be idle. Add a
> >warning in case there are any residual requests in the signaler rbtrees
> >at that point.
> >
> >Signed-off-by: Chris Wilson
> >---
> > drivers/gpu/drm/i915/intel_breadcrumbs.c | 2 ++
> > 1 file changed, 2 insertions(+)
> >
> >diff --git a/drivers/gpu/drm/i915/intel_breadcrumbs.c
> >b/drivers/gpu/drm/i915/intel_breadcrumbs.c
> >index c9c46a538edb..b7006e90a167 100644
> >--- a/drivers/gpu/drm/i915/intel_breadcrumbs.c
> >+++ b/drivers/gpu/drm/i915/intel_breadcrumbs.c
> >@@ -623,6 +623,8 @@ void intel_engine_fini_breadcrumbs(struct
> >intel_engine_cs *engine)
> > {
> > struct intel_breadcrumbs *b = &engine->breadcrumbs;
> >
> >+WARN_ON(READ_ONCE(b->first_signal));
> >+WARN_ON(!RB_EMPTY_ROOT(&b->signals));
> > if (!IS_ERR_OR_NULL(b->signaler))
> > kthread_stop(b->signaler);
> >
> >
>
> Not sure if you are just testing out theories on the CI, but in any
> case looks to me it wouldn't harm to have this in.
Only staring at the impossible, ruling out the unlikely. A leak here
would be caught by the request kmem_cache, but being explicit might help
in future.
> Reviewed-by: Tvrtko Ursulin
Imagine if I added a
WARN_ON(READ_ONCE(b->first_waiter));
WARN_ON(!RB_EMPTY_ROOT(&b->waiters));
as well? Still r-b or go with a second patch for the afterthought?
-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: Do not log disabled planes in pipe config
On 18/11/2016 14:19, Ville Syrjälä wrote: On Fri, Nov 18, 2016 at 03:13:14PM +0100, Maarten Lankhorst wrote: Op 18-11-16 om 12:40 schreef Tvrtko Ursulin: From: Tvrtko Ursulin It just says "plane X disabled" which does not seem very useful. Signed-off-by: Tvrtko Ursulin Cc: Maarten Lankhorst Cc: Ville Syrjälä Could we remove plane dumping altogether? It's not safe to do so in the way done by this function, and we could add missing things in intel_plane_atomic_calc_changes. Yeah, might make sense to dump that stuff only from some plane code. And we should probably take a good look at Rob Clark's new state dumping stuff for that, so that we'll get it in some decently standardized format. I must admit that I didn't take a very good look at Rob's stuff, but maybe he already added the dumps to some useful places, and all we'd have to do is expand the dumps with our own derived plane state... Shall I leave it with you guys then? The most I would feel confident in this area is to submit a patch which removes the plane debug from intel_dump_pipe_config if that is broken. But not sure how useful would that be without this other work you are discussing. Regards, Tvrtko ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Add a warning on shutdown if signal threads still active
On 21/11/2016 10:48, Chris Wilson wrote:
On Mon, Nov 21, 2016 at 10:42:37AM +, Tvrtko Ursulin wrote:
On 21/11/2016 09:40, Chris Wilson wrote:
When unloading the module, it is expected that we have finished
executing all requests and so the signal threads should be idle. Add a
warning in case there are any residual requests in the signaler rbtrees
at that point.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/intel_breadcrumbs.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_breadcrumbs.c
b/drivers/gpu/drm/i915/intel_breadcrumbs.c
index c9c46a538edb..b7006e90a167 100644
--- a/drivers/gpu/drm/i915/intel_breadcrumbs.c
+++ b/drivers/gpu/drm/i915/intel_breadcrumbs.c
@@ -623,6 +623,8 @@ void intel_engine_fini_breadcrumbs(struct intel_engine_cs
*engine)
{
struct intel_breadcrumbs *b = &engine->breadcrumbs;
+ WARN_ON(READ_ONCE(b->first_signal));
+ WARN_ON(!RB_EMPTY_ROOT(&b->signals));
if (!IS_ERR_OR_NULL(b->signaler))
kthread_stop(b->signaler);
Not sure if you are just testing out theories on the CI, but in any
case looks to me it wouldn't harm to have this in.
Only staring at the impossible, ruling out the unlikely. A leak here
would be caught by the request kmem_cache, but being explicit might help
in future.
Reviewed-by: Tvrtko Ursulin
Imagine if I added a
WARN_ON(READ_ONCE(b->first_waiter));
WARN_ON(!RB_EMPTY_ROOT(&b->waiters));
as well? Still r-b or go with a second patch for the afterthought?
It's the same thing conceptually so can expand and keep the r-b for what
I am concerned.
Regards,
Tvrtko
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [CI] drm/i915: Add a warning on shutdown if signal threads still active
When unloading the module, it is expected that we have finished
executing all requests and so the signal threads should be idle. Add a
warning in case there are any residual requests in the signaler rbtrees
at that point.
v2: We can also warn if there are any waiters
Signed-off-by: Chris Wilson
Reviewed-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/intel_breadcrumbs.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_breadcrumbs.c
b/drivers/gpu/drm/i915/intel_breadcrumbs.c
index c9c46a538edb..53ae7884babd 100644
--- a/drivers/gpu/drm/i915/intel_breadcrumbs.c
+++ b/drivers/gpu/drm/i915/intel_breadcrumbs.c
@@ -623,6 +623,12 @@ void intel_engine_fini_breadcrumbs(struct intel_engine_cs
*engine)
{
struct intel_breadcrumbs *b = &engine->breadcrumbs;
+ /* The engines should be idle and all requests accounted for! */
+ WARN_ON(READ_ONCE(b->first_wait));
+ WARN_ON(!RB_EMPTY_ROOT(&b->waiters));
+ WARN_ON(READ_ONCE(b->first_signal));
+ WARN_ON(!RB_EMPTY_ROOT(&b->signals));
+
if (!IS_ERR_OR_NULL(b->signaler))
kthread_stop(b->signaler);
--
2.10.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Do not log disabled planes in pipe config
Op 21-11-16 om 11:50 schreef Tvrtko Ursulin: > > On 18/11/2016 14:19, Ville Syrjälä wrote: >> On Fri, Nov 18, 2016 at 03:13:14PM +0100, Maarten Lankhorst wrote: >>> Op 18-11-16 om 12:40 schreef Tvrtko Ursulin: From: Tvrtko Ursulin It just says "plane X disabled" which does not seem very useful. Signed-off-by: Tvrtko Ursulin Cc: Maarten Lankhorst Cc: Ville Syrjälä >>> Could we remove plane dumping altogether? It's not safe to do so in the way >>> done by this function, and we could add missing things in >>> intel_plane_atomic_calc_changes. >> >> Yeah, might make sense to dump that stuff only from some plane code. And >> we should probably take a good look at Rob Clark's new state dumping stuff >> for that, so that we'll get it in some decently standardized format. >> >> I must admit that I didn't take a very good look at Rob's stuff, but >> maybe he already added the dumps to some useful places, and all we'd >> have to do is expand the dumps with our own derived plane state... > > Shall I leave it with you guys then? The most I would feel confident in this > area is to submit a patch which removes the plane debug from > intel_dump_pipe_config if that is broken. But not sure how useful would that > be without this other work you are discussing. Intel plane dumping is broken regardless, so feel I think it's good to submit a patch to nuke it. :) ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Use user, not driver, DRM_DEBUG for 2 context ioctls
For the context ioctls, we record a debug, but we use the
DRM_DEBUG_DRIVER for what is clearly a user, not driver, action. Use
DRM_DEBUG instead.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_gem_context.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_context.c
b/drivers/gpu/drm/i915/i915_gem_context.c
index 1f74ab266f6b..f93fd94a04ec 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/i915_gem_context.c
@@ -1027,7 +1027,7 @@ int i915_gem_context_create_ioctl(struct drm_device *dev,
void *data,
return PTR_ERR(ctx);
args->ctx_id = ctx->user_handle;
- DRM_DEBUG_DRIVER("HW context %d created\n", args->ctx_id);
+ DRM_DEBUG("HW context %d created\n", args->ctx_id);
return 0;
}
@@ -1060,7 +1060,7 @@ int i915_gem_context_destroy_ioctl(struct drm_device
*dev, void *data,
context_close(ctx);
mutex_unlock(&dev->struct_mutex);
- DRM_DEBUG_DRIVER("HW context %d destroyed\n", args->ctx_id);
+ DRM_DEBUG("HW context %d destroyed\n", args->ctx_id);
return 0;
}
--
2.10.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 00/37] drm: Deduplicate fb format information (v2)
Patches #2 and #3 are Reviewed-by: Christian König
.
The rest is Acked-by: Christian König .
Regards,
Christian.
Am 18.11.2016 um 20:52 schrieb ville.syrj...@linux.intel.com:
From: Ville Syrjälä
Second installment of my effort to remove the duplicated
depth/bpp/pixel_format from drm_framebuffer and just use
struct drm_format_info instead.
I tried to address all of the review feedback, and collect
up all the r-bs I already got. Thanks for the review, guys.
Changes since the last version are roughly:
* drm_framebuffer_init() now fails if the fb isn't properly prepared
* Applied mode cocciry all over to use fb->format more extensively
* Dropped a few i915 specific patches that were taken care of the
previous item
* Took up Laurent's idea that we can just compare the fb->format
pointers instead of comparing the fb->format->format values
* Added a new .get_format_info() hooks for drivers to provide custom
format information + an quick example patch how we'd hook it up
for i915 render compression support
Link to the previous version:
https://lists.freedesktop.org/archives/dri-devel/2016-November/124135.html
Entire series is available here:
git://github.com/vsyrjala/linux.git fb_format_dedup_2
Cc: Alex Deucher
Cc: Alexey Brodkin
Cc: Ben Skeggs
Cc: Ben Widawsky
Cc: Brian Starkey
Cc: "Christian König"
Cc: Dave Airlie
Cc: Gerd Hoffmann
Cc: intel-gfx@lists.freedesktop.org
Cc: Laurent Pinchart
Cc: linux-graphics-maintai...@vmware.com
Cc: Liviu Dudau
Cc: Mali DP Maintainers
Cc: Patrik Jakobsson
Cc: Paulo Zanoni
Cc: Sinclair Yeh
Cc: Thomas Hellstrom
Ville Syrjälä (37):
drm/i915: Add local 'fb' variables
drm/radeon: Add local 'fb' variables
drm/radeon: Use DIV_ROUND_UP()
drm/mgag200: Add local 'fb' variable
drm/ast: Add local 'fb' variables
drm/gma500: Add some local 'fb' variables
drm/cirrus: Add some local 'fb' variables
drm/arcpgu: Add local 'fb' variables
drm/arm: Add local 'fb' variables
drm/nouveau: Fix crtc->primary->fb vs. drm_fb fail
drm/nouveau: Add local 'fb' variables
drm/vmwgfx: Populate fb->dev before drm_framebuffer_init()
drm: Pass 'dev' to drm_helper_mode_fill_fb_struct()
drm/vmwgfx: Populate fb->pixel_format
drm/qxl: Call drm_helper_mode_fill_fb_struct() before
drm_framebuffer_init()
drm/virtio: Call drm_helper_mode_fill_fb_struct() before
drm_framebuffer_init()
drm/i915: Set fb->dev early on for inherited fbs
drm: Populate fb->dev from drm_helper_mode_fill_fb_struct()
drm: Store a pointer to drm_format_info under drm_framebuffer
drm/vmwgfx: Populate fb->format correctly
drm/i915: Populate fb->format early for inherited fbs
drm: Reject fbs w/o format info in drm_framebuffer_init()
drm: Replace drm_format_num_planes() with fb->format->num_planes
drm/i915: Eliminate the ugly 'fb?:' constructs from the ilk/skl wm
code
drm: Replace drm_format_plane_cpp() with fb->format->cpp[]
drm/fb_cma_helper: Replace drm_format_info() with fb->format
drm/nouveau: Use fb->format rather than drm_format_info()
drm/i915: Store a pointer to the pixel format info for fbc
drm: Add drm_framebuffer_plane_{width,height}()
drm/i915: Use drm_framebuffer_plane_{width,height}() where possible
drm: Nuke fb->depth
drm: Nuke fb->bits_per_pixel
drm: Nuke fb->pixel_format
drm: Replace 'format->format' comparisons to just 'format' comparisons
drm: Eliminate the useless "non-RGB fb" debug message
drm: Add mode_config .get_format_info() hook
drm/i915: Implement .get_format_info() hook for CCS
drivers/gpu/drm/amd/amdgpu/amdgpu_display.c | 2 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c | 4 +-
drivers/gpu/drm/amd/amdgpu/dce_v10_0.c | 6 +-
drivers/gpu/drm/amd/amdgpu/dce_v11_0.c | 6 +-
drivers/gpu/drm/amd/amdgpu/dce_v6_0.c | 6 +-
drivers/gpu/drm/amd/amdgpu/dce_v8_0.c | 6 +-
drivers/gpu/drm/arc/arcpgu_crtc.c | 3 +-
drivers/gpu/drm/arm/hdlcd_crtc.c| 18 ++--
drivers/gpu/drm/arm/malidp_planes.c | 10 +--
drivers/gpu/drm/armada/armada_crtc.c| 6 +-
drivers/gpu/drm/armada/armada_fb.c | 2 +-
drivers/gpu/drm/armada/armada_fbdev.c | 5 +-
drivers/gpu/drm/armada/armada_overlay.c | 6 +-
drivers/gpu/drm/ast/ast_fb.c| 4 +-
drivers/gpu/drm/ast/ast_main.c | 2 +-
drivers/gpu/drm/ast/ast_mode.c | 16 ++--
drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_layer.c | 2 +-
drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c | 22 ++---
drivers/gpu/drm/bochs/bochs_fbdev.c | 2 +-
drivers/gpu/drm/bochs/bochs_mm.c| 2 +-
drivers/gpu/drm/cirrus/cirrus_fbdev.c | 6 +-
drivers/gpu/drm/cirrus/cirrus_main.c| 2 +-
drivers/gpu/drm/cirrus/cirrus_mode.c| 9 +-
drivers/gpu/drm/drm_atomic.c
Re: [Intel-gfx] [i-g-t PATCH v8 3/5] igt/gem_wait: Use new igt_spin_batch
On 21 November 2016 at 10:25, Abdiel Janulgue
wrote:
> v7: Adapt to api rename
> v8: Restore sanitycheck wait on the recursive batch and
> avoid using C99 locals (Chris Wilson)
>
> Cc: Chris Wilson
> Cc: Daniel Vetter
> Signed-off-by: Abdiel Janulgue
> ---
> tests/gem_wait.c | 128
> ---
Hi,
I'm seeing failures on i5-5200U that I don't see with this patch
reverted. They all look like this:
(gem_wait:19238) CRITICAL: Test assertion failure function basic, file
../../intel-gpu-tools/tests/gem_wait.c:80:
(gem_wait:19238) CRITICAL: Failed assertion: __gem_wait(fd, &wait) == -62
(gem_wait:19238) CRITICAL: Last errno: 62, Timer expired
(gem_wait:19238) CRITICAL: error: 0 != -62
Stack trace:
#0 [__igt_fail_assert+0xf1]
#1 [basic+0x214]
#2 [+0x214]
Subtest busy-vebox failed.
DEBUG
(gem_wait:19238) ioctl-wrappers-DEBUG: Test requirement passed:
gem_has_ring(fd, ring)
(gem_wait:19238) igt-dummyload-DEBUG: Test requirement passed: nengine
(gem_wait:19238) CRITICAL: Test assertion failure function basic, file
../../intel-gpu-tools/tests/gem_wait.c:80:
(gem_wait:19238) CRITICAL: Failed assertion: __gem_wait(fd, &wait) == -62
(gem_wait:19238) CRITICAL: Last errno: 62, Timer expired
(gem_wait:19238) CRITICAL: error: 0 != -62
END
Subtest busy-vebox: FAIL (0.003s)
CI seems to have gained support for running BAT on IGT changes, but
that doesn't seem to have been wired to patchwork yet. Maybe you could
arrange for a CI run using a branch in your IGT tree? So this series
are tested on a wider array of HW.
Regards,
Tomeu
> 1 file changed, 8 insertions(+), 120 deletions(-)
>
> diff --git a/tests/gem_wait.c b/tests/gem_wait.c
> index b4127de..6332e76 100644
> --- a/tests/gem_wait.c
> +++ b/tests/gem_wait.c
> @@ -27,18 +27,6 @@
>
> #include "igt.h"
>
> -#include
> -#include
> -#include
> -
> -#define gettid() syscall(__NR_gettid)
> -#define sigev_notify_thread_id _sigev_un._tid
> -
> -#define LOCAL_I915_EXEC_BSD_SHIFT (13)
> -#define LOCAL_I915_EXEC_BSD_MASK (3 << LOCAL_I915_EXEC_BSD_SHIFT)
> -
> -#define ENGINE_MASK (I915_EXEC_RING_MASK | LOCAL_I915_EXEC_BSD_MASK)
> -
> static int __gem_wait(int fd, struct drm_i915_gem_wait *w)
> {
> int err;
> @@ -75,129 +63,33 @@ static void invalid_buf(int fd)
> igt_assert_eq(__gem_wait(fd, &wait), -ENOENT);
> }
>
> -static uint32_t *batch;
> -
> -static void sigiter(int sig, siginfo_t *info, void *arg)
> -{
> - *batch = MI_BATCH_BUFFER_END;
> - __sync_synchronize();
> -}
> -
> -#define MSEC_PER_SEC (1000)
> -#define USEC_PER_SEC (1000 * MSEC_PER_SEC)
> -#define NSEC_PER_SEC (1000 * USEC_PER_SEC)
> -
> #define BUSY 1
> #define HANG 2
> static void basic(int fd, unsigned engine, unsigned flags)
> {
> - const int gen = intel_gen(intel_get_drm_devid(fd));
> - struct drm_i915_gem_exec_object2 obj;
> - struct drm_i915_gem_relocation_entry reloc;
> - struct drm_i915_gem_execbuffer2 execbuf;
> struct drm_i915_gem_wait wait;
> - unsigned engines[16];
> - unsigned nengine;
> - int i, timeout;
> -
> - nengine = 0;
> - if (engine == -1) {
> - for_each_engine(fd, engine)
> - if (engine) engines[nengine++] = engine;
> - } else {
> - igt_require(gem_has_ring(fd, engine));
> - engines[nengine++] = engine;
> - }
> - igt_require(nengine);
> -
> - memset(&execbuf, 0, sizeof(execbuf));
> - execbuf.buffers_ptr = (uintptr_t)&obj;
> - execbuf.buffer_count = 1;
> -
> - memset(&obj, 0, sizeof(obj));
> - obj.handle = gem_create(fd, 4096);
> -
> - obj.relocs_ptr = (uintptr_t)&reloc;
> - obj.relocation_count = 1;
> - memset(&reloc, 0, sizeof(reloc));
> -
> - batch = gem_mmap__gtt(fd, obj.handle, 4096, PROT_WRITE);
> - gem_set_domain(fd, obj.handle,
> - I915_GEM_DOMAIN_GTT, I915_GEM_DOMAIN_GTT);
> -
> - reloc.target_handle = obj.handle; /* recurse */
> - reloc.presumed_offset = 0;
> - reloc.offset = sizeof(uint32_t);
> - reloc.delta = 0;
> - reloc.read_domains = I915_GEM_DOMAIN_COMMAND;
> - reloc.write_domain = 0;
> -
> - i = 0;
> - batch[i] = MI_BATCH_BUFFER_START;
> - if (gen >= 8) {
> - batch[i] |= 1 << 8 | 1;
> - batch[++i] = 0;
> - batch[++i] = 0;
> - } else if (gen >= 6) {
> - batch[i] |= 1 << 8;
> - batch[++i] = 0;
> - } else {
> - batch[i] |= 2 << 6;
> - batch[++i] = 0;
> - if (gen < 4) {
> - batch[i] |= 1;
> - reloc.delta = 1;
> - }
> - }
> + igt_spin_t *spin;
> + int timeout;
> + int wait_s = (flags == 0) ? NSEC_PER_SEC : 0;
>
> - for (i = 0; i < nengine; i++) {
> - ex
Re: [Intel-gfx] [PATCH] drm/i915: Use user, not driver, DRM_DEBUG for 2 context ioctls
On ma, 2016-11-21 at 11:31 +, Chris Wilson wrote: > For the context ioctls, we record a debug, but we use the > DRM_DEBUG_DRIVER for what is clearly a user, not driver, action. Use > DRM_DEBUG instead. > > Signed-off-by: Chris Wilson You could phrase the commit message to be more clear; "For user actions, we should use DRM_DEBUG. So ..." 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: Add a warning on shutdown if signal threads still active (rev2)
== Series Details == Series: drm/i915: Add a warning on shutdown if signal threads still active (rev2) URL : https://patchwork.freedesktop.org/series/15641/ State : success == Summary == Series 15641v2 drm/i915: Add a warning on shutdown if signal threads still active https://patchwork.freedesktop.org/api/1.0/series/15641/revisions/2/mbox/ fi-bdw-5557u total:244 pass:229 dwarn:0 dfail:0 fail:0 skip:15 fi-bsw-n3050 total:244 pass:204 dwarn:0 dfail:0 fail:0 skip:40 fi-bxt-t5700 total:244 pass:216 dwarn:0 dfail:0 fail:0 skip:28 fi-byt-j1900 total:244 pass:216 dwarn:0 dfail:0 fail:0 skip:28 fi-byt-n2820 total:244 pass:212 dwarn:0 dfail:0 fail:0 skip:32 fi-hsw-4770 total:244 pass:224 dwarn:0 dfail:0 fail:0 skip:20 fi-hsw-4770r total:244 pass:224 dwarn:0 dfail:0 fail:0 skip:20 fi-ilk-650 total:244 pass:191 dwarn:0 dfail:0 fail:0 skip:53 fi-ivb-3520m total:244 pass:222 dwarn:0 dfail:0 fail:0 skip:22 fi-ivb-3770 total:244 pass:222 dwarn:0 dfail:0 fail:0 skip:22 fi-kbl-7200u total:244 pass:222 dwarn:0 dfail:0 fail:0 skip:22 fi-skl-6260u total:244 pass:230 dwarn:0 dfail:0 fail:0 skip:14 fi-skl-6700hqtotal:244 pass:223 dwarn:0 dfail:0 fail:0 skip:21 fi-skl-6700k total:244 pass:222 dwarn:1 dfail:0 fail:0 skip:21 fi-skl-6770hqtotal:244 pass:230 dwarn:0 dfail:0 fail:0 skip:14 fi-snb-2520m total:244 pass:212 dwarn:0 dfail:0 fail:0 skip:32 fi-snb-2600 total:244 pass:211 dwarn:0 dfail:0 fail:0 skip:33 accd56d36a298219042d84ba9ee1b7bd66d1936c drm-intel-nightly: 2016y-11m-18d-22h-35m-31s UTC integration manifest 055cc1a drm/i915: Add a warning on shutdown if signal threads still active == Logs == For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_3066/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Use num_scalers instead of SKL_NUM_SCALERS in debugfs
On Sun, 2016-11-20 at 23:20 +0530, sunil.kam...@intel.com wrote:
> From: "A.Sunil Kamath"
>
> Better to use num_scaler itself while printing scaler_info.
> This fixes a bug of printing information for the missing
> second scaler on pipe C for SKL platform.
>
> Signed-off-by: A.Sunil Kamath
Reviewed-by: Ander Conselvan de Oliveira
> ---
> drivers/gpu/drm/i915/i915_debugfs.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
> b/drivers/gpu/drm/i915/i915_debugfs.c
> index 1cc971c..6c39881 100644
> --- a/drivers/gpu/drm/i915/i915_debugfs.c
> +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> @@ -3081,7 +3081,7 @@ static void intel_scaler_info(struct seq_file *m, struct
> intel_crtc *intel_crtc)
> pipe_config->scaler_state.scaler_users,
> pipe_config->scaler_state.scaler_id);
>
> - for (i = 0; i < SKL_NUM_SCALERS; i++) {
> + for (i = 0; i < num_scalers; i++) {
> struct intel_scaler *sc =
> &pipe_config-
> >scaler_state.scalers[i];
>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Remove plane config from intel_dump_pipe_config
From: Tvrtko Ursulin
I am told the way it is done is not safe.
Signed-off-by: Tvrtko Ursulin
Suggested-by: Maarten Lankhorst
Cc: Maarten Lankhorst
Cc: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_display.c | 38 +---
1 file changed, 1 insertion(+), 37 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index b7a7ed82c325..272a1473011c 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -12729,12 +12729,7 @@ static void intel_dump_pipe_config(struct intel_crtc
*crtc,
struct intel_crtc_state *pipe_config,
const char *context)
{
- struct drm_device *dev = crtc->base.dev;
- struct drm_i915_private *dev_priv = to_i915(dev);
- struct drm_plane *plane;
- struct intel_plane *intel_plane;
- struct intel_plane_state *state;
- struct drm_framebuffer *fb;
+ struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
DRM_DEBUG_KMS("[CRTC:%d:%s]%s\n",
crtc->base.base.id, crtc->base.name, context);
@@ -12822,37 +12817,6 @@ static void intel_dump_pipe_config(struct intel_crtc
*crtc,
pipe_config->dpll_hw_state.fp0,
pipe_config->dpll_hw_state.fp1);
}
-
- DRM_DEBUG_KMS("planes on this crtc\n");
- list_for_each_entry(plane, &dev->mode_config.plane_list, head) {
- struct drm_format_name_buf format_name;
- intel_plane = to_intel_plane(plane);
- if (intel_plane->pipe != crtc->pipe)
- continue;
-
- state = to_intel_plane_state(plane->state);
- fb = state->base.fb;
- if (!fb) {
- DRM_DEBUG_KMS("[PLANE:%d:%s] disabled, scaler_id =
%d\n",
- plane->base.id, plane->name,
state->scaler_id);
- continue;
- }
-
- DRM_DEBUG_KMS("[PLANE:%d:%s] FB:%d, fb = %ux%u format = %s\n",
- plane->base.id, plane->name,
- fb->base.id, fb->width, fb->height,
- drm_get_format_name(fb->pixel_format,
&format_name));
- if (INTEL_GEN(dev_priv) >= 9)
- DRM_DEBUG_KMS("\tscaler:%d src %dx%d+%d+%d dst
%dx%d+%d+%d\n",
- state->scaler_id,
- state->base.src.x1 >> 16,
- state->base.src.y1 >> 16,
- drm_rect_width(&state->base.src) >> 16,
- drm_rect_height(&state->base.src) >> 16,
- state->base.dst.x1, state->base.dst.y1,
- drm_rect_width(&state->base.dst),
- drm_rect_height(&state->base.dst));
- }
}
static bool check_digital_port_conflicts(struct drm_atomic_state *state)
--
2.7.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Move the release of PT page to the upper caller
a PT page will be released if it doesn't contain any meaningful mappings
during PPGTT page table shrinking. The PT entry in the upper level will
be set to a scratch entry.
Normally this works nicely, but in virtualization world, the PPGTT page
table is tracked by hypervisor. Releasing the PT page before modifying
the upper level PT entry would cause extra efforts.
As the tracked page has been returned to OS before losing track from
hypervisor, it could be written in any pattern. Hypervisor has to recognize
if a page is still being used as a PT page by validating these writing
patterns. It's complicated. Better let the guest modify the PT entry in
upper level PT first, then release the PT page.
Cc: Michał Winiarski
Cc: Michel Thierry
Cc: Joonas Lahtinen
Cc: Chris Wilson
Cc: Zhenyu Wang
Cc: Zhiyuan Lv
Signed-off-by: Zhi Wang
---
drivers/gpu/drm/i915/i915_gem_gtt.c | 18 +++---
1 file changed, 7 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index b4bde14..6cee707 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -736,10 +736,8 @@ static bool gen8_ppgtt_clear_pt(struct i915_address_space
*vm,
bitmap_clear(pt->used_ptes, pte, num_entries);
- if (bitmap_empty(pt->used_ptes, GEN8_PTES)) {
- free_pt(to_i915(vm->dev), pt);
+ if (bitmap_empty(pt->used_ptes, GEN8_PTES))
return true;
- }
pt_vaddr = kmap_px(pt);
@@ -775,13 +773,12 @@ static bool gen8_ppgtt_clear_pd(struct i915_address_space
*vm,
pde_vaddr = kmap_px(pd);
pde_vaddr[pde] = scratch_pde;
kunmap_px(ppgtt, pde_vaddr);
+ free_pt(to_i915(vm->dev), pt);
}
}
- if (bitmap_empty(pd->used_pdes, I915_PDES)) {
- free_pd(to_i915(vm->dev), pd);
+ if (bitmap_empty(pd->used_pdes, I915_PDES))
return true;
- }
return false;
}
@@ -795,7 +792,6 @@ static bool gen8_ppgtt_clear_pdp(struct i915_address_space
*vm,
uint64_t length)
{
struct i915_hw_ppgtt *ppgtt = i915_vm_to_ppgtt(vm);
- struct drm_i915_private *dev_priv = to_i915(vm->dev);
struct i915_page_directory *pd;
uint64_t pdpe;
gen8_ppgtt_pdpe_t *pdpe_vaddr;
@@ -813,16 +809,14 @@ static bool gen8_ppgtt_clear_pdp(struct
i915_address_space *vm,
pdpe_vaddr[pdpe] = scratch_pdpe;
kunmap_px(ppgtt, pdpe_vaddr);
}
+ free_pd(to_i915(vm->dev), pd);
}
}
mark_tlbs_dirty(ppgtt);
- if (USES_FULL_48BIT_PPGTT(dev_priv) &&
- bitmap_empty(pdp->used_pdpes, I915_PDPES_PER_PDP(dev_priv))) {
- free_pdp(dev_priv, pdp);
+ if (bitmap_empty(pdp->used_pdpes, I915_PDPES_PER_PDP(dev_priv)))
return true;
- }
return false;
}
@@ -836,6 +830,7 @@ static void gen8_ppgtt_clear_pml4(struct i915_address_space
*vm,
uint64_t start,
uint64_t length)
{
+ struct drm_i915_private *dev_priv = to_i915(vm->dev);
struct i915_hw_ppgtt *ppgtt = i915_vm_to_ppgtt(vm);
struct i915_page_directory_pointer *pdp;
uint64_t pml4e;
@@ -854,6 +849,7 @@ static void gen8_ppgtt_clear_pml4(struct i915_address_space
*vm,
pml4e_vaddr = kmap_px(pml4);
pml4e_vaddr[pml4e] = scratch_pml4e;
kunmap_px(ppgtt, pml4e_vaddr);
+ free_pdp(dev_priv, pdp);
}
}
}
--
1.9.1
___
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: Use num_scalers instead of SKL_NUM_SCALERS in debugfs
On Sun, 2016-11-20 at 18:16 +, Patchwork wrote: > == Series Details == > > Series: drm/i915: Use num_scalers instead of SKL_NUM_SCALERS in debugfs > URL : https://patchwork.freedesktop.org/series/15621/ > State : success > > == Summary == > > Series 15621v1 drm/i915: Use num_scalers instead of SKL_NUM_SCALERS in debugfs > https://patchwork.freedesktop.org/api/1.0/series/15621/revisions/1/mbox/ > > > fi-bdw-5557u total:244 pass:229 dwarn:0 dfail:0 fail:0 skip:15 > fi-bsw-n3050 total:244 pass:204 dwarn:0 dfail:0 fail:0 skip:40 > fi-byt-j1900 total:244 pass:216 dwarn:0 dfail:0 fail:0 skip:28 > fi-byt-n2820 total:244 pass:212 dwarn:0 dfail:0 fail:0 skip:32 > fi-hsw-4770 total:244 pass:224 dwarn:0 dfail:0 fail:0 skip:20 > fi-hsw-4770r total:244 pass:224 dwarn:0 dfail:0 fail:0 skip:20 > fi-ilk-650 total:244 pass:191 dwarn:0 dfail:0 fail:0 skip:53 > fi-ivb-3520m total:244 pass:222 dwarn:0 dfail:0 fail:0 skip:22 > fi-ivb-3770 total:244 pass:222 dwarn:0 dfail:0 fail:0 skip:22 > fi-kbl-7200u total:244 pass:222 dwarn:0 dfail:0 fail:0 skip:22 > fi-skl-6260u total:244 pass:230 dwarn:0 dfail:0 fail:0 skip:14 > fi-skl-6700hqtotal:244 pass:223 dwarn:0 dfail:0 fail:0 skip:21 > fi-skl-6700k total:244 pass:222 dwarn:1 dfail:0 fail:0 skip:21 > fi-skl-6770hqtotal:244 pass:230 dwarn:0 dfail:0 fail:0 skip:14 > fi-snb-2520m total:244 pass:212 dwarn:0 dfail:0 fail:0 skip:32 > fi-snb-2600 total:244 pass:211 dwarn:0 dfail:0 fail:0 skip:33 > > accd56d36a298219042d84ba9ee1b7bd66d1936c drm-intel-nightly: 2016y-11m-18d-22h- > 35m-31s UTC integration manifest > da14388 drm/i915: Use num_scalers instead of SKL_NUM_SCALERS in debugfs > > == Logs == > > For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_3064/ Pushed. Thankd for the patch. Ander ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [i-g-t PATCH v8 3/5] igt/gem_wait: Use new igt_spin_batch
On 11/21/2016 01:33 PM, Tomeu Vizoso wrote:
> On 21 November 2016 at 10:25, Abdiel Janulgue
> wrote:
>> v7: Adapt to api rename
>> v8: Restore sanitycheck wait on the recursive batch and
>> avoid using C99 locals (Chris Wilson)
>>
>> Cc: Chris Wilson
>> Cc: Daniel Vetter
>> Signed-off-by: Abdiel Janulgue
>> ---
>> tests/gem_wait.c | 128
>> ---
>
> Hi,
>
> I'm seeing failures on i5-5200U that I don't see with this patch
> reverted. They all look like this:
>
> (gem_wait:19238) CRITICAL: Test assertion failure function basic, file
> ../../intel-gpu-tools/tests/gem_wait.c:80:
> (gem_wait:19238) CRITICAL: Failed assertion: __gem_wait(fd, &wait) == -62
> (gem_wait:19238) CRITICAL: Last errno: 62, Timer expired
> (gem_wait:19238) CRITICAL: error: 0 != -62
> Stack trace:
> #0 [__igt_fail_assert+0xf1]
> #1 [basic+0x214]
> #2 [+0x214]
> Subtest busy-vebox failed.
> DEBUG
> (gem_wait:19238) ioctl-wrappers-DEBUG: Test requirement passed:
> gem_has_ring(fd, ring)
> (gem_wait:19238) igt-dummyload-DEBUG: Test requirement passed: nengine
> (gem_wait:19238) CRITICAL: Test assertion failure function basic, file
> ../../intel-gpu-tools/tests/gem_wait.c:80:
> (gem_wait:19238) CRITICAL: Failed assertion: __gem_wait(fd, &wait) == -62
> (gem_wait:19238) CRITICAL: Last errno: 62, Timer expired
> (gem_wait:19238) CRITICAL: error: 0 != -62
> END
> Subtest busy-vebox: FAIL (0.003s)
>
> CI seems to have gained support for running BAT on IGT changes, but
> that doesn't seem to have been wired to patchwork yet. Maybe you could
> arrange for a CI run using a branch in your IGT tree? So this series
> are tested on a wider array of HW.
Thanks for catching this again. Just tested the previous revision on our
CI farm last week. Unfortunately, we have limited bandwidth at the
moment of sending every update manually. Hopefully when we do gain BAT
on IGT change, this will mitigate the problem a bit.
Anyway, please test the following patch. That should hopefully fix the
wait issue.
- Abdiel
>
> Regards,
>
> Tomeu
>
>> 1 file changed, 8 insertions(+), 120 deletions(-)
>>
>> diff --git a/tests/gem_wait.c b/tests/gem_wait.c
>> index b4127de..6332e76 100644
>> --- a/tests/gem_wait.c
>> +++ b/tests/gem_wait.c
>> @@ -27,18 +27,6 @@
>>
>> #include "igt.h"
>>
>> -#include
>> -#include
>> -#include
>> -
>> -#define gettid() syscall(__NR_gettid)
>> -#define sigev_notify_thread_id _sigev_un._tid
>> -
>> -#define LOCAL_I915_EXEC_BSD_SHIFT (13)
>> -#define LOCAL_I915_EXEC_BSD_MASK (3 << LOCAL_I915_EXEC_BSD_SHIFT)
>> -
>> -#define ENGINE_MASK (I915_EXEC_RING_MASK | LOCAL_I915_EXEC_BSD_MASK)
>> -
>> static int __gem_wait(int fd, struct drm_i915_gem_wait *w)
>> {
>> int err;
>> @@ -75,129 +63,33 @@ static void invalid_buf(int fd)
>> igt_assert_eq(__gem_wait(fd, &wait), -ENOENT);
>> }
>>
>> -static uint32_t *batch;
>> -
>> -static void sigiter(int sig, siginfo_t *info, void *arg)
>> -{
>> - *batch = MI_BATCH_BUFFER_END;
>> - __sync_synchronize();
>> -}
>> -
>> -#define MSEC_PER_SEC (1000)
>> -#define USEC_PER_SEC (1000 * MSEC_PER_SEC)
>> -#define NSEC_PER_SEC (1000 * USEC_PER_SEC)
>> -
>> #define BUSY 1
>> #define HANG 2
>> static void basic(int fd, unsigned engine, unsigned flags)
>> {
>> - const int gen = intel_gen(intel_get_drm_devid(fd));
>> - struct drm_i915_gem_exec_object2 obj;
>> - struct drm_i915_gem_relocation_entry reloc;
>> - struct drm_i915_gem_execbuffer2 execbuf;
>> struct drm_i915_gem_wait wait;
>> - unsigned engines[16];
>> - unsigned nengine;
>> - int i, timeout;
>> -
>> - nengine = 0;
>> - if (engine == -1) {
>> - for_each_engine(fd, engine)
>> - if (engine) engines[nengine++] = engine;
>> - } else {
>> - igt_require(gem_has_ring(fd, engine));
>> - engines[nengine++] = engine;
>> - }
>> - igt_require(nengine);
>> -
>> - memset(&execbuf, 0, sizeof(execbuf));
>> - execbuf.buffers_ptr = (uintptr_t)&obj;
>> - execbuf.buffer_count = 1;
>> -
>> - memset(&obj, 0, sizeof(obj));
>> - obj.handle = gem_create(fd, 4096);
>> -
>> - obj.relocs_ptr = (uintptr_t)&reloc;
>> - obj.relocation_count = 1;
>> - memset(&reloc, 0, sizeof(reloc));
>> -
>> - batch = gem_mmap__gtt(fd, obj.handle, 4096, PROT_WRITE);
>> - gem_set_domain(fd, obj.handle,
>> - I915_GEM_DOMAIN_GTT, I915_GEM_DOMAIN_GTT);
>> -
>> - reloc.target_handle = obj.handle; /* recurse */
>> - reloc.presumed_offset = 0;
>> - reloc.offset = sizeof(uint32_t);
>> - reloc.delta = 0;
>> - reloc.read_domains = I915_GEM_DOMAIN_COMMAND;
>> - reloc.write_domain = 0;
>> -
>> - i = 0;
>> - batch[i] = MI_BATCH_BUFFER_START;
>> - if (gen >= 8) {
>> - batch[i] |= 1 << 8 | 1;
[Intel-gfx] [i-g-t PATCH v9 1/3] igt/gem_wait: Use new igt_spin_batch
v7: Adapt to api rename
v8: Restore sanitycheck wait on the recursive batch and
avoid using C99 locals (Chris Wilson)
v9: Explicitly quit the batch instead of timing out right away
Cc: Chris Wilson
Cc: Daniel Vetter
Cc: Tomeu Vizoso
Signed-off-by: Abdiel Janulgue
---
tests/gem_wait.c | 126 ---
1 file changed, 7 insertions(+), 119 deletions(-)
diff --git a/tests/gem_wait.c b/tests/gem_wait.c
index b4127de..27d13f5 100644
--- a/tests/gem_wait.c
+++ b/tests/gem_wait.c
@@ -27,18 +27,6 @@
#include "igt.h"
-#include
-#include
-#include
-
-#define gettid() syscall(__NR_gettid)
-#define sigev_notify_thread_id _sigev_un._tid
-
-#define LOCAL_I915_EXEC_BSD_SHIFT (13)
-#define LOCAL_I915_EXEC_BSD_MASK (3 << LOCAL_I915_EXEC_BSD_SHIFT)
-
-#define ENGINE_MASK (I915_EXEC_RING_MASK | LOCAL_I915_EXEC_BSD_MASK)
-
static int __gem_wait(int fd, struct drm_i915_gem_wait *w)
{
int err;
@@ -75,89 +63,18 @@ static void invalid_buf(int fd)
igt_assert_eq(__gem_wait(fd, &wait), -ENOENT);
}
-static uint32_t *batch;
-
-static void sigiter(int sig, siginfo_t *info, void *arg)
-{
- *batch = MI_BATCH_BUFFER_END;
- __sync_synchronize();
-}
-
-#define MSEC_PER_SEC (1000)
-#define USEC_PER_SEC (1000 * MSEC_PER_SEC)
-#define NSEC_PER_SEC (1000 * USEC_PER_SEC)
-
#define BUSY 1
#define HANG 2
static void basic(int fd, unsigned engine, unsigned flags)
{
- const int gen = intel_gen(intel_get_drm_devid(fd));
- struct drm_i915_gem_exec_object2 obj;
- struct drm_i915_gem_relocation_entry reloc;
- struct drm_i915_gem_execbuffer2 execbuf;
struct drm_i915_gem_wait wait;
- unsigned engines[16];
- unsigned nengine;
- int i, timeout;
-
- nengine = 0;
- if (engine == -1) {
- for_each_engine(fd, engine)
- if (engine) engines[nengine++] = engine;
- } else {
- igt_require(gem_has_ring(fd, engine));
- engines[nengine++] = engine;
- }
- igt_require(nengine);
-
- memset(&execbuf, 0, sizeof(execbuf));
- execbuf.buffers_ptr = (uintptr_t)&obj;
- execbuf.buffer_count = 1;
-
- memset(&obj, 0, sizeof(obj));
- obj.handle = gem_create(fd, 4096);
-
- obj.relocs_ptr = (uintptr_t)&reloc;
- obj.relocation_count = 1;
- memset(&reloc, 0, sizeof(reloc));
-
- batch = gem_mmap__gtt(fd, obj.handle, 4096, PROT_WRITE);
- gem_set_domain(fd, obj.handle,
- I915_GEM_DOMAIN_GTT, I915_GEM_DOMAIN_GTT);
-
- reloc.target_handle = obj.handle; /* recurse */
- reloc.presumed_offset = 0;
- reloc.offset = sizeof(uint32_t);
- reloc.delta = 0;
- reloc.read_domains = I915_GEM_DOMAIN_COMMAND;
- reloc.write_domain = 0;
-
- i = 0;
- batch[i] = MI_BATCH_BUFFER_START;
- if (gen >= 8) {
- batch[i] |= 1 << 8 | 1;
- batch[++i] = 0;
- batch[++i] = 0;
- } else if (gen >= 6) {
- batch[i] |= 1 << 8;
- batch[++i] = 0;
- } else {
- batch[i] |= 2 << 6;
- batch[++i] = 0;
- if (gen < 4) {
- batch[i] |= 1;
- reloc.delta = 1;
- }
- }
-
- for (i = 0; i < nengine; i++) {
- execbuf.flags &= ~ENGINE_MASK;
- execbuf.flags |= engines[i];
- gem_execbuf(fd, &execbuf);
- }
+ igt_spin_t *spin;
+ int timeout;
+ int wait_s = (flags == 0) ? NSEC_PER_SEC : -1;
+ spin = igt_spin_batch_new(fd, wait_s, engine, 0);
memset(&wait, 0, sizeof(wait));
- wait.bo_handle = obj.handle;
+ wait.bo_handle = spin->handle;
igt_assert_eq(__gem_wait(fd, &wait), -ETIME);
if (flags & BUSY) {
@@ -165,8 +82,7 @@ static void basic(int fd, unsigned engine, unsigned flags)
timeout = 120;
if ((flags & HANG) == 0) {
- *batch = MI_BATCH_BUFFER_END;
- __sync_synchronize();
+ igt_spin_batch_exit(spin);
timeout = 1;
}
@@ -174,30 +90,6 @@ static void basic(int fd, unsigned engine, unsigned flags)
while (__gem_wait(fd, &wait) == -ETIME)
igt_assert(igt_seconds_elapsed(&tv) < timeout);
} else {
- timer_t timer;
-
- if ((flags & HANG) == 0) {
- struct sigevent sev;
- struct sigaction act;
- struct itimerspec its;
-
- memset(&sev, 0, sizeof(sev));
- sev.sigev_notify = SIGEV_SIGNAL | SIGEV_THREAD_ID;
- sev.sigev_notify_thread_id = gettid();
- sev.sigev_signo = SIGRTMIN + 1;
- igt_assert(ti
[Intel-gfx] [PATCH v2] drm/i915: Stop the machine as we install the wedged submit_request handler
In order to prevent a race between the old callback submitting an
incomplete request and i915_gem_set_wedged() installing its nop handler,
we must ensure that the swap occurs when the machine is idle
(stop_machine).
v2: move context lost from out of BKL.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_gem.c | 26 +-
1 file changed, 21 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index d0dcaf35b429..e80ad6906fb4 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -38,6 +38,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -2770,6 +2771,12 @@ static void nop_submit_request(struct
drm_i915_gem_request *request)
static void i915_gem_cleanup_engine(struct intel_engine_cs *engine)
{
+ /* We need to be sure that no thread is running the old callback as
+* we install the nop handler (otherwise we would submit a request
+* to hardware that will never complete). In order to prevent this
+* race, we wait until the machine is idle before making the swap
+* (using stop_machine()).
+*/
engine->submit_request = nop_submit_request;
/* Mark all pending requests as complete so that any concurrent
@@ -2800,20 +2807,29 @@ static void i915_gem_cleanup_engine(struct
intel_engine_cs *engine)
}
}
-void i915_gem_set_wedged(struct drm_i915_private *dev_priv)
+static int __i915_gem_set_wedged_BKL(void *data)
{
+ struct drm_i915_private *i915 = data;
struct intel_engine_cs *engine;
enum intel_engine_id id;
+ for_each_engine(engine, i915, id)
+ i915_gem_cleanup_engine(engine);
+
+ return 0;
+}
+
+void i915_gem_set_wedged(struct drm_i915_private *dev_priv)
+{
lockdep_assert_held(&dev_priv->drm.struct_mutex);
set_bit(I915_WEDGED, &dev_priv->gpu_error.flags);
- i915_gem_context_lost(dev_priv);
- for_each_engine(engine, dev_priv, id)
- i915_gem_cleanup_engine(engine);
- mod_delayed_work(dev_priv->wq, &dev_priv->gt.idle_work, 0);
+ stop_machine(__i915_gem_set_wedged_BKL, dev_priv, NULL);
+ i915_gem_context_lost(dev_priv);
i915_gem_retire_requests(dev_priv);
+
+ mod_delayed_work(dev_priv->wq, &dev_priv->gt.idle_work, 0);
}
static void
--
2.10.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 1/3] drm/i915: Cleanup i915_gem_restore_gtt_mappings()
On Fri, Nov 18, 2016 at 01:58:35PM +, Chris Wilson wrote:
> On Fri, Nov 18, 2016 at 03:36:45PM +0200, David Weinehall wrote:
> > On resume we unbind+bind our VMA-mappings. This patch simplifies
> > this a bit by introducing a restore_vma() helper. As a nice side-effect
> > this also makes the resume callgraph self-documenting.
> >
> > v2: move the helper to i915_gem_gtt.c since it's only used by
> > i915_gem_restore_gtt_mappings(), rename to restore_vma(),
> > and make static (Chris)
> >
> > Signed-off-by: David Weinehall
> > CC: Chris Wilson
> > ---
> > drivers/gpu/drm/i915/i915_gem_gtt.c | 17 +++--
> > 1 file changed, 11 insertions(+), 6 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c
> > b/drivers/gpu/drm/i915/i915_gem_gtt.c
> > index b4bde1452f2a..2711044e3bf2 100644
> > --- a/drivers/gpu/drm/i915/i915_gem_gtt.c
> > +++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
> > @@ -3277,6 +3277,16 @@ int i915_ggtt_enable_hw(struct drm_i915_private
> > *dev_priv)
> > return 0;
> > }
> >
> > +static bool restore_vma(struct i915_vma *vma)
> > +{
> > + if (i915_vma_is_pinned(vma)) {
> > + WARN_ON(i915_vma_bind(vma, vma->obj->cache_level, PIN_UPDATE));
> > + return true;
> > + } else {
> > + WARN_ON(i915_vma_unbind(vma));
> > + return false;
> > + }
> > +}
>
> Missed a blank line [checkpatch]
Dang.
Will you fix this manually for the merge, or do you want a fixed patch?
Kind regards, David
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 1/3] drm/i915: Cleanup i915_gem_restore_gtt_mappings()
On Mon, Nov 21, 2016 at 02:21:39PM +0200, David Weinehall wrote:
> On Fri, Nov 18, 2016 at 01:58:35PM +, Chris Wilson wrote:
> > On Fri, Nov 18, 2016 at 03:36:45PM +0200, David Weinehall wrote:
> > > On resume we unbind+bind our VMA-mappings. This patch simplifies
> > > this a bit by introducing a restore_vma() helper. As a nice side-effect
> > > this also makes the resume callgraph self-documenting.
> > >
> > > v2: move the helper to i915_gem_gtt.c since it's only used by
> > > i915_gem_restore_gtt_mappings(), rename to restore_vma(),
> > > and make static (Chris)
> > >
> > > Signed-off-by: David Weinehall
> > > CC: Chris Wilson
> > > ---
> > > drivers/gpu/drm/i915/i915_gem_gtt.c | 17 +++--
> > > 1 file changed, 11 insertions(+), 6 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c
> > > b/drivers/gpu/drm/i915/i915_gem_gtt.c
> > > index b4bde1452f2a..2711044e3bf2 100644
> > > --- a/drivers/gpu/drm/i915/i915_gem_gtt.c
> > > +++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
> > > @@ -3277,6 +3277,16 @@ int i915_ggtt_enable_hw(struct drm_i915_private
> > > *dev_priv)
> > > return 0;
> > > }
> > >
> > > +static bool restore_vma(struct i915_vma *vma)
> > > +{
> > > + if (i915_vma_is_pinned(vma)) {
> > > + WARN_ON(i915_vma_bind(vma, vma->obj->cache_level, PIN_UPDATE));
> > > + return true;
> > > + } else {
> > > + WARN_ON(i915_vma_unbind(vma));
> > > + return false;
> > > + }
> > > +}
> >
> > Missed a blank line [checkpatch]
>
> Dang.
>
> Will you fix this manually for the merge, or do you want a fixed patch?
I was looking at how we get out of the pm_runtime mess. In part, we hurt
ourselves because we are using wakeref_count to disable asserts, but it
also seems that pushing the optimisation to pm_runtime is the right
thing to do.
-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: Stop the machine as we install the wedged submit_request handler
In order to prevent a race between the old callback submitting an
incomplete request and i915_gem_set_wedged() installing its nop handler,
we must ensure that the swap occurs when the machine is idle
(stop_machine).
v2: move context lost from out of BKL.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_gem.c | 26 +-
1 file changed, 21 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index d0dcaf35b429..e80ad6906fb4 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -38,6 +38,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -2770,6 +2771,12 @@ static void nop_submit_request(struct
drm_i915_gem_request *request)
static void i915_gem_cleanup_engine(struct intel_engine_cs *engine)
{
+ /* We need to be sure that no thread is running the old callback as
+* we install the nop handler (otherwise we would submit a request
+* to hardware that will never complete). In order to prevent this
+* race, we wait until the machine is idle before making the swap
+* (using stop_machine()).
+*/
engine->submit_request = nop_submit_request;
/* Mark all pending requests as complete so that any concurrent
@@ -2800,20 +2807,29 @@ static void i915_gem_cleanup_engine(struct
intel_engine_cs *engine)
}
}
-void i915_gem_set_wedged(struct drm_i915_private *dev_priv)
+static int __i915_gem_set_wedged_BKL(void *data)
{
+ struct drm_i915_private *i915 = data;
struct intel_engine_cs *engine;
enum intel_engine_id id;
+ for_each_engine(engine, i915, id)
+ i915_gem_cleanup_engine(engine);
+
+ return 0;
+}
+
+void i915_gem_set_wedged(struct drm_i915_private *dev_priv)
+{
lockdep_assert_held(&dev_priv->drm.struct_mutex);
set_bit(I915_WEDGED, &dev_priv->gpu_error.flags);
- i915_gem_context_lost(dev_priv);
- for_each_engine(engine, dev_priv, id)
- i915_gem_cleanup_engine(engine);
- mod_delayed_work(dev_priv->wq, &dev_priv->gt.idle_work, 0);
+ stop_machine(__i915_gem_set_wedged_BKL, dev_priv, NULL);
+ i915_gem_context_lost(dev_priv);
i915_gem_retire_requests(dev_priv);
+
+ mod_delayed_work(dev_priv->wq, &dev_priv->gt.idle_work, 0);
}
static void
--
2.10.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 6/6] drm/i915: Wipe hang stats as an embedded struct
Chris Wilson writes: > On Wed, Nov 16, 2016 at 05:20:34PM +0200, Mika Kuoppala wrote: >> Bannable property, banned status, guilty and active counts are >> properties of i915_gem_context. Make them so. >> >> v2: rebase >> >> Cc: Chris Wilson >> Signed-off-by: Mika Kuoppala > > Been hesistating since the substruct might have helped, but after a few > reads, I'm happier with the conversion. > > Reviewed-by: Chris Wilson Whole series pushed. Thanks for review. -Mika > -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: Add more keywords to firmware loading message
Imre Deak writes:
> On ke, 2016-11-16 at 11:33 +0200, Mika Kuoppala wrote:
>> To find out what firmware we actually loaded (from dmesg) the explicit
>> 'dmc' and 'firmware' are missing from the info printout. Add them.
>>
>> Cc: Imre Deak
>> Signed-off-by: Mika Kuoppala
>
> Reviewed-by: Imre Deak
Pushed. Thanks for review.
>
>> ---
>> drivers/gpu/drm/i915/intel_csr.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/gpu/drm/i915/intel_csr.c
>> b/drivers/gpu/drm/i915/intel_csr.c
>> index d7a04bc..10e9abc 100644
>> --- a/drivers/gpu/drm/i915/intel_csr.c
>> +++ b/drivers/gpu/drm/i915/intel_csr.c
>> @@ -405,7 +405,7 @@ static void csr_load_work_fn(struct work_struct *work)
>>
>> intel_display_power_put(dev_priv, POWER_DOMAIN_INIT);
>>
>> -DRM_INFO("Finished loading %s (v%u.%u)\n",
>> +DRM_INFO("Finished loading DMC firmware %s (v%u.%u)\n",
>> dev_priv->csr.fw_path,
>> CSR_VERSION_MAJOR(csr->version),
>> CSR_VERSION_MINOR(csr->version));
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 36/37] drm: Add mode_config .get_format_info() hook
On Sun, Nov 20, 2016 at 10:13:10AM +0200, Laurent Pinchart wrote:
> Hi Ville,
>
> Thank you for the patch.
>
> On Friday 18 Nov 2016 21:53:12 ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä
> >
> > Allow drivers to return a custom drm_format_info structure for special
> > fb layouts. We'll use this for the compression control surface in i915.
> >
> > Cc: Ben Widawsky
> > Cc: intel-gfx@lists.freedesktop.org
> > Signed-off-by: Ville Syrjälä
> > ---
> > drivers/gpu/drm/drm_fb_cma_helper.c | 2 +-
> > drivers/gpu/drm/drm_fourcc.c | 25 +
> > drivers/gpu/drm/drm_framebuffer.c| 9 +++--
> > drivers/gpu/drm/drm_modeset_helper.c | 2 +-
> > include/drm/drm_fourcc.h | 6 ++
> > include/drm/drm_mode_config.h| 15 +++
> > 6 files changed, 55 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/drm_fb_cma_helper.c
> > b/drivers/gpu/drm/drm_fb_cma_helper.c index aab4465307ed..d7f8876cf5e9
> > 100644
> > --- a/drivers/gpu/drm/drm_fb_cma_helper.c
> > +++ b/drivers/gpu/drm/drm_fb_cma_helper.c
> > @@ -186,7 +186,7 @@ struct drm_framebuffer
> > *drm_fb_cma_create_with_funcs(struct drm_device *dev, int ret;
> > int i;
> >
> > - info = drm_format_info(mode_cmd->pixel_format);
> > + info = drm_get_format_info(dev, mode_cmd);
> > if (!info)
> > return ERR_PTR(-EINVAL);
> >
> > diff --git a/drivers/gpu/drm/drm_fourcc.c b/drivers/gpu/drm/drm_fourcc.c
> > index 90d2cc8da8eb..7cfaee689f0c 100644
> > --- a/drivers/gpu/drm/drm_fourcc.c
> > +++ b/drivers/gpu/drm/drm_fourcc.c
> > @@ -199,6 +199,31 @@ const struct drm_format_info *drm_format_info(u32
> > format) EXPORT_SYMBOL(drm_format_info);
> >
> > /**
> > + * drm_format_info - query information for a given framebuffer
> > configuration
>
> I assume you meant drm_get_format_info()
Yes.
>
> > + * @dev: DRM device
>
> Do we need the dev pointer ?
Not at the moment. I was thinking we might allow drivers to return a
different set of formats based on the device type, but I'm not sure
that's all that useful since drivers will have to check for unsupported
formats anyway in .fb_create(). The only use case might be if you need
to select between two different format info structs based on the device
type, because you simply can't tell the formats apart based on the
mode_cmd. But that sort of thing feels like a bad idea to me, and might
as well just require that you must be able to tell formats that require
different format intos apart based on the mode_cmd (eg. by having
different modifiers on them).
So I guess we could just drop the 'dev' argument to make it harder for
people to make that sort of mistake.
>
> > + * @mode_cmd: metadata from the userspace fb creation request
> > + *
> > + * Returns:
> > + * The instance of struct drm_format_info that describes the pixel format,
> > or
> > + * NULL if the format is unsupported.
>
> It would be useful to document how this function differs from
> drm_format_info(). I also wonder whether it would make sense to completely
> replace drm_format_info() to avoid keeping two separate but very similar
> functions.
Yeah, that is basically what I was thinking. But I didn't feel like
doing that myself as it looked like that might involve actual work
in some of the drivers. I figured I'd leave it up to whoever cares
about said drivers.
>
> > + */
> > +const struct drm_format_info *
> > +drm_get_format_info(struct drm_device *dev,
> > + const struct drm_mode_fb_cmd2 *mode_cmd)
> > +{
> > + const struct drm_format_info *info = NULL;
> > +
> > + if (dev->mode_config.funcs->get_format_info)
> > + info = dev->mode_config.funcs->get_format_info(dev, mode_cmd);
> > +
> > + if (!info)
> > + info = drm_format_info(mode_cmd->pixel_format);
> > +
> > + return info;
> > +}
> > +EXPORT_SYMBOL(drm_get_format_info);
> > +
> > +/**
> > * drm_format_num_planes - get the number of planes for format
> > * @format: pixel format (DRM_FORMAT_*)
> > *
> > diff --git a/drivers/gpu/drm/drm_framebuffer.c
> > b/drivers/gpu/drm/drm_framebuffer.c index 94ddab41f24f..292930a5dcc2 100644
> > --- a/drivers/gpu/drm/drm_framebuffer.c
> > +++ b/drivers/gpu/drm/drm_framebuffer.c
> > @@ -126,11 +126,13 @@ int drm_mode_addfb(struct drm_device *dev,
> > return 0;
> > }
> >
> > -static int framebuffer_check(const struct drm_mode_fb_cmd2 *r)
> > +static int framebuffer_check(struct drm_device *dev,
> > +const struct drm_mode_fb_cmd2 *r)
> > {
> > const struct drm_format_info *info;
> > int i;
> >
> > + /* check if the format is supported at all */
> > info = __drm_format_info(r->pixel_format & ~DRM_FORMAT_BIG_ENDIAN);
> > if (!info) {
> > struct drm_format_name_buf format_name;
> > @@ -140,6 +142,9 @@ static int framebuffer_check(const struct
> > drm_mode_fb_cmd2 *r) return -EINVAL;
> > }
> >
> > + /* now let the driver pick i
Re: [Intel-gfx] [PATCH 36/37] drm: Add mode_config .get_format_info() hook
Hi Ville,
On Monday 21 Nov 2016 15:18:23 Ville Syrjälä wrote:
> On Sun, Nov 20, 2016 at 10:13:10AM +0200, Laurent Pinchart wrote:
> > On Friday 18 Nov 2016 21:53:12 ville.syrj...@linux.intel.com wrote:
> >> From: Ville Syrjälä
> >>
> >> Allow drivers to return a custom drm_format_info structure for special
> >> fb layouts. We'll use this for the compression control surface in i915.
> >>
> >> Cc: Ben Widawsky
> >> Cc: intel-gfx@lists.freedesktop.org
> >> Signed-off-by: Ville Syrjälä
> >> ---
> >>
> >> drivers/gpu/drm/drm_fb_cma_helper.c | 2 +-
> >> drivers/gpu/drm/drm_fourcc.c | 25 +
> >> drivers/gpu/drm/drm_framebuffer.c| 9 +++--
> >> drivers/gpu/drm/drm_modeset_helper.c | 2 +-
> >> include/drm/drm_fourcc.h | 6 ++
> >> include/drm/drm_mode_config.h| 15 +++
> >> 6 files changed, 55 insertions(+), 4 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/drm_fb_cma_helper.c
> >> b/drivers/gpu/drm/drm_fb_cma_helper.c index aab4465307ed..d7f8876cf5e9
> >> 100644
> >> --- a/drivers/gpu/drm/drm_fb_cma_helper.c
> >> +++ b/drivers/gpu/drm/drm_fb_cma_helper.c
> >> @@ -186,7 +186,7 @@ struct drm_framebuffer
> >> *drm_fb_cma_create_with_funcs(struct drm_device *dev, int ret;
> >>
> >>int i;
> >>
> >> - info = drm_format_info(mode_cmd->pixel_format);
> >> + info = drm_get_format_info(dev, mode_cmd);
> >>if (!info)
> >>return ERR_PTR(-EINVAL);
> >>
> >> diff --git a/drivers/gpu/drm/drm_fourcc.c b/drivers/gpu/drm/drm_fourcc.c
> >> index 90d2cc8da8eb..7cfaee689f0c 100644
> >> --- a/drivers/gpu/drm/drm_fourcc.c
> >> +++ b/drivers/gpu/drm/drm_fourcc.c
> >> @@ -199,6 +199,31 @@ const struct drm_format_info *drm_format_info(u32
> >> format)
> >> EXPORT_SYMBOL(drm_format_info);
> >>
> >> /**
> >> + * drm_format_info - query information for a given framebuffer
> >> configuration
> >
> > I assume you meant drm_get_format_info()
>
> Yes.
>
> >> + * @dev: DRM device
> >
> > Do we need the dev pointer ?
>
> Not at the moment. I was thinking we might allow drivers to return a
> different set of formats based on the device type, but I'm not sure
> that's all that useful since drivers will have to check for unsupported
> formats anyway in .fb_create(). The only use case might be if you need
> to select between two different format info structs based on the device
> type, because you simply can't tell the formats apart based on the
> mode_cmd. But that sort of thing feels like a bad idea to me, and might
> as well just require that you must be able to tell formats that require
> different format intos apart based on the mode_cmd (eg. by having
> different modifiers on them).
>
> So I guess we could just drop the 'dev' argument to make it harder for
> people to make that sort of mistake.
I think that's a good idea, yes.
> >> + * @mode_cmd: metadata from the userspace fb creation request
> >> + *
> >> + * Returns:
> >> + * The instance of struct drm_format_info that describes the pixel
> >> format, or
> >> + * NULL if the format is unsupported.
> >
> > It would be useful to document how this function differs from
> > drm_format_info(). I also wonder whether it would make sense to completely
> > replace drm_format_info() to avoid keeping two separate but very similar
> > functions.
>
> Yeah, that is basically what I was thinking. But I didn't feel like
> doing that myself as it looked like that might involve actual work
> in some of the drivers. I figured I'd leave it up to whoever cares
> about said drivers.
Which driver(s) are you thinking about ? If we want to make
drm_get_format_info() the default we obviously need to pass modifiers
directly, as in most cases we won't have a struct drm_mode_fb_cmd2 to pass to
the function. If we remove the dev argument you could just pass NULL modifiers
in most cases, I don't think that would involve much rework in drivers.
> >> + */
> >> +const struct drm_format_info *
> >> +drm_get_format_info(struct drm_device *dev,
> >> + const struct drm_mode_fb_cmd2 *mode_cmd)
> >> +{
> >> + const struct drm_format_info *info = NULL;
> >> +
> >> + if (dev->mode_config.funcs->get_format_info)
> >> + info = dev->mode_config.funcs->get_format_info(dev, mode_cmd);
> >> +
> >> + if (!info)
> >> + info = drm_format_info(mode_cmd->pixel_format);
> >> +
> >> + return info;
> >> +}
> >> +EXPORT_SYMBOL(drm_get_format_info);
--
Regards,
Laurent Pinchart
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC PATCH] drm/i915: replace platform flags with a platform enum
On Mon, 21 Nov 2016, Tvrtko Ursulin wrote:
> On 21/11/2016 09:27, Jani Nikula wrote:
>> On Fri, 18 Nov 2016, Tvrtko Ursulin wrote:
>>> On 18/11/2016 14:20, Jani Nikula wrote:
The platform flags in device info are (mostly) mutually
exclusive. Replace the flags with an enum. Add the platform enum also
for platforms that previously didn't have a flag, and give them codename
logging in dmesg.
>>>
>>> It just saddens me a bit that it prevents the compiler optimisation of
>>> our IS_THIS || IS_THAT || IS_TAT ugliness. :I On the basis on that I
>>> cannot quite make myself to support it, although it conceptually does
>>> make more sense.
>>
>> Personally I think making more sense conceptually trumps possible
>> compiler optimizations, especially when the code paths where this
>> actually matters are extremely rare. (Can you even point me at an
>> example where this makes a difference?)
>
> Without thinking deeply, all instances like IS_HASWELL || IS_BROADWELL,
> IS_SKYLAKE || IS_KABYLAKE, or IS_VALLEYVIEW || IS_CHERRYVIEW. Quick grep
> shows that there is at least around 170 instances of those. There might
> be more, I don't know. At least the ones I listed all currently
> translate to a single conditional in the generated code.
>
> I am not saying these are all on performance critical paths or anything,
> just that on balance, for me the sweetness of the optimisation cancels
> out the ugliness of the code (which is often unavoidable). Losing that
> and ending up with compare ladders in the code would just be a bit sad.
It doesn't persuade me much if something enables sweet optimizations
that nobody can perceive in real life.
Please also note that this brings decent codename debug prints to dmesg,
for all platforms, instead of a bunch of irrelevant is_platform = no for
every platform.
>> That said, does doing something silly like this make a difference:
>>
>> enum intel_platform {
>> INTEL_PLATFORM_UNINITIALIZED = 0,
>> INTEL_I830 = BIT(0),
>> INTEL_I845G = BIT(1),
>> INTEL_I85X = BIT(2),
>> INTEL_I865G = BIT(3),
>> INTEL_I915G = BIT(4),
>> INTEL_I915GM= BIT(5),
>> INTEL_I945G = BIT(6),
>> INTEL_I945GM= BIT(7),
>> INTEL_G33 = BIT(8),
>> INTEL_G4X = BIT(9),
>> INTEL_PINEVIEW = BIT(10),
>> INTEL_BROADWATER= BIT(11),
>> INTEL_CRESTLINE = BIT(12),
>> INTEL_IRONLAKE = BIT(13),
>> INTEL_SANDYBRIDGE = BIT(14),
>> INTEL_IVYBRIDGE = BIT(15),
>> INTEL_VALLEYVIEW= BIT(16),
>> INTEL_CHERRYVIEW= BIT(17),
>> INTEL_HASWELL = BIT(18),
>> INTEL_BROADWELL = BIT(19),
>> INTEL_SKYLAKE = BIT(20),
>> INTEL_BROXTON = BIT(21),
>> INTEL_KABYLAKE = BIT(22),
>> };
>
> I could live with that. Probably best to compare the code size before
> and after just to verify there are no surprises.
current nightly:
textdata bss dec hex filename
1254149 435282048 1299725 13d50d drivers/gpu/drm/i915/i915.ko
original platform enum patch:
textdata bss dec hex filename
1254456 435292048 1300033 13d641 drivers/gpu/drm/i915/i915.ko
the same with BIT() for platform enums:
textdata bss dec hex filename
34811672 435292048 34857249213e121 drivers/gpu/drm/i915/i915.ko
Holy cow, what happened there?!
Anyway the nightly -> original patch change is just a 300 byte increase
in text size.
BR,
Jani.
--
Jani Nikula, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Don't deref context->file_priv ERR_PTR upon reset
When a user context is closed, it's file_priv backpointer is replaced by
ERR_PTR(-EBADF); be careful not to chase this invalid pointer after a
hang and a GPU reset.
Signed-off-by: Chris Wilson
Fixes: b083a0870c79 ("drm/i915: Add per client max context ban limit")
Cc: Mika Kuoppala
---
drivers/gpu/drm/i915/i915_gem.c | 12
1 file changed, 4 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index b850e66c2f83..d75196b86693 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -2647,16 +2647,12 @@ static void i915_gem_context_mark_guilty(struct
i915_gem_context *ctx)
ctx->name, ctx->ban_score,
yesno(ctx->banned));
- if (!ctx->file_priv)
+ if (!ctx->banned || IS_ERR_OR_NULL(ctx->file_priv))
return;
- if (ctx->banned) {
- ctx->file_priv->context_bans++;
-
- DRM_DEBUG_DRIVER("client %s has has %d context banned\n",
-ctx->name,
-ctx->file_priv->context_bans);
- }
+ ctx->file_priv->context_bans++;
+ DRM_DEBUG_DRIVER("client %s has had %d context banned\n",
+ctx->name, ctx->file_priv->context_bans);
}
static void i915_gem_context_mark_innocent(struct i915_gem_context *ctx)
--
2.10.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 37/37] drm/i915: Implement .get_format_info() hook for CCS
On Mon, Nov 21, 2016 at 08:42:13AM +, Tvrtko Ursulin wrote:
>
> Hi,
>
> On 18/11/2016 19:53, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä
> >
> > By providing our own format information for the CCS formats, we should
> > be able to make framebuffer_check() do the right thing for the CCS
> > surface as well.
> >
> > Note that we'll return the same format info for both Y and Yf tiled
> > format as that's what happens with the non-CCS Y vs. Yf as well. If
> > desired, we could potentially return a unique pointer for each
> > pixel_format+tiling+ccs combination, in which case we immediately be
> > able to tell if any of that stuff changed by just comparing the
> > pointers. But that does sound a bit wasteful space wise.
> >
> > Cc: Ben Widawsky
> > Cc: intel-gfx@lists.freedesktop.org
> > Signed-off-by: Ville Syrjälä
> > ---
> > drivers/gpu/drm/i915/intel_display.c | 37
> >
> > include/uapi/drm/drm_fourcc.h| 3 +++
> > 2 files changed, 40 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_display.c
> > b/drivers/gpu/drm/i915/intel_display.c
> > index 7b7135be3b9e..de6909770c68 100644
> > --- a/drivers/gpu/drm/i915/intel_display.c
> > +++ b/drivers/gpu/drm/i915/intel_display.c
> > @@ -2488,6 +2488,42 @@ static unsigned int
> > intel_fb_modifier_to_tiling(uint64_t fb_modifier)
> > }
> > }
> >
> > +static const struct drm_format_info ccs_formats[] = {
> > + { .format = DRM_FORMAT_XRGB, .depth = 24, .num_planes = 2, .cpp = {
> > 4, 1, }, .hsub = 16, .vsub = 8, },
> > + { .format = DRM_FORMAT_XBGR, .depth = 24, .num_planes = 2, .cpp = {
> > 4, 1, }, .hsub = 16, .vsub = 8, },
> > + { .format = DRM_FORMAT_ARGB, .depth = 32, .num_planes = 2, .cpp = {
> > 4, 1, }, .hsub = 16, .vsub = 8, },
> > + { .format = DRM_FORMAT_ABGR, .depth = 32, .num_planes = 2, .cpp = {
> > 4, 1, }, .hsub = 16, .vsub = 8, },
> > +};
> > +
> > +static const struct drm_format_info *
> > +lookup_format_info(const struct drm_format_info formats[],
> > + int num_formats, u32 format)
> > +{
> > + int i;
> > +
> > + for (i = 0; i < num_formats; i++) {
> > + if (formats[i].format == format)
> > + return &formats[i];
> > + }
> > +
> > + return NULL;
> > +}
> > +
> > +static const struct drm_format_info *
> > +intel_get_format_info(struct drm_device *dev,
> > + const struct drm_mode_fb_cmd2 *cmd)
> > +{
> > + switch (cmd->modifier[0]) {
> > + case I915_FORMAT_MOD_Y_TILED_CCS:
> > + case I915_FORMAT_MOD_Yf_TILED_CCS:
> > + return lookup_format_info(ccs_formats,
> > + ARRAY_SIZE(ccs_formats),
> > + cmd->pixel_format);
> > + default:
> > + return NULL;
> > + }
> > +}
> > +
> > static int
> > intel_fill_fb_info(struct drm_i915_private *dev_priv,
> >struct drm_framebuffer *fb)
> > @@ -15922,6 +15958,7 @@ intel_user_framebuffer_create(struct drm_device
> > *dev,
> >
> > static const struct drm_mode_config_funcs intel_mode_funcs = {
> > .fb_create = intel_user_framebuffer_create,
> > + .get_format_info = intel_get_format_info,
> > .output_poll_changed = intel_fbdev_output_poll_changed,
> > .atomic_check = intel_atomic_check,
> > .atomic_commit = intel_atomic_commit,
> > diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
> > index a5890bf44c0a..2926d916f199 100644
> > --- a/include/uapi/drm/drm_fourcc.h
> > +++ b/include/uapi/drm/drm_fourcc.h
> > @@ -218,6 +218,9 @@ extern "C" {
> > */
> > #define I915_FORMAT_MOD_Yf_TILED fourcc_mod_code(INTEL, 3)
> >
> > +#define I915_FORMAT_MOD_Y_TILED_CCSfourcc_mod_code(INTEL, 4)
> > +#define I915_FORMAT_MOD_Yf_TILED_CCS fourcc_mod_code(INTEL, 5)
> > +
>
> I think when fb modifiers were started the idea was that we would later
> partition our vendor bit space for different classes of things and have
> helper functions to extract the tiling, etc, from them.
>
> For example have first 3-4 bits represent the tiling, then in this case
> one bit for CCS, etc.
>
> Have you considered that when adding these ones, and concluded this
> different scheme is better for some reason?
I haven't considered anything. And obviously this patch isn't meant
for inclusion as is. I just needed sometime to make it compile.
Generally I don't think adding magic meaning for individual bits for
things like this is a particularly good idea. Every time I've seen a
scheme like that it has eventually turned ugly on account of running
out of bits in one place or another.
--
Ville Syrjälä
Intel OTC
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 36/37] drm: Add mode_config .get_format_info() hook
On Mon, Nov 21, 2016 at 03:23:19PM +0200, Laurent Pinchart wrote:
> Hi Ville,
>
> On Monday 21 Nov 2016 15:18:23 Ville Syrjälä wrote:
> > On Sun, Nov 20, 2016 at 10:13:10AM +0200, Laurent Pinchart wrote:
> > > On Friday 18 Nov 2016 21:53:12 ville.syrj...@linux.intel.com wrote:
> > >> From: Ville Syrjälä
> > >>
> > >> Allow drivers to return a custom drm_format_info structure for special
> > >> fb layouts. We'll use this for the compression control surface in i915.
> > >>
> > >> Cc: Ben Widawsky
> > >> Cc: intel-gfx@lists.freedesktop.org
> > >> Signed-off-by: Ville Syrjälä
> > >> ---
> > >>
> > >> drivers/gpu/drm/drm_fb_cma_helper.c | 2 +-
> > >> drivers/gpu/drm/drm_fourcc.c | 25 +
> > >> drivers/gpu/drm/drm_framebuffer.c| 9 +++--
> > >> drivers/gpu/drm/drm_modeset_helper.c | 2 +-
> > >> include/drm/drm_fourcc.h | 6 ++
> > >> include/drm/drm_mode_config.h| 15 +++
> > >> 6 files changed, 55 insertions(+), 4 deletions(-)
> > >>
> > >> diff --git a/drivers/gpu/drm/drm_fb_cma_helper.c
> > >> b/drivers/gpu/drm/drm_fb_cma_helper.c index aab4465307ed..d7f8876cf5e9
> > >> 100644
> > >> --- a/drivers/gpu/drm/drm_fb_cma_helper.c
> > >> +++ b/drivers/gpu/drm/drm_fb_cma_helper.c
> > >> @@ -186,7 +186,7 @@ struct drm_framebuffer
> > >> *drm_fb_cma_create_with_funcs(struct drm_device *dev, int ret;
> > >>
> > >> int i;
> > >>
> > >> -info = drm_format_info(mode_cmd->pixel_format);
> > >> +info = drm_get_format_info(dev, mode_cmd);
> > >> if (!info)
> > >> return ERR_PTR(-EINVAL);
> > >>
> > >> diff --git a/drivers/gpu/drm/drm_fourcc.c b/drivers/gpu/drm/drm_fourcc.c
> > >> index 90d2cc8da8eb..7cfaee689f0c 100644
> > >> --- a/drivers/gpu/drm/drm_fourcc.c
> > >> +++ b/drivers/gpu/drm/drm_fourcc.c
> > >> @@ -199,6 +199,31 @@ const struct drm_format_info *drm_format_info(u32
> > >> format)
> > >> EXPORT_SYMBOL(drm_format_info);
> > >>
> > >> /**
> > >> + * drm_format_info - query information for a given framebuffer
> > >> configuration
> > >
> > > I assume you meant drm_get_format_info()
> >
> > Yes.
> >
> > >> + * @dev: DRM device
> > >
> > > Do we need the dev pointer ?
> >
> > Not at the moment. I was thinking we might allow drivers to return a
> > different set of formats based on the device type, but I'm not sure
> > that's all that useful since drivers will have to check for unsupported
> > formats anyway in .fb_create(). The only use case might be if you need
> > to select between two different format info structs based on the device
> > type, because you simply can't tell the formats apart based on the
> > mode_cmd. But that sort of thing feels like a bad idea to me, and might
> > as well just require that you must be able to tell formats that require
> > different format intos apart based on the mode_cmd (eg. by having
> > different modifiers on them).
> >
> > So I guess we could just drop the 'dev' argument to make it harder for
> > people to make that sort of mistake.
>
> I think that's a good idea, yes.
>
> > >> + * @mode_cmd: metadata from the userspace fb creation request
> > >> + *
> > >> + * Returns:
> > >> + * The instance of struct drm_format_info that describes the pixel
> > >> format, or
> > >> + * NULL if the format is unsupported.
> > >
> > > It would be useful to document how this function differs from
> > > drm_format_info(). I also wonder whether it would make sense to completely
> > > replace drm_format_info() to avoid keeping two separate but very similar
> > > functions.
> >
> > Yeah, that is basically what I was thinking. But I didn't feel like
> > doing that myself as it looked like that might involve actual work
> > in some of the drivers. I figured I'd leave it up to whoever cares
> > about said drivers.
>
> Which driver(s) are you thinking about ?
The ones that my cocci stuff couldn't convert over to fb->format.
> If we want to make
> drm_get_format_info() the default we obviously need to pass modifiers
> directly, as in most cases we won't have a struct drm_mode_fb_cmd2 to pass to
> the function. If we remove the dev argument you could just pass NULL
> modifiers
> in most cases, I don't think that would involve much rework in drivers.
fb->format is probably the right choice in most cases. But some drivers
seemed to have some kind of internal format info struct instead which
was in the way of doing a trivial conversion. I didn't want to start
doing non-trivial conversions since the series was already way too big
as is.
>
> > >> + */
> > >> +const struct drm_format_info *
> > >> +drm_get_format_info(struct drm_device *dev,
> > >> +const struct drm_mode_fb_cmd2 *mode_cmd)
> > >> +{
> > >> +const struct drm_format_info *info = NULL;
> > >> +
> > >> +if (dev->mode_config.funcs->get_format_info)
> > >> +info = dev->mode_config.funcs->get_format_info(dev,
> > >> mode_cmd);
> >
Re: [Intel-gfx] [PATCH 36/37] drm: Add mode_config .get_format_info() hook
Hi Ville, On Monday 21 Nov 2016 15:31:57 Ville Syrjälä wrote: > On Mon, Nov 21, 2016 at 03:23:19PM +0200, Laurent Pinchart wrote: > > On Monday 21 Nov 2016 15:18:23 Ville Syrjälä wrote: > >> On Sun, Nov 20, 2016 at 10:13:10AM +0200, Laurent Pinchart wrote: > >>> On Friday 18 Nov 2016 21:53:12 ville.syrj...@linux.intel.com wrote: > From: Ville Syrjälä > > Allow drivers to return a custom drm_format_info structure for > special fb layouts. We'll use this for the compression control surface > in i915. > > Cc: Ben Widawsky > Cc: intel-gfx@lists.freedesktop.org > Signed-off-by: Ville Syrjälä > --- > > drivers/gpu/drm/drm_fb_cma_helper.c | 2 +- > drivers/gpu/drm/drm_fourcc.c | 25 + > drivers/gpu/drm/drm_framebuffer.c| 9 +++-- > drivers/gpu/drm/drm_modeset_helper.c | 2 +- > include/drm/drm_fourcc.h | 6 ++ > include/drm/drm_mode_config.h| 15 +++ > 6 files changed, 55 insertions(+), 4 deletions(-) [snip] > diff --git a/drivers/gpu/drm/drm_fourcc.c > b/drivers/gpu/drm/drm_fourcc.c > index 90d2cc8da8eb..7cfaee689f0c 100644 > --- a/drivers/gpu/drm/drm_fourcc.c > +++ b/drivers/gpu/drm/drm_fourcc.c > @@ -199,6 +199,31 @@ const struct drm_format_info > *drm_format_info(u32 format) > EXPORT_SYMBOL(drm_format_info); > > /** > + * drm_format_info - query information for a given framebuffer > configuration > >>> > >>> I assume you meant drm_get_format_info() > >> > >> Yes. > >> > + * @dev: DRM device > >>> > >>> Do we need the dev pointer ? > >> > >> Not at the moment. I was thinking we might allow drivers to return a > >> different set of formats based on the device type, but I'm not sure > >> that's all that useful since drivers will have to check for unsupported > >> formats anyway in .fb_create(). The only use case might be if you need > >> to select between two different format info structs based on the device > >> type, because you simply can't tell the formats apart based on the > >> mode_cmd. But that sort of thing feels like a bad idea to me, and might > >> as well just require that you must be able to tell formats that require > >> different format intos apart based on the mode_cmd (eg. by having > >> different modifiers on them). > >> > >> So I guess we could just drop the 'dev' argument to make it harder for > >> people to make that sort of mistake. > > > > I think that's a good idea, yes. > > > + * @mode_cmd: metadata from the userspace fb creation request > + * > + * Returns: > + * The instance of struct drm_format_info that describes the pixel > format, or > + * NULL if the format is unsupported. > >>> > >>> It would be useful to document how this function differs from > >>> drm_format_info(). I also wonder whether it would make sense to > >>> completely replace drm_format_info() to avoid keeping two separate but > >>> very similar functions. > >> > >> Yeah, that is basically what I was thinking. But I didn't feel like > >> doing that myself as it looked like that might involve actual work > >> in some of the drivers. I figured I'd leave it up to whoever cares > >> about said drivers. > > > > Which driver(s) are you thinking about ? > > The ones that my cocci stuff couldn't convert over to fb->format. How about at least making drm_get_format_info() the default but converting what can be converted with coccinelle, and marking drm_format_info() as deprecated ? > > If we want to make drm_get_format_info() the default we obviously need to > > pass modifiers directly, as in most cases we won't have a struct > > drm_mode_fb_cmd2 to pass to the function. If we remove the dev argument > > you could just pass NULL modifiers in most cases, I don't think that would > > involve much rework in drivers. > > fb->format is probably the right choice in most cases. But some drivers > seemed to have some kind of internal format info struct instead which > was in the way of doing a trivial conversion. I didn't want to start > doing non-trivial conversions since the series was already way too big > as is. That's an interesting point I wanted to also mention. We have drivers that include formats information tables duplicating the one in the DRM core, with additional driver-specific information (see rcar_du_format_info() in drivers/gpu/drm/rcar-du/rcar_du_kms.c for instance). I wonder whether it would be possible to come up with a simple API that would allow providing those driver-specific data to the core, and get them back from the drm_get_format_info() function. -- Regards, Laurent Pinchart ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 37/37] drm/i915: Implement .get_format_info() hook for CCS
On 21/11/2016 13:27, Ville Syrjälä wrote:
On Mon, Nov 21, 2016 at 08:42:13AM +, Tvrtko Ursulin wrote:
Hi,
On 18/11/2016 19:53, ville.syrj...@linux.intel.com wrote:
From: Ville Syrjälä
By providing our own format information for the CCS formats, we should
be able to make framebuffer_check() do the right thing for the CCS
surface as well.
Note that we'll return the same format info for both Y and Yf tiled
format as that's what happens with the non-CCS Y vs. Yf as well. If
desired, we could potentially return a unique pointer for each
pixel_format+tiling+ccs combination, in which case we immediately be
able to tell if any of that stuff changed by just comparing the
pointers. But that does sound a bit wasteful space wise.
Cc: Ben Widawsky
Cc: intel-gfx@lists.freedesktop.org
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_display.c | 37
include/uapi/drm/drm_fourcc.h| 3 +++
2 files changed, 40 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 7b7135be3b9e..de6909770c68 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -2488,6 +2488,42 @@ static unsigned int intel_fb_modifier_to_tiling(uint64_t
fb_modifier)
}
}
+static const struct drm_format_info ccs_formats[] = {
+ { .format = DRM_FORMAT_XRGB, .depth = 24, .num_planes = 2, .cpp = {
4, 1, }, .hsub = 16, .vsub = 8, },
+ { .format = DRM_FORMAT_XBGR, .depth = 24, .num_planes = 2, .cpp = {
4, 1, }, .hsub = 16, .vsub = 8, },
+ { .format = DRM_FORMAT_ARGB, .depth = 32, .num_planes = 2, .cpp = {
4, 1, }, .hsub = 16, .vsub = 8, },
+ { .format = DRM_FORMAT_ABGR, .depth = 32, .num_planes = 2, .cpp = {
4, 1, }, .hsub = 16, .vsub = 8, },
+};
+
+static const struct drm_format_info *
+lookup_format_info(const struct drm_format_info formats[],
+ int num_formats, u32 format)
+{
+ int i;
+
+ for (i = 0; i < num_formats; i++) {
+ if (formats[i].format == format)
+ return &formats[i];
+ }
+
+ return NULL;
+}
+
+static const struct drm_format_info *
+intel_get_format_info(struct drm_device *dev,
+ const struct drm_mode_fb_cmd2 *cmd)
+{
+ switch (cmd->modifier[0]) {
+ case I915_FORMAT_MOD_Y_TILED_CCS:
+ case I915_FORMAT_MOD_Yf_TILED_CCS:
+ return lookup_format_info(ccs_formats,
+ ARRAY_SIZE(ccs_formats),
+ cmd->pixel_format);
+ default:
+ return NULL;
+ }
+}
+
static int
intel_fill_fb_info(struct drm_i915_private *dev_priv,
struct drm_framebuffer *fb)
@@ -15922,6 +15958,7 @@ intel_user_framebuffer_create(struct drm_device *dev,
static const struct drm_mode_config_funcs intel_mode_funcs = {
.fb_create = intel_user_framebuffer_create,
+ .get_format_info = intel_get_format_info,
.output_poll_changed = intel_fbdev_output_poll_changed,
.atomic_check = intel_atomic_check,
.atomic_commit = intel_atomic_commit,
diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
index a5890bf44c0a..2926d916f199 100644
--- a/include/uapi/drm/drm_fourcc.h
+++ b/include/uapi/drm/drm_fourcc.h
@@ -218,6 +218,9 @@ extern "C" {
*/
#define I915_FORMAT_MOD_Yf_TILED fourcc_mod_code(INTEL, 3)
+#define I915_FORMAT_MOD_Y_TILED_CCSfourcc_mod_code(INTEL, 4)
+#define I915_FORMAT_MOD_Yf_TILED_CCS fourcc_mod_code(INTEL, 5)
+
I think when fb modifiers were started the idea was that we would later
partition our vendor bit space for different classes of things and have
helper functions to extract the tiling, etc, from them.
For example have first 3-4 bits represent the tiling, then in this case
one bit for CCS, etc.
Have you considered that when adding these ones, and concluded this
different scheme is better for some reason?
I haven't considered anything. And obviously this patch isn't meant
for inclusion as is. I just needed sometime to make it compile.
No idea on the status of this series. Just noticed new modifiers by
accident and remembered the early discussions.
Generally I don't think adding magic meaning for individual bits for
things like this is a particularly good idea. Every time I've seen a
scheme like that it has eventually turned ugly on account of running
out of bits in one place or another.
I think in this case it might be much better. You just need one more
feature which intersects with tiling and ccs to make the list not very
manageable.
Regards,
Tvrtko
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC PATCH] drm/i915: replace platform flags with a platform enum
On Fri, Nov 18, 2016 at 04:20:32PM +0200, Jani Nikula wrote:
> The platform flags in device info are (mostly) mutually
> exclusive. Replace the flags with an enum. Add the platform enum also
> for platforms that previously didn't have a flag, and give them codename
> logging in dmesg.
>
> Pineview remains an exception, the platform being G33 for that.
>
> Signed-off-by: Jani Nikula
>
> ---
>
> Untested TGIF patch. ;)
> ---
> drivers/gpu/drm/i915/i915_debugfs.c | 1 +
> drivers/gpu/drm/i915/i915_drv.h | 76
> +++-
> drivers/gpu/drm/i915/i915_gpu_error.c| 1 +
> drivers/gpu/drm/i915/i915_pci.c | 53 +-
> drivers/gpu/drm/i915/intel_device_info.c | 40 -
> 5 files changed, 117 insertions(+), 54 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
> b/drivers/gpu/drm/i915/i915_debugfs.c
> index b7f42c448a44..982f0bdb768f 100644
> --- a/drivers/gpu/drm/i915/i915_debugfs.c
> +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> @@ -77,6 +77,7 @@ static int i915_capabilities(struct seq_file *m, void *data)
> const struct intel_device_info *info = INTEL_INFO(dev_priv);
>
> seq_printf(m, "gen: %d\n", INTEL_GEN(dev_priv));
> + seq_printf(m, "platform: %s\n", intel_platform_name(info->platform));
> seq_printf(m, "pch: %d\n", INTEL_PCH_TYPE(dev_priv));
> #define PRINT_FLAG(x) seq_printf(m, #x ": %s\n", yesno(info->x))
> DEV_INFO_FOR_EACH_FLAG(PRINT_FLAG);
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index be67aeece749..b8a1b66599dc 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -659,24 +659,8 @@ struct intel_csr {
> };
>
> #define DEV_INFO_FOR_EACH_FLAG(func) \
> - /* Keep is_* in chronological order */ \
> func(is_mobile); \
> - func(is_i85x); \
> - func(is_i915g); \
> - func(is_i945gm); \
> - func(is_g33); \
> - func(is_g4x); \
> func(is_pineview); \
> - func(is_broadwater); \
> - func(is_crestline); \
> - func(is_ivybridge); \
> - func(is_valleyview); \
> - func(is_cherryview); \
> - func(is_haswell); \
> - func(is_broadwell); \
> - func(is_skylake); \
> - func(is_broxton); \
> - func(is_kabylake); \
> func(is_alpha_support); \
> /* Keep has_* in alphabetical order */ \
> func(has_64bit_reloc); \
> @@ -726,6 +710,34 @@ static inline unsigned int sseu_subslice_total(const
> struct sseu_dev_info *sseu)
> return hweight8(sseu->slice_mask) * hweight8(sseu->subslice_mask);
> }
>
> +/* Keep in chronological order */
> +enum intel_platform {
> + INTEL_PLATFORM_UNINITIALIZED = 0,
> + INTEL_I830,
> + INTEL_I845G,
> + INTEL_I85X,
> + INTEL_I865G,
> + INTEL_I915G,
> + INTEL_I915GM,
> + INTEL_I945G,
> + INTEL_I945GM,
> + INTEL_G33,
> + INTEL_G4X,
> + INTEL_PINEVIEW,
> + INTEL_BROADWATER,
> + INTEL_CRESTLINE,
The order here is rather wonky.
Assuming we want to keep roughly to the gen based order, then we'd have:
G33/BLB
PNV
965G/BW
965GM/CL
G4X/ELK
GM45/CTG
OTOH if we want to order based on the chipset side of things (which
might be closer to a chronological order I believe) we would have:
965G/BW
965GM/CL
G33/BLB
PNV
G4X/ELK
GM45/CTG
Well, pnv might have to come after elk/ctg to actually to fit into
the chronological order correctly.
This also highlights the issue we're rather inconsistent with the
number vs. codename thing. I think if we want to keep using both we
should draw a clear line where we switch. I think I would at least
flip bw/cl over to the number scheme if we want to keep to the number
scheme for the older parts.
> + INTEL_IRONLAKE,
> + INTEL_SANDYBRIDGE,
> + INTEL_IVYBRIDGE,
> + INTEL_VALLEYVIEW,
> + INTEL_CHERRYVIEW,
> + INTEL_HASWELL,
> + INTEL_BROADWELL,
And as Chris noted this should be (based on either gen or
chronological order):
IVB
VLV
HSW
BDW
CHV
> + INTEL_SKYLAKE,
> + INTEL_BROXTON,
> + INTEL_KABYLAKE,
> +};
> +
--
Ville Syrjälä
Intel OTC
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 36/37] drm: Add mode_config .get_format_info() hook
On Mon, Nov 21, 2016 at 03:42:34PM +0200, Laurent Pinchart wrote: > Hi Ville, > > On Monday 21 Nov 2016 15:31:57 Ville Syrjälä wrote: > > On Mon, Nov 21, 2016 at 03:23:19PM +0200, Laurent Pinchart wrote: > > > On Monday 21 Nov 2016 15:18:23 Ville Syrjälä wrote: > > >> On Sun, Nov 20, 2016 at 10:13:10AM +0200, Laurent Pinchart wrote: > > >>> On Friday 18 Nov 2016 21:53:12 ville.syrj...@linux.intel.com wrote: > > From: Ville Syrjälä > > > > Allow drivers to return a custom drm_format_info structure for > > special fb layouts. We'll use this for the compression control surface > > in i915. > > > > Cc: Ben Widawsky > > Cc: intel-gfx@lists.freedesktop.org > > Signed-off-by: Ville Syrjälä > > --- > > > > drivers/gpu/drm/drm_fb_cma_helper.c | 2 +- > > drivers/gpu/drm/drm_fourcc.c | 25 + > > drivers/gpu/drm/drm_framebuffer.c| 9 +++-- > > drivers/gpu/drm/drm_modeset_helper.c | 2 +- > > include/drm/drm_fourcc.h | 6 ++ > > include/drm/drm_mode_config.h| 15 +++ > > 6 files changed, 55 insertions(+), 4 deletions(-) > > [snip] > > > diff --git a/drivers/gpu/drm/drm_fourcc.c > > b/drivers/gpu/drm/drm_fourcc.c > > index 90d2cc8da8eb..7cfaee689f0c 100644 > > --- a/drivers/gpu/drm/drm_fourcc.c > > +++ b/drivers/gpu/drm/drm_fourcc.c > > @@ -199,6 +199,31 @@ const struct drm_format_info > > *drm_format_info(u32 format) > > EXPORT_SYMBOL(drm_format_info); > > > > /** > > + * drm_format_info - query information for a given framebuffer > > configuration > > >>> > > >>> I assume you meant drm_get_format_info() > > >> > > >> Yes. > > >> > > + * @dev: DRM device > > >>> > > >>> Do we need the dev pointer ? > > >> > > >> Not at the moment. I was thinking we might allow drivers to return a > > >> different set of formats based on the device type, but I'm not sure > > >> that's all that useful since drivers will have to check for unsupported > > >> formats anyway in .fb_create(). The only use case might be if you need > > >> to select between two different format info structs based on the device > > >> type, because you simply can't tell the formats apart based on the > > >> mode_cmd. But that sort of thing feels like a bad idea to me, and might > > >> as well just require that you must be able to tell formats that require > > >> different format intos apart based on the mode_cmd (eg. by having > > >> different modifiers on them). > > >> > > >> So I guess we could just drop the 'dev' argument to make it harder for > > >> people to make that sort of mistake. > > > > > > I think that's a good idea, yes. > > > > > + * @mode_cmd: metadata from the userspace fb creation request > > + * > > + * Returns: > > + * The instance of struct drm_format_info that describes the pixel > > format, or > > + * NULL if the format is unsupported. > > >>> > > >>> It would be useful to document how this function differs from > > >>> drm_format_info(). I also wonder whether it would make sense to > > >>> completely replace drm_format_info() to avoid keeping two separate but > > >>> very similar functions. > > >> > > >> Yeah, that is basically what I was thinking. But I didn't feel like > > >> doing that myself as it looked like that might involve actual work > > >> in some of the drivers. I figured I'd leave it up to whoever cares > > >> about said drivers. > > > > > > Which driver(s) are you thinking about ? > > > > The ones that my cocci stuff couldn't convert over to fb->format. > > How about at least making drm_get_format_info() the default but converting > what can be converted with coccinelle, and marking drm_format_info() as > deprecated ? I think I already did everything except the "mark as deprecated" part. And adding that last bit into the patch would be trivial. > > > > If we want to make drm_get_format_info() the default we obviously need to > > > pass modifiers directly, as in most cases we won't have a struct > > > drm_mode_fb_cmd2 to pass to the function. If we remove the dev argument > > > you could just pass NULL modifiers in most cases, I don't think that would > > > involve much rework in drivers. > > > > fb->format is probably the right choice in most cases. But some drivers > > seemed to have some kind of internal format info struct instead which > > was in the way of doing a trivial conversion. I didn't want to start > > doing non-trivial conversions since the series was already way too big > > as is. > > That's an interesting point I wanted to also mention. We have drivers that > include formats information tables duplicating the one in the DRM core, with > additional driver-specific information (see rcar_du_format_info() in > drivers/gpu/drm/rcar-du/rcar_du_kms.c for instance). I wonder whether it > would > be possible to come up w
Re: [Intel-gfx] [PATCH 37/37] drm/i915: Implement .get_format_info() hook for CCS
On Fri, Nov 18, 2016 at 03:31:48PM -0800, Ben Widawsky wrote:
> On 16-11-18 21:53:13, Ville Syrjälä wrote:
> >From: Ville Syrjälä
> >
> >By providing our own format information for the CCS formats, we should
> >be able to make framebuffer_check() do the right thing for the CCS
> >surface as well.
> >
>
> I was hoping to see that patch as well :-). If you're adding the new fb
> modifiers, I think it'd make sense to make it part of this series.
> Alternatively, I can take 36, and 37 and make it part of my series, then
> integrate that last bit. It's up to you.
>
> >Note that we'll return the same format info for both Y and Yf tiled
> >format as that's what happens with the non-CCS Y vs. Yf as well. If
> >desired, we could potentially return a unique pointer for each
> >pixel_format+tiling+ccs combination, in which case we immediately be
> >able to tell if any of that stuff changed by just comparing the
> >pointers. But that does sound a bit wasteful space wise.
> >
> >Cc: Ben Widawsky
> >Cc: intel-gfx@lists.freedesktop.org
> >Signed-off-by: Ville Syrjälä
>
> I have a comment below however, you can consider it:
> Reviewed-by: Ben Widawsky
>
> >---
> > drivers/gpu/drm/i915/intel_display.c | 37
> >
> > include/uapi/drm/drm_fourcc.h| 3 +++
> > 2 files changed, 40 insertions(+)
> >
> >diff --git a/drivers/gpu/drm/i915/intel_display.c
> >b/drivers/gpu/drm/i915/intel_display.c
> >index 7b7135be3b9e..de6909770c68 100644
> >--- a/drivers/gpu/drm/i915/intel_display.c
> >+++ b/drivers/gpu/drm/i915/intel_display.c
> >@@ -2488,6 +2488,42 @@ static unsigned int
> >intel_fb_modifier_to_tiling(uint64_t fb_modifier)
> > }
> > }
> >
> >+static const struct drm_format_info ccs_formats[] = {
> >+{ .format = DRM_FORMAT_XRGB, .depth = 24, .num_planes = 2, .cpp = {
> >4, 1, }, .hsub = 16, .vsub = 8, },
> >+{ .format = DRM_FORMAT_XBGR, .depth = 24, .num_planes = 2, .cpp = {
> >4, 1, }, .hsub = 16, .vsub = 8, },
> >+{ .format = DRM_FORMAT_ARGB, .depth = 32, .num_planes = 2, .cpp = {
> >4, 1, }, .hsub = 16, .vsub = 8, },
> >+{ .format = DRM_FORMAT_ABGR, .depth = 32, .num_planes = 2, .cpp = {
> >4, 1, }, .hsub = 16, .vsub = 8, },
> >+};
> >+
> >+static const struct drm_format_info *
> >+lookup_format_info(const struct drm_format_info formats[],
> >+ int num_formats, u32 format)
> >+{
> >+int i;
> >+
> >+for (i = 0; i < num_formats; i++) {
> >+if (formats[i].format == format)
> >+return &formats[i];
> >+}
> >+
> >+return NULL;
> >+}
> >+
> >+static const struct drm_format_info *
> >+intel_get_format_info(struct drm_device *dev,
> >+ const struct drm_mode_fb_cmd2 *cmd)
> >+{
> >+switch (cmd->modifier[0]) {
> >+case I915_FORMAT_MOD_Y_TILED_CCS:
> >+case I915_FORMAT_MOD_Yf_TILED_CCS:
> >+return lookup_format_info(ccs_formats,
> >+ ARRAY_SIZE(ccs_formats),
> >+ cmd->pixel_format);
> >+default:
> >+return NULL;
> >+}
> >+}
> >+
>
> It sort of seems like somewhat of a waste to provide this if implementations
> are
> allowed to return NULL. It's like saying, "DRM core will check stuff for you
> if
> you provide the info, but you don't have to do it if you don't want to."
The core will check the stuff anyway. The NULL just means "I don't have
any special requirements, so the core format info will be sufficient".
> If
> that's the case you may as well provide a driver hook to just do the check,
> ie.
> s/mod_funcs->get_format_info/mode_functs->check_format/
Drivers already have to do a bunch of checks in .fb_create(). In
addition the core does some basic sanity checks before the driver
even sees the mode_cmd (except for the new .get_format_info() hook
that is). I don't want every driver to have to duplicate all of these
basic sanity checks.
One alternative to this scheme would be have a helper function that
every driver would call in .fb_create() that would do these basic sanity
checks. That way we wouldn't need the extra hook, with a slight risk
that driver would forget to call the helper.
>
> > static int
> > intel_fill_fb_info(struct drm_i915_private *dev_priv,
> >struct drm_framebuffer *fb)
> >@@ -15922,6 +15958,7 @@ intel_user_framebuffer_create(struct drm_device *dev,
> >
> > static const struct drm_mode_config_funcs intel_mode_funcs = {
> > .fb_create = intel_user_framebuffer_create,
> >+.get_format_info = intel_get_format_info,
> > .output_poll_changed = intel_fbdev_output_poll_changed,
> > .atomic_check = intel_atomic_check,
> > .atomic_commit = intel_atomic_commit,
> >diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
> >index a5890bf44c0a..2926d916f199 100644
> >--- a/include/uapi/drm/drm_fourcc.h
> >+++ b/include/uapi/drm/drm_fourcc.h
> >@@ -218,6 +218,9 @@ extern "C" {
> >
Re: [Intel-gfx] [i-g-t PATCH v7 1/5] lib: Make signal helper definitions reusable
On 21 November 2016 at 10:25, Abdiel Janulgue
wrote:
> More and more test-cases are using this.
>
> Signed-off-by: Abdiel Janulgue
> ---
> lib/igt_aux.c | 11 ---
> lib/igt_aux.h | 10 ++
> lib/igt_core.c | 3 ---
> tests/drv_hangman.c | 1 -
> 4 files changed, 10 insertions(+), 15 deletions(-)
>
> diff --git a/lib/igt_aux.c b/lib/igt_aux.c
> index 421f6d4..b5ae854 100644
> --- a/lib/igt_aux.c
> +++ b/lib/igt_aux.c
> @@ -75,17 +75,6 @@
> * fit into any other topic.
> */
>
> -
> -/* signal interrupt helpers */
> -
> -#define MSEC_PER_SEC (1000)
> -#define USEC_PER_SEC (1000*MSEC_PER_SEC)
> -#define NSEC_PER_SEC (1000*USEC_PER_SEC)
> -
> -/* signal interrupt helpers */
> -#define gettid() syscall(__NR_gettid)
> -#define sigev_notify_thread_id _sigev_un._tid
I see a few more instances of these in other files. Could those be removed now?
Otherwise it looks good to me.
Regards,
Tomeu
> -
> static struct __igt_sigiter_global {
> pid_t tid;
> timer_t timer;
> diff --git a/lib/igt_aux.h b/lib/igt_aux.h
> index d30196b..d4da499 100644
> --- a/lib/igt_aux.h
> +++ b/lib/igt_aux.h
> @@ -35,6 +35,16 @@
> extern drm_intel_bo **trash_bos;
> extern int num_trash_bos;
>
> +/* signal interrupt helpers */
> +
> +#define MSEC_PER_SEC (1000)
> +#define USEC_PER_SEC (1000*MSEC_PER_SEC)
> +#define NSEC_PER_SEC (1000*USEC_PER_SEC)
> +
> +/* signal interrupt helpers */
> +#define gettid() syscall(__NR_gettid)
> +#define sigev_notify_thread_id _sigev_un._tid
> +
> /* auxialiary igt helpers from igt_aux.c */
> /* generally useful helpers */
> void igt_fork_signal_helper(void);
> diff --git a/lib/igt_core.c b/lib/igt_core.c
> index 9cd5f98..f64c809 100644
> --- a/lib/igt_core.c
> +++ b/lib/igt_core.c
> @@ -398,9 +398,6 @@ error:
> return -errno;
> }
>
> -#define MSEC_PER_SEC (1000)
> -#define USEC_PER_SEC (1000*MSEC_PER_SEC)
> -#define NSEC_PER_SEC (1000*USEC_PER_SEC)
> uint64_t igt_nsec_elapsed(struct timespec *start)
> {
> struct timespec now;
> diff --git a/tests/drv_hangman.c b/tests/drv_hangman.c
> index f80d65d..db0a077 100644
> --- a/tests/drv_hangman.c
> +++ b/tests/drv_hangman.c
> @@ -293,7 +293,6 @@ static void test_error_state_capture(unsigned ring_id,
> * case and it takes a lot more time to wrap, so the acthd can potentially
> keep
> * increasing for a long time
> */
> -#define NSEC_PER_SEC 10LL
> static void hangcheck_unterminated(void)
> {
> int fd;
> --
> 2.7.4
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [i-g-t PATCH v9 2/5] lib: add igt_dummyload
On 21 November 2016 at 10:25, Abdiel Janulgue wrote: > A lot of igt testcases need some GPU workload to make sure a race > window is big enough. Unfortunately having a fixed amount of > workload leads to spurious test failures or overly long runtimes > on some fast/slow platforms. This library contains functionality > to submit GPU workloads that should consume exactly a specific > amount of time. > > v2 : Add recursive batch feature from Chris > v3 : Drop auto-tuned stuff. Add bo dependecy to recursive batch > by adding a dummy reloc to the bo as suggested by Ville. > v4: Fix dependency reloc as write instead of read (Ville). > Fix wrong handling of batchbuffer start on ILK causing > test failure > v5: Convert kms_busy to use this api > v6: Add this library to docs > v7: Document global use of batch, reuse defines > Minor code cleanups. > Rename igt_spin_batch and igt_post_spin_batch to > igt_spin_batch_new and igt_spin_batch_free > respectively (Tomeu Vizoso). > Fix error in dependency relocation handling in HSW causing > tests to fail. > v8: Restore correct order of objects in the execbuffer. Batch > object should always be last. > v9 : Add helper to terminate batch manually > > Cc: Daniel Vetter > Cc: Ville Syrjälä > Cc: Chris Wilson > Cc: to...@tomeuvizoso.net > Signed-off-by: Abdiel Janulgue > --- > .../intel-gpu-tools/intel-gpu-tools-docs.xml | 1 + > lib/Makefile.sources | 2 + > lib/igt.h | 1 + > lib/igt_dummyload.c| 295 > + > lib/igt_dummyload.h| 45 > 5 files changed, 344 insertions(+) > create mode 100644 lib/igt_dummyload.c > create mode 100644 lib/igt_dummyload.h > > diff --git a/docs/reference/intel-gpu-tools/intel-gpu-tools-docs.xml > b/docs/reference/intel-gpu-tools/intel-gpu-tools-docs.xml > index c862f2a..55902ab 100644 > --- a/docs/reference/intel-gpu-tools/intel-gpu-tools-docs.xml > +++ b/docs/reference/intel-gpu-tools/intel-gpu-tools-docs.xml > @@ -32,6 +32,7 @@ > > > > + > > > > diff --git a/lib/Makefile.sources b/lib/Makefile.sources > index e8e277b..7fc5ec2 100644 > --- a/lib/Makefile.sources > +++ b/lib/Makefile.sources > @@ -75,6 +75,8 @@ lib_source_list = \ > igt_draw.h \ > igt_pm.c\ > igt_pm.h\ > + igt_dummyload.c \ > + igt_dummyload.h \ > uwildmat/uwildmat.h \ > uwildmat/uwildmat.c \ > $(NULL) > diff --git a/lib/igt.h b/lib/igt.h > index d751f24..a0028d5 100644 > --- a/lib/igt.h > +++ b/lib/igt.h > @@ -32,6 +32,7 @@ > #include "igt_core.h" > #include "igt_debugfs.h" > #include "igt_draw.h" > +#include "igt_dummyload.h" > #include "igt_fb.h" > #include "igt_gt.h" > #include "igt_kms.h" > diff --git a/lib/igt_dummyload.c b/lib/igt_dummyload.c > new file mode 100644 > index 000..c3be8fa > --- /dev/null > +++ b/lib/igt_dummyload.c > @@ -0,0 +1,295 @@ > +/* > + * Copyright © 2016 Intel Corporation > + * > + * Permission is hereby granted, free of charge, to any person obtaining a > + * copy of this software and associated documentation files (the "Software"), > + * to deal in the Software without restriction, including without limitation > + * the rights to use, copy, modify, merge, publish, distribute, sublicense, > + * and/or sell copies of the Software, and to permit persons to whom the > + * Software is furnished to do so, subject to the following conditions: > + * > + * The above copyright notice and this permission notice (including the next > + * paragraph) shall be included in all copies or substantial portions of the > + * Software. > + * > + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR > + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, > + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL > + * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER > + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING > + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER > DEALINGS > + * IN THE SOFTWARE. > + * > + */ > + > +#include "igt.h" > +#include "igt_dummyload.h" > +#include > +#include > +#include > + > +/** > + * SECTION:igt_dummyload > + * @short_description: Library for submitting GPU workloads > + * @title: Dummyload > + * @include: igt.h > + * > + * A lot of igt testcases need some GPU workload to make sure a race window > is > + * big enough. Unfortunately having a fixed amount of workload leads to > + * spurious test failures or overly long runtimes on some fast/slow > platforms. > + * This library contains functionality to submit GPU workloads that should > + * consume exactly a specific amount of time. > +
[Intel-gfx] [i-g-t PATCH v8 1/5] lib: Make signal helper definitions reusable
v2: Remove definition in benchmarks/gem_syslatency.c
More and more test-cases are using this.
Signed-off-by: Abdiel Janulgue
---
benchmarks/gem_syslatency.c | 4
lib/igt_aux.c | 11 ---
lib/igt_aux.h | 10 ++
lib/igt_core.c | 3 ---
tests/drv_hangman.c | 1 -
5 files changed, 10 insertions(+), 19 deletions(-)
diff --git a/benchmarks/gem_syslatency.c b/benchmarks/gem_syslatency.c
index 6cad3a0..83bfac7 100644
--- a/benchmarks/gem_syslatency.c
+++ b/benchmarks/gem_syslatency.c
@@ -133,10 +133,6 @@ static void *gem_busyspin(void *arg)
return NULL;
}
-#define MSEC_PER_SEC (1000)
-#define USEC_PER_SEC (1000 * MSEC_PER_SEC)
-#define NSEC_PER_SEC (1000 * USEC_PER_SEC)
-
static double elapsed(const struct timespec *a, const struct timespec *b)
{
return 1e9*(b->tv_sec - a->tv_sec) + (b->tv_nsec - a ->tv_nsec);
diff --git a/lib/igt_aux.c b/lib/igt_aux.c
index 421f6d4..b5ae854 100644
--- a/lib/igt_aux.c
+++ b/lib/igt_aux.c
@@ -75,17 +75,6 @@
* fit into any other topic.
*/
-
-/* signal interrupt helpers */
-
-#define MSEC_PER_SEC (1000)
-#define USEC_PER_SEC (1000*MSEC_PER_SEC)
-#define NSEC_PER_SEC (1000*USEC_PER_SEC)
-
-/* signal interrupt helpers */
-#define gettid() syscall(__NR_gettid)
-#define sigev_notify_thread_id _sigev_un._tid
-
static struct __igt_sigiter_global {
pid_t tid;
timer_t timer;
diff --git a/lib/igt_aux.h b/lib/igt_aux.h
index d30196b..d4da499 100644
--- a/lib/igt_aux.h
+++ b/lib/igt_aux.h
@@ -35,6 +35,16 @@
extern drm_intel_bo **trash_bos;
extern int num_trash_bos;
+/* signal interrupt helpers */
+
+#define MSEC_PER_SEC (1000)
+#define USEC_PER_SEC (1000*MSEC_PER_SEC)
+#define NSEC_PER_SEC (1000*USEC_PER_SEC)
+
+/* signal interrupt helpers */
+#define gettid() syscall(__NR_gettid)
+#define sigev_notify_thread_id _sigev_un._tid
+
/* auxialiary igt helpers from igt_aux.c */
/* generally useful helpers */
void igt_fork_signal_helper(void);
diff --git a/lib/igt_core.c b/lib/igt_core.c
index 9cd5f98..f64c809 100644
--- a/lib/igt_core.c
+++ b/lib/igt_core.c
@@ -398,9 +398,6 @@ error:
return -errno;
}
-#define MSEC_PER_SEC (1000)
-#define USEC_PER_SEC (1000*MSEC_PER_SEC)
-#define NSEC_PER_SEC (1000*USEC_PER_SEC)
uint64_t igt_nsec_elapsed(struct timespec *start)
{
struct timespec now;
diff --git a/tests/drv_hangman.c b/tests/drv_hangman.c
index f80d65d..db0a077 100644
--- a/tests/drv_hangman.c
+++ b/tests/drv_hangman.c
@@ -293,7 +293,6 @@ static void test_error_state_capture(unsigned ring_id,
* case and it takes a lot more time to wrap, so the acthd can potentially keep
* increasing for a long time
*/
-#define NSEC_PER_SEC 10LL
static void hangcheck_unterminated(void)
{
int fd;
--
2.7.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [i-g-t PATCH v9 1/3] igt/gem_wait: Use new igt_spin_batch
On 21 November 2016 at 13:07, Abdiel Janulgue
wrote:
> v7: Adapt to api rename
> v8: Restore sanitycheck wait on the recursive batch and
> avoid using C99 locals (Chris Wilson)
> v9: Explicitly quit the batch instead of timing out right away
>
> Cc: Chris Wilson
> Cc: Daniel Vetter
> Cc: Tomeu Vizoso
> Signed-off-by: Abdiel Janulgue
> ---
> tests/gem_wait.c | 126
> ---
> 1 file changed, 7 insertions(+), 119 deletions(-)
Looks good to me.
Reviewed-by: Tomeu Vizoso
Cheers,
Tomeu
> diff --git a/tests/gem_wait.c b/tests/gem_wait.c
> index b4127de..27d13f5 100644
> --- a/tests/gem_wait.c
> +++ b/tests/gem_wait.c
> @@ -27,18 +27,6 @@
>
> #include "igt.h"
>
> -#include
> -#include
> -#include
> -
> -#define gettid() syscall(__NR_gettid)
> -#define sigev_notify_thread_id _sigev_un._tid
> -
> -#define LOCAL_I915_EXEC_BSD_SHIFT (13)
> -#define LOCAL_I915_EXEC_BSD_MASK (3 << LOCAL_I915_EXEC_BSD_SHIFT)
> -
> -#define ENGINE_MASK (I915_EXEC_RING_MASK | LOCAL_I915_EXEC_BSD_MASK)
> -
> static int __gem_wait(int fd, struct drm_i915_gem_wait *w)
> {
> int err;
> @@ -75,89 +63,18 @@ static void invalid_buf(int fd)
> igt_assert_eq(__gem_wait(fd, &wait), -ENOENT);
> }
>
> -static uint32_t *batch;
> -
> -static void sigiter(int sig, siginfo_t *info, void *arg)
> -{
> - *batch = MI_BATCH_BUFFER_END;
> - __sync_synchronize();
> -}
> -
> -#define MSEC_PER_SEC (1000)
> -#define USEC_PER_SEC (1000 * MSEC_PER_SEC)
> -#define NSEC_PER_SEC (1000 * USEC_PER_SEC)
> -
> #define BUSY 1
> #define HANG 2
> static void basic(int fd, unsigned engine, unsigned flags)
> {
> - const int gen = intel_gen(intel_get_drm_devid(fd));
> - struct drm_i915_gem_exec_object2 obj;
> - struct drm_i915_gem_relocation_entry reloc;
> - struct drm_i915_gem_execbuffer2 execbuf;
> struct drm_i915_gem_wait wait;
> - unsigned engines[16];
> - unsigned nengine;
> - int i, timeout;
> -
> - nengine = 0;
> - if (engine == -1) {
> - for_each_engine(fd, engine)
> - if (engine) engines[nengine++] = engine;
> - } else {
> - igt_require(gem_has_ring(fd, engine));
> - engines[nengine++] = engine;
> - }
> - igt_require(nengine);
> -
> - memset(&execbuf, 0, sizeof(execbuf));
> - execbuf.buffers_ptr = (uintptr_t)&obj;
> - execbuf.buffer_count = 1;
> -
> - memset(&obj, 0, sizeof(obj));
> - obj.handle = gem_create(fd, 4096);
> -
> - obj.relocs_ptr = (uintptr_t)&reloc;
> - obj.relocation_count = 1;
> - memset(&reloc, 0, sizeof(reloc));
> -
> - batch = gem_mmap__gtt(fd, obj.handle, 4096, PROT_WRITE);
> - gem_set_domain(fd, obj.handle,
> - I915_GEM_DOMAIN_GTT, I915_GEM_DOMAIN_GTT);
> -
> - reloc.target_handle = obj.handle; /* recurse */
> - reloc.presumed_offset = 0;
> - reloc.offset = sizeof(uint32_t);
> - reloc.delta = 0;
> - reloc.read_domains = I915_GEM_DOMAIN_COMMAND;
> - reloc.write_domain = 0;
> -
> - i = 0;
> - batch[i] = MI_BATCH_BUFFER_START;
> - if (gen >= 8) {
> - batch[i] |= 1 << 8 | 1;
> - batch[++i] = 0;
> - batch[++i] = 0;
> - } else if (gen >= 6) {
> - batch[i] |= 1 << 8;
> - batch[++i] = 0;
> - } else {
> - batch[i] |= 2 << 6;
> - batch[++i] = 0;
> - if (gen < 4) {
> - batch[i] |= 1;
> - reloc.delta = 1;
> - }
> - }
> -
> - for (i = 0; i < nengine; i++) {
> - execbuf.flags &= ~ENGINE_MASK;
> - execbuf.flags |= engines[i];
> - gem_execbuf(fd, &execbuf);
> - }
> + igt_spin_t *spin;
> + int timeout;
> + int wait_s = (flags == 0) ? NSEC_PER_SEC : -1;
> + spin = igt_spin_batch_new(fd, wait_s, engine, 0);
>
> memset(&wait, 0, sizeof(wait));
> - wait.bo_handle = obj.handle;
> + wait.bo_handle = spin->handle;
> igt_assert_eq(__gem_wait(fd, &wait), -ETIME);
>
> if (flags & BUSY) {
> @@ -165,8 +82,7 @@ static void basic(int fd, unsigned engine, unsigned flags)
>
> timeout = 120;
> if ((flags & HANG) == 0) {
> - *batch = MI_BATCH_BUFFER_END;
> - __sync_synchronize();
> + igt_spin_batch_exit(spin);
> timeout = 1;
> }
>
> @@ -174,30 +90,6 @@ static void basic(int fd, unsigned engine, unsigned flags)
> while (__gem_wait(fd, &wait) == -ETIME)
> igt_assert(igt_seconds_elapsed(&tv) < timeout);
> } else {
> - timer_t timer;
> -
> - if ((flags & HANG) == 0) {
> -
Re: [Intel-gfx] [PATCH] drm/i915: Try to group more logically in intel_dump_pipe_config
On Mon, Nov 21, 2016 at 10:44:46AM +, Tvrtko Ursulin wrote:
>
>
> On 18/11/2016 11:19, Tvrtko Ursulin wrote:
> > From: Tvrtko Ursulin
> >
> > Keep parameters relating to the pipe and crtc respectively together.
> >
> > Signed-off-by: Tvrtko Ursulin
> > Cc: Ville Syrjälä
> > ---
> > drivers/gpu/drm/i915/intel_display.c | 15 +++
> > 1 file changed, 7 insertions(+), 8 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_display.c
> > b/drivers/gpu/drm/i915/intel_display.c
> > index 200f09778776..155910c93896 100644
> > --- a/drivers/gpu/drm/i915/intel_display.c
> > +++ b/drivers/gpu/drm/i915/intel_display.c
> > @@ -12739,9 +12739,14 @@ static void intel_dump_pipe_config(struct
> > intel_crtc *crtc,
> > DRM_DEBUG_KMS("[CRTC:%d:%s]%s\n",
> > crtc->base.base.id, crtc->base.name, context);
> >
> > - DRM_DEBUG_KMS("cpu_transcoder: %s, pipe bpp: %i, dithering: %i\n",
> > + DRM_DEBUG_KMS("cpu_transcoder: %s, port clock: %d, ips: %i\n",
> > transcoder_name(pipe_config->cpu_transcoder),
> > - pipe_config->pipe_bpp, pipe_config->dither);
> > + pipe_config->port_clock, pipe_config->ips_enabled);
> > +
> > + DRM_DEBUG_KMS("pipe src size: %dx%d, bpp: %i, dithering: %i, double
> > wide: %i\n",
> > + pipe_config->pipe_src_w, pipe_config->pipe_src_h,
> > + pipe_config->pipe_bpp, pipe_config->dither,
> > + pipe_config->double_wide);
>
>
> Better grouping yay/nay? :)
Looks a lot like random shuffling.
I would suggest we just leave it as is for now. If I get
sufficiently annoyed at it when looking at bugs, I might come
up with something more sensible.
>
> Regards,
>
> Tvrtko
>
> >
> > if (pipe_config->has_pch_encoder)
> > intel_dump_m_n_config(pipe_config, "fdi",
> > @@ -12765,9 +12770,6 @@ static void intel_dump_pipe_config(struct
> > intel_crtc *crtc,
> > DRM_DEBUG_KMS("adjusted mode:\n");
> > drm_mode_debug_printmodeline(&pipe_config->base.adjusted_mode);
> > intel_dump_crtc_timings(&pipe_config->base.adjusted_mode);
> > - DRM_DEBUG_KMS("port clock: %d, pipe src size: %dx%d\n",
> > - pipe_config->port_clock,
> > - pipe_config->pipe_src_w, pipe_config->pipe_src_h);
> >
> > if (INTEL_GEN(dev_priv) >= 9)
> > DRM_DEBUG_KMS("num_scalers: %d, scaler_users: 0x%x, scaler_id:
> > %d\n",
> > @@ -12786,9 +12788,6 @@ static void intel_dump_pipe_config(struct
> > intel_crtc *crtc,
> > pipe_config->pch_pfit.size,
> > enableddisabled(pipe_config->pch_pfit.enabled));
> >
> > - DRM_DEBUG_KMS("ips: %i, double wide: %i\n",
> > - pipe_config->ips_enabled, pipe_config->double_wide);
> > -
> > if (IS_BROXTON(dev_priv)) {
> > DRM_DEBUG_KMS("dpll_hw_state: ebb0: 0x%x, ebb4: 0x%x,"
> > "pll0: 0x%x, pll1: 0x%x, pll2: 0x%x, pll3: 0x%x, "
> >
--
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] [i-g-t PATCH v8 5/5] igt/kms_busy.c: Use new igt_spin_batch
Looks good to me.
Reviewed-by: Tomeu Vizoso
Cheers,
Tomeu
On 21 November 2016 at 10:25, Abdiel Janulgue
wrote:
> v7: Adapt to api rename
> v8: Tidy up finish_fb_busy (Chris Wilson)
>
> Cc: Chris Wilson
> Cc: Daniel Vetter
> Signed-off-by: Abdiel Janulgue
> ---
> tests/kms_busy.c | 81
> +---
> 1 file changed, 6 insertions(+), 75 deletions(-)
>
> diff --git a/tests/kms_busy.c b/tests/kms_busy.c
> index b555f99..8a8a3eb 100644
> --- a/tests/kms_busy.c
> +++ b/tests/kms_busy.c
> @@ -78,80 +78,11 @@ static void do_cleanup_display(igt_display_t *dpy)
> igt_display_commit2(dpy, dpy->is_atomic ? COMMIT_ATOMIC :
> COMMIT_LEGACY);
> }
>
> -static uint32_t *
> -make_fb_busy(igt_display_t *dpy, unsigned ring, const struct igt_fb *fb)
> -{
> - const int gen = intel_gen(intel_get_drm_devid(dpy->drm_fd));
> - struct drm_i915_gem_exec_object2 obj[2];
> -#define SCRATCH 0
> -#define BATCH 1
> - struct drm_i915_gem_relocation_entry reloc[2];
> - struct drm_i915_gem_execbuffer2 execbuf;
> - uint32_t *batch;
> - int i;
> -
> - memset(&execbuf, 0, sizeof(execbuf));
> - execbuf.buffers_ptr = (uintptr_t)obj;
> - execbuf.buffer_count = 2;
> - execbuf.flags = ring;
> -
> - memset(obj, 0, sizeof(obj));
> - obj[SCRATCH].handle = fb->gem_handle;
> -
> - obj[BATCH].handle = gem_create(dpy->drm_fd, 4096);
> - obj[BATCH].relocs_ptr = (uintptr_t)reloc;
> - obj[BATCH].relocation_count = 2;
> - memset(reloc, 0, sizeof(reloc));
> - reloc[0].target_handle = obj[BATCH].handle; /* recurse */
> - reloc[0].presumed_offset = 0;
> - reloc[0].offset = sizeof(uint32_t);
> - reloc[0].delta = 0;
> - reloc[0].read_domains = I915_GEM_DOMAIN_COMMAND;
> - reloc[0].write_domain = 0;
> -
> - batch = gem_mmap__wc(dpy->drm_fd,
> -obj[BATCH].handle, 0, 4096, PROT_WRITE);
> - gem_set_domain(dpy->drm_fd, obj[BATCH].handle,
> - I915_GEM_DOMAIN_GTT, I915_GEM_DOMAIN_GTT);
> -
> - batch[i = 0] = MI_BATCH_BUFFER_START;
> - if (gen >= 8) {
> - batch[i] |= 1 << 8 | 1;
> - batch[++i] = 0;
> - batch[++i] = 0;
> - } else if (gen >= 6) {
> - batch[i] |= 1 << 8;
> - batch[++i] = 0;
> - } else {
> - batch[i] |= 2 << 6;
> - batch[++i] = 0;
> - if (gen < 4) {
> - batch[i] |= 1;
> - reloc[0].delta = 1;
> - }
> - }
> -
> - /* dummy write to fb */
> - reloc[1].target_handle = obj[SCRATCH].handle;
> - reloc[1].presumed_offset = 0;
> - reloc[1].offset = 1024;
> - reloc[1].delta = 0;
> - reloc[1].read_domains = I915_GEM_DOMAIN_RENDER;
> - reloc[1].write_domain = I915_GEM_DOMAIN_RENDER;
> -
> - gem_execbuf(dpy->drm_fd, &execbuf);
> - gem_close(dpy->drm_fd, obj[BATCH].handle);
> -
> - return batch;
> -}
> -
> -static void finish_fb_busy(uint32_t *batch, int msecs)
> +static void finish_fb_busy(igt_spin_t *spin, int msecs)
> {
> struct timespec tv = { 0, msecs * 1000 * 1000 };
> nanosleep(&tv, NULL);
> - batch[0] = MI_BATCH_BUFFER_END;
> - __sync_synchronize();
> - munmap(batch, 4096);
> + igt_spin_batch_exit(spin);
> }
>
> static void sighandler(int sig)
> @@ -165,9 +96,8 @@ static void flip_to_fb(igt_display_t *dpy, int pipe,
> struct pollfd pfd = { .fd = dpy->drm_fd, .events = POLLIN };
> struct timespec tv = { 1, 0 };
> struct drm_event_vblank ev;
> - uint32_t *batch;
> -
> - batch = make_fb_busy(dpy, ring, fb);
> + igt_spin_t *t = igt_spin_batch_new(dpy->drm_fd, -1,
> + ring, fb->gem_handle);
> igt_fork(child, 1) {
> igt_assert(gem_bo_busy(dpy->drm_fd, fb->gem_handle));
> do_or_die(drmModePageFlip(dpy->drm_fd,
> @@ -179,7 +109,8 @@ static void flip_to_fb(igt_display_t *dpy, int pipe,
> }
> igt_assert_f(nanosleep(&tv, NULL) == -1,
> "flip to %s blocked waiting for busy fb", name);
> - finish_fb_busy(batch, 2*TIMEOUT);
> + finish_fb_busy(t, 2*TIMEOUT);
> + igt_spin_batch_free(dpy->drm_fd, t);
> igt_waitchildren();
> igt_assert(read(dpy->drm_fd, &ev, sizeof(ev)) == sizeof(ev));
> igt_assert(poll(&pfd, 1, 0) == 0);
> --
> 2.7.4
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [i-g-t PATCH v8 4/5] igt/kms_flip: Use new igt_spin_batch
On 21 November 2016 at 10:25, Abdiel Janulgue
wrote:
> v7: Reuse NSEC_PER_SEC defines
> v8: Don't wait on the fb, it must be busy. Exit the spin batch
> when flip is queued (Chris Wilson)
>
> Cc: Chris Wilson
> Cc: Daniel Vetter
> Signed-off-by: Abdiel Janulgue
> ---
> tests/kms_flip.c | 212
> +++
> 1 file changed, 26 insertions(+), 186 deletions(-)
Looks good to me.
Reviewed-by: Tomeu Vizoso
Cheers,
Tomeu
> diff --git a/tests/kms_flip.c b/tests/kms_flip.c
> index 2a9fe2e..437c564 100644
> --- a/tests/kms_flip.c
> +++ b/tests/kms_flip.c
> @@ -85,9 +85,6 @@
> #define DRM_CAP_TIMESTAMP_MONOTONIC 6
> #endif
>
> -#define USEC_PER_SEC 100L
> -#define NSEC_PER_SEC 10L
> -
> drmModeRes *resources;
> int drm_fd;
> static drm_intel_bufmgr *bufmgr;
> @@ -191,109 +188,6 @@ static unsigned long gettime_us(void)
> return ts.tv_sec * 100 + ts.tv_nsec / 1000;
> }
>
> -static int calibrate_dummy_load(struct test_output *o,
> - const char *ring_name,
> - int (*emit)(struct test_output *o, int limit,
> int timeout))
> -{
> - unsigned long start;
> - int ops = 1;
> -
> - start = gettime_us();
> -
> - do {
> - unsigned long diff;
> - int ret;
> -
> - ret = emit(o, (ops+1)/2, 10);
> - diff = gettime_us() - start;
> -
> - if (ret || diff / USEC_PER_SEC >= 1)
> - break;
> -
> - ops += ops;
> - } while (ops < 10);
> -
> - igt_debug("%s dummy load calibrated: %d operations / second\n",
> - ring_name, ops);
> -
> - return ops;
> -}
> -
> -static void blit_copy(drm_intel_bo *dst, drm_intel_bo *src,
> - unsigned int width, unsigned int height,
> - unsigned int dst_pitch, unsigned int src_pitch)
> -{
> - BLIT_COPY_BATCH_START(0);
> - OUT_BATCH((3 << 24) | /* 32 bits */
> - (0xcc << 16) | /* copy ROP */
> - dst_pitch);
> - OUT_BATCH(0 << 16 | 0);
> - OUT_BATCH(height << 16 | width);
> - OUT_RELOC_FENCED(dst, I915_GEM_DOMAIN_RENDER, I915_GEM_DOMAIN_RENDER,
> 0);
> - OUT_BATCH(0 << 16 | 0);
> - OUT_BATCH(src_pitch);
> - OUT_RELOC_FENCED(src, I915_GEM_DOMAIN_RENDER, 0, 0);
> - ADVANCE_BATCH();
> -
> - if (batch->gen >= 6) {
> - BEGIN_BATCH(3, 0);
> - OUT_BATCH(XY_SETUP_CLIP_BLT_CMD);
> - OUT_BATCH(0);
> - OUT_BATCH(0);
> - ADVANCE_BATCH();
> - }
> -}
> -
> -static int _emit_dummy_load__bcs(struct test_output *o, int limit, int
> timeout)
> -{
> - int i, ret = 0;
> - drm_intel_bo *src_bo, *dst_bo, *fb_bo;
> - struct igt_fb *fb_info = &o->fb_info[o->current_fb_id];
> -
> - igt_require(bufmgr);
> -
> - src_bo = drm_intel_bo_alloc(bufmgr, "dummy_bo", 2048*2048*4, 4096);
> - igt_assert(src_bo);
> -
> - dst_bo = drm_intel_bo_alloc(bufmgr, "dummy_bo", 2048*2048*4, 4096);
> - igt_assert(dst_bo);
> -
> - fb_bo = gem_handle_to_libdrm_bo(bufmgr, drm_fd, "imported",
> fb_info->gem_handle);
> - igt_assert(fb_bo);
> -
> - for (i = 0; i < limit; i++) {
> - blit_copy(dst_bo, src_bo,
> - 2048, 2048,
> - 2048*4, 2048*4);
> -
> - igt_swap(src_bo, dst_bo);
> - }
> - blit_copy(fb_bo, src_bo,
> - min(o->fb_width, 2048), min(o->fb_height, 2048),
> - fb_info->stride, 2048*4);
> - intel_batchbuffer_flush(batch);
> -
> - if (timeout > 0)
> - ret = drm_intel_gem_bo_wait(fb_bo, timeout * NSEC_PER_SEC);
> -
> - drm_intel_bo_unreference(src_bo);
> - drm_intel_bo_unreference(dst_bo);
> - drm_intel_bo_unreference(fb_bo);
> -
> - return ret;
> -}
> -
> -static void emit_dummy_load__bcs(struct test_output *o, int seconds)
> -{
> - static int ops_per_sec;
> -
> - if (ops_per_sec == 0)
> - ops_per_sec = calibrate_dummy_load(o, "bcs",
> - _emit_dummy_load__bcs);
> -
> - _emit_dummy_load__bcs(o, seconds * ops_per_sec, 0);
> -}
> -
> static void emit_fence_stress(struct test_output *o)
> {
> const int num_fences = gem_available_fences(drm_fd);
> @@ -338,82 +232,6 @@ static void emit_fence_stress(struct test_output *o)
> free(exec);
> }
>
> -static int _emit_dummy_load__rcs(struct test_output *o, int limit, int
> timeout)
> -{
> - const struct igt_fb *fb_info = &o->fb_info[o->current_fb_id];
> - igt_render_copyfunc_t copyfunc;
> - struct igt_buf sb[3], *src, *dst, *fb;
> - int i, ret = 0;
> -
> - igt_require(bufmgr);
> -
> - copyfunc = igt_get_render_copyfunc(devid);
> - if (co
[Intel-gfx] ✗ Fi.CI.BAT: warning for drm/i915: Remove plane config from intel_dump_pipe_config
== Series Details == Series: drm/i915: Remove plane config from intel_dump_pipe_config URL : https://patchwork.freedesktop.org/series/15650/ State : warning == Summary == Series 15650v1 drm/i915: Remove plane config from intel_dump_pipe_config https://patchwork.freedesktop.org/api/1.0/series/15650/revisions/1/mbox/ Test kms_force_connector_basic: Subgroup force-load-detect: pass -> DMESG-WARN (fi-snb-2520m) fi-bdw-5557u total:244 pass:229 dwarn:0 dfail:0 fail:0 skip:15 fi-bsw-n3050 total:244 pass:204 dwarn:0 dfail:0 fail:0 skip:40 fi-bxt-t5700 total:244 pass:216 dwarn:0 dfail:0 fail:0 skip:28 fi-byt-j1900 total:244 pass:216 dwarn:0 dfail:0 fail:0 skip:28 fi-byt-n2820 total:244 pass:212 dwarn:0 dfail:0 fail:0 skip:32 fi-hsw-4770 total:244 pass:224 dwarn:0 dfail:0 fail:0 skip:20 fi-hsw-4770r total:244 pass:224 dwarn:0 dfail:0 fail:0 skip:20 fi-ilk-650 total:244 pass:191 dwarn:0 dfail:0 fail:0 skip:53 fi-ivb-3520m total:244 pass:222 dwarn:0 dfail:0 fail:0 skip:22 fi-ivb-3770 total:244 pass:222 dwarn:0 dfail:0 fail:0 skip:22 fi-kbl-7200u total:244 pass:222 dwarn:0 dfail:0 fail:0 skip:22 fi-skl-6260u total:244 pass:230 dwarn:0 dfail:0 fail:0 skip:14 fi-skl-6700hqtotal:244 pass:223 dwarn:0 dfail:0 fail:0 skip:21 fi-skl-6700k total:244 pass:222 dwarn:1 dfail:0 fail:0 skip:21 fi-skl-6770hqtotal:244 pass:230 dwarn:0 dfail:0 fail:0 skip:14 fi-snb-2520m total:244 pass:211 dwarn:1 dfail:0 fail:0 skip:32 fi-snb-2600 total:244 pass:211 dwarn:0 dfail:0 fail:0 skip:33 d6149d212b69a8e1d9229fe80fca034a0abe1d0e drm-intel-nightly: 2016y-11m-21d-12h-48m-13s UTC integration manifest 0d588c0 drm/i915: Remove plane config from intel_dump_pipe_config == Logs == For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_3068/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH i-g-t v8 12/21] tests/sw_sync: Add subtest test_sync_multi_timeline_wait
From: Robert Foss
This subtest verifies that waiting, timing out on a wait and that counting
fences in various states works.
Signed-off-by: Robert Foss
Reviewed-by: Eric Engestrom
---
tests/sw_sync.c | 66 +
1 file changed, 66 insertions(+)
diff --git a/tests/sw_sync.c b/tests/sw_sync.c
index 09c7ab8..13b2005 100644
--- a/tests/sw_sync.c
+++ b/tests/sw_sync.c
@@ -230,6 +230,69 @@ static void test_sync_merge_same(void)
close(timeline);
}
+static void test_sync_multi_timeline_wait(void)
+{
+ int timeline[3];
+ int in_fence[3];
+ int fence_merge;
+ int active, signaled, ret;
+
+ timeline[0] = sw_sync_timeline_create();
+ timeline[1] = sw_sync_timeline_create();
+ timeline[2] = sw_sync_timeline_create();
+
+ in_fence[0] = sw_sync_fence_create(timeline[0], 5);
+ in_fence[1] = sw_sync_fence_create(timeline[1], 5);
+ in_fence[2] = sw_sync_fence_create(timeline[2], 5);
+
+ fence_merge = sync_merge(in_fence[0], in_fence[1]);
+ fence_merge = sync_merge(in_fence[2], fence_merge);
+
+ /* Confirm fence isn't signaled */
+ active = sync_fence_count_status(fence_merge,
+ SW_SYNC_FENCE_STATUS_ACTIVE);
+ igt_assert_f(active == 3, "Fence signaled too early\n");
+
+ ret = sync_wait(fence_merge, 0);
+ igt_assert_f(ret == -1 && errno == ETIME, "Failure waiting on fence
until timeout\n");
+
+ sw_sync_timeline_inc(timeline[0], 5);
+ active = sync_fence_count_status(fence_merge,
+ SW_SYNC_FENCE_STATUS_ACTIVE);
+ signaled = sync_fence_count_status(fence_merge,
+ SW_SYNC_FENCE_STATUS_SIGNALED);
+ igt_assert_f(active == 2 && signaled == 1,
+ "Fence did not signal properly\n");
+
+ sw_sync_timeline_inc(timeline[1], 5);
+ active = sync_fence_count_status(fence_merge,
+ SW_SYNC_FENCE_STATUS_ACTIVE);
+ signaled = sync_fence_count_status(fence_merge,
+ SW_SYNC_FENCE_STATUS_SIGNALED);
+ igt_assert_f(active == 1 && signaled == 2,
+ "Fence did not signal properly\n");
+
+ sw_sync_timeline_inc(timeline[2], 5);
+ active = sync_fence_count_status(fence_merge,
+ SW_SYNC_FENCE_STATUS_ACTIVE);
+ signaled = sync_fence_count_status(fence_merge,
+ SW_SYNC_FENCE_STATUS_SIGNALED);
+ igt_assert_f(active == 0 && signaled == 3,
+"Fence did not signal properly\n");
+
+ /* confirm you can successfully wait */
+ ret = sync_wait(fence_merge, 100);
+ igt_assert_f(ret == 0, "Failure waiting on signaled fence\n");
+
+ close(in_fence[0]);
+ close(in_fence[1]);
+ close(in_fence[2]);
+ close(fence_merge);
+ close(timeline[0]);
+ close(timeline[1]);
+ close(timeline[2]);
+}
+
static void * test_sync_multi_consumer_thread(void *arg)
{
data_t *data = arg;
@@ -492,6 +555,9 @@ igt_main
igt_subtest("sync_merge_same")
test_sync_merge_same();
+ igt_subtest("sync_multi_timeline_wait")
+ test_sync_multi_timeline_wait();
+
igt_subtest("sync_multi_consumer")
test_sync_multi_consumer();
--
2.10.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH i-g-t v8 05/21] tests/sw_sync: Add subtest test_alloc_merge_fence
From: Robert Foss
This subtest verifies that merging two fences works in the simples possible
case.
Signed-off-by: Robert Foss
Reviewed-by: Eric Engestrom
---
tests/sw_sync.c | 23 +++
1 file changed, 23 insertions(+)
diff --git a/tests/sw_sync.c b/tests/sw_sync.c
index f9d4fe9..03bc0b3 100644
--- a/tests/sw_sync.c
+++ b/tests/sw_sync.c
@@ -63,6 +63,26 @@ static void test_alloc_fence_invalid_timeline(void)
igt_assert(__sw_sync_fence_create(-1, 0) < 0);
}
+static void test_alloc_merge_fence(void)
+{
+ int in_fence[2];
+ int fence_merge;
+ int timeline[2];
+
+ timeline[0] = sw_sync_timeline_create();
+ timeline[1] = sw_sync_timeline_create();
+
+ in_fence[0] = sw_sync_fence_create(timeline[0], 1);
+ in_fence[1] = sw_sync_fence_create(timeline[1], 1);
+ fence_merge = sync_merge(in_fence[1], in_fence[0]);
+
+ close(in_fence[0]);
+ close(in_fence[1]);
+ close(fence_merge);
+ close(timeline[0]);
+ close(timeline[1]);
+}
+
igt_main
{
igt_subtest("alloc_timeline")
@@ -73,5 +93,8 @@ igt_main
igt_subtest("alloc_fence_invalid_timeline")
test_alloc_fence_invalid_timeline();
+
+ igt_subtest("alloc_merge_fence")
+ test_alloc_merge_fence();
}
--
2.10.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH i-g-t v8 04/21] tests/sw_sync: Add subtest test_alloc_fence_invalid_timeline
From: Robert Foss
This subtests tests that creating fences on negative timelines fail.
Signed-off-by: Robert Foss
Reviewed-by: Eric Engestrom
---
tests/sw_sync.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/tests/sw_sync.c b/tests/sw_sync.c
index 8e7764a..f9d4fe9 100644
--- a/tests/sw_sync.c
+++ b/tests/sw_sync.c
@@ -58,6 +58,10 @@ static void test_alloc_fence(void)
close(timeline);
}
+static void test_alloc_fence_invalid_timeline(void)
+{
+ igt_assert(__sw_sync_fence_create(-1, 0) < 0);
+}
igt_main
{
@@ -66,5 +70,8 @@ igt_main
igt_subtest("alloc_fence")
test_alloc_fence();
+
+ igt_subtest("alloc_fence_invalid_timeline")
+ test_alloc_fence_invalid_timeline();
}
--
2.10.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH i-g-t v8 11/21] tests/sw_sync: Add subtest test_sync_random_merge
From: Robert Foss
This subtest verifies that creating many timelines and merging random fences
from each timeline with eachother results in merged fences that are fully
functional.
Signed-off-by: Robert Foss
Reviewed-by: Eric Engestrom
---
tests/sw_sync.c | 73 +
1 file changed, 73 insertions(+)
diff --git a/tests/sw_sync.c b/tests/sw_sync.c
index 11373bb..09c7ab8 100644
--- a/tests/sw_sync.c
+++ b/tests/sw_sync.c
@@ -399,6 +399,76 @@ static void test_sync_multi_consumer_producer(void)
igt_assert_f(thread_ret == 0, "A sync thread reported failure.\n");
}
+static void test_sync_random_merge(void)
+{
+ int i, size, ret;
+ const int nbr_timeline = 32;
+ const int nbr_merge = 1024;
+ int fence_map[nbr_timeline];
+ int timeline_arr[nbr_timeline];
+ int fence, tmpfence, merged;
+ int timeline, timeline_offset, sync_pt;
+
+ srand(time(NULL));
+
+ for (i = 0; i < nbr_timeline; i++) {
+ timeline_arr[i] = sw_sync_timeline_create();
+ fence_map[i] = -1;
+ }
+
+ sync_pt = rand();
+ fence = sw_sync_fence_create(timeline_arr[0], sync_pt);
+
+ fence_map[0] = sync_pt;
+
+ /* Randomly create syncpoints out of a fixed set of timelines,
+* and merge them together.
+*/
+ for (i = 0; i < nbr_merge; i++) {
+ /* Generate syncpoint. */
+ timeline_offset = rand() % nbr_timeline;
+ timeline = timeline_arr[timeline_offset];
+ sync_pt = rand();
+
+ /* Keep track of the latest sync_pt in each timeline. */
+ if (fence_map[timeline_offset] == -1)
+ fence_map[timeline_offset] = sync_pt;
+ else if (fence_map[timeline_offset] < sync_pt)
+ fence_map[timeline_offset] = sync_pt;
+
+ /* Merge. */
+ tmpfence = sw_sync_fence_create(timeline, sync_pt);
+ merged = sync_merge(tmpfence, fence);
+ close(tmpfence);
+ close(fence);
+ fence = merged;
+ }
+
+ size = 0;
+ for (i = 0; i < nbr_timeline; i++)
+ if (fence_map[i] != -1)
+ size++;
+
+ /* Trigger the merged fence. */
+ for (i = 0; i < nbr_timeline; i++) {
+ if (fence_map[i] != -1) {
+ ret = sync_wait(fence, 0);
+ igt_assert_f(ret == -1 && errno == ETIME,
+ "Failure waiting on fence until timeout\n");
+ /* Increment the timeline to the last sync_pt */
+ sw_sync_timeline_inc(timeline_arr[i], fence_map[i]);
+ }
+ }
+
+ /* Check that the fence is triggered. */
+ ret = sync_wait(fence, 0);
+ igt_assert_f(ret == 0, "Failure triggering fence\n");
+
+ close(fence);
+ for (i = 0; i < nbr_timeline; i++)
+ close(timeline_arr[i]);
+}
+
igt_main
{
igt_subtest("alloc_timeline")
@@ -427,5 +497,8 @@ igt_main
igt_subtest("sync_multi_consumer_producer")
test_sync_multi_consumer_producer();
+
+ igt_subtest("sync_random_merge")
+ test_sync_random_merge();
}
--
2.10.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH i-g-t v8 13/21] tests/sw_sync: Add subtest test_sync_multi_producer_single_consumer
From: Robert Foss
This subtest runs a single consumer thread and multiple producer thread that
are synchronized using multiple timelines.
Signed-off-by: Robert Foss
Reviewed-by: Eric Engestrom
---
tests/sw_sync.c | 139
1 file changed, 139 insertions(+)
diff --git a/tests/sw_sync.c b/tests/sw_sync.c
index 13b2005..265e446 100644
--- a/tests/sw_sync.c
+++ b/tests/sw_sync.c
@@ -462,6 +462,142 @@ static void test_sync_multi_consumer_producer(void)
igt_assert_f(thread_ret == 0, "A sync thread reported failure.\n");
}
+static int test_mspc_wait_on_fence(int fence)
+{
+ int error, active;
+
+ do {
+ error = sync_fence_count_status(fence,
+ SW_SYNC_FENCE_STATUS_ERROR);
+ igt_assert_f(error == 0, "Error occurred on fence\n");
+ active = sync_fence_count_status(fence,
+
SW_SYNC_FENCE_STATUS_ACTIVE);
+ } while (active);
+
+ return 0;
+}
+
+static struct {
+ int iterations;
+ int threads;
+ int counter;
+ int cons_timeline;
+ int *prod_timeline;
+ pthread_mutex_t lock;
+} test_mpsc_data;
+
+static int mpsc_producer_thread(void *d)
+{
+ int id = (long)d;
+ int fence, i;
+ int *prod_timeline = test_mpsc_data.prod_timeline;
+ int cons_timeline = test_mpsc_data.cons_timeline;
+ int iterations = test_mpsc_data.iterations;
+
+ for (i = 0; i < iterations; i++) {
+ fence = sw_sync_fence_create(cons_timeline, i);
+
+ /* Wait for the consumer to finish. Use alternate
+* means of waiting on the fence
+*/
+ if ((iterations + id) % 8 != 0) {
+ igt_assert_f(sync_wait(fence, -1) == 0,
+"Failure waiting on fence\n");
+ } else {
+ igt_assert_f(test_mspc_wait_on_fence(fence) == 0,
+"Failure waiting on fence\n");
+ }
+
+ /* Every producer increments the counter, the consumer
+* checks and erases it
+*/
+ pthread_mutex_lock(&test_mpsc_data.lock);
+ test_mpsc_data.counter++;
+ pthread_mutex_unlock(&test_mpsc_data.lock);
+
+ sw_sync_timeline_inc(prod_timeline[id], 1);
+ close(fence);
+ }
+
+ return 0;
+}
+
+static int mpsc_consumer_thread(void)
+{
+ int fence, merged, tmp, it, i;
+ int *prod_timeline = test_mpsc_data.prod_timeline;
+ int cons_timeline = test_mpsc_data.cons_timeline;
+ int iterations = test_mpsc_data.iterations;
+ int n = test_mpsc_data.threads;
+
+ for (it = 1; it <= iterations; it++) {
+ fence = sw_sync_fence_create(prod_timeline[0], it);
+ for (i = 1; i < n; i++) {
+ tmp = sw_sync_fence_create(prod_timeline[i], it);
+ merged = sync_merge(tmp, fence);
+ close(tmp);
+ close(fence);
+ fence = merged;
+ }
+
+ /* Make sure we see an increment from every producer thread.
+* Vary the means by which we wait.
+*/
+ if (iterations % 8 != 0) {
+ igt_assert_f(sync_wait(fence, -1) == 0,
+ "Producers did not increment as
expected\n");
+ } else {
+ igt_assert_f(test_mspc_wait_on_fence(fence) == 0,
+"Failure waiting on fence\n");
+ }
+
+ igt_assert_f(test_mpsc_data.counter == n * it,
+"Counter value mismatch\n");
+
+ /* Release the producer threads */
+ sw_sync_timeline_inc(cons_timeline, 1);
+ close(fence);
+ }
+
+ return 0;
+}
+
+/* IMPORTANT NOTE: if you see this test failing on your system, it may be
+ * due to a shortage of file descriptors. Please ensure your system has
+ * a sensible limit for this test to finish correctly.
+ */
+static void test_sync_multi_producer_single_consumer(void)
+{
+ int iterations = 1 << 12;
+ int n = 5;
+ int prod_timeline[n];
+ int cons_timeline;
+ pthread_t threads[n];
+ long i;
+
+ cons_timeline = sw_sync_timeline_create();
+ for (i = 0; i < n; i++)
+ prod_timeline[i] = sw_sync_timeline_create();
+
+ test_mpsc_data.prod_timeline = prod_timeline;
+ test_mpsc_data.cons_timeline = cons_timeline;
+ test_mpsc_data.iterations = iterations;
+ test_mpsc_data.threads = n;
+ test_mpsc_data.counter = 0;
+ pthread_mutex_init(&test_mpsc_data.lock, NULL);
+
+ for (i = 0; i < n; i++) {
+
[Intel-gfx] [PATCH i-g-t v8 10/21] tests/sw_sync: Add subtest test_sync_multi_consumer_producer
From: Robert Foss
This test verifies that stressing the kernel by creating multiple
consumer/producer threads that wait on a single timeline to be incremented
by another conumer/producer thread does not fail.
And that the order amongst the threads is maintained.
Signed-off-by: Robert Foss
Reviewed-by: Eric Engestrom
---
tests/sw_sync.c | 83 +
1 file changed, 83 insertions(+)
diff --git a/tests/sw_sync.c b/tests/sw_sync.c
index cd0c588..11373bb 100644
--- a/tests/sw_sync.c
+++ b/tests/sw_sync.c
@@ -319,6 +319,86 @@ static void test_sync_multi_consumer(void)
igt_assert_f(thread_ret == 0, "A sync thread reported failure.\n");
}
+static void * test_sync_multi_consumer_producer_thread(void *arg)
+{
+ data_t *data = arg;
+ int thread_id = data->thread_id;
+ int nbr_threads = data->nbr_threads;
+ int timeline = data->timeline;
+ int iterations = data->nbr_iterations;
+ int ret, i;
+
+ for (i = 0; i < iterations; i++) {
+ int next_point = i * nbr_threads + thread_id;
+ int fence = sw_sync_fence_create(timeline, next_point);
+
+ ret = sync_wait(fence, 1000);
+ if (ret == -1)
+ {
+ return (void *) 1;
+ }
+
+ if (*(data->counter) != next_point)
+ {
+ return (void *) 1;
+ }
+
+ (*data->counter)++;
+
+ /* Kick off the next thread. */
+ sw_sync_timeline_inc(timeline, 1);
+
+ close(fence);
+ }
+ return NULL;
+}
+
+static void test_sync_multi_consumer_producer(void)
+{
+ const uint32_t nbr_threads = 8;
+ const uint32_t nbr_iterations = 1 << 14;
+ data_t data_arr[nbr_threads];
+ pthread_t thread_arr[nbr_threads];
+ int timeline;
+ volatile uint32_t counter = 0;
+ uintptr_t thread_ret = 0;
+ data_t data;
+ int i, ret;
+
+ timeline = sw_sync_timeline_create();
+
+ data.nbr_iterations = nbr_iterations;
+ data.nbr_threads = nbr_threads;
+ data.counter = &counter;
+ data.timeline = timeline;
+
+ /* Start consumer threads. */
+ for (i = 0; i < nbr_threads; i++)
+ {
+ data_arr[i] = data;
+ data_arr[i].thread_id = i;
+ ret = pthread_create(&thread_arr[i], NULL,
+test_sync_multi_consumer_producer_thread,
+(void *) &(data_arr[i]));
+ igt_assert_eq(ret, 0);
+ }
+
+ /* Wait for threads to complete. */
+ for (i = 0; i < nbr_threads; i++)
+ {
+ uintptr_t local_thread_ret;
+ pthread_join(thread_arr[i], (void **)&local_thread_ret);
+ thread_ret |= local_thread_ret;
+ }
+
+ close(timeline);
+
+ igt_assert_f(counter == nbr_threads * nbr_iterations,
+"Counter has unexpected value.\n");
+
+ igt_assert_f(thread_ret == 0, "A sync thread reported failure.\n");
+}
+
igt_main
{
igt_subtest("alloc_timeline")
@@ -344,5 +424,8 @@ igt_main
igt_subtest("sync_multi_consumer")
test_sync_multi_consumer();
+
+ igt_subtest("sync_multi_consumer_producer")
+ test_sync_multi_consumer_producer();
}
--
2.10.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH i-g-t v8 20/21] tests/sw_sync: Add subtest test_sync_busy_fork
From: Robert Foss
Add subtest test_sync_busy_fork which increments the timeline in a forked child
process.
Signed-off-by: Robert Foss
---
tests/sw_sync.c | 39 +++
1 file changed, 39 insertions(+)
diff --git a/tests/sw_sync.c b/tests/sw_sync.c
index 3a67877..e0bf6c3 100644
--- a/tests/sw_sync.c
+++ b/tests/sw_sync.c
@@ -171,6 +171,42 @@ static void test_sync_busy(void)
close(timeline);
}
+static void test_sync_busy_fork(void)
+{
+ int fence, ret;
+ int timeline;
+ int skip = 0;
+
+ timeline = sw_sync_timeline_create();
+ fence = sw_sync_fence_create(timeline, 1);
+
+ switch (fork()) {
+ case 0:
+ /* Child process */
+ usleep(1*1000*1000);
+ /* Advance timeline from 0 -> 1 */
+ sw_sync_timeline_inc(timeline, 1);
+ _Exit(0);
+ break;
+ case -1:
+ /* Failed fork */
+ skip = 1;
+ break;
+ default:
+ /* Parent process */
+ ret = sync_wait(fence, 0);
+ igt_assert_f(ret == -1 && errno == ETIME, "Fence signaled (it
should not have been signalled yet)\n");
+
+ ret = sync_wait(fence, 2*1000);
+ igt_assert_f(ret == 0, "Fence not signaled (timeline value 1
fence seqno 1)\n");
+ break;
+ }
+
+ close(fence);
+ close(timeline);
+ igt_require(!skip);
+}
+
static void test_sync_merge_invalid(void)
{
int in_fence;
@@ -789,6 +825,9 @@ igt_main
igt_subtest("sync_busy")
test_sync_busy();
+ igt_subtest("sync_busy_fork")
+ test_sync_busy_fork();
+
igt_subtest("sync_merge_invalid")
test_sync_merge_invalid();
--
2.10.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH i-g-t v8 08/21] tests/sw_sync: Add subtest test_sync_merge_same
From: Robert Foss
This subtest verifies merging a fence with itself does not fail.
Signed-off-by: Robert Foss
Reviewed-by: Eric Engestrom
---
tests/sw_sync.c | 27 +++
1 file changed, 27 insertions(+)
diff --git a/tests/sw_sync.c b/tests/sw_sync.c
index 96dcbff..ada1243 100644
--- a/tests/sw_sync.c
+++ b/tests/sw_sync.c
@@ -195,6 +195,30 @@ static void test_sync_merge(void)
close(timeline);
}
+static void test_sync_merge_same(void)
+{
+ int in_fence[2];
+ int timeline;
+ int signaled;
+
+ timeline = sw_sync_timeline_create();
+ in_fence[0] = sw_sync_fence_create(timeline, 1);
+ in_fence[1] = sync_merge(in_fence[0], in_fence[0]);
+
+ signaled = sync_fence_count_status(in_fence[0],
+ SW_SYNC_FENCE_STATUS_SIGNALED);
+ igt_assert_f(signaled == 0, "fence signaled too early\n");
+
+ sw_sync_timeline_inc(timeline, 1);
+ signaled = sync_fence_count_status(in_fence[0],
+ SW_SYNC_FENCE_STATUS_SIGNALED);
+ igt_assert_f(signaled == 1, "fence did not signal\n");
+
+ close(in_fence[0]);
+ close(in_fence[1]);
+ close(timeline);
+}
+
igt_main
{
igt_subtest("alloc_timeline")
@@ -214,5 +238,8 @@ igt_main
igt_subtest("sync_merge")
test_sync_merge();
+
+ igt_subtest("sync_merge_same")
+ test_sync_merge_same();
}
--
2.10.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH i-g-t v8 18/21] tests/sw_sync: Add igt_require check for sw_sync feature
From: Robert Foss
Make sure that this test is skipped if the sw_sync feature is missing from
the host system.
Signed-off-by: Robert Foss
---
lib/sw_sync.c | 1 +
tests/sw_sync.c | 3 +++
2 files changed, 4 insertions(+)
diff --git a/lib/sw_sync.c b/lib/sw_sync.c
index 38fe670..ac793ad 100644
--- a/lib/sw_sync.c
+++ b/lib/sw_sync.c
@@ -38,6 +38,7 @@
#include
#include
+#include "igt_debugfs.h"
#include "sw_sync.h"
#include "drmtest.h"
#include "ioctl_wrappers.h"
diff --git a/tests/sw_sync.c b/tests/sw_sync.c
index ef21af6..562b71f 100644
--- a/tests/sw_sync.c
+++ b/tests/sw_sync.c
@@ -727,6 +727,9 @@ static void test_sync_random_merge(void)
igt_main
{
+ igt_fixture
+ igt_require_sw_sync();
+
igt_subtest("alloc_timeline")
test_alloc_timeline();
--
2.10.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH i-g-t v8 09/21] tests/sw_sync: Add subtest test_sync_multi_consumer
From: Robert Foss
This subtest verifies the access ordering of multiple consumer threads.
Signed-off-by: Robert Foss
Reviewed-by: Eric Engestrom
---
tests/sw_sync.c | 103
1 file changed, 103 insertions(+)
diff --git a/tests/sw_sync.c b/tests/sw_sync.c
index ada1243..cd0c588 100644
--- a/tests/sw_sync.c
+++ b/tests/sw_sync.c
@@ -27,6 +27,8 @@
*Robert Foss
*/
+#include
+#include
#include
#include
@@ -39,6 +41,15 @@
IGT_TEST_DESCRIPTION("Test SW Sync Framework");
+typedef struct {
+ int timeline;
+ uint32_t thread_id;
+ uint32_t nbr_threads;
+ uint32_t nbr_iterations;
+ volatile uint32_t * volatile counter;
+ sem_t *sem;
+} data_t;
+
static void test_alloc_timeline(void)
{
int timeline;
@@ -219,6 +230,95 @@ static void test_sync_merge_same(void)
close(timeline);
}
+static void * test_sync_multi_consumer_thread(void *arg)
+{
+ data_t *data = arg;
+ int thread_id = data->thread_id;
+ int nbr_threads = data->nbr_threads;
+ int timeline = data->timeline;
+ int iterations = data->nbr_iterations;
+ int ret, i;
+
+ for (i = 0; i < iterations; i++) {
+ int next_point = i * nbr_threads + thread_id;
+ int fence = sw_sync_fence_create(timeline, next_point);
+
+ ret = sync_wait(fence, 1000);
+ if (ret == -1)
+ {
+ return (void *) 1;
+ }
+
+ if (*(data->counter) != next_point)
+ {
+ return (void *) 1;
+ }
+
+ sem_post(data->sem);
+ close(fence);
+ }
+ return NULL;
+}
+
+static void test_sync_multi_consumer(void)
+{
+ const uint32_t nbr_threads = 8;
+ const uint32_t nbr_iterations = 1 << 14;
+ data_t data_arr[nbr_threads];
+ pthread_t thread_arr[nbr_threads];
+ sem_t sem;
+ int timeline;
+ volatile uint32_t counter = 0;
+ uintptr_t thread_ret = 0;
+ data_t data;
+ int i, ret;
+
+ sem_init(&sem, 0, 0);
+ timeline = sw_sync_timeline_create();
+
+ data.nbr_iterations = nbr_iterations;
+ data.nbr_threads = nbr_threads;
+ data.counter = &counter;
+ data.timeline = timeline;
+ data.sem = &sem;
+
+ /* Start sync threads. */
+ for (i = 0; i < nbr_threads; i++)
+ {
+ data_arr[i] = data;
+ data_arr[i].thread_id = i;
+ ret = pthread_create(&thread_arr[i], NULL,
+test_sync_multi_consumer_thread,
+(void *) &(data_arr[i]));
+ igt_assert_eq(ret, 0);
+ }
+
+ /* Produce 'content'. */
+ for (i = 0; i < nbr_threads * nbr_iterations; i++)
+ {
+ sem_wait(&sem);
+
+ counter++;
+ sw_sync_timeline_inc(timeline, 1);
+ }
+
+ /* Wait for threads to complete. */
+ for (i = 0; i < nbr_threads; i++)
+ {
+ uintptr_t local_thread_ret;
+ pthread_join(thread_arr[i], (void **)&local_thread_ret);
+ thread_ret |= local_thread_ret;
+ }
+
+ close(timeline);
+ sem_destroy(&sem);
+
+ igt_assert_f(counter == nbr_threads * nbr_iterations,
+"Counter has unexpected value.\n");
+
+ igt_assert_f(thread_ret == 0, "A sync thread reported failure.\n");
+}
+
igt_main
{
igt_subtest("alloc_timeline")
@@ -241,5 +341,8 @@ igt_main
igt_subtest("sync_merge_same")
test_sync_merge_same();
+
+ igt_subtest("sync_multi_consumer")
+ test_sync_multi_consumer();
}
--
2.10.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH i-g-t v8 15/21] tests/sw_sync: Add subtest test_timeline_closed
From: Robert Foss
This subtest verifies that the fences of a timeline are not signalled when
a timelne is closed.
Signed-off-by: Robert Foss
---
tests/sw_sync.c | 17 +
1 file changed, 17 insertions(+)
diff --git a/tests/sw_sync.c b/tests/sw_sync.c
index b5ea692..1d2c921 100644
--- a/tests/sw_sync.c
+++ b/tests/sw_sync.c
@@ -75,6 +75,20 @@ static void test_alloc_fence_invalid_timeline(void)
igt_assert(__sw_sync_fence_create(-1, 0) < 0);
}
+static void test_timeline_closed(void)
+{
+ int fence, ret;
+ int timeline;
+
+ timeline = sw_sync_timeline_create();
+ fence = sw_sync_fence_create(timeline, 1);
+
+ close(timeline);
+ ret = sync_wait(fence, 0);
+ igt_assert_f(ret == -1 && errno == ETIME,
+"Failure waiting on unsignaled fence on closed
timeline\n");
+}
+
static void test_alloc_merge_fence(void)
{
int in_fence[2];
@@ -707,6 +721,9 @@ igt_main
igt_subtest("alloc_fence_invalid_timeline")
test_alloc_fence_invalid_timeline();
+ igt_subtest("timeline_closed")
+ test_timeline_closed();
+
igt_subtest("alloc_merge_fence")
test_alloc_merge_fence();
--
2.10.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH i-g-t v8 14/21] tests/sw_sync: Add subtest test_sync_expired_merge
From: Rafael Antognolli
This test creates an already expired fence, then creates a merged fence
out of that expired one (passed twice to the merge operation), and
finally closes the merged fence. It shows that if the refcounts are
wrong on the original expired fence, it might get freed while still in
use. Usually a kernel panick will follow.
Signed-off-by: Rafael Antognolli
Signed-off-by: Robert Foss
---
tests/sw_sync.c | 31 +++
1 file changed, 31 insertions(+)
diff --git a/tests/sw_sync.c b/tests/sw_sync.c
index 265e446..b5ea692 100644
--- a/tests/sw_sync.c
+++ b/tests/sw_sync.c
@@ -598,6 +598,34 @@ static void test_sync_multi_producer_single_consumer(void)
pthread_join(threads[i], NULL);
}
+static void test_sync_expired_merge(void)
+{
+ int iterations = 1 << 20;
+ int timeline;
+ int i;
+ int fence_expired, fence_merged;
+
+ timeline = sw_sync_timeline_create();
+
+ sw_sync_timeline_inc(timeline, 100);
+ fence_expired = sw_sync_fence_create(timeline, 1);
+ igt_assert_f(sync_wait(fence_expired, 0) == 0,
+"Failure waiting for expired fence\n");
+
+ fence_merged = sync_merge(fence_expired, fence_expired);
+ close(fence_merged);
+
+ for (i = 0; i < iterations; i++) {
+ int fence = sync_merge(fence_expired, fence_expired);
+
+ igt_assert_f(sync_wait(fence, -1) == 0,
+"Failure waiting on fence\n");
+ close(fence);
+ }
+
+ close(fence_expired);
+}
+
static void test_sync_random_merge(void)
{
int i, size, ret;
@@ -703,6 +731,9 @@ igt_main
igt_subtest("sync_multi_producer_single_consumer")
test_sync_multi_producer_single_consumer();
+ igt_subtest("sync_expired_merge")
+ test_sync_expired_merge();
+
igt_subtest("sync_random_merge")
test_sync_random_merge();
}
--
2.10.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH i-g-t v8 00/21] Implement sw_sync test
From: Robert Foss This series implements the sw_sync test and the lib/sw_sync helper functions for said test. The sw_sync subtests range from very basic tests of the sw_sync functionality, to stress testing and randomized tests. Changes since v1: Added "Reviewed-by: Eric Engestrom " tag lib/sw_sync: - Fixed fd value checking - Fixed fd validity check in sw_sync_fd_close() - Moved sw_sync related paths to define - Switched from malloc+memset to calloc in sync_file_info() - Switched sizeof to dereferenced ptr tests/sw_sync: - Moved lib/sw_sync related code to lib/sw_sync commit - Replaced memset with assignment in loop Changes since v2: lib/sw_sync: - Replaced fd validity check in sw_sync_timeline_create() - Replace sw_sync_XXX_destroy() functions with close() - Simplified sw_sync_timeline_inc() comparison - Changed sw_sync_merge() return value to -errno - Changed name of sw_sync_fence_size() to sw_sync_fence_count() - Reworked implementation of sw_sync_fence_count() - Reworked implementation of sw_sync_fence_count_status() tests/sw_sync: - Replace sw_sync_XXX_destroy() functions with close() Changes since v3: lib/sw_sync: - Changed sw_sync_fence_create() to take uint32_t seqno - Added raw __sw_sync_fence_create() and failure check sw_sync_fence_create() tests/sw_sync: - Switch to using __sw_sync_fence_create() for failure cases Changes since v4: lib/sw_sync: - Fixed whitespace in sw_sync_fence_count() - Fixed whitespace and style of sw_sync_wait() - Fixed whitespace in __sw_sync_fence_count_status() Changes since v5: lib/sw_sync: - Added kernel_has_sw_sync() - Added igt_require_sw_sync() - Split out __sw_sync_merge() from sw_sync_merge() - Added igt_debugfs.h include - Change sw_sync_wait to reflect android implementation - Renamed some functions: - sw_sync_merge -> sync_merge - sw_sync_wait -> sync_wait - sw_sync_fence_count -> sync_fence_count - sw_sync_fence_count_status -> sync_fence_count_status - __sw_sync_fence_count_status -> __sync_fence_count_status tests/sw_sync: - Added subtest test_sync_expired_merge - Added subtest test_timeline_closed - Added subtest test_timeline_closed_signaled - Added subtest test_sync_merge_invalid - Added subtest test_sync_busy_fork - Added subtest test_sync_busy_unixsockets - Skip test on no sw_sync support - Reworked comments of test_sync_wait - Renamed test_sync_wait -> test_sync_busy - Improved test_sync_wait igt_assert_f messages Changes since v6: tests/sw_sync: - Added igt_assert to test_sync_expired_merge - Added prime increments to test_sync_busy Changes since v7: - Removed accidental inclusions Rafael Antognolli (1): tests/sw_sync: Add subtest test_sync_expired_merge Robert Foss (20): lib/sw_sync: Add helper functions for managing synchronization primitives tests/sw_sync: Add sw_sync test tests/sw_sync: Add subtest test_alloc_fence tests/sw_sync: Add subtest test_alloc_fence_invalid_timeline tests/sw_sync: Add subtest test_alloc_merge_fence tests/sw_sync: Add subtest test_sync_busy tests/sw_sync: Add subtest test_sync_merge tests/sw_sync: Add subtest test_sync_merge_same tests/sw_sync: Add subtest test_sync_multi_consumer tests/sw_sync: Add subtest test_sync_multi_consumer_producer tests/sw_sync: Add subtest test_sync_random_merge tests/sw_sync: Add subtest test_sync_multi_timeline_wait tests/sw_sync: Add subtest test_sync_multi_producer_single_consumer tests/sw_sync: Add subtest test_timeline_closed tests/sw_sync: Add subtest test_timeline_closed_signaled lib/sw_sync: Add igt_require_sw_sync to enable skipping on no sw_sync support tests/sw_sync: Add igt_require check for sw_sync feature tests/sw_sync: Add subtest test_sync_merge_invalid tests/sw_sync: Add subtest test_sync_busy_fork tests/sw_sync: Add subtest test_sync_busy_unixsocket lib/Makefile.sources | 2 + lib/sw_sync.c | 222 lib/sw_sync.h | 49 +++ tests/Makefile.sources | 1 + tests/drm_fence| Bin 0 -> 901032 bytes tests/kms_atomic.c.rej | 15 + tests/kms_fence| Bin 0 -> 1798632 bytes tests/sw_sync.c| 961 + 8 files changed, 1250 insertions(+) create mode 100644 lib/sw_sync.c create mode 100644 lib/sw_sync.h create mode 100755 tests/drm_fence create mode 100644 tests/kms_atomic.c.rej create mode 100755 tests/kms_fence create mode 100644 tests/sw_sync.c -- 2.10.2 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH i-g-t v8 01/21] lib/sw_sync: Add helper functions for managing synchronization primitives
From: Robert Foss
Base functions to help testing the Sync File Framework (explicit fencing
mechanism ported from Android).
These functions allow you to create, use and destroy timelines and fences.
Signed-off-by: Robert Foss
Signed-off-by: Gustavo Padovan
Reviewed-by: Eric Engestrom
---
lib/Makefile.sources | 2 +
lib/sw_sync.c| 199 +++
lib/sw_sync.h| 48 +
3 files changed, 249 insertions(+)
create mode 100644 lib/sw_sync.c
create mode 100644 lib/sw_sync.h
diff --git a/lib/Makefile.sources b/lib/Makefile.sources
index e8e277b..7aaf42f 100644
--- a/lib/Makefile.sources
+++ b/lib/Makefile.sources
@@ -63,6 +63,8 @@ lib_source_list = \
rendercopy_gen8.c \
rendercopy_gen9.c \
rendercopy.h\
+ sw_sync.c \
+ sw_sync.h \
intel_reg_map.c \
intel_iosf.c\
igt_kms.c \
diff --git a/lib/sw_sync.c b/lib/sw_sync.c
new file mode 100644
index 000..861119e
--- /dev/null
+++ b/lib/sw_sync.c
@@ -0,0 +1,199 @@
+/*
+ * Copyright 2012 Google, Inc
+ * Copyright © 2016 Collabora, Ltd.
+ *
+ * Based on the implementation from the Android Open Source Project
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
+ * IN THE SOFTWARE.
+ *
+ * Authors:
+ *Robert Foss
+ */
+
+#ifndef ANDROID
+#define _GNU_SOURCE
+#else
+#include
+#endif
+#include
+#include
+#include
+#include
+#include
+
+#include "sw_sync.h"
+#include "drmtest.h"
+#include "ioctl_wrappers.h"
+
+#ifndef SW_SYNC_IOC_INC
+struct sw_sync_create_fence_data {
+ __u32 value;
+ charname[32];
+ __s32 fence;
+};
+
+#define SW_SYNC_IOC_MAGIC 'W'
+#define SW_SYNC_IOC_CREATE_FENCE _IOWR(SW_SYNC_IOC_MAGIC, 0,\
+ struct
sw_sync_create_fence_data)
+#define SW_SYNC_IOC_INC_IOW(SW_SYNC_IOC_MAGIC, 1,
__u32)
+#endif
+
+#define DEVFS_SW_SYNC "/dev/sw_sync"
+#define DEBUGFS_SW_SYNC "/sys/kernel/debug/sync/sw_sync"
+
+
+int sw_sync_fd_is_valid(int fd)
+{
+ int status;
+
+ if (fd < 0)
+ return 0;
+
+ status = fcntl(fd, F_GETFD, 0);
+ return status >= 0;
+}
+
+int sw_sync_timeline_create(void)
+{
+ int fd = open(DEVFS_SW_SYNC, O_RDWR);
+
+ if (fd < 0)
+ fd = open(DEBUGFS_SW_SYNC, O_RDWR);
+
+ igt_assert(sw_sync_fd_is_valid(fd));
+
+ return fd;
+}
+
+int __sw_sync_fence_create(int fd, uint32_t seqno)
+{
+
+ struct sw_sync_create_fence_data data;
+
+ memset(&data, 0, sizeof(data));
+ data.value = seqno;
+
+ if (igt_ioctl(fd, SW_SYNC_IOC_CREATE_FENCE, &data))
+ return -errno;
+
+ return data.fence;
+}
+
+int sw_sync_fence_create(int fd, uint32_t seqno)
+{
+ int fence = __sw_sync_fence_create(fd, seqno);
+ igt_assert(fence >= 0);
+ return fence;
+}
+
+void sw_sync_timeline_inc(int fd, uint32_t count)
+{
+ uint32_t arg = count;
+
+ do_ioctl(fd, SW_SYNC_IOC_INC, &arg);
+}
+
+int sw_sync_merge(int fd1, int fd2)
+{
+ struct sync_merge_data data = {};
+ int err;
+
+ data.fd2 = fd2;
+
+ err = ioctl(fd1, SYNC_IOC_MERGE, &data);
+ if (err < 0)
+ return -errno;
+
+ sw_sync_fd_is_valid(data.fence);
+
+ return data.fence;
+}
+
+int sw_sync_wait(int fd, int timeout)
+{
+ struct pollfd fds = {0};
+ int ret;
+
+ fds.fd = fd;
+ fds.events = POLLIN;
+
+ do {
+ret = poll(&fds, 1, timeout);
+if (ret > 0) {
+ if (fds.revents & (POLLERR | POLLNVAL)) {
+ errno = EINVAL;
+ return -1;
+ }
+ return 0;
+
[Intel-gfx] [PATCH i-g-t v8 03/21] tests/sw_sync: Add subtest test_alloc_fence
From: Robert Foss
Add subtest alloc_fence that verifies that it's possible to allocate a fence
on a timeline.
Signed-off-by: Robert Foss
Reviewed-by: Eric Engestrom
---
tests/sw_sync.c | 16
1 file changed, 16 insertions(+)
diff --git a/tests/sw_sync.c b/tests/sw_sync.c
index 7d27234..8e7764a 100644
--- a/tests/sw_sync.c
+++ b/tests/sw_sync.c
@@ -46,9 +46,25 @@ static void test_alloc_timeline(void)
close(timeline);
}
+static void test_alloc_fence(void)
+{
+ int in_fence;
+ int timeline;
+
+ timeline = sw_sync_timeline_create();
+ in_fence = sw_sync_fence_create(timeline, 0);
+
+ close(in_fence);
+ close(timeline);
+}
+
+
igt_main
{
igt_subtest("alloc_timeline")
test_alloc_timeline();
+
+ igt_subtest("alloc_fence")
+ test_alloc_fence();
}
--
2.10.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH i-g-t v8 16/21] tests/sw_sync: Add subtest test_timeline_closed_signaled
From: Robert Foss
Add subtest test_timeline_closed_signaled that verifies that a signaled fence
stays signaled after its timeline has been closed.
Signed-off-by: Robert Foss
---
tests/sw_sync.c | 18 ++
1 file changed, 18 insertions(+)
diff --git a/tests/sw_sync.c b/tests/sw_sync.c
index 1d2c921..ef21af6 100644
--- a/tests/sw_sync.c
+++ b/tests/sw_sync.c
@@ -89,6 +89,21 @@ static void test_timeline_closed(void)
"Failure waiting on unsignaled fence on closed
timeline\n");
}
+static void test_timeline_closed_signaled(void)
+{
+ int fence, ret;
+ int timeline;
+
+ timeline = sw_sync_timeline_create();
+ fence = sw_sync_fence_create(timeline, 1);
+
+ sw_sync_timeline_inc(timeline, 1);
+ close(timeline);
+ ret = sync_wait(fence, 0);
+ igt_assert_f(ret == 0,
+"Failure waiting on signaled fence for closed timeline\n");
+}
+
static void test_alloc_merge_fence(void)
{
int in_fence[2];
@@ -724,6 +739,9 @@ igt_main
igt_subtest("timeline_closed")
test_timeline_closed();
+ igt_subtest("timeline_closed_signaled")
+ test_timeline_closed_signaled();
+
igt_subtest("alloc_merge_fence")
test_alloc_merge_fence();
--
2.10.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH i-g-t v8 06/21] tests/sw_sync: Add subtest test_sync_busy
From: Robert Foss
This subtest verifies that waiting on fences works properly.
Signed-off-by: Robert Foss
Reviewed-by: Eric Engestrom
---
tests/sw_sync.c | 51 +++
1 file changed, 51 insertions(+)
diff --git a/tests/sw_sync.c b/tests/sw_sync.c
index 03bc0b3..b962e82 100644
--- a/tests/sw_sync.c
+++ b/tests/sw_sync.c
@@ -32,6 +32,7 @@
#include "igt.h"
#include "igt_aux.h"
+#include "igt_primes.h"
#include "sw_sync.h"
@@ -83,6 +84,53 @@ static void test_alloc_merge_fence(void)
close(timeline[1]);
}
+static void test_sync_busy(void)
+{
+ int fence, ret;
+ int timeline;
+ int seqno;
+
+ timeline = sw_sync_timeline_create();
+ fence = sw_sync_fence_create(timeline, 5);
+
+ /* Make sure that fence has not been signaled yet */
+ ret = sync_wait(fence, 0);
+ igt_assert_f(ret == -1 && errno == ETIME, "Fence signaled early
(timeline value 0, fence seqno 5)\n");
+
+ /* Advance timeline from 0 -> 1 */
+ sw_sync_timeline_inc(timeline, 1);
+
+ /* Make sure that fence has not been signaled yet */
+ ret = sync_wait(fence, 0);
+ igt_assert_f(ret == -1 && errno == ETIME, "Fence signaled early
(timeline value 1, fence seqno 5)\n");
+
+ /* Advance timeline from 1 -> 5: signaling the fence (seqno 5)*/
+ sw_sync_timeline_inc(timeline, 4);
+ ret = sync_wait(fence, 0);
+ igt_assert_f(ret == 0, "Fence not signaled (timeline value 5, fence
seqno 5)\n");
+
+ /* Go even further, and confirm wait still succeeds */
+ sw_sync_timeline_inc(timeline, 5);
+ ret = sync_wait(fence, 0);
+ igt_assert_f(ret == 0, "Fence not signaled (timeline value 10, fence
seqno 5)\n");
+
+ seqno = 10;
+ for_each_prime_number(prime, 100) {
+ int fence_prime;
+ seqno += prime;
+
+ fence_prime = sw_sync_fence_create(timeline, seqno);
+ sw_sync_timeline_inc(timeline, prime);
+
+ ret = sync_wait(fence_prime, 0);
+ igt_assert_f(ret == 0, "Fence not signaled during test of prime
timeline increments\n");
+ close(fence_prime);
+ }
+
+ close(fence);
+ close(timeline);
+}
+
igt_main
{
igt_subtest("alloc_timeline")
@@ -96,5 +144,8 @@ igt_main
igt_subtest("alloc_merge_fence")
test_alloc_merge_fence();
+
+ igt_subtest("sync_busy")
+ test_sync_busy();
}
--
2.10.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH i-g-t v8 07/21] tests/sw_sync: Add subtest test_sync_merge
From: Robert Foss
Add subtest test_sync_merge that tests merging fences and the validity of the
resulting merged fence.
Signed-off-by: Robert Foss
Reviewed-by: Eric Engestrom
---
tests/sw_sync.c | 67 +
1 file changed, 67 insertions(+)
diff --git a/tests/sw_sync.c b/tests/sw_sync.c
index b962e82..96dcbff 100644
--- a/tests/sw_sync.c
+++ b/tests/sw_sync.c
@@ -131,6 +131,70 @@ static void test_sync_busy(void)
close(timeline);
}
+static void test_sync_merge(void)
+{
+ int in_fence[3];
+ int fence_merge;
+ int timeline;
+ int active, signaled;
+
+ timeline = sw_sync_timeline_create();
+ in_fence[0] = sw_sync_fence_create(timeline, 1);
+ in_fence[1] = sw_sync_fence_create(timeline, 2);
+ in_fence[2] = sw_sync_fence_create(timeline, 3);
+
+ fence_merge = sync_merge(in_fence[0], in_fence[1]);
+ fence_merge = sync_merge(in_fence[2], fence_merge);
+
+ /* confirm all fences have one active point (even d) */
+ active = sync_fence_count_status(in_fence[0],
+ SW_SYNC_FENCE_STATUS_ACTIVE);
+ igt_assert_f(active == 1, "in_fence[0] has too many active fences\n");
+ active = sync_fence_count_status(in_fence[1],
+ SW_SYNC_FENCE_STATUS_ACTIVE);
+ igt_assert_f(active == 1, "in_fence[1] has too many active fences\n");
+ active = sync_fence_count_status(in_fence[2],
+ SW_SYNC_FENCE_STATUS_ACTIVE);
+ igt_assert_f(active == 1, "in_fence[2] has too many active fences\n");
+ active = sync_fence_count_status(fence_merge,
+ SW_SYNC_FENCE_STATUS_ACTIVE);
+ igt_assert_f(active == 1, "fence_merge has too many active fences\n");
+
+ /* confirm that fence_merge is not signaled until the max of fence
0,1,2 */
+ sw_sync_timeline_inc(timeline, 1);
+ signaled = sync_fence_count_status(in_fence[0],
+ SW_SYNC_FENCE_STATUS_SIGNALED);
+ active = sync_fence_count_status(fence_merge,
+ SW_SYNC_FENCE_STATUS_ACTIVE);
+ igt_assert_f(signaled == 1, "in_fence[0] did not signal\n");
+ igt_assert_f(active == 1, "fence_merge signaled too early\n");
+
+ sw_sync_timeline_inc(timeline, 1);
+ signaled = sync_fence_count_status(in_fence[1],
+ SW_SYNC_FENCE_STATUS_SIGNALED);
+ active = sync_fence_count_status(fence_merge,
+ SW_SYNC_FENCE_STATUS_ACTIVE);
+ igt_assert_f(signaled == 1, "in_fence[1] did not signal\n");
+ igt_assert_f(active == 1, "fence_merge signaled too early\n");
+
+ sw_sync_timeline_inc(timeline, 1);
+ signaled = sync_fence_count_status(in_fence[2],
+ SW_SYNC_FENCE_STATUS_SIGNALED);
+ igt_assert_f(signaled == 1, "in_fence[2] did not signal\n");
+ signaled = sync_fence_count_status(fence_merge,
+ SW_SYNC_FENCE_STATUS_SIGNALED);
+ active = sync_fence_count_status(fence_merge,
+ SW_SYNC_FENCE_STATUS_ACTIVE);
+ igt_assert_f(active == 0 && signaled == 1,
+"fence_merge did not signal\n");
+
+ close(in_fence[0]);
+ close(in_fence[1]);
+ close(in_fence[2]);
+ close(fence_merge);
+ close(timeline);
+}
+
igt_main
{
igt_subtest("alloc_timeline")
@@ -147,5 +211,8 @@ igt_main
igt_subtest("sync_busy")
test_sync_busy();
+
+ igt_subtest("sync_merge")
+ test_sync_merge();
}
--
2.10.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH i-g-t v8 21/21] tests/sw_sync: Add subtest test_sync_busy_unixsocket
From: Robert Foss
Add subtest test_sync_busy_fork which increments the timeline in a forked child
process, where the timeline fd has been sent through a UNIX socket.
Signed-off-by: Robert Foss
---
tests/sw_sync.c | 103
1 file changed, 103 insertions(+)
diff --git a/tests/sw_sync.c b/tests/sw_sync.c
index e0bf6c3..bcf5731 100644
--- a/tests/sw_sync.c
+++ b/tests/sw_sync.c
@@ -30,6 +30,8 @@
#include
#include
#include
+#include
+#include
#include
#include "igt.h"
@@ -171,6 +173,104 @@ static void test_sync_busy(void)
close(timeline);
}
+static void test_sync_busy_fork_unixsocket(void)
+{
+ int fence, ret;
+ int timeline;
+ int skip = 0;
+ int sv[2];
+
+
+ timeline = sw_sync_timeline_create();
+ fence = sw_sync_fence_create(timeline, 1);
+
+ if (socketpair(AF_UNIX, SOCK_DGRAM, 0, sv) != 0) {
+ skip = 1;
+ goto out;
+ }
+
+ switch (fork()) {
+ case 0:
+ {
+ /* Child process */
+ int socket = sv[1];
+ int socket_timeline;
+ struct msghdr msg = {0};
+ struct cmsghdr *cmsg;
+ unsigned char *data;
+ char m_buffer[256];
+ char c_buffer[256];
+ struct iovec io = { .iov_base = m_buffer, .iov_len =
sizeof(m_buffer) };
+ close(sv[0]);
+
+ msg.msg_iov = &io;
+ msg.msg_iovlen = 1;
+ msg.msg_control = c_buffer;
+ msg.msg_controllen = sizeof(c_buffer);
+
+ if (recvmsg(socket, &msg, 0) < 0)
+ _Exit(1);
+
+ cmsg = CMSG_FIRSTHDR(&msg);
+ data = CMSG_DATA(cmsg);
+ socket_timeline = *((int *) data);
+
+ /* Advance timeline from 0 -> 1 */
+ sw_sync_timeline_inc(socket_timeline, 1);
+
+ _Exit(0);
+ break;
+ }
+ case -1:
+ {
+ /* Failed fork */
+ skip = 1;
+ break;
+ }
+ default:
+ {
+ /* Parent process */
+ int socket = sv[0];
+ struct cmsghdr *cmsg;
+ struct iovec io = { .iov_base = (char *)"ABC", .iov_len = 3 };
+ struct msghdr msg = { 0 };
+ char buf[CMSG_SPACE(sizeof(timeline))];
+ memset(buf, '\0', sizeof(buf));
+ close(sv[1]);
+
+ msg.msg_iov = &io;
+ msg.msg_iovlen = 1;
+ msg.msg_control = buf;
+ msg.msg_controllen = sizeof(buf);
+
+ cmsg = CMSG_FIRSTHDR(&msg);
+ cmsg->cmsg_level = SOL_SOCKET;
+ cmsg->cmsg_type = SCM_RIGHTS;
+ cmsg->cmsg_len = CMSG_LEN(sizeof(timeline));
+
+ *((int *) CMSG_DATA(cmsg)) = timeline;
+ msg.msg_controllen = cmsg->cmsg_len;
+
+ ret = sync_wait(fence, 0);
+ igt_assert_f(ret == -1 && errno == ETIME, "Fence signaled (it
should not have been signalled yet)\n");
+
+ if (sendmsg(socket, &msg, 0) < 0) {
+ skip = 1;
+ goto out;
+ }
+
+ ret = sync_wait(fence, 2*1000);
+ igt_assert_f(ret == 0, "Fence not signaled (timeline value 1
fence seqno 1)\n");
+ break;
+ }
+ }
+
+out:
+ close(fence);
+ close(timeline);
+ igt_require(!skip);
+}
+
static void test_sync_busy_fork(void)
{
int fence, ret;
@@ -828,6 +928,9 @@ igt_main
igt_subtest("sync_busy_fork")
test_sync_busy_fork();
+ igt_subtest("sync_busy_fork_unixsocket")
+ test_sync_busy_fork_unixsocket();
+
igt_subtest("sync_merge_invalid")
test_sync_merge_invalid();
--
2.10.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH i-g-t v8 17/21] lib/sw_sync: Add igt_require_sw_sync to enable skipping on no sw_sync support
From: Robert Foss
Add igt_require_sw_sync to provide tests to skip if sw_sync support isn't
available on the host machine.
Signed-off-by: Robert Foss
---
lib/sw_sync.c | 22 ++
lib/sw_sync.h | 1 +
2 files changed, 23 insertions(+)
diff --git a/lib/sw_sync.c b/lib/sw_sync.c
index 862f8c4..38fe670 100644
--- a/lib/sw_sync.c
+++ b/lib/sw_sync.c
@@ -197,3 +197,25 @@ int sync_fence_count_status(int fd, int status)
igt_assert(count >= 0);
return count;
}
+
+static bool kernel_has_sw_sync(void)
+{
+ bool err;
+
+ igt_ignore_warn(system("/sbin/modprobe -s r sw_sync"));
+
+ err = false;
+ if (access(DEVFS_SW_SYNC, R_OK | W_OK) < 0) {
+ char buf[128];
+
+ snprintf(buf, sizeof(buf), "%s/sw_sync", igt_debugfs_mount());
+ err = access(DEBUGFS_SW_SYNC, R_OK | W_OK) < 0;
+ }
+
+ return !err;
+}
+
+void igt_require_sw_sync(void)
+{
+ igt_require(kernel_has_sw_sync());
+}
diff --git a/lib/sw_sync.h b/lib/sw_sync.h
index 1f47b29..0bbe73c 100644
--- a/lib/sw_sync.h
+++ b/lib/sw_sync.h
@@ -43,6 +43,7 @@ int sync_merge(int fd1, int fd2);
int sync_wait(int fence, int timeout);
int sync_fence_count(int fd);
int sync_fence_count_status(int fd, int status);
+void igt_require_sw_sync(void);
#endif
--
2.10.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH i-g-t v8 19/21] tests/sw_sync: Add subtest test_sync_merge_invalid
From: Robert Foss
Add subtest test_sync_merge_invalid that tests merging invalid fences.
Signed-off-by: Robert Foss
---
tests/sw_sync.c | 41 +
1 file changed, 41 insertions(+)
diff --git a/tests/sw_sync.c b/tests/sw_sync.c
index 562b71f..3a67877 100644
--- a/tests/sw_sync.c
+++ b/tests/sw_sync.c
@@ -171,6 +171,44 @@ static void test_sync_busy(void)
close(timeline);
}
+static void test_sync_merge_invalid(void)
+{
+ int in_fence;
+ int fence_invalid;
+ int fence_merge;
+ int timeline;
+ char tmppath[] = "/tmp/igt-XX";
+ int skip = 0;
+
+ timeline = sw_sync_timeline_create();
+ in_fence = sw_sync_fence_create(timeline, 1);
+
+ fence_invalid = -1;
+ fence_merge = sync_merge(in_fence, fence_invalid);
+ igt_assert_f(fence_merge < 0, "Verify invalid fd (-1) handling");
+
+ fence_invalid = drm_open_driver(DRIVER_ANY);
+ fence_merge = sync_merge(in_fence, fence_invalid);
+ igt_assert_f(fence_merge < 0, "Verify invalid fd (device fd) handling");
+
+ fence_invalid = mkstemp(tmppath);
+ if (fence_invalid == -1) {
+ skip = 1;
+ goto out;
+ }
+ unlink(tmppath);
+ fence_invalid = drm_open_driver(DRIVER_ANY);
+ fence_merge = sync_merge(in_fence, fence_invalid);
+ close(fence_invalid);
+ igt_assert_f(fence_merge < 0, "Verify invalid fd (file fd) handling");
+
+out:
+ close(in_fence);
+ close(fence_merge);
+ close(timeline);
+ igt_require(skip == 0);
+}
+
static void test_sync_merge(void)
{
int in_fence[3];
@@ -751,6 +789,9 @@ igt_main
igt_subtest("sync_busy")
test_sync_busy();
+ igt_subtest("sync_merge_invalid")
+ test_sync_merge_invalid();
+
igt_subtest("sync_merge")
test_sync_merge();
--
2.10.2
___
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: Move the release of PT page to the upper caller
== Series Details == Series: drm/i915: Move the release of PT page to the upper caller URL : https://patchwork.freedesktop.org/series/15651/ State : success == Summary == Series 15651v1 drm/i915: Move the release of PT page to the upper caller https://patchwork.freedesktop.org/api/1.0/series/15651/revisions/1/mbox/ fi-bdw-5557u total:244 pass:229 dwarn:0 dfail:0 fail:0 skip:15 fi-bsw-n3050 total:244 pass:204 dwarn:0 dfail:0 fail:0 skip:40 fi-bxt-t5700 total:244 pass:216 dwarn:0 dfail:0 fail:0 skip:28 fi-byt-j1900 total:244 pass:216 dwarn:0 dfail:0 fail:0 skip:28 fi-byt-n2820 total:244 pass:212 dwarn:0 dfail:0 fail:0 skip:32 fi-hsw-4770 total:244 pass:224 dwarn:0 dfail:0 fail:0 skip:20 fi-hsw-4770r total:244 pass:224 dwarn:0 dfail:0 fail:0 skip:20 fi-ilk-650 total:244 pass:191 dwarn:0 dfail:0 fail:0 skip:53 fi-ivb-3520m total:244 pass:222 dwarn:0 dfail:0 fail:0 skip:22 fi-ivb-3770 total:244 pass:222 dwarn:0 dfail:0 fail:0 skip:22 fi-kbl-7200u total:244 pass:222 dwarn:0 dfail:0 fail:0 skip:22 fi-skl-6260u total:244 pass:230 dwarn:0 dfail:0 fail:0 skip:14 fi-skl-6700hqtotal:244 pass:223 dwarn:0 dfail:0 fail:0 skip:21 fi-skl-6700k total:244 pass:222 dwarn:1 dfail:0 fail:0 skip:21 fi-skl-6770hqtotal:244 pass:230 dwarn:0 dfail:0 fail:0 skip:14 fi-snb-2520m total:244 pass:212 dwarn:0 dfail:0 fail:0 skip:32 fi-snb-2600 total:244 pass:211 dwarn:0 dfail:0 fail:0 skip:33 d6149d212b69a8e1d9229fe80fca034a0abe1d0e drm-intel-nightly: 2016y-11m-21d-12h-48m-13s UTC integration manifest a7b4f2e drm/i915: Move the release of PT page to the upper caller == Logs == For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_3069/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 3/5] drm/i915: Update CRTC state if connector link status property changed
On Mon, Nov 21, 2016 at 11:10:45AM +0100, Daniel Vetter wrote:
> On Mon, Nov 21, 2016 at 09:42:57AM +, Chris Wilson wrote:
> > On Mon, Nov 21, 2016 at 10:38:20AM +0100, Daniel Vetter wrote:
> > > On Fri, Nov 18, 2016 at 09:44:49AM -0800, Manasi Navare wrote:
> > > > On Fri, Nov 18, 2016 at 06:21:21PM +0200, Ville Syrjälä wrote:
> > > > > On Fri, Nov 18, 2016 at 04:35:25PM +0100, Daniel Vetter wrote:
> > > > > > On Fri, Nov 18, 2016 at 05:28:54PM +0200, Ville Syrjälä wrote:
> > > > > > > On Fri, Nov 18, 2016 at 03:18:06PM +0100, Maarten Lankhorst wrote:
> > > > > > > > Op 18-11-16 om 15:11 schreef Ville Syrjälä:
> > > > > > > > > On Fri, Nov 18, 2016 at 02:50:52PM +0100, Maarten Lankhorst
> > > > > > > > > wrote:
> > > > > > > > >> Op 18-11-16 om 08:13 schreef Manasi Navare:
> > > > > > > > >>> CRTC state connector_changed needs to be set to true
> > > > > > > > >>> if connector link status property has changed. This will
> > > > > > > > >>> tell the
> > > > > > > > >>> driver to do a complete modeset due to change in connector
> > > > > > > > >>> property.
> > > > > > > > >>>
> > > > > > > > >>> Acked-by: Harry Wentland
> > > > > > > > >>> Acked-by: Tony Cheng
> > > > > > > > >>> Cc: dri-de...@lists.freedesktop.org
> > > > > > > > >>> Cc: Jani Nikula
> > > > > > > > >>> Cc: Daniel Vetter
> > > > > > > > >>> Cc: Ville Syrjala
> > > > > > > > >>> Signed-off-by: Manasi Navare
> > > > > > > > >>> ---
> > > > > > > > >>> drivers/gpu/drm/drm_atomic_helper.c | 7 +++
> > > > > > > > >>> 1 file changed, 7 insertions(+)
> > > > > > > > >>>
> > > > > > > > >>> diff --git a/drivers/gpu/drm/drm_atomic_helper.c
> > > > > > > > >>> b/drivers/gpu/drm/drm_atomic_helper.c
> > > > > > > > >>> index 0b16587..2125fd1 100644
> > > > > > > > >>> --- a/drivers/gpu/drm/drm_atomic_helper.c
> > > > > > > > >>> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> > > > > > > > >>> @@ -519,6 +519,13 @@ static int
> > > > > > > > >>> handle_conflicting_encoders(struct drm_atomic_state *state,
> > > > > > > > >>>connector_state);
> > > > > > > > >>> if (ret)
> > > > > > > > >>> return ret;
> > > > > > > > >>> +
> > > > > > > > >>> + if (connector->state->crtc) {
> > > > > > > > >>> + crtc_state =
> > > > > > > > >>> drm_atomic_get_existing_crtc_state(state,
> > > > > > > > >>> +
> > > > > > > > >>> connector->state->crtc);
> > > > > > > > >>> + if (connector->link_status ==
> > > > > > > > >>> DRM_MODE_LINK_STATUS_BAD)
> > > > > > > > >>> + crtc_state->connectors_changed
> > > > > > > > >>> = true;
> > > > > > > > >>> + }
> > > > > > > > >>> }
> > > > > > > > >>>
> > > > > > > > >>> /*
> > > > > > > > >> This will cause ordinary atomic commits that happen to
> > > > > > > > >> change connector flags to potentially fail with -EINVAL if
> > > > > > > > >> ALLOW_MODESET is not set.
> > > > > > > > >> For this reason I'm not sure this flag should be set
> > > > > > > > >> automatically by the kernel. Could we add add a retrain link
> > > > > > > > >> property instead, that
> > > > > > > > >> always return 0 when queried, but writing a 1 causing
> > > > > > > > >> connectors_changed to be set on bad link status?
> > > > > > > > > Or just check for allow_modeset before setting
> > > > > > > > > connectors_changed=true here?
> > > > > > > >
> > > > > > > > I don't think modesets should be done automatically like that,
> > > > > > > > even if ALLOW_MODESET is set a modeset may not be expected by
> > > > > > > > userspace.
> > > > > > >
> > > > > > > Presumably userspace would want a picture on the screen using any
> > > > > > > means
> > > > > > > if it said ALLOW_MODESET. So if it can't tolerate the modeset it
> > > > > > > should
> > > > > > > probably say as much?
> > > > > >
> > > > > > Yeah, agreed. Also, if the link is bad then we pretty much have to
> > > > > > do a
> > > > > > modeset to recover it, otherwise you'll be forever stuck with a bad
> > > > > > screen.
> > > > > >
> > > > > > What we could try is to gate this of whether userspace touches the
> > > > > > mode
> > > > > > property on the corresponding CRTC. I.e. if that's touched (even if
> > > > > > it's
> > > > > > the same mode), and a link is bad in one of the connectors in the
> > > > > > state
> > > > > > then we do a full modeset to recover.
> > > > > >
> > > > > > Another option would be to make the link status writeable. Trying to
> > > > > > change it from bad->good would force the modeset. That would be
> > > > > > 100% clear
> > > > > > to userspace, not special hacks needed with checking for
> > > > > > allow_modeset,
> > > > > > no magic property that auto-changes its value. And 100% backwards
> > > > > > compat
> > > > > > because existing userspace should never touch properties it doesn't
> > >
Re: [Intel-gfx] [PATCH i-g-t v8 02/21] tests/sw_sync: Add sw_sync test
On Mon, Nov 21, 2016 at 10:29:03AM -0500, robert.f...@collabora.com wrote: > From: Robert Foss > > Add initial tests for sw_sync. > > Signed-off-by: Robert Foss > Signed-off-by: Gustavo Padovan > Reviewed-by: Eric Engestrom > --- > lib/sw_sync.c | 12 +-- > lib/sw_sync.h | 8 > tests/Makefile.sources | 1 + > tests/drm_fence| Bin 0 -> 901032 bytes > tests/kms_atomic.c.rej | 15 ++ > tests/kms_fence| Bin 0 -> 1798632 bytes > tests/sw_sync.c| 54 > + > 7 files changed, 80 insertions(+), 10 deletions(-) > create mode 100755 tests/drm_fence > create mode 100644 tests/kms_atomic.c.rej > create mode 100755 tests/kms_fence Awooga. -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: Stop the machine as we install the wedged submit_request handler
== Series Details == Series: drm/i915: Stop the machine as we install the wedged submit_request handler URL : https://patchwork.freedesktop.org/series/15652/ State : success == Summary == Series 15652v1 drm/i915: Stop the machine as we install the wedged submit_request handler https://patchwork.freedesktop.org/api/1.0/series/15652/revisions/1/mbox/ fi-bdw-5557u total:244 pass:229 dwarn:0 dfail:0 fail:0 skip:15 fi-bsw-n3050 total:244 pass:204 dwarn:0 dfail:0 fail:0 skip:40 fi-bxt-t5700 total:244 pass:216 dwarn:0 dfail:0 fail:0 skip:28 fi-byt-j1900 total:244 pass:216 dwarn:0 dfail:0 fail:0 skip:28 fi-byt-n2820 total:244 pass:212 dwarn:0 dfail:0 fail:0 skip:32 fi-hsw-4770 total:244 pass:224 dwarn:0 dfail:0 fail:0 skip:20 fi-hsw-4770r total:244 pass:224 dwarn:0 dfail:0 fail:0 skip:20 fi-ilk-650 total:244 pass:191 dwarn:0 dfail:0 fail:0 skip:53 fi-ivb-3520m total:244 pass:222 dwarn:0 dfail:0 fail:0 skip:22 fi-ivb-3770 total:244 pass:222 dwarn:0 dfail:0 fail:0 skip:22 fi-kbl-7200u total:244 pass:222 dwarn:0 dfail:0 fail:0 skip:22 fi-skl-6260u total:244 pass:230 dwarn:0 dfail:0 fail:0 skip:14 fi-skl-6700hqtotal:244 pass:223 dwarn:0 dfail:0 fail:0 skip:21 fi-skl-6700k total:244 pass:222 dwarn:1 dfail:0 fail:0 skip:21 fi-skl-6770hqtotal:244 pass:230 dwarn:0 dfail:0 fail:0 skip:14 fi-snb-2520m total:244 pass:212 dwarn:0 dfail:0 fail:0 skip:32 fi-snb-2600 total:244 pass:211 dwarn:0 dfail:0 fail:0 skip:33 d6149d212b69a8e1d9229fe80fca034a0abe1d0e drm-intel-nightly: 2016y-11m-21d-12h-48m-13s UTC integration manifest 54b0b7c drm/i915: Stop the machine as we install the wedged submit_request handler == Logs == For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_3070/ ___ 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: Disable hangcheck when wedged (rev2)
== Series Details == Series: series starting with [1/3] drm/i915: Disable hangcheck when wedged (rev2) URL : https://patchwork.freedesktop.org/series/15543/ State : warning == Summary == Series 15543v2 Series without cover letter https://patchwork.freedesktop.org/api/1.0/series/15543/revisions/2/mbox/ Test kms_pipe_crc_basic: Subgroup hang-read-crc-pipe-b: pass -> DMESG-WARN (fi-ilk-650) fi-bdw-5557u total:244 pass:229 dwarn:0 dfail:0 fail:0 skip:15 fi-bsw-n3050 total:244 pass:204 dwarn:0 dfail:0 fail:0 skip:40 fi-bxt-t5700 total:244 pass:216 dwarn:0 dfail:0 fail:0 skip:28 fi-byt-j1900 total:244 pass:216 dwarn:0 dfail:0 fail:0 skip:28 fi-byt-n2820 total:244 pass:212 dwarn:0 dfail:0 fail:0 skip:32 fi-hsw-4770 total:244 pass:224 dwarn:0 dfail:0 fail:0 skip:20 fi-hsw-4770r total:244 pass:224 dwarn:0 dfail:0 fail:0 skip:20 fi-ilk-650 total:244 pass:190 dwarn:1 dfail:0 fail:0 skip:53 fi-ivb-3520m total:244 pass:222 dwarn:0 dfail:0 fail:0 skip:22 fi-ivb-3770 total:244 pass:222 dwarn:0 dfail:0 fail:0 skip:22 fi-kbl-7200u total:244 pass:222 dwarn:0 dfail:0 fail:0 skip:22 fi-skl-6260u total:244 pass:230 dwarn:0 dfail:0 fail:0 skip:14 fi-skl-6700hqtotal:244 pass:223 dwarn:0 dfail:0 fail:0 skip:21 fi-skl-6700k total:244 pass:222 dwarn:1 dfail:0 fail:0 skip:21 fi-skl-6770hqtotal:244 pass:230 dwarn:0 dfail:0 fail:0 skip:14 fi-snb-2520m total:244 pass:212 dwarn:0 dfail:0 fail:0 skip:32 fi-snb-2600 total:244 pass:211 dwarn:0 dfail:0 fail:0 skip:33 d6149d212b69a8e1d9229fe80fca034a0abe1d0e drm-intel-nightly: 2016y-11m-21d-12h-48m-13s UTC integration manifest 1886e59 drm/i915: Stop the machine as we install the wedged submit_request handler 0012d66 drm/i915: Complete requests in nop_submit_request 8355d47 drm/i915: Disable hangcheck when wedged == Logs == For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_3071/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v5 1/8] drm/i915/skl: Add variables to check x_tile and y_tile
Em Sex, 2016-11-18 às 20:39 +0530, Mahesh Kumar escreveu:
> This patch adds variable to check for X_tiled & y_tiled planes,
> instead
> of always checking against framebuffer-modifiers.
>
> Changes:
> - Created separate patch as per Paulo's comment
> - Added x_tiled variable as well
> Changes since V2:
> - Incorporate Paulo's comments
> - Rebase
>
> Signed-off-by: Mahesh Kumar
> ---
> drivers/gpu/drm/i915/intel_pm.c | 22 --
> 1 file changed, 12 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_pm.c
> b/drivers/gpu/drm/i915/intel_pm.c
> index e54708d..8908736 100644
> --- a/drivers/gpu/drm/i915/intel_pm.c
> +++ b/drivers/gpu/drm/i915/intel_pm.c
> @@ -3592,13 +3592,18 @@ static int skl_compute_plane_wm(const struct
> drm_i915_private *dev_priv,
> struct intel_atomic_state *state =
> to_intel_atomic_state(cstate->base.state);
> bool apply_memory_bw_wa = skl_needs_memory_bw_wa(state);
> + bool y_tiled, x_tiled;
>
> if (latency == 0 || !cstate->base.active || !intel_pstate-
> >base.visible) {
> *enabled = false;
> return 0;
> }
>
> - if (apply_memory_bw_wa && fb->modifier ==
> I915_FORMAT_MOD_X_TILED)
> + y_tiled = fb->modifier == I915_FORMAT_MOD_Y_TILED ||
> + fb->modifier ==
> I915_FORMAT_MOD_Yf_TILED;
Unusual indentation here. I can fix this while applying the patch.
Reviewed-by: Paulo Zanoni
> + x_tiled = fb->modifier == I915_FORMAT_MOD_X_TILED;
> +
> + if (apply_memory_bw_wa && x_tiled)
> latency += 15;
>
> width = drm_rect_width(&intel_pstate->base.src) >> 16;
> @@ -3637,16 +3642,15 @@ static int skl_compute_plane_wm(const struct
> drm_i915_private *dev_priv,
> y_min_scanlines *= 2;
>
> plane_bytes_per_line = width * cpp;
> - if (fb->modifier == I915_FORMAT_MOD_Y_TILED ||
> - fb->modifier == I915_FORMAT_MOD_Yf_TILED) {
> + if (y_tiled) {
> plane_blocks_per_line =
> DIV_ROUND_UP(plane_bytes_per_line *
> y_min_scanlines, 512);
> plane_blocks_per_line /= y_min_scanlines;
> - } else if (fb->modifier == DRM_FORMAT_MOD_NONE) {
> + } else if (x_tiled) {
> + plane_blocks_per_line =
> DIV_ROUND_UP(plane_bytes_per_line, 512);
> + } else {
> plane_blocks_per_line =
> DIV_ROUND_UP(plane_bytes_per_line, 512)
> + 1;
> - } else {
> - plane_blocks_per_line =
> DIV_ROUND_UP(plane_bytes_per_line, 512);
> }
>
> method1 = skl_wm_method1(plane_pixel_rate, cpp, latency);
> @@ -3657,8 +3661,7 @@ static int skl_compute_plane_wm(const struct
> drm_i915_private *dev_priv,
>
> y_tile_minimum = plane_blocks_per_line * y_min_scanlines;
>
> - if (fb->modifier == I915_FORMAT_MOD_Y_TILED ||
> - fb->modifier == I915_FORMAT_MOD_Yf_TILED) {
> + if (y_tiled) {
> selected_result = max(method2, y_tile_minimum);
> } else {
> if ((cpp * cstate->base.adjusted_mode.crtc_htotal /
> 512 < 1) &&
> @@ -3674,8 +3677,7 @@ static int skl_compute_plane_wm(const struct
> drm_i915_private *dev_priv,
> res_lines = DIV_ROUND_UP(selected_result,
> plane_blocks_per_line);
>
> if (level >= 1 && level <= 7) {
> - if (fb->modifier == I915_FORMAT_MOD_Y_TILED ||
> - fb->modifier == I915_FORMAT_MOD_Yf_TILED) {
> + if (y_tiled) {
> res_blocks += y_tile_minimum;
> res_lines += y_min_scanlines;
> } else {
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Don't deref context->file_priv ERR_PTR upon reset
== Series Details == Series: drm/i915: Don't deref context->file_priv ERR_PTR upon reset URL : https://patchwork.freedesktop.org/series/15658/ State : failure == Summary == Series 15658v1 drm/i915: Don't deref context->file_priv ERR_PTR upon reset https://patchwork.freedesktop.org/api/1.0/series/15658/revisions/1/mbox/ Test drv_module_reload_basic: pass -> DMESG-WARN (fi-skl-6770hq) Test kms_pipe_crc_basic: Subgroup suspend-read-crc-pipe-b: pass -> INCOMPLETE (fi-skl-6260u) fi-bdw-5557u total:244 pass:229 dwarn:0 dfail:0 fail:0 skip:15 fi-bsw-n3050 total:244 pass:204 dwarn:0 dfail:0 fail:0 skip:40 fi-bxt-t5700 total:244 pass:216 dwarn:0 dfail:0 fail:0 skip:28 fi-byt-j1900 total:244 pass:216 dwarn:0 dfail:0 fail:0 skip:28 fi-byt-n2820 total:244 pass:212 dwarn:0 dfail:0 fail:0 skip:32 fi-hsw-4770 total:244 pass:224 dwarn:0 dfail:0 fail:0 skip:20 fi-hsw-4770r total:244 pass:224 dwarn:0 dfail:0 fail:0 skip:20 fi-ilk-650 total:244 pass:191 dwarn:0 dfail:0 fail:0 skip:53 fi-ivb-3520m total:244 pass:222 dwarn:0 dfail:0 fail:0 skip:22 fi-ivb-3770 total:244 pass:222 dwarn:0 dfail:0 fail:0 skip:22 fi-kbl-7200u total:244 pass:222 dwarn:0 dfail:0 fail:0 skip:22 fi-skl-6260u total:207 pass:194 dwarn:0 dfail:0 fail:0 skip:12 fi-skl-6700hqtotal:244 pass:223 dwarn:0 dfail:0 fail:0 skip:21 fi-skl-6700k total:244 pass:222 dwarn:1 dfail:0 fail:0 skip:21 fi-skl-6770hqtotal:244 pass:229 dwarn:1 dfail:0 fail:0 skip:14 fi-snb-2520m total:244 pass:212 dwarn:0 dfail:0 fail:0 skip:32 fi-snb-2600 total:244 pass:211 dwarn:0 dfail:0 fail:0 skip:33 d6149d212b69a8e1d9229fe80fca034a0abe1d0e drm-intel-nightly: 2016y-11m-21d-12h-48m-13s UTC integration manifest dab7666 drm/i915: Don't deref context->file_priv ERR_PTR upon reset == Logs == For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_3072/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v5 2/8] drm/i915/bxt: IPC WA for Broxton
Em Sex, 2016-11-18 às 20:39 +0530, Mahesh Kumar escreveu:
> If IPC is enabled in BXT, display underruns are observed.
> WA: The Line Time programmed in the WM_LINETIME register should be
> half of the actual calculated Line Time.
>
> Programmed Line Time = 1/2*Calculated Line Time
>
> Signed-off-by: Mahesh Kumar
> ---
> drivers/gpu/drm/i915/i915_drv.c | 2 ++
> drivers/gpu/drm/i915/i915_drv.h | 3 +++
> drivers/gpu/drm/i915/intel_pm.c | 11 +--
> 3 files changed, 14 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.c
> b/drivers/gpu/drm/i915/i915_drv.c
> index 445fec9..1b0a589 100644
> --- a/drivers/gpu/drm/i915/i915_drv.c
> +++ b/drivers/gpu/drm/i915/i915_drv.c
> @@ -1243,6 +1243,8 @@ int i915_driver_load(struct pci_dev *pdev,
> const struct pci_device_id *ent)
>
> intel_runtime_pm_enable(dev_priv);
>
> + dev_priv->ipc_enabled = false;
> +
> /* Everything is in place, we can now relax! */
> DRM_INFO("Initialized %s %d.%d.%d %s for %s on minor %d\n",
> driver.name, driver.major, driver.minor,
> driver.patchlevel,
> diff --git a/drivers/gpu/drm/i915/i915_drv.h
> b/drivers/gpu/drm/i915/i915_drv.h
> index 63c0ea0..394d7ea 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -2128,6 +2128,9 @@ struct drm_i915_private {
> /* perform PHY state sanity checks? */
> bool chv_phy_assert[2];
>
> + /* To apply IPC WA */
The comment is not exactly necessary since we can just look where
ipc_enabled is used to find out why it's here. As a bonus, whenever we
add more ipc_enabled readers we won't need to update the comment.
> + bool ipc_enabled;
> +
> /* Used to save the pipe-to-encoder mapping for audio */
> struct intel_encoder *av_enc_map[I915_MAX_PIPES];
>
> diff --git a/drivers/gpu/drm/i915/intel_pm.c
> b/drivers/gpu/drm/i915/intel_pm.c
> index 8908736..7090a7c 100644
> --- a/drivers/gpu/drm/i915/intel_pm.c
> +++ b/drivers/gpu/drm/i915/intel_pm.c
> @@ -3769,7 +3769,10 @@ skl_compute_wm_level(const struct
> drm_i915_private *dev_priv,
> static uint32_t
> skl_compute_linetime_wm(struct intel_crtc_state *cstate)
> {
> + struct drm_atomic_state *state = cstate->base.state;
> + struct drm_i915_private *dev_priv = to_i915(state->dev);
> uint32_t pixel_rate;
> + uint32_t linetime_wm;
>
> if (!cstate->base.active)
> return 0;
> @@ -3779,8 +3782,12 @@ skl_compute_linetime_wm(struct
> intel_crtc_state *cstate)
> if (WARN_ON(pixel_rate == 0))
> return 0;
>
> - return DIV_ROUND_UP(8 * cstate-
> >base.adjusted_mode.crtc_htotal * 1000,
> - pixel_rate);
> + linetime_wm = DIV_ROUND_UP(8 * cstate-
> >base.adjusted_mode.crtc_htotal *
> + 1000, pixel_rate);
Weird indentation here again. Is your editor configured to show tabs as
4 spaces?
> + if (IS_BROXTON(dev_priv) && dev_priv->ipc_enabled)
Once we merge Gemnilake, we'll need to write a patch checking for it
here.
Anyway, my two suggestions can be fixed while merging, so:
Reviewed-by: Paulo Zanoni
> + linetime_wm = DIV_ROUND_UP(linetime_wm, 2);
> +
> + return linetime_wm;
> }
>
> static void skl_compute_transition_wm(struct intel_crtc_state
> *cstate,
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v5 3/8] drm/i915/kbl: IPC workaround for kabylake
Em Sex, 2016-11-18 às 20:39 +0530, Mahesh Kumar escreveu: > IPC (Isoch Priority Control) may cause underflows. > > KBL WA: When IPC is enabled, watermark latency values must be > increased > by 4us across all levels. This brings level 0 up to 6us. > > Signed-off-by: Mahesh Kumar > --- > drivers/gpu/drm/i915/intel_pm.c | 4 > 1 file changed, 4 insertions(+) > > diff --git a/drivers/gpu/drm/i915/intel_pm.c > b/drivers/gpu/drm/i915/intel_pm.c > index 7090a7c..df39b50 100644 > --- a/drivers/gpu/drm/i915/intel_pm.c > +++ b/drivers/gpu/drm/i915/intel_pm.c > @@ -3599,6 +3599,10 @@ static int skl_compute_plane_wm(const struct > drm_i915_private *dev_priv, > return 0; > } > > + /* IPC WA for kabylake */ > + if (IS_KABYLAKE(dev_priv) && dev_priv->ipc_enabled) > + latency += 4; > + Nitpick: put this a little below so it's next to the other code that changes the latency. With or without this: Reviewed-by: Paulo Zanoni > y_tiled = fb->modifier == I915_FORMAT_MOD_Y_TILED || > fb->modifier == > I915_FORMAT_MOD_Yf_TILED; > x_tiled = fb->modifier == I915_FORMAT_MOD_X_TILED; ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/bxt: Use smaller 8/3X MIPI clock divider value for dual link.
On Sat, 19 Nov 2016 11:20:56 +0100 David Weinehall wrote: > On Fri, Nov 18, 2016 at 02:11:56PM -0800, Bob Paauwe wrote: > > For a single link (channel) DSI panel we want to use a larger divider > > and keep the clock rate down to save power when in DPI/video mode. However > > when using a dual-link DSI panel this may reduce the clock below what's > > needed to get a stable display. > > > > Use the smaller divider (faster clock) for either DBI/command mode or > > when using dual link. > > > > Signed-off-by: Bob Paauwe > > --- > > drivers/gpu/drm/i915/intel_dsi_pll.c | 9 +++-- > > 1 file changed, 7 insertions(+), 2 deletions(-) > > > > diff --git a/drivers/gpu/drm/i915/intel_dsi_pll.c > > b/drivers/gpu/drm/i915/intel_dsi_pll.c > > index 56eff60..9edc57e 100644 > > --- a/drivers/gpu/drm/i915/intel_dsi_pll.c > > +++ b/drivers/gpu/drm/i915/intel_dsi_pll.c > > @@ -414,8 +414,13 @@ static void bxt_dsi_program_clocks(struct drm_device > > *dev, enum port port, > > rx_div_lower = rx_div & RX_DIVIDER_BIT_1_2; > > rx_div_upper = (rx_div & RX_DIVIDER_BIT_3_4) >> 2; > > > > - /* As per bpsec program the 8/3X clock divider to the below value */ > > - if (dev_priv->vbt.dsi.config->is_cmd_mode) > > + /* > > +* Set the 8/3X clock to divide by 3 for DBI mode as it needs a > > Shouldn't this be "divide by 2", to be consistent with the code > and the commit message? The value programmed into the bits isn't the same as the what the value represents. In this case we program the bits to 10b to use the by 3 divider and 11b to use the by 4 divider. It can also be programmed with 01b for a by 2 divider but that's not used. The 0x2 and 0x3 would probably be better represented by defines to make that clear, but I'd think would be a separate patch. > > > +* faster clock than DPI mode. However, dual link panels also > > +* need the faster clock, even when in DPI mode. > > +*/ > > + if (dev_priv->vbt.dsi.config->is_cmd_mode || > > + dev_priv->vbt.dsi.config->dual_link) > > mipi_8by3_divider = 0x2; > > else > > mipi_8by3_divider = 0x3; > > > Kind regards, David Weinehall -- -- Bob Paauwe bob.j.paa...@intel.com IOTG / PED Software Organization Intel Corp. Folsom, CA (916) 356-6193 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [RFC i-g-t v2 0/5] intel-gpu-tools: Add support for the Chamelium
This is the next version of the patchset for adding Chamelium support into intel-gpu-tools. The major changes (described in more details in the actual patches): - Connector mappings are specified in a configuration file, no more guessing - Some fixes for tests that were throwing false negatives - Cleanups - Split into slightly smaller patches As well, it was suggested that we use libsoup for the XMLRPC interactions with the Chamelium since we already include glib in igt's build deps, however I decided against it because (at least this seems to be the case on Fedora) libsoup is actually packaged seperately from glib, so using it would still require adding another dependency anyway. If I'm wrong here, feel free to let me know. As a final note: a few of the DisplayPort tests can prove to be unreliable on some hardware, and the dp-display test will only work once by default. This is due to a couple of bugs with chameleond's handling of the chamelium's DP receiver. These problems can mostly be alleviated by using the patches I've got here https://github.com/Lyude/chameleond/tree/wip/chameleon-fixes All of which I'll be sending to Google at some point (whenever I get their strange depot-tools setup). As well, all of the display tests won't work on non-intel hardware due to a couple of errorneous intel-hardware specific assumptions made in igt_kms.c, which I should have fixed soon. Lyude (5): igt_aux: Add igt_skip_without_suspend_support() igt_aux: Add igt_set_autoresume_delay() igt_aux: Add some list helpers from wayland igt_kms: Add helpers for watching for sysfs hotplug events Add support for hotplug testing with the Chamelium configure.ac | 13 + lib/Makefile.am| 10 +- lib/igt.h | 3 + lib/igt_aux.c | 94 +++ lib/igt_aux.h | 41 +++ lib/igt_chamelium.c| 689 + lib/igt_chamelium.h| 69 + lib/igt_kms.c | 109 lib/igt_kms.h | 6 + scripts/run-tests.sh | 4 +- tests/Makefile.am | 5 +- tests/Makefile.sources | 1 + tests/chamelium.c | 407 + 13 files changed, 1447 insertions(+), 4 deletions(-) create mode 100644 lib/igt_chamelium.c create mode 100644 lib/igt_chamelium.h create mode 100644 tests/chamelium.c -- 2.7.4 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [RFC i-g-t v2 2/5] igt_aux: Add igt_set_autoresume_delay()
The default autoresume delay is about 5 seconds. It's possible on a
system that's not very fast this might not be a long enough time, since
an asynchronous hotplug event we scheduled on the chamelium that was
intended to happen during suspend could happen before we actually manage
to suspend. So, add a function that allows us to increase the autoresume
time to ensure this never happens during suspend/resume tests with the
chamelium.
Signed-off-by: Lyude
Changes since v1:
- Use igt_require, not assert
---
lib/igt_aux.c | 46 ++
lib/igt_aux.h | 1 +
2 files changed, 47 insertions(+)
diff --git a/lib/igt_aux.c b/lib/igt_aux.c
index 9754148..67432c6 100644
--- a/lib/igt_aux.c
+++ b/lib/igt_aux.c
@@ -812,6 +812,52 @@ void igt_system_suspend_autoresume(enum igt_suspend_state
state,
close(power_dir);
}
+static int original_autoresume_delay;
+
+static void igt_restore_autoresume_delay(int sig)
+{
+ int delay_fd;
+ char delay_str[10];
+
+ igt_require((delay_fd =
open("/sys/module/suspend/parameters/pm_test_delay",
+ O_WRONLY)) >= 0);
+
+ snprintf(delay_str, sizeof(delay_str), "%d", original_autoresume_delay);
+ igt_require(write(delay_fd, delay_str, strlen(delay_str)));
+
+ close(delay_fd);
+}
+
+/**
+ * igt_set_autoresume_delay:
+ * @delay_secs: The delay in seconds before resuming the system
+ *
+ * Sets how long we wait to resume the system after suspending it, using the
+ * suspend.pm_test_delay variable. On exit, the original delay value is
+ * restored.
+ */
+void igt_set_autoresume_delay(int delay_secs)
+{
+ int delay_fd;
+ char delay_str[10];
+
+ igt_skip_on_simulation();
+
+ igt_require((delay_fd =
open("/sys/module/suspend/parameters/pm_test_delay",
+ O_RDWR)) >= 0);
+
+ if (!original_autoresume_delay) {
+ igt_require(read(delay_fd, delay_str, sizeof(delay_str)));
+ original_autoresume_delay = atoi(delay_str);
+ igt_install_exit_handler(igt_restore_autoresume_delay);
+ }
+
+ snprintf(delay_str, sizeof(delay_str), "%d", delay_secs);
+ igt_require(write(delay_fd, delay_str, strlen(delay_str)));
+
+ close(delay_fd);
+}
+
/**
* igt_drop_root:
*
diff --git a/lib/igt_aux.h b/lib/igt_aux.h
index 973a9cd..7cee901 100644
--- a/lib/igt_aux.h
+++ b/lib/igt_aux.h
@@ -174,6 +174,7 @@ void igt_skip_without_suspend_support(enum
igt_suspend_state state,
enum igt_suspend_test test);
void igt_system_suspend_autoresume(enum igt_suspend_state state,
enum igt_suspend_test test);
+void igt_set_autoresume_delay(int delay_secs);
/* dropping priviledges */
void igt_drop_root(void);
--
2.7.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [RFC i-g-t v2 3/5] igt_aux: Add some list helpers from wayland
Since we're going to be using lists for keeping track of EDIDs we've
allocated on the chamelium, add some generic list helpers from the
wayland project.
Signed-off-by: Lyude
Changes since v1:
- Rename list helpers to be more like those from the Linux kernel
---
lib/igt_aux.c | 27 +++
lib/igt_aux.h | 38 ++
2 files changed, 65 insertions(+)
diff --git a/lib/igt_aux.c b/lib/igt_aux.c
index 67432c6..6e44218 100644
--- a/lib/igt_aux.c
+++ b/lib/igt_aux.c
@@ -1343,3 +1343,30 @@ double igt_stop_siglatency(struct igt_mean *result)
return mean;
}
+
+void igt_list_init(struct igt_list *igt_list)
+{
+ igt_list->prev = igt_list;
+ igt_list->next = igt_list;
+}
+
+void igt_list_add(struct igt_list *igt_list, struct igt_list *elm)
+{
+ elm->prev = igt_list;
+ elm->next = igt_list->next;
+ igt_list->next = elm;
+ elm->next->prev = elm;
+}
+
+void igt_list_del(struct igt_list *elm)
+{
+ elm->prev->next = elm->next;
+ elm->next->prev = elm->prev;
+ elm->next = NULL;
+ elm->prev = NULL;
+}
+
+bool igt_list_empty(const struct igt_list *igt_list)
+{
+ return igt_list->next == igt_list;
+}
diff --git a/lib/igt_aux.h b/lib/igt_aux.h
index 7cee901..c021e3a 100644
--- a/lib/igt_aux.h
+++ b/lib/igt_aux.h
@@ -267,4 +267,42 @@ double igt_stop_siglatency(struct igt_mean *result);
void igt_set_module_param(const char *name, const char *val);
void igt_set_module_param_int(const char *name, int val);
+/*
+ * This list data structure is a verbatim copy from wayland-util.h from the
+ * Wayland project; except that wl_ prefix has been removed.
+ */
+
+struct igt_list {
+ struct igt_list *prev;
+ struct igt_list *next;
+};
+
+void igt_list_init(struct igt_list *list);
+void igt_list_add(struct igt_list *list, struct igt_list *elm);
+void igt_list_del(struct igt_list *elm);
+bool igt_list_empty(const struct igt_list *list);
+
+#ifdef __GNUC__
+#define container_of(ptr, sample, member) \
+ (__typeof__(sample))((char *)(ptr) - \
+((char *)&(sample)->member - (char *)(sample)))
+#else
+#define container_of(ptr, sample, member) \
+ (void *)((char *)(ptr) - \
+((char *)&(sample)->member - (char *)(sample)))
+#endif
+
+#define igt_list_for_each(pos, head, member) \
+ for (pos = 0, pos = container_of((head)->next, pos, member);\
+&pos->member != (head);\
+pos = container_of(pos->member.next, pos, member))
+
+#define igt_list_for_each_safe(pos, tmp, head, member) \
+ for (pos = 0, tmp = 0, \
+pos = container_of((head)->next, pos, member), \
+tmp = container_of((pos)->member.next, tmp, member); \
+&pos->member != (head);\
+pos = tmp, \
+tmp = container_of(pos->member.next, tmp, member))
+
#endif /* IGT_AUX_H */
--
2.7.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [RFC i-g-t v2 1/5] igt_aux: Add igt_skip_without_suspend_support()
Since all of the chamelium calls are blocking, we need to be able to
make suspend/resume tests with it multi-threaded. As such, it's not the
best idea to rely on igt_system_suspend_autoresume() for skipping tests
on systems without suspend/resume support since we could accidentally
leave the thread controlling the chamelium running after the test gets
skipped.
Signed-off-by: Lyude
---
lib/igt_aux.c | 21 +
lib/igt_aux.h | 2 ++
2 files changed, 23 insertions(+)
diff --git a/lib/igt_aux.c b/lib/igt_aux.c
index 421f6d4..9754148 100644
--- a/lib/igt_aux.c
+++ b/lib/igt_aux.c
@@ -743,6 +743,27 @@ static uint32_t get_supported_suspend_states(int power_dir)
}
/**
+ * igt_skip_without_suspend_state:
+ * @state: an #igt_suspend_state to check for
+ *
+ * Check whether or not the system supports the given @state, and skip the
+ * current test if it doesn't. Useful for tests we want to skip before
+ * attempting to call #igt_system_suspend_autoresume.
+ */
+void igt_skip_without_suspend_support(enum igt_suspend_state state,
+ enum igt_suspend_test test)
+{
+ int power_dir;
+
+ igt_require((power_dir = open("/sys/power", O_RDONLY)) >= 0);
+ igt_require(get_supported_suspend_states(power_dir) & (1 << state));
+ igt_require(test == SUSPEND_TEST_NONE ||
+ faccessat(power_dir, "pm_test", R_OK | W_OK, 0) == 0);
+
+ close(power_dir);
+}
+
+/**
* igt_system_suspend_autoresume:
* @state: an #igt_suspend_state, the target suspend state
* @test: an #igt_suspend_test, test point at which to complete the suspend
diff --git a/lib/igt_aux.h b/lib/igt_aux.h
index d30196b..973a9cd 100644
--- a/lib/igt_aux.h
+++ b/lib/igt_aux.h
@@ -170,6 +170,8 @@ enum igt_suspend_test {
SUSPEND_TEST_NUM,
};
+void igt_skip_without_suspend_support(enum igt_suspend_state state,
+ enum igt_suspend_test test);
void igt_system_suspend_autoresume(enum igt_suspend_state state,
enum igt_suspend_test test);
--
2.7.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [RFC i-g-t v2 4/5] igt_kms: Add helpers for watching for sysfs hotplug events
This adds some basic helpers for connecting to udev and watching for
sysfs hotplug events.
Signed-off-by: Lyude
---
lib/igt_kms.c | 109 ++
lib/igt_kms.h | 6
2 files changed, 115 insertions(+)
diff --git a/lib/igt_kms.c b/lib/igt_kms.c
index 989704e..433a721 100644
--- a/lib/igt_kms.c
+++ b/lib/igt_kms.c
@@ -38,6 +38,10 @@
#elif HAVE_SYS_KD_H
#include
#endif
+#ifdef HAVE_UDEV
+#include
+#include
+#endif
#include
#include
@@ -2760,6 +2764,111 @@ void igt_reset_connectors(void)
"detect");
}
+#ifdef HAVE_UDEV
+static struct udev_monitor *hotplug_mon;
+
+/**
+ * igt_watch_hotplug:
+ *
+ * Begin monitoring udev for hotplug events.
+ */
+void igt_watch_hotplug(void)
+{
+ struct udev *udev;
+ int ret, flags, fd;
+
+ if (hotplug_mon)
+ igt_cleanup_hotplug();
+
+ udev = udev_new();
+ igt_assert(udev != NULL);
+
+ hotplug_mon = udev_monitor_new_from_netlink(udev, "udev");
+ igt_assert(hotplug_mon != NULL);
+
+ ret = udev_monitor_filter_add_match_subsystem_devtype(hotplug_mon,
+ "drm",
+ "drm_minor");
+ igt_assert_eq(ret, 0);
+ ret = udev_monitor_filter_update(hotplug_mon);
+ igt_assert_eq(ret, 0);
+ ret = udev_monitor_enable_receiving(hotplug_mon);
+ igt_assert_eq(ret, 0);
+
+ /* Set the fd for udev as non blocking */
+ fd = udev_monitor_get_fd(hotplug_mon);
+ flags = fcntl(fd, F_GETFL, 0);
+ igt_assert(flags);
+
+ flags |= O_NONBLOCK;
+ igt_assert_neq(fcntl(fd, F_SETFL, flags), -1);
+}
+
+/**
+ * igt_hotplug_detected:
+ * @timeout_secs: How long to wait for a hotplug event to occur.
+ *
+ * Assert that a hotplug event was received since we last checked the monitor.
+ *
+ * Returns: true if a sysfs hotplug event was received, false if we timed out
+ */
+bool igt_hotplug_detected(int timeout_secs)
+{
+ struct udev_device *dev;
+ const char *hotplug_val;
+ struct pollfd fd = {
+ .fd = udev_monitor_get_fd(hotplug_mon),
+ .events = POLLIN
+ };
+ bool hotplug_received = false;
+
+ /* Go through all of the events pending on the udev monitor. Once we
+* receive a hotplug, we continue going through the rest of the events
+* so that redundant hotplug events don't change the results of future
+* checks
+*/
+ while (!hotplug_received && poll(&fd, 1, timeout_secs * 1000)) {
+ dev = udev_monitor_receive_device(hotplug_mon);
+
+ hotplug_val = udev_device_get_property_value(dev, "HOTPLUG");
+ if (hotplug_val && atoi(hotplug_val) == 1)
+ hotplug_received = true;
+
+ udev_device_unref(dev);
+ }
+
+ return hotplug_received;
+}
+
+/**
+ * igt_flush_hotplugs:
+ * @mon: A udev monitor created by #igt_watch_hotplug
+ *
+ * Get rid of any pending hotplug events waiting on the udev monitor
+ */
+void igt_flush_hotplugs(void)
+{
+ struct udev_device *dev;
+
+ while ((dev = udev_monitor_receive_device(hotplug_mon)))
+ udev_device_unref(dev);
+}
+
+/**
+ * igt_cleanup_hotplug:
+ *
+ * Cleanup the resources allocated by #igt_watch_hotplug
+ */
+void igt_cleanup_hotplug(void)
+{
+ struct udev *udev = udev_monitor_get_udev(hotplug_mon);
+
+ udev_monitor_unref(hotplug_mon);
+ hotplug_mon = NULL;
+ udev_unref(udev);
+}
+#endif
+
/**
* kmstest_get_vbl_flag:
* @pipe_id: Pipe to convert to flag representation.
diff --git a/lib/igt_kms.h b/lib/igt_kms.h
index 6422adc..95395cd 100644
--- a/lib/igt_kms.h
+++ b/lib/igt_kms.h
@@ -479,5 +479,11 @@ uint32_t kmstest_get_vbl_flag(uint32_t pipe_id);
const unsigned char* igt_kms_get_base_edid(void);
const unsigned char* igt_kms_get_alt_edid(void);
+#ifdef HAVE_UDEV
+void igt_watch_hotplug(void);
+bool igt_hotplug_detected(int timeout_secs);
+void igt_flush_hotplugs(void);
+void igt_cleanup_hotplug(void);
+#endif
#endif /* __IGT_KMS_H__ */
--
2.7.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [RFC i-g-t v2 5/5] Add support for hotplug testing with the Chamelium
For the purpose of testing things such as hotplugging and bad monitors,
the ChromeOS team ended up designing a neat little device known as the
Chamelium. More information on this can be found here:
https://www.chromium.org/chromium-os/testing/chamelium
This adds support for a couple of things to intel-gpu-tools:
- igt library functions for connecting to udev and monitoring it for
hotplug events, loosely based off of the unfinished hotplugging
implementation in testdisplay
- Library functions for controlling the chamelium in tests using
xmlrpc. A couple of RPC calls were ommitted here, mainly because they
didn't seem very useful for our needs or because they're just plain
broken
- A set of basic tests using the chamelium.
Because there's no sure fire way to figure out the mappings between
chamelium connectors and the DRM connectors on the machine, we rely on
the user specifying these mappings manually in the Chamelium
configuration file.
Running these tests requires (of course) a working Chamelium, along with
the RPC URL for the chamelium being specified in the environment
variable CHAMELIUM_HOST. If no URL is specified, the tests will just
skip on their own. As well, tests for connectors which are not actually
present on the system or the chamelium will skip on their own as well.
Signed-off-by: Lyude
Changes since v1:
- Don't try to guess connector mappings, have the user specify them
manually using a configuration file
- Open DRM fd using DRIVER_ANY, not DRIVER_INTEL
- Lower the hotplug timeout a little bit, since 30 seconds was leftover
from debugging these tests anyway
- Don't try to keep track of the original state of the chamelium ports,
and just leave them plugged in after each run. This makes more sense
to me, since I'd imagine in automated testing setups using chameliums
that all of the extra monitors will probably be provided by the
Chamelium to begin with, so keeping them plugged in would make sure
tests running afterwards that require >1 monitor don't get skipped.
- Add wait_for_connector() to the chamelium tests. After some more
testing, I found that depending on the system some tests would throw
false negatives due to us not waiting long enough for the system to
detect that we connected something to it. This mainly happened with
VGA connectors, since their lack of HPD makes them take significantly
longer for the hardware to notice. wait_for_connector() fixes this by
continually reprobing the status of the desired connector (without
relying on a hpd event happening, since that might never come) until
we get what we want, or we time out and fail.
- Use kmstest_get_property() for retrieving EDIDs instead of doing it by
hand
- Don't hardcode PIPE_A for bringing up the display, use kmstest to find
an appropriate CRTC to use.
---
configure.ac | 13 +
lib/Makefile.am| 10 +-
lib/igt.h | 3 +
lib/igt_chamelium.c| 689 +
lib/igt_chamelium.h| 69 +
scripts/run-tests.sh | 4 +-
tests/Makefile.am | 5 +-
tests/Makefile.sources | 1 +
tests/chamelium.c | 407 +
9 files changed, 1197 insertions(+), 4 deletions(-)
create mode 100644 lib/igt_chamelium.c
create mode 100644 lib/igt_chamelium.h
create mode 100644 tests/chamelium.c
diff --git a/configure.ac b/configure.ac
index e181c83..53d7074 100644
--- a/configure.ac
+++ b/configure.ac
@@ -262,6 +262,18 @@ if test "x$with_libunwind" = xyes; then
AC_MSG_ERROR([libunwind not found. Use
--without-libunwind to disable libunwind support.]))
fi
+# enable support for using the chamelium
+AC_ARG_ENABLE(chamelium,
+ AS_HELP_STRING([--without-chamelium],
+[Build tests without chamelium support]),
+ [], [with_chamelium=yes])
+
+AM_CONDITIONAL(HAVE_CHAMELIUM, [test "x$with_chamelium" = xyes])
+if test "x$with_chamelium" = xyes; then
+ AC_DEFINE(HAVE_CHAMELIUM, 1, [chamelium suport])
+ PKG_CHECK_MODULES(XMLRPC, xmlrpc_client)
+fi
+
# enable debug symbols
AC_ARG_ENABLE(debug,
AS_HELP_STRING([--disable-debug],
@@ -359,6 +371,7 @@ echo " Assembler : ${enable_assembler}"
echo " Debugger : ${enable_debugger}"
echo " Overlay: X: ${enable_overlay_xlib}, Xv:
${enable_overlay_xvlib}"
echo " x86-specific tools : ${build_x86}"
+echo " Chamelium support : ${with_chamelium}"
echo ""
echo " • API-Documentation : ${enable_gtk_doc}"
echo " • Fail on warnings : ${enable_werror}"
diff --git a/lib/Makefile.am b/lib/Makefile.am
index 4c0893d..aeac43a 100644
--- a/lib/Makefile.am
+++ b/lib/Makefile.am
@@ -22,8 +22,14 @@ if !HAVE_LIBDRM_INTEL
stubs/drm/intel_bufmgr.h
endif
+if HAVE_CHAMELIUM
+libintel_tools_la_SOURCES += \
+ igt_chamelium.c \
+ igt_
Re: [Intel-gfx] [PATCH v5 4/8] drm/i915/bxt: Enable IPC support
Em Sex, 2016-11-18 às 20:39 +0530, Mahesh Kumar escreveu:
> This patch adds IPC support for platforms. This patch enables IPC
> only for BXT/KBL platform as for SKL recommendation is to keep is
> disabled.
> IPC (Isochronous Priority Control) is the hardware feature, which
> dynamically controles the memory read priority of Display.
>
> When IPC is enabled, plane read requests are sent at high priority
> until
> filling above the transition watermark, then the requests are sent at
> lower priority until dropping below the level 0 watermark.
> The lower priority requests allow other memory clients to have better
> memory access. When IPC is disabled, all plane read requests are sent
> at
> high priority.
>
> Changes since V1:
> - Remove commandline parameter to disable ipc
> - Address Paulo's comments
> Changes since V2:
> - Address review comments
> - Set ipc_enabled flag
>
> Signed-off-by: Mahesh Kumar
> ---
> drivers/gpu/drm/i915/i915_drv.c | 1 +
> drivers/gpu/drm/i915/i915_reg.h | 1 +
> drivers/gpu/drm/i915/intel_drv.h | 1 +
> drivers/gpu/drm/i915/intel_pm.c | 15 +++
> 4 files changed, 18 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.c
> b/drivers/gpu/drm/i915/i915_drv.c
> index 1b0a589..4074601 100644
> --- a/drivers/gpu/drm/i915/i915_drv.c
> +++ b/drivers/gpu/drm/i915/i915_drv.c
> @@ -1244,6 +1244,7 @@ int i915_driver_load(struct pci_dev *pdev,
> const struct pci_device_id *ent)
> intel_runtime_pm_enable(dev_priv);
>
> dev_priv->ipc_enabled = false;
> + intel_enable_ipc(dev_priv);
So now we have to places that touch dev_priv->ipc_enabled. This one and
intel_enable_ipc(). Please move that "dev_priv->ipc_enabled = false"
line to inside intel_enable_ipc(). It's much easier to read the code
when there's a single function responsible for setting the appropriate
value to a variable.
Besides, my understanding of your discussion with Maarten in the last
revision of this patch was that we needed to change where
intel_enable_ipc() is called in order to make sure the bit stays
enabled after suspend/resume. If that's not needed, why is it not
needed?
>
> /* Everything is in place, we can now relax! */
> DRM_INFO("Initialized %s %d.%d.%d %s for %s on minor %d\n",
> diff --git a/drivers/gpu/drm/i915/i915_reg.h
> b/drivers/gpu/drm/i915/i915_reg.h
> index c70c07a..300418a 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -6076,6 +6076,7 @@ enum {
> #define DISP_FBC_WM_DIS (1<<15)
> #define DISP_ARB_CTL2_MMIO(0x45004)
> #define DISP_DATA_PARTITION_5_6 (1<<6)
> +#define DISP_IPC_ENABLE (1<<3)
> #define DBUF_CTL _MMIO(0x45008)
> #define DBUF_POWER_REQUEST (1<<31)
> #define DBUF_POWER_STATE(1<<30)
> diff --git a/drivers/gpu/drm/i915/intel_drv.h
> b/drivers/gpu/drm/i915/intel_drv.h
> index cd132c2..ad542a2 100644
> --- a/drivers/gpu/drm/i915/intel_drv.h
> +++ b/drivers/gpu/drm/i915/intel_drv.h
> @@ -1745,6 +1745,7 @@ bool skl_ddb_allocation_overlaps(const struct
> skl_ddb_entry **entries,
> uint32_t ilk_pipe_pixel_rate(const struct intel_crtc_state
> *pipe_config);
> bool ilk_disable_lp_wm(struct drm_device *dev);
> int sanitize_rc6_option(struct drm_i915_private *dev_priv, int
> enable_rc6);
> +void intel_enable_ipc(struct drm_i915_private *dev_priv);
> static inline int intel_enable_rc6(void)
> {
> return i915.enable_rc6;
> diff --git a/drivers/gpu/drm/i915/intel_pm.c
> b/drivers/gpu/drm/i915/intel_pm.c
> index df39b50..d8090aa 100644
> --- a/drivers/gpu/drm/i915/intel_pm.c
> +++ b/drivers/gpu/drm/i915/intel_pm.c
> @@ -4682,6 +4682,21 @@ void intel_update_watermarks(struct intel_crtc
> *crtc)
> dev_priv->display.update_wm(crtc);
> }
>
> +void intel_enable_ipc(struct drm_i915_private *dev_priv)
> +{
> + u32 val;
> +
> + if (!(IS_BROXTON(dev_priv) || IS_KABYLAKE(dev_priv)))
> + return;
> +
> + val = I915_READ(DISP_ARB_CTL2);
> +
> + val |= DISP_IPC_ENABLE;
> +
> + I915_WRITE(DISP_ARB_CTL2, val);
> + dev_priv->ipc_enabled = true;
> +}
> +
> /*
> * Lock protecting IPS related data structures
> */
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 3/5] drm/i915: Update CRTC state if connector link status property changed
On Mon, Nov 21, 2016 at 04:48:07PM +0100, Daniel Vetter wrote:
> On Mon, Nov 21, 2016 at 11:10:45AM +0100, Daniel Vetter wrote:
> > On Mon, Nov 21, 2016 at 09:42:57AM +, Chris Wilson wrote:
> > > On Mon, Nov 21, 2016 at 10:38:20AM +0100, Daniel Vetter wrote:
> > > > On Fri, Nov 18, 2016 at 09:44:49AM -0800, Manasi Navare wrote:
> > > > > On Fri, Nov 18, 2016 at 06:21:21PM +0200, Ville Syrjälä wrote:
> > > > > > On Fri, Nov 18, 2016 at 04:35:25PM +0100, Daniel Vetter wrote:
> > > > > > > On Fri, Nov 18, 2016 at 05:28:54PM +0200, Ville Syrjälä wrote:
> > > > > > > > On Fri, Nov 18, 2016 at 03:18:06PM +0100, Maarten Lankhorst
> > > > > > > > wrote:
> > > > > > > > > Op 18-11-16 om 15:11 schreef Ville Syrjälä:
> > > > > > > > > > On Fri, Nov 18, 2016 at 02:50:52PM +0100, Maarten Lankhorst
> > > > > > > > > > wrote:
> > > > > > > > > >> Op 18-11-16 om 08:13 schreef Manasi Navare:
> > > > > > > > > >>> CRTC state connector_changed needs to be set to true
> > > > > > > > > >>> if connector link status property has changed. This will
> > > > > > > > > >>> tell the
> > > > > > > > > >>> driver to do a complete modeset due to change in
> > > > > > > > > >>> connector property.
> > > > > > > > > >>>
> > > > > > > > > >>> Acked-by: Harry Wentland
> > > > > > > > > >>> Acked-by: Tony Cheng
> > > > > > > > > >>> Cc: dri-de...@lists.freedesktop.org
> > > > > > > > > >>> Cc: Jani Nikula
> > > > > > > > > >>> Cc: Daniel Vetter
> > > > > > > > > >>> Cc: Ville Syrjala
> > > > > > > > > >>> Signed-off-by: Manasi Navare
> > > > > > > > > >>> ---
> > > > > > > > > >>> drivers/gpu/drm/drm_atomic_helper.c | 7 +++
> > > > > > > > > >>> 1 file changed, 7 insertions(+)
> > > > > > > > > >>>
> > > > > > > > > >>> diff --git a/drivers/gpu/drm/drm_atomic_helper.c
> > > > > > > > > >>> b/drivers/gpu/drm/drm_atomic_helper.c
> > > > > > > > > >>> index 0b16587..2125fd1 100644
> > > > > > > > > >>> --- a/drivers/gpu/drm/drm_atomic_helper.c
> > > > > > > > > >>> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> > > > > > > > > >>> @@ -519,6 +519,13 @@ static int
> > > > > > > > > >>> handle_conflicting_encoders(struct drm_atomic_state
> > > > > > > > > >>> *state,
> > > > > > > > > >>> connector_state);
> > > > > > > > > >>> if (ret)
> > > > > > > > > >>> return ret;
> > > > > > > > > >>> +
> > > > > > > > > >>> + if (connector->state->crtc) {
> > > > > > > > > >>> + crtc_state =
> > > > > > > > > >>> drm_atomic_get_existing_crtc_state(state,
> > > > > > > > > >>> +
> > > > > > > > > >>> connector->state->crtc);
> > > > > > > > > >>> + if (connector->link_status ==
> > > > > > > > > >>> DRM_MODE_LINK_STATUS_BAD)
> > > > > > > > > >>> + crtc_state->connectors_changed
> > > > > > > > > >>> = true;
> > > > > > > > > >>> + }
> > > > > > > > > >>> }
> > > > > > > > > >>>
> > > > > > > > > >>> /*
> > > > > > > > > >> This will cause ordinary atomic commits that happen to
> > > > > > > > > >> change connector flags to potentially fail with -EINVAL if
> > > > > > > > > >> ALLOW_MODESET is not set.
> > > > > > > > > >> For this reason I'm not sure this flag should be set
> > > > > > > > > >> automatically by the kernel. Could we add add a retrain
> > > > > > > > > >> link property instead, that
> > > > > > > > > >> always return 0 when queried, but writing a 1 causing
> > > > > > > > > >> connectors_changed to be set on bad link status?
> > > > > > > > > > Or just check for allow_modeset before setting
> > > > > > > > > > connectors_changed=true here?
> > > > > > > > >
> > > > > > > > > I don't think modesets should be done automatically like
> > > > > > > > > that, even if ALLOW_MODESET is set a modeset may not be
> > > > > > > > > expected by userspace.
> > > > > > > >
> > > > > > > > Presumably userspace would want a picture on the screen using
> > > > > > > > any means
> > > > > > > > if it said ALLOW_MODESET. So if it can't tolerate the modeset
> > > > > > > > it should
> > > > > > > > probably say as much?
> > > > > > >
> > > > > > > Yeah, agreed. Also, if the link is bad then we pretty much have
> > > > > > > to do a
> > > > > > > modeset to recover it, otherwise you'll be forever stuck with a
> > > > > > > bad
> > > > > > > screen.
> > > > > > >
> > > > > > > What we could try is to gate this of whether userspace touches
> > > > > > > the mode
> > > > > > > property on the corresponding CRTC. I.e. if that's touched (even
> > > > > > > if it's
> > > > > > > the same mode), and a link is bad in one of the connectors in the
> > > > > > > state
> > > > > > > then we do a full modeset to recover.
> > > > > > >
> > > > > > > Another option would be to make the link status writeable. Trying
> > > > > > > to
> > > > > > > change it from bad->good would force the modeset. That would be
> > > > > > > 1
