[Intel-gfx] [PATCH] drm/i915/skl: Disable underrun reporting on MST unplug

[Lyude]

Unplugging MST displays usually causes underruns, so turn off underrun
reporting so people don't report false positives.

Signed-off-by: Lyude 
---
 drivers/gpu/drm/i915/intel_display.c | 9 -
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 6e0d828..fa8a72b 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -5146,6 +5146,10 @@ static void haswell_crtc_disable(struct drm_crtc *crtc)
if (intel_crtc->config->has_pch_encoder)
intel_set_pch_fifo_underrun_reporting(dev_priv, TRANSCODER_A,
  false);
+   else if (intel_crtc->config->dp_encoder_is_mst)
+   intel_set_cpu_fifo_underrun_reporting(dev_priv,
+ intel_crtc->pipe, false);
+
 
for_each_encoder_on_crtc(dev, crtc, encoder) {
intel_opregion_notify_encoder(encoder, false);
@@ -5182,7 +5186,10 @@ static void haswell_crtc_disable(struct drm_crtc *crtc)
 
intel_set_pch_fifo_underrun_reporting(dev_priv, TRANSCODER_A,
  true);
-   }
+   } else if (intel_crtc->config->dp_encoder_is_mst)
+   intel_set_cpu_fifo_underrun_reporting(dev_priv,
+ intel_crtc->pipe, true);
+
 }
 
 static void i9xx_pfit_enable(struct intel_crtc *crtc)
-- 
2.5.5

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 2/4] drm/i915/fbc: sanitize i915.enable_fbc during FBC init

[Paulo Zanoni]

The DDX driver changes its behavior depending on the value it reads
from i915.enable_fbc, so sanitize the value in order to allow it to
know what's going on. It uses this in order to choose the defaults for
the TearFree option. Before this patch, it will read -1 and always
assume that FBC is disabled, so it won't force TearFree.

Signed-off-by: Paulo Zanoni 
---
 drivers/gpu/drm/i915/intel_fbc.c | 19 +++
 1 file changed, 11 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_fbc.c b/drivers/gpu/drm/i915/intel_fbc.c
index fc3c094..3d84ce3 100644
--- a/drivers/gpu/drm/i915/intel_fbc.c
+++ b/drivers/gpu/drm/i915/intel_fbc.c
@@ -824,21 +824,14 @@ static bool intel_fbc_can_choose(struct intel_crtc *crtc)
 {
struct drm_i915_private *dev_priv = crtc->base.dev->dev_private;
struct intel_fbc *fbc = _priv->fbc;
-   bool enable_by_default = IS_HASWELL(dev_priv) ||
-IS_BROADWELL(dev_priv);
 
if (intel_vgpu_active(dev_priv->dev)) {
fbc->no_fbc_reason = "VGPU is active";
return false;
}
 
-   if (i915.enable_fbc < 0 && !enable_by_default) {
-   fbc->no_fbc_reason = "disabled per chip default";
-   return false;
-   }
-
if (!i915.enable_fbc) {
-   fbc->no_fbc_reason = "disabled per module param";
+   fbc->no_fbc_reason = "disabled per module param or by default";
return false;
}
 
@@ -1240,6 +1233,16 @@ void intel_fbc_init(struct drm_i915_private *dev_priv)
fbc->active = false;
fbc->work.scheduled = false;
 
+   /* The DDX driver changes its behavior depending on the value it reads
+* from i915.enable_fbc, so sanitize the value in order to allow it to
+* know what's going on. */
+   if (i915.enable_fbc < 0) {
+   i915.enable_fbc = IS_HASWELL(dev_priv) ||
+ IS_BROADWELL(dev_priv);
+   DRM_DEBUG_KMS("Sanitized enable_fbc value: %d\n",
+ i915.enable_fbc);
+   }
+
if (!HAS_FBC(dev_priv)) {
fbc->no_fbc_reason = "unsupported by this chipset";
return;
-- 
2.8.0.rc3

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH igt 1/3] kms_frontbuffer_tracking: prefer the BLT drawing method

[Paulo Zanoni]

A recent Kernel fix changed the way GTT and WC mmaps behave during
frontbuffer drawing. This, added with the fact that GTT mmaps are
special cases for PSR, suggests that maybe we should move to BLT
drawing in places where we can, in order to simplify things a little
bit.

v2: New commit message.

Signed-off-by: Paulo Zanoni 
---
 tests/kms_frontbuffer_tracking.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/tests/kms_frontbuffer_tracking.c b/tests/kms_frontbuffer_tracking.c
index b4fbbc5..c6d6bc0 100644
--- a/tests/kms_frontbuffer_tracking.c
+++ b/tests/kms_frontbuffer_tracking.c
@@ -1130,7 +1130,7 @@ static void fill_fb_region(struct fb_region *region, enum 
color ecolor)
 {
uint32_t color = pick_color(region->fb, ecolor);
 
-   igt_draw_rect_fb(drm.fd, NULL, NULL, region->fb, IGT_DRAW_MMAP_CPU,
+   igt_draw_rect_fb(drm.fd, drm.bufmgr, NULL, region->fb, IGT_DRAW_BLT,
 region->x, region->y, region->w, region->h,
 color);
 }
@@ -3565,7 +3565,7 @@ int main(int argc, char *argv[])
if (t.pipes != PIPE_SINGLE ||
t.screen != SCREEN_PRIM ||
t.plane != PLANE_PRI ||
-   t.method != IGT_DRAW_MMAP_CPU)
+   t.method != IGT_DRAW_BLT)
continue;
igt_subtest_f("%s-%s-scaledprimary",
  feature_str(t.feature),
@@ -3578,7 +3578,7 @@ int main(int argc, char *argv[])
t.screen != SCREEN_PRIM ||
t.plane != PLANE_PRI ||
t.fbs != FBS_INDIVIDUAL ||
-   t.method != IGT_DRAW_MMAP_CPU)
+   t.method != IGT_DRAW_BLT)
continue;
 
igt_subtest_f("%s-modesetfrombusy", feature_str(t.feature))
-- 
2.8.0.rc3

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH igt 2/3] kms_frontbuffer_tracking: recreate the FBs at every subtest

[Paulo Zanoni]

This patch was originally written because of a workaround we were
planning to merge. Later we improved the workaround so it wouldn't
need this patch anymore. Then later we gave up on the workaround, but
decided to go with a plan that would cause GTT mmap writes to
invalidate FBC in case the frontbuffer ever had a WC mmap. So now we
need the patch again because we don't want a subtest that involves an
WC mmap to change the behavior of other unrelated subtests that use
GTT mmaps.

Even if we don't go with the current planned Kernel patch, merging
this should be worth in order to avoid future related problems.

v2: New commit message.

Signed-off-by: Paulo Zanoni 
---
 tests/kms_frontbuffer_tracking.c | 40 
 1 file changed, 20 insertions(+), 20 deletions(-)

diff --git a/tests/kms_frontbuffer_tracking.c b/tests/kms_frontbuffer_tracking.c
index c6d6bc0..f37de6d 100644
--- a/tests/kms_frontbuffer_tracking.c
+++ b/tests/kms_frontbuffer_tracking.c
@@ -711,12 +711,31 @@ static void create_shared_fb(enum pixel_format format)
  PLANE_PRI, >big);
 }
 
+static void destroy_fbs(enum pixel_format format)
+{
+   struct screen_fbs *s = [format];
+
+   if (!s->initialized)
+   return;
+
+   if (scnd_mode_params.connector_id) {
+   igt_remove_fb(drm.fd, >scnd_pri);
+   igt_remove_fb(drm.fd, >scnd_cur);
+   igt_remove_fb(drm.fd, >scnd_spr);
+   }
+   igt_remove_fb(drm.fd, >prim_pri);
+   igt_remove_fb(drm.fd, >prim_cur);
+   igt_remove_fb(drm.fd, >prim_spr);
+   igt_remove_fb(drm.fd, >offscreen);
+   igt_remove_fb(drm.fd, >big);
+}
+
 static void create_fbs(enum pixel_format format)
 {
struct screen_fbs *s = [format];
 
if (s->initialized)
-   return;
+   destroy_fbs(format);
 
s->initialized = true;
 
@@ -747,25 +766,6 @@ static void create_fbs(enum pixel_format format)
  LOCAL_I915_FORMAT_MOD_X_TILED, PLANE_SPR, >scnd_spr);
 }
 
-static void destroy_fbs(enum pixel_format format)
-{
-   struct screen_fbs *s = [format];
-
-   if (!s->initialized)
-   return;
-
-   if (scnd_mode_params.connector_id) {
-   igt_remove_fb(drm.fd, >scnd_pri);
-   igt_remove_fb(drm.fd, >scnd_cur);
-   igt_remove_fb(drm.fd, >scnd_spr);
-   }
-   igt_remove_fb(drm.fd, >prim_pri);
-   igt_remove_fb(drm.fd, >prim_cur);
-   igt_remove_fb(drm.fd, >prim_spr);
-   igt_remove_fb(drm.fd, >offscreen);
-   igt_remove_fb(drm.fd, >big);
-}
-
 static bool set_mode_for_params(struct modeset_params *params)
 {
int rc;
-- 
2.8.0.rc3

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH igt 3/3] kms_frontbuffer_tracking: properly handle mixing GTT and WC mmaps

[Paulo Zanoni]

The new Kernel behavior is that whenever a buffer has ever been WC
mmapped, the GTT mmaps will be treated as CPU operations. Because of
this, if we don't issue the dirty_fb IOCTL after doing frontbuffer
rendering with the GTT mmaps, FBC will remain disabled. Luckily, the
only subtest that does this sort of mix is the multidraw subtest.

Signed-off-by: Paulo Zanoni 
---
 tests/kms_frontbuffer_tracking.c | 12 
 1 file changed, 12 insertions(+)

diff --git a/tests/kms_frontbuffer_tracking.c b/tests/kms_frontbuffer_tracking.c
index f37de6d..89e6ea8 100644
--- a/tests/kms_frontbuffer_tracking.c
+++ b/tests/kms_frontbuffer_tracking.c
@@ -2079,6 +2079,7 @@ static void multidraw_subtest(const struct test_mode *t)
struct modeset_params *params = pick_params(t);
struct fb_region *target;
enum igt_draw_method m1, m2, used_method;
+   bool wc_used = false;
 
switch (t->plane) {
case PLANE_PRI:
@@ -2108,6 +2109,17 @@ static void multidraw_subtest(const struct test_mode *t)
igt_draw_get_method_name(used_method));
 
draw_rect(pattern, target, used_method, r);
+
+   if (used_method == IGT_DRAW_MMAP_WC)
+   wc_used = true;
+
+   if (used_method == IGT_DRAW_MMAP_GTT &&
+   wc_used) {
+   struct rect rect =
+   pattern->get_rect(target, r);
+   fb_dirty_ioctl(target, );
+   }
+
update_wanted_crc(t,
  >crcs[t->format][r]);
 
-- 
2.8.0.rc3

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 1/4] drm/i915/fbc: update busy_bits even for GTT and flip flushes

[Paulo Zanoni]

We ignore ORIGIN_GTT because the hardware tracking can recognize GTT
writes and take care of them. We also ignore ORIGIN_FLIP because we
deal with flips without relying on the frontbuffer tracking
infrastructure. On the other hand, a flush is a flush and means we're
good to go, so we need to update busy_bits in order to reflect that,
even if we're not going to do anything else about it.

How to reproduce the bug fixed by this patch:
 - boot SKL up to the desktop environment
 - stop the display manager
 - run any of the igt/kms_frontbuffer_tracking/*fbc*onoff* subtests
 - the tests will fail

The steps above will create the right conditions for us to lose track
of busy_bits. If you, for example, run the full set of FBC tests, the
onoff subtests will succeed.

Also notice that the "bug" is that we'll just keep FBC disabled on
cases where it could be enabled, so it's not something the users can
perceive, it just affects power consumption numbers on properly
configured machines.

Testcase: igt/kms_frontbuffer_tracking/*fbc*onoff* (see above)
Reviewed-by: Daniel Vetter 
Signed-off-by: Paulo Zanoni 
---
 drivers/gpu/drm/i915/intel_fbc.c | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_fbc.c b/drivers/gpu/drm/i915/intel_fbc.c
index d5a7cfe..fc3c094 100644
--- a/drivers/gpu/drm/i915/intel_fbc.c
+++ b/drivers/gpu/drm/i915/intel_fbc.c
@@ -997,13 +997,13 @@ void intel_fbc_flush(struct drm_i915_private *dev_priv,
if (!fbc_supported(dev_priv))
return;
 
-   if (origin == ORIGIN_GTT || origin == ORIGIN_FLIP)
-   return;
-
mutex_lock(>lock);
 
fbc->busy_bits &= ~frontbuffer_bits;
 
+   if (origin == ORIGIN_GTT || origin == ORIGIN_FLIP)
+   goto out;
+
if (!fbc->busy_bits && fbc->enabled &&
(frontbuffer_bits & intel_fbc_get_frontbuffer_bit(fbc))) {
if (fbc->active)
@@ -1012,6 +1012,7 @@ void intel_fbc_flush(struct drm_i915_private *dev_priv,
__intel_fbc_post_update(fbc->crtc);
}
 
+out:
mutex_unlock(>lock);
 }
 
-- 
2.8.0.rc3

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 4/4] drm/i915/fbc: enable FBC on gen 9+ too

[Paulo Zanoni]

Now that we're more protected against user space doing frontbuffer
mmap rendering, the last - how many times did I say this before? -
SKL problem seems to be solved. So let's give it a try.

And since the other newer platforms are still under preliminary
support, let's enable FBC on them too to make sure we fix FBC on them.
Also, it seems KBL is passing the tests.

If you reached this commit through git bisect or if you just want more
information about FBC, please see:
commit a98ee79317b4091cafb502b4ffdbbbe1335e298c
Author: Paulo Zanoni 
Date:   Tue Feb 16 18:47:21 2016 -0200
drm/i915/fbc: enable FBC by default on HSW and BDW

v2: Enable not only on SKL, but for everything new (Daniel).

Signed-off-by: Paulo Zanoni 
---
 drivers/gpu/drm/i915/intel_fbc.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_fbc.c b/drivers/gpu/drm/i915/intel_fbc.c
index 3d84ce3..548d00c 100644
--- a/drivers/gpu/drm/i915/intel_fbc.c
+++ b/drivers/gpu/drm/i915/intel_fbc.c
@@ -1238,7 +1238,8 @@ void intel_fbc_init(struct drm_i915_private *dev_priv)
 * know what's going on. */
if (i915.enable_fbc < 0) {
i915.enable_fbc = IS_HASWELL(dev_priv) ||
- IS_BROADWELL(dev_priv);
+ IS_BROADWELL(dev_priv) ||
+ INTEL_INFO(dev_priv)->gen >= 9;
DRM_DEBUG_KMS("Sanitized enable_fbc value: %d\n",
  i915.enable_fbc);
}
-- 
2.8.0.rc3

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 0/4] Enable FBC on SKL, v3

[Paulo Zanoni]

Now with the suggestion from Chris instead of the old workaround. We don't need
new DDX patches anymore, but now we need new IGT patches.

Chris Wilson (1):
  drm/i915: use ORIGIN_CPU for frontbuffer invalidation on WC mmaps

Paulo Zanoni (3):
  drm/i915/fbc: update busy_bits even for GTT and flip flushes
  drm/i915/fbc: sanitize i915.enable_fbc during FBC init
  drm/i915/fbc: enable FBC on gen 9+ too

 drivers/gpu/drm/i915/i915_drv.h  |  1 +
 drivers/gpu/drm/i915/i915_gem.c  | 14 +++---
 drivers/gpu/drm/i915/intel_fbc.c | 27 ---
 3 files changed, 28 insertions(+), 14 deletions(-)

-- 
2.8.0.rc3

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 3/4] drm/i915: use ORIGIN_CPU for frontbuffer invalidation on WC mmaps

[Paulo Zanoni]

From: Chris Wilson 

... instead of the previous ORIGIN_GTT. This should actually
invalidate FBC once something is written on the frontbuffer using WC
mmaps. The problem with ORIGIN_GTT is that the automatic hardware
tracking is not able to detect the WC writes as it can detect the GTT
writes.

This should help fix the SKL bug where nothing happens when you type
your username/password on lightdm.

This patch was originally pasted on an email by Chris and converted to
an actual git patch by Paulo.

Cc:  # 4.6
Cc: Chris Wilson 
Signed-off-by: Paulo Zanoni 
---
 drivers/gpu/drm/i915/i915_drv.h |  1 +
 drivers/gpu/drm/i915/i915_gem.c | 14 +++---
 2 files changed, 12 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index dd18772..17b42a8 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2157,6 +2157,7 @@ struct drm_i915_gem_object {
unsigned int cache_dirty:1;
 
unsigned int frontbuffer_bits:INTEL_FRONTBUFFER_BITS;
+   unsigned int has_wc_mmap:1;
 
unsigned int pin_display;
 
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 40f90c7..bfafa07 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -1608,6 +1608,13 @@ static struct intel_rps_client *to_rps_client(struct 
drm_file *file)
return >rps;
 }
 
+static enum fb_op_origin
+write_origin(struct drm_i915_gem_object *obj, unsigned domain)
+{
+   return domain == I915_GEM_DOMAIN_GTT && !obj->has_wc_mmap ?
+  ORIGIN_GTT : ORIGIN_CPU;
+}
+
 /**
  * Called when user space prepares to use an object with the CPU, either
  * through the mmap ioctl's mapping or a GTT mapping.
@@ -1661,9 +1668,7 @@ i915_gem_set_domain_ioctl(struct drm_device *dev, void 
*data,
ret = i915_gem_object_set_to_cpu_domain(obj, write_domain != 0);
 
if (write_domain != 0)
-   intel_fb_obj_invalidate(obj,
-   write_domain == I915_GEM_DOMAIN_GTT ?
-   ORIGIN_GTT : ORIGIN_CPU);
+   intel_fb_obj_invalidate(obj, write_origin(obj, write_domain));
 
 unref:
drm_gem_object_unreference(>base);
@@ -1761,6 +1766,9 @@ i915_gem_mmap_ioctl(struct drm_device *dev, void *data,
else
addr = -ENOMEM;
up_write(>mmap_sem);
+
+   /* This may race, but that's ok, it only gets set */
+   to_intel_bo(obj)->has_wc_mmap = true;
}
drm_gem_object_unreference_unlocked(obj);
if (IS_ERR((void *)addr))
-- 
2.8.0.rc3

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH i-g-t] kms_atomic: Skip rather than fail on non-atomic drivers

[Matt Roper]

i915 does not yet support the atomic modesetting interface by default;
at the moment it must be turned on explicitly via an
'i915.nuclear_pageflip' kernel command line option.  We should skip
(rather than fail) this IGT test when running on kernels that don't
advertise support for atomic modesetting.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=93014
Signed-off-by: Matt Roper 
---
 tests/kms_atomic.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tests/kms_atomic.c b/tests/kms_atomic.c
index 2f3080a..6a6cfa7 100644
--- a/tests/kms_atomic.c
+++ b/tests/kms_atomic.c
@@ -723,7 +723,7 @@ static void atomic_setup(struct kms_atomic_state *state)
desc->fd = drm_open_driver_master(DRIVER_INTEL);
igt_assert_fd(desc->fd);
 
-   do_or_die(drmSetClientCap(desc->fd, DRM_CLIENT_CAP_ATOMIC, 1));
+   igt_skip_on(drmSetClientCap(desc->fd, DRM_CLIENT_CAP_ATOMIC, 1));
 
res = drmModeGetResources(desc->fd);
res_plane = drmModeGetPlaneResources(desc->fd);
-- 
2.1.4

___
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: Use consistent forcewake auto-release timeout across kernel configs

[Chris Wilson]

On Mon, Apr 04, 2016 at 08:41:20PM +0100, Dave Gordon wrote:
> On 04/04/16 19:58, Chris Wilson wrote:
> >On Mon, Apr 04, 2016 at 05:51:09PM +0100, Tvrtko Ursulin wrote:
> >>From: Tvrtko Ursulin 
> >>
> >>Current implementation releases the forcewake at any time between
> >>straight away, and one jiffie from the last put, or first automatic
> >>grab.
> >
> >That isn't the problem though. The problem is that we set the timer on
> >first use rather than last use. All you are stating here is that by
> >lengthening the timeout on your system you reduce the number of times it
> >times out.
> 
> I thought that was already done, per my comments on one of your
> recent patches (rename __force_wake_get to __force_wake_auto) and
> your reply (gains are probably worth extra complexity). But of
> course Tvrtko wasn't here the last few days so may not have seen
> that. I suppose it would make sense to fold both changes together.

We were talking about the cost of having 2 passes vs 1 to do the same
task. Before Tvrtko left, I realised again that we didn't defer the
timer itself for every access, rearming a timer on every register access
seems costly (more so switching to hrtimer). Rearming the timer inside
the timer callback seems a reasonable compromise.
 
> But changing the timeout to 1ms makes it generally *shorter* than
> before, not longer. The gain can't just be from having a longer
> timeout, 'cos it isn't. (Average timeout now 1.5ms vs. previous
> 8ms?)

It is. jiffies+1 does not equal an 8ms delay (it would be 1ms on his
machine anways, 10ms on mine). The issue is that +1 jiffie is up to 1
jiffie and often close to 0, and that very well explains the wakeups
Tvrtko measured.

> I think it should come from the fact that accesses are likely to be
> bursty, having a bimodal distribution in the time domain. When we've
> made one access, we're likely to make another much sooner than 1ms
> later, but once we stop making accesses there will probably be far
> more than 1ms before the next set of accesses.

Yes. We expect temporal coherence in the access patten. That's assuredly
so since we very rarely access one register by itself.

> One more idea - do we want two different expiry periods depending on
> whether the caller used the _auto version or not?

Hard to tell. Broadly speaking we have two users of the non-auto
interface: userspace disabling forcewake indefinitely, and the other is
code that wants to hold the spinlock + forcewake over a bunch of
register writes.
 
> If they did, they're probably anticipating "only a few" accesses in
> the current operation, but perhaps with no idea about when the next
> set of accesses will occur.
> 
> If not, then the final decrement means they think they've finished
> for a while, and perhaps don't expect to come back for quite a long
> time. In that situation the timeout only helps avoid rapid off/on
> cycles by unrelated functions, not between logically-related
> operations.

Execlists. (Wants to hold forcewake over a bunch of reads and writes,
and may be very frequent context switches or very slow)
 
> So would two different timeouts make sense? Or even ...
> 
> _auto: longish timeout from the *first* _get() - don't rearm thereafter
> other: shortish timeout from the _put() - non-auto _get() will cancel
> 
> or is that just too complicated?

The challenge is that I think we should be pushing for shorter timeouts,
because of the bimodality in many accesses followed by a long period of
sleep. One of the original reasons for the choice in 1 jiffie with a
pinned timer was that it should mean that on the next call to schedule()
we should be deasserting forcewake (i.e. we only hold forcewake for this
sequence of register accesses). However, execlists scuppers that by
having an interrupt context that requires forcewake, and frequently so.

So I think we do need a combination of something like task_work_run() to
tie a forcewake reference to the active task with something like an
extra timer to allow frequent wakers to avoid having to retake
forcewake.
-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 i-g-t] test/gem_mocs_settings: Testing MOCS register settings

[Chris Wilson]

On Mon, Apr 04, 2016 at 06:30:21PM +0100, Peter Antoine wrote:
> >As well as checking for creating new contexts after resume, we also need
> >to check that the register values are preserved across suspend (i.e.
> >that the register state is being saved back into the context image and
> >then restored).
> 
> Ok, I'll add another test case that does this for the render engine
> (the only one that is effected (at the moment) by context save and
> resume.

We do expect that the mocs values for other rings to be preserved across
suspend. Or did I misunderstand you? i.e create-context; bcs; suspend;
bcs should^W must work.
-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 1/3] drm/i915: Use consistent forcewake auto-release timeout across kernel configs

[Dave Gordon]

On 04/04/16 19:58, Chris Wilson wrote:

On Mon, Apr 04, 2016 at 05:51:09PM +0100, Tvrtko Ursulin wrote:

From: Tvrtko Ursulin 

Current implementation releases the forcewake at any time between
straight away, and one jiffie from the last put, or first automatic
grab.


That isn't the problem though. The problem is that we set the timer on
first use rather than last use. All you are stating here is that by
lengthening the timeout on your system you reduce the number of times it
times out.


I thought that was already done, per my comments on one of your recent 
patches (rename __force_wake_get to __force_wake_auto) and your reply 
(gains are probably worth extra complexity). But of course Tvrtko wasn't 
here the last few days so may not have seen that. I suppose it would 
make sense to fold both changes together.


But changing the timeout to 1ms makes it generally *shorter* than 
before, not longer. The gain can't just be from having a longer timeout, 
'cos it isn't. (Average timeout now 1.5ms vs. previous 8ms?)


I think it should come from the fact that accesses are likely to be 
bursty, having a bimodal distribution in the time domain. When we've 
made one access, we're likely to make another much sooner than 1ms 
later, but once we stop making accesses there will probably be far more 
than 1ms before the next set of accesses.



Having said that, the conversion to hrtimer seems sensible but to add
tracking of the last access as opposed to first we either fallback to
jiffie (in which case hrtimer is moot) or rely on ktime_get_raw() being
fast enough for every register write. Hmm, my usual response to that has
been if it matters we avoid the heavyweight macros and use the _FW
interface - or even raw readl/writel.

Could you try storing ktime_get_raw() on every access and rearming the
timer if it expires before last-access + min-period?
-Chris


One more idea - do we want two different expiry periods depending on 
whether the caller used the _auto version or not?


If they did, they're probably anticipating "only a few" accesses in the 
current operation, but perhaps with no idea about when the next set of 
accesses will occur.


If not, then the final decrement means they think they've finished for a 
while, and perhaps don't expect to come back for quite a long time. In 
that situation the timeout only helps avoid rapid off/on cycles by 
unrelated functions, not between logically-related operations.


So would two different timeouts make sense? Or even ...

_auto: longish timeout from the *first* _get() - don't rearm thereafter
other: shortish timeout from the _put() - non-auto _get() will cancel

or is that just too complicated?

.Dave.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 2/3] drm/i915: Simplify for_each_fw_domain iterators

[Dave Gordon]

On 04/04/16 17:51, Tvrtko Ursulin wrote:

From: Tvrtko Ursulin 

As the vast majority of users does not use the domain id variable,


"do not use"


we can eliminate it from the iterator and also change the latter
using the same principle as was recently done for for_each_engine.

For a couple of callers which do need the domain id, or the domain
mask, store the later in the domain itself at init time and use
both through it.


"For a couple of callers which do need the domain mask, store it
in the domain array (which already has the domain id), then both
can be retrieved thence." ?


Result is clearer code and smaller generated binary, especially
in the tight fw get/put loops. Also, relationship between domain
id and mask is no longer assumed in the macro.


"in the macro or elsewhere" ?


Signed-off-by: Tvrtko Ursulin 


A few typos & clarifications above, plus a minor quibble about a macro
name (which you haven't actually changed, but might as well fix).
Otherwise LGTM, so

Reviewed-by: Dave Gordon 

(even if you don't change the macro name)


---
  drivers/gpu/drm/i915/i915_debugfs.c |  5 ++---
  drivers/gpu/drm/i915/i915_drv.h | 17 +++---
  drivers/gpu/drm/i915/intel_uncore.c | 45 +
  3 files changed, 32 insertions(+), 35 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index a2e3af02c292..06fce014d0b4 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -1464,12 +1464,11 @@ static int i915_forcewake_domains(struct seq_file *m, 
void *data)
struct drm_device *dev = node->minor->dev;
struct drm_i915_private *dev_priv = dev->dev_private;
struct intel_uncore_forcewake_domain *fw_domain;
-   int i;

spin_lock_irq(_priv->uncore.lock);
-   for_each_fw_domain(fw_domain, dev_priv, i) {
+   for_each_fw_domain(fw_domain, dev_priv) {
seq_printf(m, "%s.wake_count = %u\n",
-  intel_uncore_forcewake_domain_to_str(i),
+  intel_uncore_forcewake_domain_to_str(fw_domain->id),
   fw_domain->wake_count);
}
spin_unlock_irq(_priv->uncore.lock);
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 7d4c704d7d75..160f980f0368 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -665,6 +665,7 @@ struct intel_uncore {
struct intel_uncore_forcewake_domain {
struct drm_i915_private *i915;
enum forcewake_domain_id id;
+   enum forcewake_domains mask;


At present this mask will always have only one bit set, but I suppose 
there might be some utility in allowing multiple bits (virtual domains?)



unsigned wake_count;
struct hrtimer timer;
i915_reg_t reg_set;
@@ -679,14 +680,14 @@ struct intel_uncore {
  };

  /* Iterate over initialised fw domains */
-#define for_each_fw_domain_mask(domain__, mask__, dev_priv__, i__) \
-   for ((i__) = 0, (domain__) = &(dev_priv__)->uncore.fw_domain[0]; \
-(i__) < FW_DOMAIN_ID_COUNT; \
-(i__)++, (domain__) = &(dev_priv__)->uncore.fw_domain[i__]) \
-   for_each_if (((mask__) & (dev_priv__)->uncore.fw_domains) & (1 
<< (i__)))
-
-#define for_each_fw_domain(domain__, dev_priv__, i__) \
-   for_each_fw_domain_mask(domain__, FORCEWAKE_ALL, dev_priv__, i__)
+#define for_each_fw_domain_mask(domain__, mask__, dev_priv__) \
+   for ((domain__) = &(dev_priv__)->uncore.fw_domain[0]; \
+(domain__) < &(dev_priv__)->uncore.fw_domain[FW_DOMAIN_ID_COUNT]; \
+(domain__)++) \
+   for_each_if ((mask__) & (domain__)->mask)
+


For consistency with the for_each_engine() macros, the name ought to be 
"for_each_fw_domain_mask*ed*()", showing that we're iterating over a 
subset selected by the 'mask' parameter, rather than iterating over all 
possible masks.


.Dave.


+#define for_each_fw_domain(domain__, dev_priv__) \
+   for_each_fw_domain_mask(domain__, FORCEWAKE_ALL, dev_priv__)

  #define CSR_VERSION(major, minor) ((major) << 16 | (minor))
  #define CSR_VERSION_MAJOR(version)((version) >> 16)
diff --git a/drivers/gpu/drm/i915/intel_uncore.c 
b/drivers/gpu/drm/i915/intel_uncore.c
index 76ac990de354..49edd641b434 100644
--- a/drivers/gpu/drm/i915/intel_uncore.c
+++ b/drivers/gpu/drm/i915/intel_uncore.c
@@ -111,9 +111,8 @@ static void
  fw_domains_get(struct drm_i915_private *dev_priv, enum forcewake_domains 
fw_domains)
  {
struct intel_uncore_forcewake_domain *d;
-   enum forcewake_domain_id id;

-   for_each_fw_domain_mask(d, fw_domains, dev_priv, id) {
+   for_each_fw_domain_mask(d, fw_domains, dev_priv) {
fw_domain_wait_ack_clear(d);

Re: [Intel-gfx] [PATCH 3/3] drm/i915: Do not serialize forcewake acquire across domains

[Chris Wilson]

On Mon, Apr 04, 2016 at 05:51:11PM +0100, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin 
> 
> On platforms with multiple forcewake domains it seems more efficient
> to request all desired ones and then to wait for acks to avoid
> needlessly serializing on each domain.

Not convinced since we have more machines with one domain than two. What
I did was to compact the domains array so that we only iterated over the
known set - but that feels overkill when we only have two domains today.

For the same reason (only one machine with two domains), I didn't think
seperate functions to iterate over one domain and another to iterate
over all was worth it.

What you can do though is remove an excess posting read from
fw_domains_put.

Compared to the cost of a register access (the spinlock irq mostly) the
iterator doesn't strike me as being that worthwhile an optimisation
target.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 2/3] drm/i915: Simplify for_each_fw_domain iterators

[Chris Wilson]

On Mon, Apr 04, 2016 at 05:51:10PM +0100, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin 
> 
> As the vast majority of users does not use the domain id variable,
> we can eliminate it from the iterator and also change the latter
> using the same principle as was recently done for for_each_engine.
> 
> For a couple of callers which do need the domain id, or the domain
> mask, store the later in the domain itself at init time and use
> both through it.
> 
> Result is clearer code and smaller generated binary, especially
> in the tight fw get/put loops. Also, relationship between domain
> id and mask is no longer assumed in the macro.
> 
> Signed-off-by: Tvrtko Ursulin 

Hah, I made exactly (admittedly I didn't think of adding BUILD_BUG_ON)
the same patch just as you went off on holiday and weren't around to
comment!

Reviewed-by: Chris Wilson 
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 1/3] drm/i915: Use consistent forcewake auto-release timeout across kernel configs

[Chris Wilson]

On Mon, Apr 04, 2016 at 05:51:09PM +0100, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin 
> 
> Current implementation releases the forcewake at any time between
> straight away, and one jiffie from the last put, or first automatic
> grab.

That isn't the problem though. The problem is that we set the timer on
first use rather than last use. All you are stating here is that by
lengthening the timeout on your system you reduce the number of times it
times out.

Having said that, the conversion to hrtimer seems sensible but to add
tracking of the last access as opposed to first we either fallback to
jiffie (in which case hrtimer is moot) or rely on ktime_get_raw() being
fast enough for every register write. Hmm, my usual response to that has
been if it matters we avoid the heavyweight macros and use the _FW
interface - or even raw readl/writel.

Could you try storing ktime_get_raw() on every access and rearming the
timer if it expires before last-access + min-period?
-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 1/3] drm/i915: Use consistent forcewake auto-release timeout across kernel configs

[Dave Gordon]

On 04/04/16 17:51, Tvrtko Ursulin wrote:

From: Tvrtko Ursulin 

Current implementation releases the forcewake at any time between
straight away, and one jiffie from the last put, or first automatic
grab.

This does not sound like what was desired since jiffies are typically
between 1 and 10ms depending on the kernel configuration.

Change the auto-release mechanism to use hrtimers and set the timeout
to 1ms with a 1ms of slack. This should make the GPU power consistent
across kernel configs and the slack should enable some timer coallescing


"coalescing"


where multiple force-wake domains exist, or with unrelated timers.

For GlBench/T-Rex this decreases the number of forcewake releases from
~480 to ~300 per second, and for a heavy combined OGL/OCL test from
~670 to ~360.

Signed-off-by: Tvrtko Ursulin 


LGTM.

Reviewed-by: Dave Gordon 


---
  drivers/gpu/drm/i915/i915_drv.h |  2 +-
  drivers/gpu/drm/i915/intel_uncore.c | 25 -
  2 files changed, 17 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index dd187727c813..7d4c704d7d75 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -666,7 +666,7 @@ struct intel_uncore {
struct drm_i915_private *i915;
enum forcewake_domain_id id;
unsigned wake_count;
-   struct timer_list timer;
+   struct hrtimer timer;
i915_reg_t reg_set;
u32 val_set;
u32 val_clear;
diff --git a/drivers/gpu/drm/i915/intel_uncore.c 
b/drivers/gpu/drm/i915/intel_uncore.c
index ac1c545436af..76ac990de354 100644
--- a/drivers/gpu/drm/i915/intel_uncore.c
+++ b/drivers/gpu/drm/i915/intel_uncore.c
@@ -60,7 +60,11 @@ fw_domain_reset(const struct intel_uncore_forcewake_domain 
*d)
  static inline void
  fw_domain_arm_timer(struct intel_uncore_forcewake_domain *d)
  {
-   mod_timer_pinned(>timer, jiffies + 1);
+   d->wake_count++;
+   hrtimer_start_range_ns(>timer,
+  ktime_set(0, NSEC_PER_MSEC),
+  NSEC_PER_MSEC,
+  HRTIMER_MODE_REL);
  }

  static inline void
@@ -224,9 +228,11 @@ static int __gen6_gt_wait_for_fifo(struct drm_i915_private 
*dev_priv)
return ret;
  }

-static void intel_uncore_fw_release_timer(unsigned long arg)
+static enum hrtimer_restart
+intel_uncore_fw_release_timer(struct hrtimer *timer)
  {
-   struct intel_uncore_forcewake_domain *domain = (void *)arg;
+   struct intel_uncore_forcewake_domain *domain =
+  container_of(timer, struct intel_uncore_forcewake_domain, timer);
unsigned long irqflags;

assert_rpm_device_not_suspended(domain->i915);
@@ -240,6 +246,8 @@ static void intel_uncore_fw_release_timer(unsigned long arg)
  1 << domain->id);

spin_unlock_irqrestore(>i915->uncore.lock, irqflags);
+
+   return HRTIMER_NORESTART;
  }

  void intel_uncore_forcewake_reset(struct drm_device *dev, bool restore)
@@ -259,16 +267,16 @@ void intel_uncore_forcewake_reset(struct drm_device *dev, 
bool restore)
active_domains = 0;

for_each_fw_domain(domain, dev_priv, id) {
-   if (del_timer_sync(>timer) == 0)
+   if (hrtimer_cancel(>timer) == 0)
continue;

-   intel_uncore_fw_release_timer((unsigned long)domain);
+   intel_uncore_fw_release_timer(>timer);
}

spin_lock_irqsave(_priv->uncore.lock, irqflags);

for_each_fw_domain(domain, dev_priv, id) {
-   if (timer_pending(>timer))
+   if (hrtimer_active(>timer))
active_domains |= (1 << id);
}

@@ -491,7 +499,6 @@ static void __intel_uncore_forcewake_put(struct 
drm_i915_private *dev_priv,
if (--domain->wake_count)
continue;

-   domain->wake_count++;
fw_domain_arm_timer(domain);
}
  }
@@ -732,7 +739,6 @@ static inline void __force_wake_auto(struct 
drm_i915_private *dev_priv,
continue;
}

-   domain->wake_count++;
fw_domain_arm_timer(domain);
}

@@ -1150,7 +1156,8 @@ static void fw_domain_init(struct drm_i915_private 
*dev_priv,
d->i915 = dev_priv;
d->id = domain_id;

-   setup_timer(>timer, intel_uncore_fw_release_timer, (unsigned long)d);
+   hrtimer_init(>timer, CLOCK_MONOTONIC, HRTIMER_MODE_REL);
+   d->timer.function = intel_uncore_fw_release_timer;

dev_priv->uncore.fw_domains |= (1 << domain_id);




___

Re: [Intel-gfx] [PATCH v2 8/9] drm/i915/dsi: add support for gpio elements on CHV

[Ville Syrjälä]

On Fri, Mar 18, 2016 at 01:11:16PM +0200, Jani Nikula wrote:
> From: Yogesh Mohan Marimuthu 
> 
> Add support for CHV gpio programming in DSI gpio elements.
> 
> XXX: I'd like to have a gpio table for chv as well as others.
> 
> [Rewritten by Jani, based on earlier work by Yogesh and Deepak.]
> 
> Signed-off-by: Yogesh Mohan Marimuthu 
> Signed-off-by: Deepak M 
> Signed-off-by: Jani Nikula 
> ---
>  drivers/gpu/drm/i915/intel_dsi_panel_vbt.c | 66 
> ++
>  1 file changed, 66 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c 
> b/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
> index ca48f7aa6a05..f8d3f608e9c8 100644
> --- a/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
> +++ b/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
> @@ -97,6 +97,23 @@ static struct vlv_gpio_map vlv_gpio_table[] = {
>   { 11, IOSF_PORT_GPIO_NC, VLV_GPIO_NC_11_PCONF0 },
>  };
>  
> +#define CHV_MAX_GPIO_NUM_N   72
> +#define CHV_MAX_GPIO_NUM_SE  99
> +#define CHV_MAX_GPIO_NUM_SW  197
> +#define CHV_MIN_GPIO_NUM_SE  73
> +#define CHV_MIN_GPIO_NUM_SW  100
> +#define CHV_MIN_GPIO_NUM_E   198

Not sure why we need min+max for these.

I would probably just do something like:

#define CHV_GPIO_IDX_START_N0
#define CHV_GPIO_IDX_START_SE   73
#define CHV_GPIO_IDX_START_SW   100
#define CHV_GPIO_IDX_START_SE   198

> +
> +#define CHV_PAD_FMLY_BASE0x4400
> +#define CHV_PAD_FMLY_SIZE0x400
> +#define CHV_PAD_CFG_0_1_REG_SIZE 0x8
> +#define CHV_PAD_CFG_REG_SIZE 0x4

I'd hide all the uglies that use these in macros like:

#define CHV_GPIO_PAD_CFG0(f, i) (0x4400 + (f) * 0x400 + (i) * 8)
#define CHV_GPIO_PAD_CFG1(f, i) (0x4400 + (f) * 0x400 + (i) * 8 + 4)

> +#define CHV_VBT_MAX_PINS_PER_FMLY15
> +
> +#define CHV_GPIO_CFG_UNLOCK  0x

Maybe just define the bit for documentation purpose and just write a
raw 0 to the register.

#define  CHV_GPIO_CFGLOCK   (1 << 31)

> +#define CHV_GPIO_CFG_HIZ 0x8100

That's still not hiz.

#define  CHV_GPIO_GPIOCFG_GPIO  (0 << 8)
#define  CHV_GPIO_GPIOCFG_GPO   (1 << 8)
#define  CHV_GPIO_GPIOCFG_GPI   (2 << 8)
#define  CHV_GPIO_GPIOCFG_HIZ   (3 << 8)
#define  CHV_GPIO_GPIOEN(1 << 15)

> +#define CHV_GPIO_CFG_TX_STATE_SHIFT  1

Maybe

#define  CHV_GPIO_GPIOTXSTATE(state)((state) << 1)

> +
>  static inline enum port intel_dsi_seq_port_to_port(u8 port)
>  {
>   return port ? PORT_C : PORT_A;
> @@ -241,6 +258,53 @@ static void vlv_exec_gpio(struct drm_i915_private 
> *dev_priv,
>   mutex_unlock(_priv->sb_lock);
>  }
>  
> +static void chv_exec_gpio(struct drm_i915_private *dev_priv,
> +   u8 gpio_source, u8 gpio_index, u8 action)
> +{
> + u16 pconf0, padval;

cfg0, cfg1 to match the reg names. Or just drop them entirely since the
parametrized macros I suggested earlier would make thing very clear
without temp variables.

> + u16 family_num;
> + u8 port;
> +
> + /* XXX: add a table similar to vlv for checking gpio indexes */

If we bother going that far, then I think we should just go for gpiolib
instead.

> + if (dev_priv->vbt.dsi.seq_version >= 3) {
> + if (gpio_index <= CHV_MAX_GPIO_NUM_N) {
> + port = CHV_IOSF_PORT_GPIO_N;
> + } else if (gpio_index <= CHV_MAX_GPIO_NUM_SE) {
> + port = CHV_IOSF_PORT_GPIO_SE;
> + gpio_index = gpio_index - CHV_MIN_GPIO_NUM_SE;
> + } else if (gpio_index <= CHV_MAX_GPIO_NUM_SW) {
> + port = CHV_IOSF_PORT_GPIO_SW;
> + gpio_index = gpio_index - CHV_MIN_GPIO_NUM_SW;
> + } else {
> + port = CHV_IOSF_PORT_GPIO_E;
> + gpio_index = gpio_index - CHV_MIN_GPIO_NUM_E;
> + }
> + } else if (dev_priv->vbt.dsi.seq_version == 2) {
> + if (gpio_source == 0) {
> + port = IOSF_PORT_GPIO_NC;
> + } else if (gpio_source == 1) {
> + port = IOSF_PORT_GPIO_SC;
> + } else {
> + DRM_DEBUG_KMS("unknown gpio source %u\n", gpio_source);
> + return;
> + }
> + } else {
> + port = IOSF_PORT_GPIO_NC;
> + }
> +
> + family_num = gpio_index / CHV_VBT_MAX_PINS_PER_FMLY;
> + gpio_index = gpio_index - (family_num * CHV_VBT_MAX_PINS_PER_FMLY);

I'd still use % for clarity.

> + padval = CHV_PAD_FMLY_BASE + (family_num * CHV_PAD_FMLY_SIZE) +
> + (((u16)gpio_index) * CHV_PAD_CFG_0_1_REG_SIZE);
> + pconf0 = padval + CHV_PAD_CFG_REG_SIZE;
> +
> + mutex_lock(_priv->sb_lock);
> + vlv_iosf_sb_write(dev_priv, port, pconf0, CHV_GPIO_CFG_UNLOCK);
> + vlv_iosf_sb_write(dev_priv, port, padval, CHV_GPIO_CFG_HIZ |
> +  

[Intel-gfx] [PATCH v2] drm/i915/Gen9+: optional IPC enablement

[Dongwon Kim]

With IPC(Isochronous Priority Control) enabled,
display sends requests based on the priority of each
request. To enable it, a i915 param, i915.enable_ipc
should be set to 1.

v2: corrected matched type of enable_ipc in
module_param_named_unsafe macro

Signed-off-by: Dongwon Kim 
---
 drivers/gpu/drm/i915/i915_params.c | 5 +
 drivers/gpu/drm/i915/i915_params.h | 1 +
 drivers/gpu/drm/i915/i915_reg.h| 1 +
 drivers/gpu/drm/i915/intel_pm.c| 5 +
 4 files changed, 12 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_params.c 
b/drivers/gpu/drm/i915/i915_params.c
index 1779f02..4d5ac80 100644
--- a/drivers/gpu/drm/i915/i915_params.c
+++ b/drivers/gpu/drm/i915/i915_params.c
@@ -58,6 +58,7 @@ struct i915_params i915 __read_mostly = {
.guc_log_level = -1,
.enable_dp_mst = true,
.inject_load_failure = 0,
+   .enable_ipc = 0,
 };
 
 module_param_named(modeset, i915.modeset, int, 0400);
@@ -210,3 +211,7 @@ MODULE_PARM_DESC(enable_dp_mst,
 module_param_named_unsafe(inject_load_failure, i915.inject_load_failure, uint, 
0400);
 MODULE_PARM_DESC(inject_load_failure,
"Force an error after a number of failure check points (0:disabled 
(default), N:force failure at the Nth failure check point)");
+
+module_param_named_unsafe(enable_ipc, i915.enable_ipc, bool, 0400);
+MODULE_PARM_DESC(enable_ipc,
+   "Enable Isochronous Priority Control (1=enabled, 0=disabled [default]");
diff --git a/drivers/gpu/drm/i915/i915_params.h 
b/drivers/gpu/drm/i915/i915_params.h
index 02bc278..3b3fa1b 100644
--- a/drivers/gpu/drm/i915/i915_params.h
+++ b/drivers/gpu/drm/i915/i915_params.h
@@ -61,6 +61,7 @@ struct i915_params {
bool verbose_state_checks;
bool nuclear_pageflip;
bool enable_dp_mst;
+   bool enable_ipc;
 };
 
 extern struct i915_params i915 __read_mostly;
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 12f5103..0b638c5 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -5995,6 +5995,7 @@ enum skl_disp_power_wells {
 #define  DISP_FBC_WM_DIS   (1<<15)
 #define DISP_ARB_CTL2  _MMIO(0x45004)
 #define  DISP_DATA_PARTITION_5_6   (1<<6)
+#define  DISP_ENABLE_IPC   (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_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 9bc9c25..9c696c0 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -3682,6 +3682,11 @@ static void skl_update_wm(struct drm_crtc *crtc)
skl_write_wm_values(dev_priv, results);
skl_flush_wm_values(dev_priv, results);
 
+   /* optional IPC enablement */
+   if (i915.enable_ipc)
+   I915_WRITE(DISP_ARB_CTL2,
+   I915_READ(DISP_ARB_CTL2) | DISP_ENABLE_IPC);
+
/* store the new configuration */
dev_priv->wm.skl_hw = *results;
 }
-- 
1.9.1

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH v4 1/3] drm/i915/guc: reset GuC and retry on firmware load failure

[Dave Gordon]

From: Arun Siluvery 

Due to timing issues in the HW, some of the status bits required for GuC
authentication occasionally don't get set; when that happens, the GuC
cannot be initialized and we will be left with a wedged GPU. The W/A
suggested is to perform a soft reset of the GuC and attempt to reload
the F/W again for few times before giving up.

As the failure is dependent on timing, tests performed by triggering
manual full gpu reset (i915_wedged) showed that we could sometimes hit
this after several thousand iterations, but sometimes tests ran even
longer without any issues. Reset and reload mechanism proved helpful
when we indeed hit f/w load failure, so it is better to include this
to improve driver stability.

This change implements the following WAs,

WaEnableuKernelHeaderValidFix:skl,bxt
WaEnableGuCBootHashCheckNotSet:skl,bxt

Signed-off-by: Arun Siluvery 
Signed-off-by: Dave Gordon 
Reviewed-by: Alex Dai 
---
 drivers/gpu/drm/i915/i915_drv.h |  1 +
 drivers/gpu/drm/i915/i915_guc_reg.h |  1 +
 drivers/gpu/drm/i915/i915_reg.h |  1 +
 drivers/gpu/drm/i915/intel_guc_loader.c | 49 +++--
 drivers/gpu/drm/i915/intel_uncore.c | 19 +
 5 files changed, 69 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index dd18772..1847ef9 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2746,6 +2746,7 @@ extern long i915_compat_ioctl(struct file *filp, unsigned 
int cmd,
 extern int intel_gpu_reset(struct drm_device *dev, u32 engine_mask);
 extern bool intel_has_gpu_reset(struct drm_device *dev);
 extern int i915_reset(struct drm_device *dev);
+extern int intel_guc_reset(struct drm_i915_private *dev_priv);
 extern void intel_engine_init_hangcheck(struct intel_engine_cs *engine);
 extern unsigned long i915_chipset_val(struct drm_i915_private *dev_priv);
 extern unsigned long i915_mch_val(struct drm_i915_private *dev_priv);
diff --git a/drivers/gpu/drm/i915/i915_guc_reg.h 
b/drivers/gpu/drm/i915/i915_guc_reg.h
index e4ba582..94ceee5 100644
--- a/drivers/gpu/drm/i915/i915_guc_reg.h
+++ b/drivers/gpu/drm/i915/i915_guc_reg.h
@@ -27,6 +27,7 @@
 /* Definitions of GuC H/W registers, bits, etc */
 
 #define GUC_STATUS _MMIO(0xc000)
+#define   GS_MIA_IN_RESET  (1 << 0)
 #define   GS_BOOTROM_SHIFT 1
 #define   GS_BOOTROM_MASK(0x7F << GS_BOOTROM_SHIFT)
 #define   GS_BOOTROM_RSA_FAILED  (0x50 << GS_BOOTROM_SHIFT)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 12f5103..f4ebf31 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -165,6 +165,7 @@ static inline bool i915_mmio_reg_valid(i915_reg_t reg)
 #define  GEN6_GRDOM_MEDIA  (1 << 2)
 #define  GEN6_GRDOM_BLT(1 << 3)
 #define  GEN6_GRDOM_VECS   (1 << 4)
+#define  GEN9_GRDOM_GUC(1 << 5)
 #define  GEN8_GRDOM_MEDIA2 (1 << 7)
 
 #define RING_PP_DIR_BASE(ring) _MMIO((ring)->mmio_base+0x228)
diff --git a/drivers/gpu/drm/i915/intel_guc_loader.c 
b/drivers/gpu/drm/i915/intel_guc_loader.c
index b4976f9..d84c560 100644
--- a/drivers/gpu/drm/i915/intel_guc_loader.c
+++ b/drivers/gpu/drm/i915/intel_guc_loader.c
@@ -353,6 +353,24 @@ static int guc_ucode_xfer(struct drm_i915_private 
*dev_priv)
return ret;
 }
 
+static int i915_reset_guc(struct drm_i915_private *dev_priv)
+{
+   int ret;
+   u32 guc_status;
+
+   ret = intel_guc_reset(dev_priv);
+   if (ret) {
+   DRM_ERROR("GuC reset failed, ret = %d\n", ret);
+   return ret;
+   }
+
+   guc_status = I915_READ(GUC_STATUS);
+   WARN(!(guc_status & GS_MIA_IN_RESET),
+"GuC status: 0x%x, MIA core expected to be in reset\n", 
guc_status);
+
+   return ret;
+}
+
 /**
  * intel_guc_ucode_load() - load GuC uCode into the device
  * @dev:   drm device
@@ -417,9 +435,36 @@ int intel_guc_ucode_load(struct drm_device *dev)
if (err)
goto fail;
 
+   /*
+* WaEnableuKernelHeaderValidFix:skl,bxt
+* For BXT, this is only upto B0 but below WA is required for later
+* steppings also so this is extended as well.
+*/
+   /* WaEnableGuCBootHashCheckNotSet:skl,bxt */
err = guc_ucode_xfer(dev_priv);
-   if (err)
-   goto fail;
+   if (err) {
+   int retries = 3;
+
+   DRM_ERROR("GuC fw load failed, err=%d, attempting reset and 
retry\n", err);
+
+   while (retries--) {
+   err = i915_reset_guc(dev_priv);
+   if (err)
+   break;
+
+   err = 

[Intel-gfx] [PATCH v4 3/3] DO NOT MERGE: add enable_guc_loading parameter

[Dave Gordon]

Split the function of "enable_guc_submission" into two separate options.
The new one "enable_guc_loading" controls only the *fetching and loading*
of the GuC firmware image. The existing one is redefined to control only
the *use* of the GuC for batch submission once the firmware is loaded.

In addition, the degree of control has been refined from a simple bool
to an integer key, allowing several options:
 -1  (default)whatever the platform default is
  0  DISABLE  don't load/use the GuC
  1  BEST EFFORT  try to load/use the GuC, fallback if not available
  2  REQUIRE  must load/use the GuC, else leave the GPU wedged

The new platform default (as coded here) will be to attempt to load
the GuC iff the device has a GuC that requires firmware, to attempt to
use it iff the device has a GuC that supports the submission protocol
(with or without firmware), and to fall back to execlist mode if any
required firmware cannot be found or fails to load.

Signed-off-by: Dave Gordon 

---
 drivers/gpu/drm/i915/i915_gem.c |  1 -
 drivers/gpu/drm/i915/i915_params.c  | 14 -
 drivers/gpu/drm/i915/i915_params.h  |  3 +-
 drivers/gpu/drm/i915/intel_guc_loader.c | 98 ++---
 4 files changed, 67 insertions(+), 49 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index ca96fc1..da34db5 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -4885,7 +4885,6 @@ int i915_gem_init_engines(struct drm_device *dev)
ret = intel_guc_ucode_load(dev);
if (ret) {
DRM_ERROR("Failed to initialize GuC, error %d\n", ret);
-   ret = -EIO;
goto out;
}
}
diff --git a/drivers/gpu/drm/i915/i915_params.c 
b/drivers/gpu/drm/i915/i915_params.c
index 1779f02..21f325b 100644
--- a/drivers/gpu/drm/i915/i915_params.c
+++ b/drivers/gpu/drm/i915/i915_params.c
@@ -54,7 +54,8 @@ struct i915_params i915 __read_mostly = {
.verbose_state_checks = 1,
.nuclear_pageflip = 0,
.edp_vswing = 0,
-   .enable_guc_submission = false,
+   .enable_guc_loading = -1,
+   .enable_guc_submission = -1,
.guc_log_level = -1,
.enable_dp_mst = true,
.inject_load_failure = 0,
@@ -197,8 +198,15 @@ struct i915_params i915 __read_mostly = {
 "(0=use value from vbt [default], 1=low power swing(200mV),"
 "2=default swing(400mV))");
 
-module_param_named_unsafe(enable_guc_submission, i915.enable_guc_submission, 
bool, 0400);
-MODULE_PARM_DESC(enable_guc_submission, "Enable GuC submission 
(default:false)");
+module_param_named_unsafe(enable_guc_loading, i915.enable_guc_loading, int, 
0400);
+MODULE_PARM_DESC(enable_guc_submission,
+   "Enable GuC firmware loading "
+   "(-1=auto [default], 0=never, 1=if available, 2=required)");
+
+module_param_named_unsafe(enable_guc_submission, i915.enable_guc_submission, 
int, 0400);
+MODULE_PARM_DESC(enable_guc_submission,
+   "Enable GuC submission "
+   "(-1=auto [default], 0=never, 1=if available, 2=required)");
 
 module_param_named(guc_log_level, i915.guc_log_level, int, 0400);
 MODULE_PARM_DESC(guc_log_level,
diff --git a/drivers/gpu/drm/i915/i915_params.h 
b/drivers/gpu/drm/i915/i915_params.h
index 02bc278..9f1d17b 100644
--- a/drivers/gpu/drm/i915/i915_params.h
+++ b/drivers/gpu/drm/i915/i915_params.h
@@ -45,6 +45,8 @@ struct i915_params {
int enable_ips;
int invert_brightness;
int enable_cmd_parser;
+   int enable_guc_loading;
+   int enable_guc_submission;
int guc_log_level;
int use_mmio_flip;
int mmio_debug;
@@ -57,7 +59,6 @@ struct i915_params {
bool load_detect_test;
bool reset;
bool disable_display;
-   bool enable_guc_submission;
bool verbose_state_checks;
bool nuclear_pageflip;
bool enable_dp_mst;
diff --git a/drivers/gpu/drm/i915/intel_guc_loader.c 
b/drivers/gpu/drm/i915/intel_guc_loader.c
index 876e5da..2ec9cf1 100644
--- a/drivers/gpu/drm/i915/intel_guc_loader.c
+++ b/drivers/gpu/drm/i915/intel_guc_loader.c
@@ -387,49 +387,37 @@ int intel_guc_ucode_load(struct drm_device *dev)
 {
struct drm_i915_private *dev_priv = dev->dev_private;
struct intel_guc_fw *guc_fw = _priv->guc.guc_fw;
+   const char *fw_path = guc_fw->guc_fw_path;
int retries, err = 0;
 
-   if (!i915.enable_guc_submission)
-   return 0;
-
-   DRM_DEBUG_DRIVER("GuC fw status: fetch %s, load %s\n",
+   DRM_DEBUG_DRIVER("GuC fw status: path %s, fetch %s, load %s\n",
+   fw_path,
intel_guc_fw_status_repr(guc_fw->guc_fw_fetch_status),
intel_guc_fw_status_repr(guc_fw->guc_fw_load_status));
 
-   direct_interrupts_to_host(dev_priv);
+   /* Loading 

[Intel-gfx] [PATCH v4 2/3] drm/i915/guc: always reset GuC before loading firmware

[Dave Gordon]

After a suspend-resume cycle, the resumed kernel has no idea what the
booted kernel may have done to the GuC before replacing itself with the
resumed image. In particular, it may have already loaded the GuC with
firmware, which will then cause this kernel's attempt to (re)load the
firmware to fail (GuC program memory is write-once!). The symptoms
(GuC firmware reload fails after hibernation) are further described
in the Bugzilla reference below.

So let's *always* reset the GuC just before (re)loading the firmware;
the hardware should then be in a well-known state, and we may even
avoid some of the issues arising from unpredictable timing.

Also added some more fields & values to the definition of the GUC_STATUS
register, which is the key diagnostic indicator if the GuC load fails.

Signed-off-by: Dave Gordon 
Reviewed-by: Arun Siluvery 
Cc: Alex Dai 
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=94390

---
 drivers/gpu/drm/i915/i915_guc_reg.h | 12 --
 drivers/gpu/drm/i915/intel_guc_loader.c | 40 -
 2 files changed, 29 insertions(+), 23 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_guc_reg.h 
b/drivers/gpu/drm/i915/i915_guc_reg.h
index 94ceee5..80786d9 100644
--- a/drivers/gpu/drm/i915/i915_guc_reg.h
+++ b/drivers/gpu/drm/i915/i915_guc_reg.h
@@ -27,10 +27,12 @@
 /* Definitions of GuC H/W registers, bits, etc */
 
 #define GUC_STATUS _MMIO(0xc000)
-#define   GS_MIA_IN_RESET  (1 << 0)
+#define   GS_RESET_SHIFT   0
+#define   GS_MIA_IN_RESET(0x01 << GS_RESET_SHIFT)
 #define   GS_BOOTROM_SHIFT 1
 #define   GS_BOOTROM_MASK(0x7F << GS_BOOTROM_SHIFT)
 #define   GS_BOOTROM_RSA_FAILED  (0x50 << GS_BOOTROM_SHIFT)
+#define   GS_BOOTROM_JUMP_PASSED (0x76 << GS_BOOTROM_SHIFT)
 #define   GS_UKERNEL_SHIFT 8
 #define   GS_UKERNEL_MASK(0xFF << GS_UKERNEL_SHIFT)
 #define   GS_UKERNEL_LAPIC_DONE  (0x30 << GS_UKERNEL_SHIFT)
@@ -38,7 +40,13 @@
 #define   GS_UKERNEL_READY   (0xF0 << GS_UKERNEL_SHIFT)
 #define   GS_MIA_SHIFT 16
 #define   GS_MIA_MASK(0x07 << GS_MIA_SHIFT)
-#define   GS_MIA_CORE_STATE  (1 << GS_MIA_SHIFT)
+#define   GS_MIA_CORE_STATE  (0x01 << GS_MIA_SHIFT)
+#define   GS_MIA_HALT_REQUESTED  (0x02 << GS_MIA_SHIFT)
+#define   GS_MIA_ISR_ENTRY   (0x04 << GS_MIA_SHIFT)
+#define   GS_AUTH_STATUS_SHIFT 30
+#define   GS_AUTH_STATUS_MASK(0x03 << GS_AUTH_STATUS_SHIFT)
+#define   GS_AUTH_STATUS_BAD (0x01 << GS_AUTH_STATUS_SHIFT)
+#define   GS_AUTH_STATUS_GOOD(0x02 << GS_AUTH_STATUS_SHIFT)
 
 #define SOFT_SCRATCH(n)_MMIO(0xc180 + (n) * 4)
 #define SOFT_SCRATCH_COUNT 16
diff --git a/drivers/gpu/drm/i915/intel_guc_loader.c 
b/drivers/gpu/drm/i915/intel_guc_loader.c
index d84c560..876e5da 100644
--- a/drivers/gpu/drm/i915/intel_guc_loader.c
+++ b/drivers/gpu/drm/i915/intel_guc_loader.c
@@ -387,7 +387,7 @@ int intel_guc_ucode_load(struct drm_device *dev)
 {
struct drm_i915_private *dev_priv = dev->dev_private;
struct intel_guc_fw *guc_fw = _priv->guc.guc_fw;
-   int err = 0;
+   int retries, err = 0;
 
if (!i915.enable_guc_submission)
return 0;
@@ -441,29 +441,26 @@ int intel_guc_ucode_load(struct drm_device *dev)
 * steppings also so this is extended as well.
 */
/* WaEnableGuCBootHashCheckNotSet:skl,bxt */
-   err = guc_ucode_xfer(dev_priv);
-   if (err) {
-   int retries = 3;
-
-   DRM_ERROR("GuC fw load failed, err=%d, attempting reset and 
retry\n", err);
-
-   while (retries--) {
-   err = i915_reset_guc(dev_priv);
-   if (err)
-   break;
-
-   err = guc_ucode_xfer(dev_priv);
-   if (!err) {
-   DRM_DEBUG_DRIVER("GuC fw reload succeeded after 
reset\n");
-   break;
-   }
-   DRM_DEBUG_DRIVER("GuC fw reload retries left: %d\n", 
retries);
-   }
-
+   for (retries = 3; ; ) {
+   /*
+* Always reset the GuC just before (re)loading, so
+* that the state and timing are fairly predictable
+*/
+   err = i915_reset_guc(dev_priv);
if (err) {
-   DRM_ERROR("GuC fw reload attempt failed, ret=%d\n", 
err);
+   DRM_ERROR("GuC reset failed, err %d\n", err);
goto fail;
}
+
+   err = guc_ucode_xfer(dev_priv);
+   if (!err)
+   break;
+
+  

[Intel-gfx] [PATCH v4 0/3] GuC reset-and-retry patches (resend)

[Dave Gordon]

This is a resend, primarily for CI purposes. All patches to be
merged have already been reviewed. The final patch (NOT to be
merged) enables GuC loading and submission for testing purposes.

Arun Siluvery (1):
  drm/i915/guc: reset GuC and retry on firmware load failure

Dave Gordon (2):
  drm/i915/guc: always reset GuC before loading firmware
  drm/i915: add enable_guc_loading parameter

 drivers/gpu/drm/i915/i915_drv.h |   1 +
 drivers/gpu/drm/i915/i915_gem.c |   1 -
 drivers/gpu/drm/i915/i915_guc_reg.h |  11 ++-
 drivers/gpu/drm/i915/i915_params.c  |  14 ++-
 drivers/gpu/drm/i915/i915_params.h  |   3 +-
 drivers/gpu/drm/i915/i915_reg.h |   1 +
 drivers/gpu/drm/i915/intel_guc_loader.c | 147 ++--
 drivers/gpu/drm/i915/intel_uncore.c |  19 +
 8 files changed, 144 insertions(+), 53 deletions(-)

-- 
1.9.1

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v2 9/9] drm/i915/bxt: add bxt dsi gpio element support

[Ville Syrjälä]

On Fri, Mar 18, 2016 at 01:11:17PM +0200, Jani Nikula wrote:
> Use a table similar to vlv to check for accepted gpio indexes. For now,
> add all, but this list should be trimmed down. Use managed gpio request,
> which will be automatically released when the driver is detached.
> 
> Signed-off-by: Jani Nikula 
> ---
>  drivers/gpu/drm/i915/intel_dsi_panel_vbt.c | 667 
> -
>  1 file changed, 666 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c 
> b/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
> index f8d3f608e9c8..6b8dc15f3656 100644
> --- a/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
> +++ b/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
> @@ -29,6 +29,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -114,6 +115,636 @@ static struct vlv_gpio_map vlv_gpio_table[] = {
>  #define CHV_GPIO_CFG_HIZ 0x8100
>  #define CHV_GPIO_CFG_TX_STATE_SHIFT  1
>  
> +#define BXT_HV_DDI0_DDC_SDA_PIN  187
> +#define BXT_HV_DDI0_DDC_SCL_PIN  188
> +#define BXT_HV_DDI1_DDC_SDA_PIN  189
> +#define BXT_HV_DDI1_DDC_SCL_PIN  190

More magic numbers without explanation. This also suffers from the same
problem that the i2c seq patch has, as in requesting/frobbing random
gpios. We should really use the consumer gpio consumer API I think to
make sure we get the right thing.

> +#define BXT_DBI_SDA_PIN  191
> +#define BXT_DBI_SCL_PIN  192
> +#define BXT_PANEL0_VDDEN_PIN 193
> +#define BXT_PANEL0_BKLTEN_PIN194
> +#define BXT_PANEL0_BKLTCTL_PIN   195
> +#define BXT_PANEL1_VDDEN_PIN 196
> +#define BXT_PANEL1_BKLTEN_PIN197
> +#define BXT_PANEL1_BKLTCTL_PIN   198
> +#define BXT_DBI_CSX_PIN  199
> +#define BXT_DBI_RESX_PIN 200
> +#define BXT_GP_INTD_DSI_TE1_PIN  201
> +#define BXT_GP_INTD_DSI_TE2_PIN  202
> +#define BXT_USB_OC0_B_PIN203
> +#define BXT_USB_OC1_B_PIN204
> +#define BXT_MEX_WAKE0_B_PIN  205
> +#define BXT_MEX_WAKE1_B_PIN  206
> +#define BXT_EMMC0_CLK_PIN156
> +#define BXT_EMMC0_D0_PIN 157
> +#define BXT_EMMC0_D1_PIN 158
> +#define BXT_EMMC0_D2_PIN 159
> +#define BXT_EMMC0_D3_PIN 160
> +#define BXT_EMMC0_D4_PIN 161
> +#define BXT_EMMC0_D5_PIN 162
> +#define BXT_EMMC0_D6_PIN 163
> +#define BXT_EMMC0_D7_PIN 164
> +#define BXT_EMMC0_CMD_PIN165
> +#define BXT_SDIO_CLK_PIN 166
> +#define BXT_SDIO_D0_PIN  167
> +#define BXT_SDIO_D1_PIN  168
> +#define BXT_SDIO_D2_PIN  169
> +#define BXT_SDIO_D3_PIN  170
> +#define BXT_SDIO_CMD_PIN 171
> +#define BXT_SDCARD_CLK_PIN   172
> +#define BXT_SDCARD_D0_PIN173
> +#define BXT_SDCARD_D1_PIN174
> +#define BXT_SDCARD_D2_PIN175
> +#define BXT_SDCARD_D3_PIN176
> +#define BXT_SDCARD_CD_B_PIN  177
> +#define BXT_SDCARD_CMD_PIN   178
> +#define BXT_SDCARD_LVL_CLK_FB_PIN179
> +#define BXT_SDCARD_LVL_CMD_DIR_PIN   180
> +#define BXT_SDCARD_LVL_DAT_DIR_PIN   181
> +#define BXT_EMMC0_STROBE_PIN 182
> +#define BXT_SDIO_PWR_DOWN_B_PIN  183
> +#define BXT_SDCARD_PWR_DOWN_B_PIN184
> +#define BXT_SDCARD_LVL_SEL_PIN   185
> +#define BXT_SDCARD_LVL_WP_PIN186
> +#define BXT_LPSS_I2C0_SDA_PIN124
> +#define BXT_LPSS_I2C0_SCL_PIN125
> +#define BXT_LPSS_I2C1_SDA_PIN126
> +#define BXT_LPSS_I2C1_SCL_PIN127
> +#define BXT_LPSS_I2C2_SDA_PIN128
> +#define BXT_LPSS_I2C2_SCL_PIN129
> +#define BXT_LPSS_I2C3_SDA_PIN130
> +#define BXT_LPSS_I2C3_SCL_PIN131
> +#define BXT_LPSS_I2C4_SDA_PIN132
> +#define BXT_LPSS_I2C4_SCL_PIN133
> +#define BXT_LPSS_I2C5_SDA_PIN134
> +#define BXT_LPSS_I2C5_SCL_PIN135
> +#define BXT_LPSS_I2C6_SDA_PIN136
> +#define BXT_LPSS_I2C6_SCL_PIN137
> +#define BXT_LPSS_I2C7_SDA_PIN138
> +#define BXT_LPSS_I2C7_SCL_PIN139
> +#define BXT_ISH_I2C0_SDA_PIN 140
> +#define BXT_ISH_I2C0_SCL_PIN 141
> +#define BXT_ISH_I2C1_SDA_PIN 142
> +#define BXT_ISH_I2C1_SCL_PIN 143
> +#define BXT_ISH_I2C2_SDA_PIN 144
> +#define BXT_ISH_I2C2_SCL_PIN 145
> +#define BXT_ISH_GPIO_0_PIN   146
> +#define BXT_ISH_GPIO_1_PIN   147
> +#define BXT_ISH_GPIO_2_PIN   148
> +#define BXT_ISH_GPIO_3_PIN   149
> +#define BXT_ISH_GPIO_4_PIN   150
> +#define 

Re: [Intel-gfx] [PATCH v2 7/9] drm/i915/chv: add more IOSF port definitions

[Ville Syrjälä]

On Fri, Mar 18, 2016 at 01:11:15PM +0200, Jani Nikula wrote:
> Signed-off-by: Jani Nikula 

Reviewed-by: Ville Syrjälä 

> ---
>  drivers/gpu/drm/i915/i915_reg.h | 4 
>  1 file changed, 4 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 07e04495cd9a..6e36c0d51023 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -623,6 +623,10 @@ static inline bool i915_mmio_reg_valid(i915_reg_t reg)
>  #define   IOSF_PORT_GPIO_SC  0x48
>  #define   IOSF_PORT_GPIO_SUS 0xa8
>  #define   IOSF_PORT_CCU  0xa9
> +#define   CHV_IOSF_PORT_GPIO_N   0x13
> +#define   CHV_IOSF_PORT_GPIO_SE  0x48
> +#define   CHV_IOSF_PORT_GPIO_E   0xa8
> +#define   CHV_IOSF_PORT_GPIO_SW  0xb2
>  #define VLV_IOSF_DATA_MMIO(VLV_DISPLAY_BASE 
> + 0x2104)
>  #define VLV_IOSF_ADDR_MMIO(VLV_DISPLAY_BASE 
> + 0x2108)
>  
> -- 
> 2.1.4

-- 
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 v2 4/9] drm/i915/dsi: add gpio indexes to the gpio table

[Ville Syrjälä]

On Fri, Mar 18, 2016 at 01:11:12PM +0200, Jani Nikula wrote:
> This lets us specify the exact gpios we want to let through, without
> leaving holes in the array.
> 
> Signed-off-by: Jani Nikula 
> ---
>  drivers/gpu/drm/i915/intel_dsi_panel_vbt.c | 54 
> ++
>  1 file changed, 32 insertions(+), 22 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c 
> b/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
> index b04d88e6127b..744368d01ee6 100644
> --- a/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
> +++ b/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
> @@ -75,24 +75,25 @@ static inline struct vbt_panel *to_vbt_panel(struct 
> drm_panel *panel)
>  #define VLV_GPIO_PCONF0(base_offset) (base_offset)
>  #define VLV_GPIO_PAD_VAL(base_offset)((base_offset) + 8)
>  
> -struct gpio_table {
> +struct vlv_gpio_map {
> + u8 gpio_index;

Not really sure what we want to do with this one, since it's not really
used in the series. Based on that I'd drop it for now.

Anyways, u8+u16+bool doesn't pack all that nicely. Putting the bool and
u8 next to each other would be better.

>   u16 base_offset;
>   bool init;
>  };
>  
> -static struct gpio_table vlv_gpio_table[] = {
> - { VLV_GPIO_NC_0_HV_DDI0_HPD },
> - { VLV_GPIO_NC_1_HV_DDI0_DDC_SDA },
> - { VLV_GPIO_NC_2_HV_DDI0_DDC_SCL },
> - { VLV_GPIO_NC_3_PANEL0_VDDEN },
> - { VLV_GPIO_NC_4_PANEL0_BLKEN },
> - { VLV_GPIO_NC_5_PANEL0_BLKCTL },
> - { VLV_GPIO_NC_6_PCONF0 },
> - { VLV_GPIO_NC_7_PCONF0 },
> - { VLV_GPIO_NC_8_PCONF0 },
> - { VLV_GPIO_NC_9_PCONF0 },
> - { VLV_GPIO_NC_10_PCONF0 },
> - { VLV_GPIO_NC_11_PCONF0 },
> +static struct vlv_gpio_map vlv_gpio_table[] = {
> + { 0, VLV_GPIO_NC_0_HV_DDI0_HPD },
> + { 1, VLV_GPIO_NC_1_HV_DDI0_DDC_SDA },
> + { 2, VLV_GPIO_NC_2_HV_DDI0_DDC_SCL },
> + { 3, VLV_GPIO_NC_3_PANEL0_VDDEN },
> + { 4, VLV_GPIO_NC_4_PANEL0_BLKEN },
> + { 5, VLV_GPIO_NC_5_PANEL0_BLKCTL },
> + { 6, VLV_GPIO_NC_6_PCONF0 },
> + { 7, VLV_GPIO_NC_7_PCONF0 },
> + { 8, VLV_GPIO_NC_8_PCONF0 },
> + { 9, VLV_GPIO_NC_9_PCONF0 },
> + { 10, VLV_GPIO_NC_10_PCONF0 },
> + { 11, VLV_GPIO_NC_11_PCONF0 },
>  };
>  
>  static inline enum port intel_dsi_seq_port_to_port(u8 port)
> @@ -194,6 +195,8 @@ static const u8 *mipi_exec_gpio(struct intel_dsi 
> *intel_dsi, const u8 *data)
>   u32 val;
>   struct drm_device *dev = intel_dsi->base.base.dev;
>   struct drm_i915_private *dev_priv = dev->dev_private;
> + struct vlv_gpio_map *map = NULL;
> + int i;
>  
>   if (dev_priv->vbt.dsi.seq_version >= 3)
>   data++;
> @@ -209,13 +212,20 @@ static const u8 *mipi_exec_gpio(struct intel_dsi 
> *intel_dsi, const u8 *data)
>   /* pull up/down */
>   action = *data++ & 1;
>  
> - if (gpio_index >= ARRAY_SIZE(vlv_gpio_table)) {
> - DRM_DEBUG_KMS("unknown gpio index %u\n", gpio_index);
> + if (!IS_VALLEYVIEW(dev_priv)) {
> + DRM_DEBUG_KMS("GPIO element not supported on this platform\n");
>   goto out;
>   }
>  
> - if (!IS_VALLEYVIEW(dev_priv)) {
> - DRM_DEBUG_KMS("GPIO element not supported on this platform\n");
> + for (i = 0; i < ARRAY_SIZE(vlv_gpio_table); i++) {
> + if (gpio_index == vlv_gpio_table[i].gpio_index) {
> + map = _gpio_table[i];
> + break;
> + }
> + }
> +
> + if (!map) {
> + DRM_DEBUG_KMS("invalid gpio index %u\n", gpio_index);
>   goto out;
>   }
>  
> @@ -233,15 +243,15 @@ static const u8 *mipi_exec_gpio(struct intel_dsi 
> *intel_dsi, const u8 *data)
>   }
>   }
>  
> - pconf0 = VLV_GPIO_PCONF0(vlv_gpio_table[gpio_index].base_offset);
> - padval = VLV_GPIO_PAD_VAL(vlv_gpio_table[gpio_index].base_offset);
> + pconf0 = VLV_GPIO_PCONF0(map->base_offset);
> + padval = VLV_GPIO_PAD_VAL(map->base_offset);
>  
>   mutex_lock(_priv->sb_lock);
> - if (!vlv_gpio_table[gpio_index].init) {
> + if (!map->init) {
>   /* program the function */
>   /* FIXME: remove constant below */
>   vlv_iosf_sb_write(dev_priv, port, pconf0, 0x2000CC00);
> - vlv_gpio_table[gpio_index].init = true;
> + map->init = true;
>   }
>  
>   val = 0x4 | action;
> -- 
> 2.1.4

-- 
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 i-g-t] test/gem_mocs_settings: Testing MOCS register settings

[Peter Antoine]

Response inline.

On Mon, 4 Apr 2016, Chris Wilson wrote:


On Mon, Apr 04, 2016 at 02:43:08PM +0100, Peter Antoine wrote:

+static void run_test(int fd, unsigned mode)
+{
+   const int gen = intel_gen(intel_get_drm_devid(fd));
+   const struct intel_execution_engine *e;
+
+   igt_require(gen >= 9);
+
+   test_mocs_values(fd);
+
+   switch(mode) {
+   case NONE:  break;
+   case RESET: igt_force_gpu_reset();  break;
+   case SUSPEND:   igt_system_suspend_autoresume(); break;
+   case HIBERNATE: igt_system_hibernate_autoresume(); break;
+   };
+
+   /*
+* Do render after other engines as older versions of code will
+* cause the RCS context to program the registers and the test
+* becomes invalid
+*/


If you defer fd allocation to here, then that is moot, as we can create
the fd for each test and be sure that the default context is
uninitialised.


Ok, will wrap each test within an fd of it's own.




+   for (e = intel_execution_engines; e->name; e++)
+   if (e->exec_id != I915_EXEC_DEFAULT &&
+   e->exec_id != I915_EXEC_RENDER &&
+   gem_has_ring(fd, e->exec_id | e->flags))
+   test_context_mocs_values(fd, e, true);
+
+   for (e = intel_execution_engines; e->name; e++)
+   if (e->exec_id == I915_EXEC_RENDER &&
+   gem_has_ring(fd, e->exec_id | e->flags)) {
+   test_context_mocs_values(fd, e, true);
+   test_context_mocs_values(fd, e, false);
+   }


As well as checking for creating new contexts after resume, we also need
to check that the register values are preserved across suspend (i.e.
that the register state is being saved back into the context image and
then restored).


Ok, I'll add another test case that does this for the render engine (the 
only one that is effected (at the moment) by context save and resume.


I might as well move the render engine context tests to a new testcase. As 
it is the only engine that uses the context registers.




If we get truly paranoid (and why not?!) then we can create a pair of
contexts, change the register values in one and verify that the second
context is unaffected.


Might as well, can add a test case that dirties the RCS context registers 
and see if they are the same after resume and if a new context is created 
afterwards that it has the correct values.


Peter.



-Chris




--
   Peter Antoine (Android Graphics Driver Software Engineer)
   -
   Intel Corporation (UK) Limited
   Registered No. 1134945 (England)
   Registered Office: Pipers Way, Swindon SN3 1RJ
   VAT No: 860 2173 47
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v2 3/9] drm/i915/dsi: clean up vlv gpio table and definitions

[Ville Syrjälä]

On Fri, Mar 18, 2016 at 01:11:11PM +0200, Jani Nikula wrote:
> Define and store the pad base offset in the array, and reference the
> pconf0 and padval registers through macros. Add VLV prefixes to
> macros. Use spec nomenclature for pconf0 and padval.
> 
> v2: Address Ville's review comments, squash another patch here.
> 
> Signed-off-by: Jani Nikula 
> ---
>  drivers/gpu/drm/i915/intel_dsi_panel_vbt.c | 87 
> ++
>  1 file changed, 39 insertions(+), 48 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c 
> b/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
> index af1a47b5224f..b04d88e6127b 100644
> --- a/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
> +++ b/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
> @@ -58,50 +58,41 @@ static inline struct vbt_panel *to_vbt_panel(struct 
> drm_panel *panel)
>  
>  #define NS_KHZ_RATIO 100
>  
> -#define GPI0_NC_0_HV_DDI0_HPD   0x4130
> -#define GPIO_NC_0_HV_DDI0_PAD   0x4138
> -#define GPIO_NC_1_HV_DDI0_DDC_SDA   0x4120
> -#define GPIO_NC_1_HV_DDI0_DDC_SDA_PAD   0x4128
> -#define GPIO_NC_2_HV_DDI0_DDC_SCL   0x4110
> -#define GPIO_NC_2_HV_DDI0_DDC_SCL_PAD   0x4118
> -#define GPIO_NC_3_PANEL0_VDDEN  0x4140
> -#define GPIO_NC_3_PANEL0_VDDEN_PAD  0x4148
> -#define GPIO_NC_4_PANEL0_BLKEN  0x4150
> -#define GPIO_NC_4_PANEL0_BLKEN_PAD  0x4158
> -#define GPIO_NC_5_PANEL0_BLKCTL 0x4160
> -#define GPIO_NC_5_PANEL0_BLKCTL_PAD 0x4168
> -#define GPIO_NC_6_PCONF00x4180
> -#define GPIO_NC_6_PAD   0x4188
> -#define GPIO_NC_7_PCONF00x4190
> -#define GPIO_NC_7_PAD   0x4198
> -#define GPIO_NC_8_PCONF00x4170
> -#define GPIO_NC_8_PAD   0x4178
> -#define GPIO_NC_9_PCONF00x4100
> -#define GPIO_NC_9_PAD   0x4108
> -#define GPIO_NC_10_PCONF0   0x40E0
> -#define GPIO_NC_10_PAD  0x40E8
> -#define GPIO_NC_11_PCONF0   0x40F0
> -#define GPIO_NC_11_PAD  0x40F8
> +/* base offsets for gpio pads */
> +#define VLV_GPIO_NC_0_HV_DDI0_HPD0x4130
> +#define VLV_GPIO_NC_1_HV_DDI0_DDC_SDA0x4120
> +#define VLV_GPIO_NC_2_HV_DDI0_DDC_SCL0x4110
> +#define VLV_GPIO_NC_3_PANEL0_VDDEN   0x4140
> +#define VLV_GPIO_NC_4_PANEL0_BLKEN   0x4150
> +#define VLV_GPIO_NC_5_PANEL0_BLKCTL  0x4160
> +#define VLV_GPIO_NC_6_PCONF0 0x4180
> +#define VLV_GPIO_NC_7_PCONF0 0x4190
> +#define VLV_GPIO_NC_8_PCONF0 0x4170
> +#define VLV_GPIO_NC_9_PCONF0 0x4100
> +#define VLV_GPIO_NC_10_PCONF00x40E0
> +#define VLV_GPIO_NC_11_PCONF00x40F0

Still looks wonky with those unnamed ones using _PCONF0, and some of the
named ones not matching the spec 100%.

Digging through the spec I came up with this list:

#define VLV_GPIO_NC_0_HV_DDI0_HPD   0x4130
#define VLV_GPIO_NC_1_HV_DDI0_DDC_SDA   0x4120
#define VLV_GPIO_NC_2_HV_DDI0_DDC_SCL   0x4110
#define VLV_GPIO_NC_3_PANEL0_VDDEN  0x4140
#define VLV_GPIO_NC_4_PANEL0_BKLTEN 0x4150
#define VLV_GPIO_NC_5_PANEL0_BKLTCTL0x4160
#define VLV_GPIO_NC_6_HV_DDI1_HPD   0x4180
#define VLV_GPIO_NC_7_HV_DDI1_DDC_SDA   0x4190
#define VLV_GPIO_NC_8_HV_DDI1_DDC_SCL   0x4170
#define VLV_GPIO_NC_9_PANEL1_VDDEN  0x4100
#define VLV_GPIO_NC_10_PANEL1_BKLTEN0x40E0
#define VLV_GPIO_NC_11_PANEL1_BKLTCTL   0x40F0

> +
> +#define VLV_GPIO_PCONF0(base_offset) (base_offset)
> +#define VLV_GPIO_PAD_VAL(base_offset)((base_offset) + 8)
>  
>  struct gpio_table {
> - u16 function_reg;
> - u16 pad_reg;
> - u8 init;
> + u16 base_offset;
> + bool init;
>  };
>  
> -static struct gpio_table gtable[] = {
> - { GPI0_NC_0_HV_DDI0_HPD, GPIO_NC_0_HV_DDI0_PAD, 0 },
> - { GPIO_NC_1_HV_DDI0_DDC_SDA, GPIO_NC_1_HV_DDI0_DDC_SDA_PAD, 0 },
> - { GPIO_NC_2_HV_DDI0_DDC_SCL, GPIO_NC_2_HV_DDI0_DDC_SCL_PAD, 0 },
> - { GPIO_NC_3_PANEL0_VDDEN, GPIO_NC_3_PANEL0_VDDEN_PAD, 0 },
> - { GPIO_NC_4_PANEL0_BLKEN, GPIO_NC_4_PANEL0_BLKEN_PAD, 0 },
> - { GPIO_NC_5_PANEL0_BLKCTL, GPIO_NC_5_PANEL0_BLKCTL_PAD, 0 },
> - { GPIO_NC_6_PCONF0, GPIO_NC_6_PAD, 0 },
> - { GPIO_NC_7_PCONF0, GPIO_NC_7_PAD, 0 },
> - { GPIO_NC_8_PCONF0, GPIO_NC_8_PAD, 0 },
> - { GPIO_NC_9_PCONF0, GPIO_NC_9_PAD, 0 },
> - { GPIO_NC_10_PCONF0, GPIO_NC_10_PAD, 0},
> - { GPIO_NC_11_PCONF0, GPIO_NC_11_PAD, 0}
> +static struct gpio_table vlv_gpio_table[] = {
> + { VLV_GPIO_NC_0_HV_DDI0_HPD },
> + { VLV_GPIO_NC_1_HV_DDI0_DDC_SDA },
> + { VLV_GPIO_NC_2_HV_DDI0_DDC_SCL },
> + { VLV_GPIO_NC_3_PANEL0_VDDEN },
> + { VLV_GPIO_NC_4_PANEL0_BLKEN },
> + { VLV_GPIO_NC_5_PANEL0_BLKCTL },
> + { VLV_GPIO_NC_6_PCONF0 },
> + { VLV_GPIO_NC_7_PCONF0 },
> + { VLV_GPIO_NC_8_PCONF0 },
> + { VLV_GPIO_NC_9_PCONF0 },
> + { VLV_GPIO_NC_10_PCONF0 },
> + { VLV_GPIO_NC_11_PCONF0 },
>  };
>  
>  

[Intel-gfx] [PATCH 3/3] drm/i915: Do not serialize forcewake acquire across domains

[Tvrtko Ursulin]

From: Tvrtko Ursulin 

On platforms with multiple forcewake domains it seems more efficient
to request all desired ones and then to wait for acks to avoid
needlessly serializing on each domain.

Signed-off-by: Tvrtko Ursulin 
---
 drivers/gpu/drm/i915/intel_uncore.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_uncore.c 
b/drivers/gpu/drm/i915/intel_uncore.c
index 49edd641b434..03674c3cfaf7 100644
--- a/drivers/gpu/drm/i915/intel_uncore.c
+++ b/drivers/gpu/drm/i915/intel_uncore.c
@@ -115,8 +115,10 @@ fw_domains_get(struct drm_i915_private *dev_priv, enum 
forcewake_domains fw_doma
for_each_fw_domain_mask(d, fw_domains, dev_priv) {
fw_domain_wait_ack_clear(d);
fw_domain_get(d);
-   fw_domain_wait_ack(d);
}
+
+   for_each_fw_domain_mask(d, fw_domains, dev_priv)
+   fw_domain_wait_ack(d);
 }
 
 static void
-- 
1.9.1

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 2/3] drm/i915: Simplify for_each_fw_domain iterators

[Tvrtko Ursulin]

From: Tvrtko Ursulin 

As the vast majority of users does not use the domain id variable,
we can eliminate it from the iterator and also change the latter
using the same principle as was recently done for for_each_engine.

For a couple of callers which do need the domain id, or the domain
mask, store the later in the domain itself at init time and use
both through it.

Result is clearer code and smaller generated binary, especially
in the tight fw get/put loops. Also, relationship between domain
id and mask is no longer assumed in the macro.

Signed-off-by: Tvrtko Ursulin 
---
 drivers/gpu/drm/i915/i915_debugfs.c |  5 ++---
 drivers/gpu/drm/i915/i915_drv.h | 17 +++---
 drivers/gpu/drm/i915/intel_uncore.c | 45 +
 3 files changed, 32 insertions(+), 35 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index a2e3af02c292..06fce014d0b4 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -1464,12 +1464,11 @@ static int i915_forcewake_domains(struct seq_file *m, 
void *data)
struct drm_device *dev = node->minor->dev;
struct drm_i915_private *dev_priv = dev->dev_private;
struct intel_uncore_forcewake_domain *fw_domain;
-   int i;
 
spin_lock_irq(_priv->uncore.lock);
-   for_each_fw_domain(fw_domain, dev_priv, i) {
+   for_each_fw_domain(fw_domain, dev_priv) {
seq_printf(m, "%s.wake_count = %u\n",
-  intel_uncore_forcewake_domain_to_str(i),
+  intel_uncore_forcewake_domain_to_str(fw_domain->id),
   fw_domain->wake_count);
}
spin_unlock_irq(_priv->uncore.lock);
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 7d4c704d7d75..160f980f0368 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -665,6 +665,7 @@ struct intel_uncore {
struct intel_uncore_forcewake_domain {
struct drm_i915_private *i915;
enum forcewake_domain_id id;
+   enum forcewake_domains mask;
unsigned wake_count;
struct hrtimer timer;
i915_reg_t reg_set;
@@ -679,14 +680,14 @@ struct intel_uncore {
 };
 
 /* Iterate over initialised fw domains */
-#define for_each_fw_domain_mask(domain__, mask__, dev_priv__, i__) \
-   for ((i__) = 0, (domain__) = &(dev_priv__)->uncore.fw_domain[0]; \
-(i__) < FW_DOMAIN_ID_COUNT; \
-(i__)++, (domain__) = &(dev_priv__)->uncore.fw_domain[i__]) \
-   for_each_if (((mask__) & (dev_priv__)->uncore.fw_domains) & (1 
<< (i__)))
-
-#define for_each_fw_domain(domain__, dev_priv__, i__) \
-   for_each_fw_domain_mask(domain__, FORCEWAKE_ALL, dev_priv__, i__)
+#define for_each_fw_domain_mask(domain__, mask__, dev_priv__) \
+   for ((domain__) = &(dev_priv__)->uncore.fw_domain[0]; \
+(domain__) < &(dev_priv__)->uncore.fw_domain[FW_DOMAIN_ID_COUNT]; \
+(domain__)++) \
+   for_each_if ((mask__) & (domain__)->mask)
+
+#define for_each_fw_domain(domain__, dev_priv__) \
+   for_each_fw_domain_mask(domain__, FORCEWAKE_ALL, dev_priv__)
 
 #define CSR_VERSION(major, minor)  ((major) << 16 | (minor))
 #define CSR_VERSION_MAJOR(version) ((version) >> 16)
diff --git a/drivers/gpu/drm/i915/intel_uncore.c 
b/drivers/gpu/drm/i915/intel_uncore.c
index 76ac990de354..49edd641b434 100644
--- a/drivers/gpu/drm/i915/intel_uncore.c
+++ b/drivers/gpu/drm/i915/intel_uncore.c
@@ -111,9 +111,8 @@ static void
 fw_domains_get(struct drm_i915_private *dev_priv, enum forcewake_domains 
fw_domains)
 {
struct intel_uncore_forcewake_domain *d;
-   enum forcewake_domain_id id;
 
-   for_each_fw_domain_mask(d, fw_domains, dev_priv, id) {
+   for_each_fw_domain_mask(d, fw_domains, dev_priv) {
fw_domain_wait_ack_clear(d);
fw_domain_get(d);
fw_domain_wait_ack(d);
@@ -124,9 +123,8 @@ static void
 fw_domains_put(struct drm_i915_private *dev_priv, enum forcewake_domains 
fw_domains)
 {
struct intel_uncore_forcewake_domain *d;
-   enum forcewake_domain_id id;
 
-   for_each_fw_domain_mask(d, fw_domains, dev_priv, id) {
+   for_each_fw_domain_mask(d, fw_domains, dev_priv) {
fw_domain_put(d);
fw_domain_posting_read(d);
}
@@ -136,10 +134,9 @@ static void
 fw_domains_posting_read(struct drm_i915_private *dev_priv)
 {
struct intel_uncore_forcewake_domain *d;
-   enum forcewake_domain_id id;
 
/* No need to do for all, just do for first found */
-   for_each_fw_domain(d, dev_priv, id) {
+   for_each_fw_domain(d, dev_priv) {
fw_domain_posting_read(d);
break;
}
@@ -149,12 +146,11 @@ static 

[Intel-gfx] [PATCH 1/3] drm/i915: Use consistent forcewake auto-release timeout across kernel configs

[Tvrtko Ursulin]

From: Tvrtko Ursulin 

Current implementation releases the forcewake at any time between
straight away, and one jiffie from the last put, or first automatic
grab.

This does not sound like what was desired since jiffies are typically
between 1 and 10ms depending on the kernel configuration.

Change the auto-release mechanism to use hrtimers and set the timeout
to 1ms with a 1ms of slack. This should make the GPU power consistent
across kernel configs and the slack should enable some timer coallescing
where multiple force-wake domains exist, or with unrelated timers.

For GlBench/T-Rex this decreases the number of forcewake releases from
~480 to ~300 per second, and for a heavy combined OGL/OCL test from
~670 to ~360.

Signed-off-by: Tvrtko Ursulin 
---
 drivers/gpu/drm/i915/i915_drv.h |  2 +-
 drivers/gpu/drm/i915/intel_uncore.c | 25 -
 2 files changed, 17 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index dd187727c813..7d4c704d7d75 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -666,7 +666,7 @@ struct intel_uncore {
struct drm_i915_private *i915;
enum forcewake_domain_id id;
unsigned wake_count;
-   struct timer_list timer;
+   struct hrtimer timer;
i915_reg_t reg_set;
u32 val_set;
u32 val_clear;
diff --git a/drivers/gpu/drm/i915/intel_uncore.c 
b/drivers/gpu/drm/i915/intel_uncore.c
index ac1c545436af..76ac990de354 100644
--- a/drivers/gpu/drm/i915/intel_uncore.c
+++ b/drivers/gpu/drm/i915/intel_uncore.c
@@ -60,7 +60,11 @@ fw_domain_reset(const struct intel_uncore_forcewake_domain 
*d)
 static inline void
 fw_domain_arm_timer(struct intel_uncore_forcewake_domain *d)
 {
-   mod_timer_pinned(>timer, jiffies + 1);
+   d->wake_count++;
+   hrtimer_start_range_ns(>timer,
+  ktime_set(0, NSEC_PER_MSEC),
+  NSEC_PER_MSEC,
+  HRTIMER_MODE_REL);
 }
 
 static inline void
@@ -224,9 +228,11 @@ static int __gen6_gt_wait_for_fifo(struct drm_i915_private 
*dev_priv)
return ret;
 }
 
-static void intel_uncore_fw_release_timer(unsigned long arg)
+static enum hrtimer_restart
+intel_uncore_fw_release_timer(struct hrtimer *timer)
 {
-   struct intel_uncore_forcewake_domain *domain = (void *)arg;
+   struct intel_uncore_forcewake_domain *domain =
+  container_of(timer, struct intel_uncore_forcewake_domain, timer);
unsigned long irqflags;
 
assert_rpm_device_not_suspended(domain->i915);
@@ -240,6 +246,8 @@ static void intel_uncore_fw_release_timer(unsigned long arg)
  1 << domain->id);
 
spin_unlock_irqrestore(>i915->uncore.lock, irqflags);
+
+   return HRTIMER_NORESTART;
 }
 
 void intel_uncore_forcewake_reset(struct drm_device *dev, bool restore)
@@ -259,16 +267,16 @@ void intel_uncore_forcewake_reset(struct drm_device *dev, 
bool restore)
active_domains = 0;
 
for_each_fw_domain(domain, dev_priv, id) {
-   if (del_timer_sync(>timer) == 0)
+   if (hrtimer_cancel(>timer) == 0)
continue;
 
-   intel_uncore_fw_release_timer((unsigned long)domain);
+   intel_uncore_fw_release_timer(>timer);
}
 
spin_lock_irqsave(_priv->uncore.lock, irqflags);
 
for_each_fw_domain(domain, dev_priv, id) {
-   if (timer_pending(>timer))
+   if (hrtimer_active(>timer))
active_domains |= (1 << id);
}
 
@@ -491,7 +499,6 @@ static void __intel_uncore_forcewake_put(struct 
drm_i915_private *dev_priv,
if (--domain->wake_count)
continue;
 
-   domain->wake_count++;
fw_domain_arm_timer(domain);
}
 }
@@ -732,7 +739,6 @@ static inline void __force_wake_auto(struct 
drm_i915_private *dev_priv,
continue;
}
 
-   domain->wake_count++;
fw_domain_arm_timer(domain);
}
 
@@ -1150,7 +1156,8 @@ static void fw_domain_init(struct drm_i915_private 
*dev_priv,
d->i915 = dev_priv;
d->id = domain_id;
 
-   setup_timer(>timer, intel_uncore_fw_release_timer, (unsigned long)d);
+   hrtimer_init(>timer, CLOCK_MONOTONIC, HRTIMER_MODE_REL);
+   d->timer.function = intel_uncore_fw_release_timer;
 
dev_priv->uncore.fw_domains |= (1 << domain_id);
 
-- 
1.9.1

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v2 2/9] drm/i915/dsi: add support for DSI sequence block v2 gpio element

[Ville Syrjälä]

On Fri, Mar 18, 2016 at 01:11:10PM +0200, Jani Nikula wrote:
> In sequence block v2, and only in v2, the gpio source (i.e. IOSF port)
> is specified separately.
> 
> v2: initialize gpio_source to 0 and handle v1 and v2 in the same branch
> 
> Signed-off-by: Jani Nikula 

Reviewed-by: Ville Syrjälä 

> ---
>  drivers/gpu/drm/i915/intel_dsi_panel_vbt.c | 22 ++
>  1 file changed, 18 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c 
> b/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
> index f687b2e9d8ca..af1a47b5224f 100644
> --- a/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
> +++ b/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
> @@ -198,7 +198,7 @@ static const u8 *mipi_exec_delay(struct intel_dsi 
> *intel_dsi, const u8 *data)
>  
>  static const u8 *mipi_exec_gpio(struct intel_dsi *intel_dsi, const u8 *data)
>  {
> - u8 gpio_index, action;
> + u8 gpio_source, gpio_index, action, port;
>   u16 function, pad;
>   u32 val;
>   struct drm_device *dev = intel_dsi->base.base.dev;
> @@ -209,6 +209,12 @@ static const u8 *mipi_exec_gpio(struct intel_dsi 
> *intel_dsi, const u8 *data)
>  
>   gpio_index = *data++;
>  
> + /* gpio source in sequence v2 only */
> + if (dev_priv->vbt.dsi.seq_version == 2)
> + gpio_source = (*data >> 1) & 3;
> + else
> + gpio_source = 0;
> +
>   /* pull up/down */
>   action = *data++ & 1;
>  
> @@ -225,6 +231,15 @@ static const u8 *mipi_exec_gpio(struct intel_dsi 
> *intel_dsi, const u8 *data)
>   if (dev_priv->vbt.dsi.seq_version >= 3) {
>   DRM_DEBUG_KMS("GPIO element v3 not supported\n");
>   goto out;
> + } else {
> + if (gpio_source == 0) {
> + port = IOSF_PORT_GPIO_NC;
> + } else if (gpio_source == 1) {
> + port = IOSF_PORT_GPIO_SC;
> + } else {
> + DRM_DEBUG_KMS("unknown gpio source %u\n", gpio_source);
> + goto out;
> + }
>   }
>  
>   function = gtable[gpio_index].function_reg;
> @@ -234,15 +249,14 @@ static const u8 *mipi_exec_gpio(struct intel_dsi 
> *intel_dsi, const u8 *data)
>   if (!gtable[gpio_index].init) {
>   /* program the function */
>   /* FIXME: remove constant below */
> - vlv_iosf_sb_write(dev_priv, IOSF_PORT_GPIO_NC, function,
> -   0x2000CC00);
> + vlv_iosf_sb_write(dev_priv, port, function, 0x2000CC00);
>   gtable[gpio_index].init = 1;
>   }
>  
>   val = 0x4 | action;
>  
>   /* pull up/down */
> - vlv_iosf_sb_write(dev_priv, IOSF_PORT_GPIO_NC, pad, val);
> + vlv_iosf_sb_write(dev_priv, port, pad, val);
>   mutex_unlock(_priv->sb_lock);
>  
>  out:
> -- 
> 2.1.4

-- 
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 i-g-t] lib/igt_kms: Fix atomic plane commit when fb_id is 0.

[Ville Syrjälä]

On Mon, Apr 04, 2016 at 06:47:25PM +0300, Marius Vlad wrote:
> igt_atomic_prepare_plane_commit() assumes that the framebuffer is always
> set-up.
> 
> Signed-off-by: Marius Vlad 
> ---
>  lib/igt_kms.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/lib/igt_kms.c b/lib/igt_kms.c
> index 82257a6..30c5b7e 100644
> --- a/lib/igt_kms.c
> +++ b/lib/igt_kms.c
> @@ -1585,7 +1585,7 @@ igt_atomic_prepare_plane_commit(igt_plane_t *plane, 
> igt_output_t *output,
>   igt_atomic_populate_plane_req(req, plane, IGT_PLANE_FB_ID, 
> fb_id);
>   }
>  
> - if (plane->position_changed || plane->size_changed) {
> + if ((plane->position_changed || plane->size_changed) && fb_id != 0) {
>   uint32_t src_x = IGT_FIXED(plane->fb->src_x, 0); /* src_x */
>   uint32_t src_y = IGT_FIXED(plane->fb->src_y, 0); /* src_y */
>   uint32_t src_w = IGT_FIXED(plane->fb->src_w, 0); /* src_w */

Someone should really move the src coordinates from the fb into the plane.

-- 
Ville Syrjälä
Intel OTC
___
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/bxt: Fix/enable display power well support/runtime PM (rev4)

[Patchwork]

== Series Details ==

Series: drm/i915/bxt: Fix/enable display power well support/runtime PM (rev4)
URL   : https://patchwork.freedesktop.org/series/5177/
State : failure

== Summary ==

Series 5177v4 drm/i915/bxt: Fix/enable display power well support/runtime PM
http://patchwork.freedesktop.org/api/1.0/series/5177/revisions/4/mbox/

Test gem_exec_suspend:
Subgroup basic-s3:
pass   -> DMESG-WARN (skl-nuci5)
pass   -> DMESG-WARN (skl-i7k-2)
Test kms_force_connector_basic:
Subgroup force-load-detect:
pass   -> SKIP   (snb-x220t)
Subgroup prune-stale-modes:
skip   -> PASS   (ilk-hp8440p)
Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-a:
pass   -> DMESG-WARN (skl-nuci5)
pass   -> DMESG-WARN (skl-i7k-2)
Subgroup suspend-read-crc-pipe-b:
incomplete -> PASS   (hsw-gt2)
pass   -> DMESG-WARN (skl-nuci5)
pass   -> DMESG-WARN (skl-i7k-2)
Subgroup suspend-read-crc-pipe-c:
pass   -> DMESG-WARN (skl-nuci5)
pass   -> DMESG-WARN (skl-i7k-2)

bdw-ultratotal:196  pass:175  dwarn:0   dfail:0   fail:0   skip:21 
bsw-nuc-2total:196  pass:159  dwarn:0   dfail:0   fail:0   skip:37 
byt-nuc  total:196  pass:161  dwarn:0   dfail:0   fail:0   skip:35 
hsw-brixbox  total:196  pass:174  dwarn:0   dfail:0   fail:0   skip:22 
hsw-gt2  total:196  pass:179  dwarn:0   dfail:0   fail:0   skip:17 
ilk-hp8440p  total:196  pass:132  dwarn:0   dfail:0   fail:0   skip:64 
ivb-t430stotal:196  pass:171  dwarn:0   dfail:0   fail:0   skip:25 
skl-i7k-2total:196  pass:169  dwarn:4   dfail:0   fail:0   skip:23 
skl-nuci5total:196  pass:181  dwarn:4   dfail:0   fail:0   skip:11 
snb-dellxps  total:196  pass:162  dwarn:0   dfail:0   fail:0   skip:34 
snb-x220ttotal:196  pass:161  dwarn:0   dfail:0   fail:1   skip:34 
BOOT FAILED for bdw-nuci7

Results at /archive/results/CI_IGT_test/Patchwork_1792/

aedfaaef290af9c8df7d9f4adf22cbe21704d091 drm-intel-nightly: 
2016y-04m-04d-13h-09m-54s UTC integration manifest
0856c119319cb46ce75deb40ceb354cfc94a0f3d drm/i915/bxt: Enable runtime PM
c7dc45a16dfd3efb2dcc9faae2713e67bb52f23f Revert "drm/i915/bxt: Disable power 
well support"
50b663dd828817c64ef4f5d4fc2aa9b28c4177e0 drm/i915/bxt: Add HW state 
verification for DDI PHY and CDCLK
85628341a1f806116d6728ac5955221131f6cdcb drm/i915/bxt: Don't reprogram an 
already enabled DDI PHY
a4826afc34198a6384fcaace3924b8aa0c4aeca6 drm/i915/bxt: Sanitize the DBUF HW 
state together with CDCLK
053c5d3774a47ac9d35c93b0efaeef9bdc4bab05 drm/i915/bxt: Don't toggle power well 
1 on-demand
ed38c6615e2e6f45ab8fd18683c4fa0e19ec614f drm/i915/bxt: Power down DDI PHYs 
separately during the per PHY uninit
9c52a0e1eb6caf4315205820d3eed6c82c44fb03 drm/i915/bxt: Pass drm_i915_private to 
DDI PHY, CDCLK helpers
5161e56e9e810ef1fe02f4e8a1b26f577027beff drm/i915/skl: Unexport 
skl_pw1_misc_io_init
b615884026b3c6e5b26769256e41a104ed57e443 drm/i915/bxt: Suspend power domains 
during suspend-to-idle
268e9266500fb8fa163df5e864edefd047006cbd drm/i915/gen9: Fix DMC/DC state asserts
8790850ad164b4b9d64824fa918a34f88ebecf1b drm/i915/gen9: Make power well 
disabling synchronous
a57cdf35ae7c264efec7699d439ab834c6ece96b drm/i915/bxt: Reset secondary power 
well requests left on by DMC/KVMR
5b7b27b56eefe803c55799da91b9aec290d367df drm/i915/bxt: Add a note about 
BXT_PORT_CL1CM_DW30 being read-only
d3bb08086ddbb824e230bbec068b12909e2d5fd9 drm/i915/bxt: Fix GRC code register 
field definitions
d90dbdf335eb4124a7e9c6952c926f32d4496151 drm/i915/bxt: Reject DMC firmware 
versions with known bugs

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH i-g-t] lib/igt_kms: Fix atomic plane commit when fb_id is 0.

[Lionel Landwerlin]

Hi Marius,

Thanks for this. I have the same patch on a branch I haven't send yet 
(oops).


In my patch I implemented this by setting src_* to 0 if fb_id == 0.
I'm not sure what makes more sense but anyway :

Reviewed-by: Lionel Landwerlin 

On 04/04/16 16:47, Marius Vlad wrote:

igt_atomic_prepare_plane_commit() assumes that the framebuffer is always
set-up.

Signed-off-by: Marius Vlad 
---
  lib/igt_kms.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lib/igt_kms.c b/lib/igt_kms.c
index 82257a6..30c5b7e 100644
--- a/lib/igt_kms.c
+++ b/lib/igt_kms.c
@@ -1585,7 +1585,7 @@ igt_atomic_prepare_plane_commit(igt_plane_t *plane, 
igt_output_t *output,
igt_atomic_populate_plane_req(req, plane, IGT_PLANE_FB_ID, 
fb_id);
}
  
-	if (plane->position_changed || plane->size_changed) {

+   if ((plane->position_changed || plane->size_changed) && fb_id != 0) {
uint32_t src_x = IGT_FIXED(plane->fb->src_x, 0); /* src_x */
uint32_t src_y = IGT_FIXED(plane->fb->src_y, 0); /* src_y */
uint32_t src_w = IGT_FIXED(plane->fb->src_w, 0); /* src_w */


___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 2/2] drm/i915/BXT: Tolerance at BXT DSI pipe_config comparison

[Ramalingam C]

On Thursday 31 March 2016 12:34 AM, Daniel Vetter wrote:

On Wed, Mar 30, 2016 at 07:49:40PM +0530, Ramalingam C wrote:

On Wednesday 30 March 2016 05:02 PM, Daniel Vetter wrote:

On Tue, Mar 29, 2016 at 11:04:51PM +0530, Ramalingam C wrote:

At BXT DSI, PIPE registers are inactive. So we can't get the
PIPE's mode parameters from them. The possible option is
retriving them from the PORT registers. But mode timing
parameters are progammed to port registers interms of byteclocks.

The formula used to convert the pixels interms of byteclk is
DIV_ROUND_UP(DIV_ROUND_UP(pixels * bpp * burst_mode_ratio,
8 * 100), lane_count);

So we retrieve them, interms of pixels as
DIV_ROUND_UP((clk_hs * lane_count * 8 * 100),
(bpp * burst_mode_ratio));

Due to the multiple DIV_ROUND_UP in both formulas we get the worst
case delta in the retrieved PIPE's timing parameter as below
DIV_ROUND_UP((8 * intel_dsi->lane_count * 100),
(dsi_pixel_format_bpp(intel_dsi->pixel_format) *
intel_dsi->burst_mode_ratio)))

This converson of byteclk to pixel is required for hsync, hfp and hbp.
Which intern impacts horrizontal timing parameters. At worst case to
get htotal all there parameters are added with hactive.
Hence delta will be 3 times of above formula. Hence this value is
considered as tolerance for pipe_config comparison, in case of BXT DSI.

Signed-off-by: Ramalingam C 

This is the wrong way round imo, better would be to adjust the adjusted
mode in the bxt dsi compute_config function to match the hw granularity.
Stuff _really_ should match exactly, the fuzzy clock matching is mostly
because our clock cod is a mess, and we can't/don't properly
forward-compuate the actual clock timings we program into the hardware.
-Daniel

Daniel, I got your point. But the problem will be that difficulty(even if
possible) in adjusting the adjusted mode parameters.
Reason is we are not programing the mode parameter as such. We will derive
the hfp, hsync and hbp from
hsync_start, hsync_end, hdisplay and htotal. These will be adjusted(divided
by 2) for dual link scenario.
And then resultant will go into the conversion as mentioned in the commit
message (two DIV_ROUND_UP onwards
and one DIV_ROUND_UP backwards). For this we have to make the parameter
divisible by three different factors.
So IMHO, even if this is possible, it will look more messy.

Predicting the max error and tolerating it in pipe_config_compare will be
the straight forward and more reasonable.
Please let me know if i can go ahead in this approach.

Yeah I discussed this some more with Jani on irc. I'd say we should store
this adjusted horizontal timings (the ones fudged with burst_mode_ratio,
lane_count, dual-link and all these things applied) into
crtc_state->base.adjusted_mode. And then ofc also read those values out.

The overall idea of the state verify/compare logic is that we start out
with requested state from userspace, then derive the real hw state. And
then compare that computed hw state with what's there already. Except for
clocks, where there's special reasons, we never go back, since going back
requires us to apply a range. This is the only way to guarnatee that "hw
has the same exact mode programmed in both cases" iff "intel_crtc_state
matches per intel_crtc_config_compare".

state->adjusted_mode is never exposed to userspace, so there's no problem
if it's has "strange" values. And we already have pipe_src_h/w to express
the logical input rectangle.

The idea is similar to how we set adjusted_mode.flags to what we actually
program, instead of trying to make something up that's not perfectly
accurate.
-Daniel

Daniel,

I have tested by adjusting the adjusted_mode in set_dsi_timings() 
instead of intel_dsi_compute_config().
Reason is if we modify the adjusted mode at intel_dsi_compute_config() 
itself, then modified value will
be taken as input for set_dsi_timings. Hence the get_config will deviate 
further. I hope this should be fine with you and Jani.


This will work out, if set_dsi_timings() is called after the 
dsi_compute_config() on every suspend and resume or modeset.

I will verify this on Android once and update.

Please share your view on this, so that can update the patch with 
corresponding changes.



---
Reviewed at 
https://lists.freedesktop.org/archives/intel-gfx/2016-March/089548.html

  drivers/gpu/drm/i915/intel_display.c |   62 +++---
  1 file changed, 57 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index c0627d6..282f036 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -12557,6 +12557,9 @@ intel_pipe_config_compare(struct drm_device *dev,
  bool adjust)
  {
bool ret = true;
+   struct intel_crtc 

[Intel-gfx] [PATCH i-g-t] lib/igt_kms: Fix atomic plane commit when fb_id is 0.

[Marius Vlad]

igt_atomic_prepare_plane_commit() assumes that the framebuffer is always
set-up.

Signed-off-by: Marius Vlad 
---
 lib/igt_kms.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lib/igt_kms.c b/lib/igt_kms.c
index 82257a6..30c5b7e 100644
--- a/lib/igt_kms.c
+++ b/lib/igt_kms.c
@@ -1585,7 +1585,7 @@ igt_atomic_prepare_plane_commit(igt_plane_t *plane, 
igt_output_t *output,
igt_atomic_populate_plane_req(req, plane, IGT_PLANE_FB_ID, 
fb_id);
}
 
-   if (plane->position_changed || plane->size_changed) {
+   if ((plane->position_changed || plane->size_changed) && fb_id != 0) {
uint32_t src_x = IGT_FIXED(plane->fb->src_x, 0); /* src_x */
uint32_t src_y = IGT_FIXED(plane->fb->src_y, 0); /* src_y */
uint32_t src_w = IGT_FIXED(plane->fb->src_w, 0); /* src_w */
-- 
2.5.0

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v5 36/46] input: misc: max77693: switch to the atomic API

[Thierry Reding]

On Thu, Mar 31, 2016 at 08:57:18PM +0200, Boris Brezillon wrote:
> On Thu, 31 Mar 2016 10:48:01 -0700
> Dmitry Torokhov  wrote:
> 
> > Hi Boris,
> > 
> > On Wed, Mar 30, 2016 at 10:03:59PM +0200, Boris Brezillon wrote:
> > > pwm_config/enable/disable() have been deprecated and should be replaced
> > > by pwm_apply_state().
> > > 
> > > Signed-off-by: Boris Brezillon 
> > > ---
> > >  drivers/input/misc/max77693-haptic.c | 23 +--
> > >  1 file changed, 17 insertions(+), 6 deletions(-)
> > > 
> > > diff --git a/drivers/input/misc/max77693-haptic.c 
> > > b/drivers/input/misc/max77693-haptic.c
> > > index cf6aac0..aef7dc4 100644
> > > --- a/drivers/input/misc/max77693-haptic.c
> > > +++ b/drivers/input/misc/max77693-haptic.c
> > > @@ -70,13 +70,16 @@ struct max77693_haptic {
> > >  
> > >  static int max77693_haptic_set_duty_cycle(struct max77693_haptic *haptic)
> > >  {
> > > + struct pwm_state pstate;
> > >   struct pwm_args pargs = { };
> > > - int delta;
> > >   int error;
> > >  
> > >   pwm_get_args(haptic->pwm_dev, );
> > > - delta = (pargs.period + haptic->pwm_duty) / 2;
> > > - error = pwm_config(haptic->pwm_dev, delta, pargs.period);
> > > + pwm_get_state(haptic->pwm_dev, );
> > > +
> > > + pstate.period = pargs.period;
> > > + pstate.duty_cycle = (pargs.period + haptic->pwm_duty) / 2;
> > > + error = pwm_apply_state(haptic->pwm_dev, );
> > 
> > This does not make sense with regard to the atomic API. If you look in
> > max77693_haptic_play_work(), right after calling
> > max77693_haptic_set_duty_cycle() we either try to enable or disable the
> > pwm. When switching to this new API we should combine both actions.
> 
> True. I'll address that, unless Thierry is fine keeping the non-atomic
> API, in which case I'll just drop patches 32 to 46.

I'm fine with keeping the pwm_enable(), pwm_disable() and pwm_config()
APIs, but they should only be used as shortcuts. Where possible the new
atomic API should be used to combine multiple operations into one.

Thierry


signature.asc
Description: PGP signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v5 34/46] clk: pwm: switch to the atomic API

[Thierry Reding]

On Thu, Mar 31, 2016 at 08:57:35AM +0200, Boris Brezillon wrote:
> Hi Stephen,
> 
> On Wed, 30 Mar 2016 15:01:49 -0700
> Stephen Boyd  wrote:
> 
> > On 03/30, Boris Brezillon wrote:
> > > diff --git a/drivers/clk/clk-pwm.c b/drivers/clk/clk-pwm.c
> > > index ebcd738..49ec5b1 100644
> > > --- a/drivers/clk/clk-pwm.c
> > > +++ b/drivers/clk/clk-pwm.c
> > > @@ -28,15 +28,29 @@ static inline struct clk_pwm *to_clk_pwm(struct 
> > > clk_hw *hw)
> > >  static int clk_pwm_prepare(struct clk_hw *hw)
> > >  {
> > >   struct clk_pwm *clk_pwm = to_clk_pwm(hw);
> > > + struct pwm_state pstate;
> > >  
> > > - return pwm_enable(clk_pwm->pwm);
> > > + pwm_get_state(clk_pwm->pwm, );
> > > + if (pstate.enabled)
> > > + return 0;
> > > +
> > > + pstate.enabled = true;
> > > +
> > > + return pwm_apply_state(clk_pwm->pwm, );
> > 
> > This doesn't seem atomic anymore if we're checking the state and
> > then not calling apply_state if it's already enabled. But I
> > assume this doesn't matter because we "own" the pwm here?
> 
> Yep. Actually it's not atomic in term of concurrency (maybe the
> 'atomic' word is not appropriate here). Atomicity is here referring to
> the fact that we're now providing all the PWM parameters in the same
> request instead of splitting it in pwm_config() + pwm_enable/disable()
> calls.

It's usually not possible to do really atomic updates with PWM hardware.
The idea is merely that we should be able to submit one request and the
framework (and drivers) will be responsible for making sure it is
applied as a whole or not at all. With the legacy API it is possible for
users to set the duty cycle and period, but then fail to enable/disable
the PWM.

pwm_apply_state() reporting success should indicate that the hardware
state is now what software wanted it to be. That kind of implies that
the application is serialized.

This doesn't imply that hardware state won't change between a call to
pwm_get_state() and pwm_apply_state(), though technically this is what
will usually happen because PWM devices are exclusively used by a single
user. Users are responsible for synchronizing accesses within their own
code.

> Concurrent accesses still have to be controlled by the PWM user (which
> is already the case for this driver, thanks to the locking
> infrastructure in the CCF).
> 
> > Otherwise I would think this would be unconditional apply state
> > and duplicates would be ignored in the pwm framework.
> > 
> 
> Yep, I'll remove the if (pstate.enabled) branch.

Yes, it should be the PWM framework's job to check for changes in state
and discard no-ops.

Thierry


signature.asc
Description: PGP signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [v2,1/3] drm/i915/shrinker: Account for unshrinkable unbound pages

[Patchwork]

== Series Details ==

Series: series starting with [v2,1/3] drm/i915/shrinker: Account for 
unshrinkable unbound pages
URL   : https://patchwork.freedesktop.org/series/5276/
State : success

== Summary ==

Series 5276v1 Series without cover letter
http://patchwork.freedesktop.org/api/1.0/series/5276/revisions/1/mbox/

Test kms_force_connector_basic:
Subgroup prune-stale-modes:
skip   -> PASS   (ilk-hp8440p)
Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-b:
incomplete -> PASS   (hsw-gt2)

bdw-ultratotal:196  pass:175  dwarn:0   dfail:0   fail:0   skip:21 
bsw-nuc-2total:196  pass:159  dwarn:0   dfail:0   fail:0   skip:37 
byt-nuc  total:196  pass:161  dwarn:0   dfail:0   fail:0   skip:35 
hsw-brixbox  total:196  pass:174  dwarn:0   dfail:0   fail:0   skip:22 
hsw-gt2  total:196  pass:178  dwarn:0   dfail:0   fail:0   skip:18 
ilk-hp8440p  total:196  pass:132  dwarn:0   dfail:0   fail:0   skip:64 
ivb-t430stotal:196  pass:171  dwarn:0   dfail:0   fail:0   skip:25 
skl-i7k-2total:196  pass:173  dwarn:0   dfail:0   fail:0   skip:23 
skl-nuci5total:196  pass:185  dwarn:0   dfail:0   fail:0   skip:11 
snb-dellxps  total:196  pass:162  dwarn:0   dfail:0   fail:0   skip:34 
snb-x220ttotal:196  pass:162  dwarn:0   dfail:0   fail:1   skip:33 

Results at /archive/results/CI_IGT_test/Patchwork_1791/

aedfaaef290af9c8df7d9f4adf22cbe21704d091 drm-intel-nightly: 
2016y-04m-04d-13h-09m-54s UTC integration manifest
59131f4a7f435c15b4797e95193837956c3e2783 drm/i915/shrinker: Hook up vmap 
allocation failure notifier
f5f0a32a712bb00a9f81d1dda84a327fc92b8ee2 mm/vmap: Add a notifier for when we 
run out of vmap address space
28d83aa606ac3fcd8d36da20939c964b185dd78e drm/i915/shrinker: Account for 
unshrinkable unbound pages

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v5 32/46] pwm: deprecate pwm_config(), pwm_enable() and pwm_disable()

[Thierry Reding]

On Thu, Mar 31, 2016 at 08:54:54PM +0200, Boris Brezillon wrote:
> Hi Dmitry,
> 
> On Thu, 31 Mar 2016 10:38:58 -0700
> Dmitry Torokhov  wrote:
> 
> > Hi Boris,
> > 
> > On Wed, Mar 30, 2016 at 10:03:55PM +0200, Boris Brezillon wrote:
> > > Prefix those function as deprecated to encourage all existing users to
> > > switch to pwm_apply_state().
> > 
> > Why not keep at least some of them as wrappers where we do not need to
> > chnage several parameters at once? It is much easier to have a driver
> > do:
> > 
> > error = pwm_enable(pwm);
> > if (error)
> > ...
> > 
> > rather than declaring the state variable, fectch it, adjust and then
> > apply.
> 
> True. Actually deprecating the non-atomic API was not my primary goal.
> Thierry would you mind if we keep both APIs around?

I'm fine with keeping these around, though purely as shortcuts. If users
need to modify two parameters at once (e.g. duty cycle and enable) then
they should be converted to use the atomic API, otherwise there'd be
little point in introduce it.

Thierry


signature.asc
Description: PGP signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v5 08/46] hwmon: pwm-fan: use pwm_get_args() where appropriate

[Thierry Reding]

On Thu, Mar 31, 2016 at 09:07:09AM +0200, Boris Brezillon wrote:
> Hi Guenter,
> 
> On Wed, 30 Mar 2016 15:52:44 -0700
> Guenter Roeck  wrote:
> 
> > On Wed, Mar 30, 2016 at 10:03:31PM +0200, Boris Brezillon wrote:
> > > The PWM framework has clarified the concept of reference PWM config
> > > (the platform dependent config retrieved from the DT or the PWM
> > > lookup table) and real PWM state.
> > > 
> > > Use pwm_get_args() when the PWM user wants to retrieve this reference
> > > config and not the current state.
> > > 
> > > This is part of the rework allowing the PWM framework to support
> > > hardware readout and expose real PWM state even when the PWM has
> > > just been requested (before the user calls pwm_config/enable/disable()).
> > > 
> > > Signed-off-by: Boris Brezillon 
> > > ---
> > >  drivers/hwmon/pwm-fan.c | 19 +--
> > >  1 file changed, 13 insertions(+), 6 deletions(-)
> > > 
> > > diff --git a/drivers/hwmon/pwm-fan.c b/drivers/hwmon/pwm-fan.c
> > > index 3e23003..82c5656 100644
> > > --- a/drivers/hwmon/pwm-fan.c
> > > +++ b/drivers/hwmon/pwm-fan.c
> > > @@ -40,15 +40,18 @@ struct pwm_fan_ctx {
> > >  
> > >  static int  __set_pwm(struct pwm_fan_ctx *ctx, unsigned long pwm)
> > >  {
> > > + struct pwm_args pargs = { };
> > 
> > Hi Boris,
> > 
> > I guess I am missing some context; sorry for that. Unfortunately,
> > I did not easily find an explanation, so please bear with me.
> > 
> > Two questions: Why do we need a local copy of struct pwm_args instead
> > of a pointer to it ? If it can change while being used, isn't it
> > inconsistent anyway ?
> 
> It cannot change after pwm_get() is called. For the reason behind
> prototype: I just followed the Thierry's proposal, but I'm perfectly
> fine returning a const struct pwm_args pointer intead of passing
> pwm_args as a parameter.
> 
> Thierry, what's your opinion?

I do prefer the current variant because it is more consistent with the
new atomic API, even if not strictly necessary because of the immutable
data.

> > Also, assuming the local copy is necessary, why initialize pargs ? 
> > After all, pwm_get_args() just overwrites it.
> 
> It's a leftover from a previous version where pwm_get_args was
> implemented this way:
> 
> static inline void pwm_get_args(pwm, args)
> {
>   if (pwm)
>   *args = pwm->args
> }
> 
> and this implementation was generating a lot of 'uninitialized
> variable' warnings.
> 
> I just decided to drop the 'if (pwm)' test, because, IMO, this
> should be checked way before calling pwm_get_args() is called.

Sounds fine to me.

Thierry


signature.asc
Description: PGP signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [v4,1/2] shmem: Support for registration of driver/file owner specific ops

[Patchwork]

== Series Details ==

Series: series starting with [v4,1/2] shmem: Support for registration of 
driver/file owner specific ops
URL   : https://patchwork.freedesktop.org/series/5274/
State : failure

== Summary ==

Series 5274v1 Series without cover letter
http://patchwork.freedesktop.org/api/1.0/series/5274/revisions/1/mbox/

Test kms_force_connector_basic:
Subgroup prune-stale-modes:
skip   -> PASS   (ilk-hp8440p)

bdw-nuci7total:196  pass:184  dwarn:0   dfail:0   fail:0   skip:12 
bdw-ultratotal:196  pass:175  dwarn:0   dfail:0   fail:0   skip:21 
bsw-nuc-2total:196  pass:159  dwarn:0   dfail:0   fail:0   skip:37 
byt-nuc  total:196  pass:161  dwarn:0   dfail:0   fail:0   skip:35 
hsw-brixbox  total:196  pass:174  dwarn:0   dfail:0   fail:0   skip:22 
ilk-hp8440p  total:196  pass:132  dwarn:0   dfail:0   fail:0   skip:64 
ivb-t430stotal:196  pass:171  dwarn:0   dfail:0   fail:0   skip:25 
skl-i7k-2total:196  pass:173  dwarn:0   dfail:0   fail:0   skip:23 
skl-nuci5total:196  pass:185  dwarn:0   dfail:0   fail:0   skip:11 
snb-x220ttotal:196  pass:162  dwarn:0   dfail:0   fail:1   skip:33 
BOOT FAILED for hsw-gt2
BOOT FAILED for snb-dellxps

Results at /archive/results/CI_IGT_test/Patchwork_1790/

aedfaaef290af9c8df7d9f4adf22cbe21704d091 drm-intel-nightly: 
2016y-04m-04d-13h-09m-54s UTC integration manifest
0358887a71b8fb16f91ca11effaf8f1d66d4c884 drm/i915: Make GPU pages movable
57e7361fc3c9c485d408254264ff404dd3125c1c shmem: Support for registration of 
driver/file owner specific ops

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH v3 14/16] drm/i915/bxt: Add HW state verification for DDI PHY and CDCLK

[Imre Deak]

I caught a few errors in our current PHY/CDCLK programming by sanity
checking the actual programmed state, so I thought it would be also
useful for the future. In addition to verifying the state after
programming it also verify it after exiting DC5, to make sure DMC
restored/kept intact everything related.

v2:
- Inlining __phy_reg_verify_state() doesn't make sense and also
  incorrect, so don't do it (PW/CI gcc)
v3:
- Rebase on latest -nightly

Signed-off-by: Imre Deak 
---
 drivers/gpu/drm/i915/i915_drv.h |   1 +
 drivers/gpu/drm/i915/intel_ddi.c| 124 +++-
 drivers/gpu/drm/i915/intel_display.c|   5 ++
 drivers/gpu/drm/i915/intel_drv.h|   2 +
 drivers/gpu/drm/i915/intel_runtime_pm.c |   8 +++
 5 files changed, 138 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index dd18772..6f4a721 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1908,6 +1908,7 @@ struct drm_i915_private {
 * crappiness (can't read out DPLL_MD for pipes B & C).
 */
u32 chv_dpll_md[I915_MAX_PIPES];
+   u32 bxt_phy_grc;
 
u32 suspend_count;
bool suspended_to_idle;
diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index d944bff..fd20119 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -1753,6 +1753,13 @@ static bool broxton_phy_is_enabled(struct 
drm_i915_private *dev_priv,
return true;
 }
 
+static u32 broxton_get_grc(struct drm_i915_private *dev_priv, enum dpio_phy 
phy)
+{
+   u32 val = I915_READ(BXT_PORT_REF_DW6(phy));
+
+   return (val & GRC_CODE_MASK) >> GRC_CODE_SHIFT;
+}
+
 static void broxton_phy_init(struct drm_i915_private *dev_priv,
 enum dpio_phy phy)
 {
@@ -1762,6 +1769,9 @@ static void broxton_phy_init(struct drm_i915_private 
*dev_priv,
if (broxton_phy_is_enabled(dev_priv, phy)) {
DRM_DEBUG_DRIVER("DDI PHY %d already enabled, "
 "won't reprogram it\n", phy);
+   /* Still read out the GRC value for state verification */
+   if (phy == DPIO_PHY1)
+   dev_priv->bxt_phy_grc = broxton_get_grc(dev_priv, phy);
 
return;
}
@@ -1857,8 +1867,8 @@ static void broxton_phy_init(struct drm_i915_private 
*dev_priv,
 10))
DRM_ERROR("timeout waiting for PHY1 GRC\n");
 
-   val = I915_READ(BXT_PORT_REF_DW6(DPIO_PHY1));
-   val = (val & GRC_CODE_MASK) >> GRC_CODE_SHIFT;
+   val = dev_priv->bxt_phy_grc = broxton_get_grc(dev_priv,
+ DPIO_PHY1);
grc_code = val << GRC_CODE_FAST_SHIFT |
   val << GRC_CODE_SLOW_SHIFT |
   val;
@@ -1901,6 +1911,116 @@ void broxton_ddi_phy_uninit(struct drm_i915_private 
*dev_priv)
broxton_phy_uninit(dev_priv, DPIO_PHY0);
 }
 
+static bool __printf(6, 7)
+__phy_reg_verify_state(struct drm_i915_private *dev_priv, enum dpio_phy phy,
+  i915_reg_t reg, u32 mask, u32 expected,
+  const char *reg_fmt, ...)
+{
+   struct va_format vaf;
+   va_list args;
+   u32 val;
+
+   val = I915_READ(reg);
+   if ((val & mask) == expected)
+   return true;
+
+   va_start(args, reg_fmt);
+   vaf.fmt = reg_fmt;
+   vaf.va = 
+
+   DRM_DEBUG_DRIVER("DDI PHY %d reg %pV [%08x] state mismatch: "
+"current %08x, expected %08x (mask %08x)\n",
+phy, , reg.reg, val, (val & ~mask) | expected,
+mask);
+
+   va_end(args);
+
+   return false;
+}
+
+static bool broxton_phy_verify_state(struct drm_i915_private *dev_priv,
+enum dpio_phy phy)
+{
+   enum port port;
+   u32 ports;
+   uint32_t mask;
+   bool ok;
+
+#define _CHK(reg, mask, exp, fmt, ...) \
+   __phy_reg_verify_state(dev_priv, phy, reg, mask, exp, fmt,  \
+  ## __VA_ARGS__)
+
+   /* We expect the PHY to be always enabled */
+   if (!broxton_phy_is_enabled(dev_priv, phy))
+   return false;
+
+   ok = true;
+
+   if (phy == DPIO_PHY0)
+   ports = BIT(PORT_B) | BIT(PORT_C);
+   else
+   ports = BIT(PORT_A);
+
+   for_each_port_masked(port, ports) {
+   int lane;
+
+   for (lane = 0; lane < 4; lane++)
+   ok &= _CHK(BXT_PORT_TX_DW14_LN(port, lane),
+   LATENCY_OPTIM,
+   lane != 1 ? LATENCY_OPTIM : 0,
+   "BXT_PORT_TX_DW14_LN(%d, %d)", port, lane);

Re: [Intel-gfx] [PATCH 4/4] drm/i915: Determine DP++ type 1 DVI adaptor presence based on VBT

[Zanoni, Paulo R]

Em Sex, 2016-04-01 às 17:45 +0300, Ville Syrjälä escreveu:
> On Thu, Mar 31, 2016 at 10:06:37PM +, Zanoni, Paulo R wrote:
> > 
> > Em Ter, 2016-02-23 às 18:46 +0200, ville.syrj...@linux.intel.com
> > escreveu:
> > > 
> > > From: Ville Syrjälä 
> > > 
> > > DP dual mode type 1 DVI adaptors aren't required to implement any
> > > registers, so it's a bit hard to detect them. The best way would
> > > be to check the state of the CONFIG1 pin, but we have no way to
> > > do that. So as a last resort, check the VBT to see if the HDMI
> > > port is in fact a dual mode capable DP port.
> > > 
> > > Signed-off-by: Ville Syrjälä 
> > > ---
> > >  drivers/gpu/drm/i915/intel_bios.h |  3 +++
> > >  drivers/gpu/drm/i915/intel_dp.c   | 28
> > > 
> > >  drivers/gpu/drm/i915/intel_drv.h  |  1 +
> > >  drivers/gpu/drm/i915/intel_hdmi.c | 23 +--
> > >  4 files changed, 53 insertions(+), 2 deletions(-)
> > > 
> > > diff --git a/drivers/gpu/drm/i915/intel_bios.h
> > > b/drivers/gpu/drm/i915/intel_bios.h
> > > index 350d4e0f75a4..50d1659efe47 100644
> > > --- a/drivers/gpu/drm/i915/intel_bios.h
> > > +++ b/drivers/gpu/drm/i915/intel_bios.h
> > > @@ -730,6 +730,7 @@ struct bdb_psr {
> > >  #define   DEVICE_TYPE_INT_TV 0x1009
> > >  #define   DEVICE_TYPE_HDMI   0x60D2
> > >  #define   DEVICE_TYPE_DP 0x68C6
> > > +#define   DEVICE_TYPE_DP_DUAL_MODE   0x60D6
> > >  #define   DEVICE_TYPE_eDP0x78C6
> > >  
> > >  #define  DEVICE_TYPE_CLASS_EXTENSION (1 << 15)
> > > @@ -764,6 +765,8 @@ struct bdb_psr {
> > >    DEVICE_TYPE_DISPLAYPORT_OUTPUT | \
> > >    DEVICE_TYPE_ANALOG_OUTPUT)
> > >  
> > > +#define DEVICE_TYPE_DP_DUAL_MODE_BITS
> > > ~DEVICE_TYPE_NOT_HDMI_OUTPUT
> > > +
> > >  /* define the DVO port for HDMI output type */
> > >  #define  DVO_B   1
> > >  #define  DVO_C   2
> > > diff --git a/drivers/gpu/drm/i915/intel_dp.c
> > > b/drivers/gpu/drm/i915/intel_dp.c
> > > index cbc06596659a..f3edacf517ac 100644
> > > --- a/drivers/gpu/drm/i915/intel_dp.c
> > > +++ b/drivers/gpu/drm/i915/intel_dp.c
> > > @@ -5104,6 +5104,34 @@ bool intel_dp_is_edp(struct drm_device
> > > *dev,
> > > enum port port)
> > >   return false;
> > >  }
> > >  
> > > +bool intel_dp_is_dual_mode(struct drm_i915_private *dev_priv,
> > > enum
> > > port port)
> > > +{
> > > + const union child_device_config *p_child;
> > > + int i;
> > > + static const short port_mapping[] = {
> > > + [PORT_B] = DVO_PORT_DPB,
> > > + [PORT_C] = DVO_PORT_DPC,
> > > + [PORT_D] = DVO_PORT_DPD,
> > > + [PORT_E] = DVO_PORT_DPE,
> > > + };
> > > +
> > > + if (port == PORT_A || port >= ARRAY_SIZE(port_mapping))
> > > + return false;
> > > +
> > > + if (!dev_priv->vbt.child_dev_num)
> > > + return false;
> > > +
> > > + for (i = 0; i < dev_priv->vbt.child_dev_num; i++) {
> > > + p_child = _priv->vbt.child_dev[i];
> > > +
> > > + if (p_child->common.dvo_port ==
> > > port_mapping[port]
> > > &&
> > > + (p_child->common.device_type &
> > > DEVICE_TYPE_DP_DUAL_MODE_BITS) ==
> > > + (DEVICE_TYPE_DP_DUAL_MODE &
> > > DEVICE_TYPE_DP_DUAL_MODE_BITS))
> > > + return true;
> > > + }
> > Some thoughts:
> > 
> > This is going to be implemented for all VBT versions. Since there's
> > no
> > real history about anything before version 155, is this really what
> > we
> > want? A huge part of the "we don't trust the VBT" culture we have
> > on
> > our team is because of those old versions being completely
> > unreliable.
> > If this is the case, we could make this implementation just be a
> > small
> > patch in parse_ddi_port(). I'm kinda afraid we may somehow break
> > old
> > machines yet again.
> I don't think it matters much. ILK being the oldest platform with
> DP++
> capable of >165MHz, and at least my ILK here already has VBT version
> 163. Also this device type stuff was there before 155 already. And
> the is_edp() thing has worked for us mostly fine so if we things the
> same way it seems unlikely we get too many problems.

> 
> > 
> > 
> > - Instead of creating these complicated bit masks, why don't we
> > just
> > specifically check "if bit 2 and bit 4 are enabled, we're using an
> > adaptor"? Much simpler IMHO.
> I'm not sure it's a good idea to trust that some crappy BIOS doesn't
> just set whatever random bits on a random port. So a more
> conservative approach seems like a better idea to me. Also it matches
> how we do the is_edp() check.

Funcion intel_ddi_init() already only looks at the specific bits when
deciding whether to initialize DP or HDMI. OTOH that's just for HSW+
which has a somewhat-trustable VBT.

Anyway, I have no further comments for the series. Feel free to send v2
based on the discussion and your conclusions.

> 
> > 
> > 
> > - Jani's recent patch suggests you may want to move this function

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/bxt: Fix/enable display power well support/runtime PM (rev3)

[Patchwork]

== Series Details ==

Series: drm/i915/bxt: Fix/enable display power well support/runtime PM (rev3)
URL   : https://patchwork.freedesktop.org/series/5177/
State : failure

== Summary ==

  CC [M]  drivers/net/ethernet/realtek/8139cp.o
  CC [M]  drivers/net/ethernet/realtek/8139too.o
  LD  drivers/pci/pcie/pcieportdrv.o
  CC [M]  drivers/net/ethernet/realtek/r8169.o
  LD  drivers/net/ethernet/renesas/built-in.o
  CC [M]  drivers/net/ethernet/intel/igb/e1000_82575.o
  LD [M]  drivers/mmc/core/mmc_core.o
  CC [M]  drivers/net/ethernet/intel/igb/e1000_nvm.o
  CC [M]  drivers/net/ethernet/intel/igb/e1000_mac.o
  LD  drivers/net/ethernet/smsc/built-in.o
  CC [M]  drivers/net/ethernet/smsc/smsc9420.o
  LD  drivers/net/ethernet/synopsys/built-in.o
  CC [M]  drivers/net/ethernet/intel/igb/e1000_phy.o
  LD  drivers/mmc/built-in.o
  CC [M]  drivers/net/ethernet/intel/igb/e1000_mbx.o
  CC [M]  drivers/net/ethernet/intel/igb/e1000_i210.o
  CC [M]  drivers/net/ethernet/intel/igb/igb_ptp.o
  CC [M]  drivers/net/ethernet/intel/igb/igb_hwmon.o
  LD  drivers/pci/pcie/aer/aerdriver.o
  LD  drivers/pci/pcie/aer/built-in.o
  LD  drivers/pci/pcie/built-in.o
  LD  drivers/pci/built-in.o
  LD [M]  drivers/net/ethernet/intel/e1000e/e1000e.o
  LD [M]  drivers/net/ethernet/intel/igbvf/igbvf.o
  LD [M]  drivers/net/ethernet/broadcom/genet/genet.o
  LD [M]  drivers/net/ethernet/intel/igb/igb.o
  LD  drivers/net/ethernet/built-in.o
  LD  drivers/net/built-in.o
Makefile:962: recipe for target 'drivers' failed
make: *** [drivers] Error 2

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v2 08/16] drm/i915/skl: Unexport skl_pw1_misc_io_init

[Imre Deak]

On ma, 2016-04-04 at 15:01 +0200, Patrik Jakobsson wrote:
> On Mon, Apr 04, 2016 at 03:42:57PM +0300, Imre Deak wrote:
> > On Broxton we need to enable/disable power well 1 during the
> > init/unit display
> > sequence similarly to Skylake/Kabylake. The code for this will be
> > added in a
> > follow-up patch, but to prepare for that unexport
> > skl_pw1_misc_io_init(). It's
> > a simple function called only from a single place and having it
> > inlined in the
> > Skylake display core init/unit functions will make it easier to
> > compare it
> > with its Broxton counterpart.
> > 
> > No functional change.
> > 
> > v2:
> > - Fix incorrect enable vs. disable power well call in
> >   skl_display_core_uninit() (Patrik)
> > 
> > CC: Patrik Jakobsson 
> > Signed-off-by: Imre Deak 
> > ---
> >  drivers/gpu/drm/i915/intel_drv.h|  2 --
> >  drivers/gpu/drm/i915/intel_runtime_pm.c | 49 -
> > 
> >  2 files changed, 18 insertions(+), 33 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/intel_drv.h
> > b/drivers/gpu/drm/i915/intel_drv.h
> > index 9255b56..8ba2ac3 100644
> > --- a/drivers/gpu/drm/i915/intel_drv.h
> > +++ b/drivers/gpu/drm/i915/intel_drv.h
> > @@ -1460,8 +1460,6 @@ int intel_power_domains_init(struct
> > drm_i915_private *);
> >  void intel_power_domains_fini(struct drm_i915_private *);
> >  void intel_power_domains_init_hw(struct drm_i915_private
> > *dev_priv, bool resume);
> >  void intel_power_domains_suspend(struct drm_i915_private
> > *dev_priv);
> > -void skl_pw1_misc_io_init(struct drm_i915_private *dev_priv);
> > -void skl_pw1_misc_io_fini(struct drm_i915_private *dev_priv);
> >  void intel_runtime_pm_enable(struct drm_i915_private *dev_priv);
> >  const char *
> >  intel_display_power_domain_str(enum intel_display_power_domain
> > domain);
> > diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c
> > b/drivers/gpu/drm/i915/intel_runtime_pm.c
> > index b16315e..8d401bb 100644
> > --- a/drivers/gpu/drm/i915/intel_runtime_pm.c
> > +++ b/drivers/gpu/drm/i915/intel_runtime_pm.c
> > @@ -1921,34 +1921,6 @@ static struct i915_power_well
> > skl_power_wells[] = {
> >     },
> >  };
> >  
> > -void skl_pw1_misc_io_init(struct drm_i915_private *dev_priv)
> > -{
> > -   struct i915_power_well *well;
> > -
> > -   if (!(IS_SKYLAKE(dev_priv) || IS_KABYLAKE(dev_priv)))
> > -   return;
> > -
> > -   well = lookup_power_well(dev_priv, SKL_DISP_PW_1);
> > -   intel_power_well_enable(dev_priv, well);
> > -
> > -   well = lookup_power_well(dev_priv, SKL_DISP_PW_MISC_IO);
> > -   intel_power_well_enable(dev_priv, well);
> > -}
> > -
> > -void skl_pw1_misc_io_fini(struct drm_i915_private *dev_priv)
> > -{
> > -   struct i915_power_well *well;
> > -
> > -   if (!(IS_SKYLAKE(dev_priv) || IS_KABYLAKE(dev_priv)))
> > -   return;
> > -
> > -   well = lookup_power_well(dev_priv, SKL_DISP_PW_1);
> > -   intel_power_well_disable(dev_priv, well);
> > -
> > -   well = lookup_power_well(dev_priv, SKL_DISP_PW_MISC_IO);
> > -   intel_power_well_disable(dev_priv, well);
> > -}
> > -
> >  static struct i915_power_well bxt_power_wells[] = {
> >     {
> >     .name = "always-on",
> > @@ -2139,9 +2111,10 @@ static void
> > intel_power_domains_sync_hw(struct drm_i915_private *dev_priv)
> >  }
> >  
> >  static void skl_display_core_init(struct drm_i915_private
> > *dev_priv,
> > -     bool resume)
> > +      bool resume)
> >  {
> >     struct i915_power_domains *power_domains = _priv-
> > >power_domains;
> > +   struct i915_power_well *well;
> >     uint32_t val;
> >  
> >     gen9_set_dc_state(dev_priv, DC_STATE_DISABLE);
> > @@ -2152,7 +2125,13 @@ static void skl_display_core_init(struct
> > drm_i915_private *dev_priv,
> >  
> >     /* enable PG1 and Misc I/O */
> >     mutex_lock(_domains->lock);
> > -   skl_pw1_misc_io_init(dev_priv);
> > +
> > +   well = lookup_power_well(dev_priv, SKL_DISP_PW_1);
> > +   intel_power_well_enable(dev_priv, well);
> > +
> > +   well = lookup_power_well(dev_priv, SKL_DISP_PW_MISC_IO);
> > +   intel_power_well_enable(dev_priv, well);
> > +
> >     mutex_unlock(_domains->lock);
> >  
> >     if (!resume)
> > @@ -2167,6 +2146,7 @@ static void skl_display_core_init(struct
> > drm_i915_private *dev_priv,
> >  static void skl_display_core_uninit(struct drm_i915_private
> > *dev_priv)
> >  {
> >     struct i915_power_domains *power_domains = _priv-
> > >power_domains;
> > +   struct i915_power_well *well;
> >  
> >     gen9_set_dc_state(dev_priv, DC_STATE_DISABLE);
> >  
> > @@ -2174,8 +2154,15 @@ static void skl_display_core_uninit(struct
> > drm_i915_private *dev_priv)
> >  
> >     /* The spec doesn't call for removing the reset handshake
> > flag */
> >     /* disable PG1 and Misc I/O */
> > +
> >     mutex_lock(_domains->lock);
> > -   skl_pw1_misc_io_fini(dev_priv);
> > +
> > +   well = lookup_power_well(dev_priv, 

Re: [Intel-gfx] [PATCH i-g-t] test/gem_mocs_settings: Testing MOCS register settings

[Chris Wilson]

On Mon, Apr 04, 2016 at 02:43:08PM +0100, Peter Antoine wrote:
> +static void run_test(int fd, unsigned mode)
> +{
> + const int gen = intel_gen(intel_get_drm_devid(fd));
> + const struct intel_execution_engine *e;
> +
> + igt_require(gen >= 9);
> +
> + test_mocs_values(fd);
> +
> + switch(mode) {
> + case NONE:  break;
> + case RESET: igt_force_gpu_reset();  break;
> + case SUSPEND:   igt_system_suspend_autoresume(); break;
> + case HIBERNATE: igt_system_hibernate_autoresume(); break;
> + };
> +
> + /*
> +  * Do render after other engines as older versions of code will
> +  * cause the RCS context to program the registers and the test
> +  * becomes invalid
> +  */

If you defer fd allocation to here, then that is moot, as we can create
the fd for each test and be sure that the default context is
uninitialised.

> + for (e = intel_execution_engines; e->name; e++)
> + if (e->exec_id != I915_EXEC_DEFAULT &&
> + e->exec_id != I915_EXEC_RENDER &&
> + gem_has_ring(fd, e->exec_id | e->flags))
> + test_context_mocs_values(fd, e, true);
> +
> + for (e = intel_execution_engines; e->name; e++)
> + if (e->exec_id == I915_EXEC_RENDER &&
> + gem_has_ring(fd, e->exec_id | e->flags)) {
> + test_context_mocs_values(fd, e, true);
> + test_context_mocs_values(fd, e, false);
> + }

As well as checking for creating new contexts after resume, we also need
to check that the register values are preserved across suspend (i.e.
that the register state is being saved back into the context image and
then restored).

If we get truly paranoid (and why not?!) then we can create a pair of
contexts, change the register values in one and verify that the second
context is unaffected.
-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 3/3] drm/i915/shrinker: Hook up vmap allocation failure notifier

[Chris Wilson]

If the core runs out of vmap address space, it will call a notifier in
case any driver can reap some of its vmaps. As i915.ko is possibily
holding onto vmap address space that could be recovered, hook into the
notifier chain and try and reap objects holding onto vmaps.

Signed-off-by: Chris Wilson 
Cc: Andrew Morton 
Cc: David Rientjes 
Cc: Roman Pen 
Cc: Mel Gorman 
Cc: linux...@kvack.org
Cc: linux-ker...@vger.kernel.org
Cc: Joonas Lahtinen 
Cc: Tvrtko Ursulin 
Cc: Mika Kahola 
---
 drivers/gpu/drm/i915/i915_drv.h  |  1 +
 drivers/gpu/drm/i915/i915_gem_shrinker.c | 39 
 2 files changed, 40 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index dd187727c813..6443745d4182 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1257,6 +1257,7 @@ struct i915_gem_mm {
struct i915_hw_ppgtt *aliasing_ppgtt;
 
struct notifier_block oom_notifier;
+   struct notifier_block vmap_notifier;
struct shrinker shrinker;
bool shrinker_no_lock_stealing;
 
diff --git a/drivers/gpu/drm/i915/i915_gem_shrinker.c 
b/drivers/gpu/drm/i915/i915_gem_shrinker.c
index e391ee3ec486..be7501afb59e 100644
--- a/drivers/gpu/drm/i915/i915_gem_shrinker.c
+++ b/drivers/gpu/drm/i915/i915_gem_shrinker.c
@@ -28,6 +28,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
@@ -356,6 +357,40 @@ i915_gem_shrinker_oom(struct notifier_block *nb, unsigned 
long event, void *ptr)
return NOTIFY_DONE;
 }
 
+static int
+i915_gem_shrinker_vmap(struct notifier_block *nb, unsigned long event, void 
*ptr)
+{
+   struct drm_i915_private *dev_priv =
+   container_of(nb, struct drm_i915_private, mm.vmap_notifier);
+   struct drm_device *dev = dev_priv->dev;
+   unsigned long timeout = msecs_to_jiffies(5000) + 1;
+   unsigned long freed_pages;
+   bool was_interruptible;
+   bool unlock;
+
+   while (!i915_gem_shrinker_lock(dev, ) && --timeout) {
+   schedule_timeout_killable(1);
+   if (fatal_signal_pending(current))
+   return NOTIFY_DONE;
+   }
+   if (timeout == 0) {
+   pr_err("Unable to purge GPU vmaps due to lock contention.\n");
+   return NOTIFY_DONE;
+   }
+
+   was_interruptible = dev_priv->mm.interruptible;
+   dev_priv->mm.interruptible = false;
+
+   freed_pages = i915_gem_shrink_all(dev_priv);
+
+   dev_priv->mm.interruptible = was_interruptible;
+   if (unlock)
+   mutex_unlock(>struct_mutex);
+
+   *(unsigned long *)ptr += freed_pages;
+   return NOTIFY_DONE;
+}
+
 /**
  * i915_gem_shrinker_init - Initialize i915 shrinker
  * @dev_priv: i915 device
@@ -371,6 +406,9 @@ void i915_gem_shrinker_init(struct drm_i915_private 
*dev_priv)
 
dev_priv->mm.oom_notifier.notifier_call = i915_gem_shrinker_oom;
WARN_ON(register_oom_notifier(_priv->mm.oom_notifier));
+
+   dev_priv->mm.vmap_notifier.notifier_call = i915_gem_shrinker_vmap;
+   WARN_ON(register_vmap_purge_notifier(_priv->mm.vmap_notifier));
 }
 
 /**
@@ -381,6 +419,7 @@ void i915_gem_shrinker_init(struct drm_i915_private 
*dev_priv)
  */
 void i915_gem_shrinker_cleanup(struct drm_i915_private *dev_priv)
 {
+   WARN_ON(unregister_vmap_purge_notifier(_priv->mm.vmap_notifier));
WARN_ON(unregister_oom_notifier(_priv->mm.oom_notifier));
unregister_shrinker(_priv->mm.shrinker);
 }
-- 
2.8.0.rc3

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] vmap purge notifier for exhaustion of the vmalloc arena

[Chris Wilson]

Andrew has already acked this for merge through the DRM tree, but it still
needs a review. vmalloc() is quite an extensively used interface so the key
question is have we broken anything by adding a blocking notifier into the
callchain (though we only block if gfp_t says we can).
-Chris

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH v2 2/3] mm/vmap: Add a notifier for when we run out of vmap address space

[Chris Wilson]

vmaps are temporary kernel mappings that may be of long duration.
Reusing a vmap on an object is preferrable for a driver as the cost of
setting up the vmap can otherwise dominate the operation on the object.
However, the vmap address space is rather limited on 32bit systems and
so we add a notification for vmap pressure in order for the driver to
release any cached vmappings.

The interface is styled after the oom-notifier where the callees are
passed a pointer to an unsigned long counter for them to indicate if they
have freed any space.

v2: Guard the blocking notifier call with gfpflags_allow_blocking()
v3: Correct typo in forward declaration and move to head of file

Signed-off-by: Chris Wilson 
Cc: Andrew Morton 
Cc: David Rientjes 
Cc: Roman Peniaev 
Cc: Mel Gorman 
Cc: linux...@kvack.org
Cc: linux-ker...@vger.kernel.org
Acked-by: Andrew Morton  # for inclusion via DRM
Cc: Joonas Lahtinen 
Cc: Tvrtko Ursulin 
---
 include/linux/vmalloc.h |  4 
 mm/vmalloc.c| 27 +++
 2 files changed, 31 insertions(+)

diff --git a/include/linux/vmalloc.h b/include/linux/vmalloc.h
index d1f1d338af20..8b51df3ab334 100644
--- a/include/linux/vmalloc.h
+++ b/include/linux/vmalloc.h
@@ -8,6 +8,7 @@
 #include 
 
 struct vm_area_struct; /* vma defining user mapping in mm_types.h */
+struct notifier_block; /* in notifier.h */
 
 /* bits in flags of vmalloc's vm_struct below */
 #define VM_IOREMAP 0x0001  /* ioremap() and friends */
@@ -187,4 +188,7 @@ pcpu_free_vm_areas(struct vm_struct **vms, int nr_vms)
 #define VMALLOC_TOTAL 0UL
 #endif
 
+int register_vmap_purge_notifier(struct notifier_block *nb);
+int unregister_vmap_purge_notifier(struct notifier_block *nb);
+
 #endif /* _LINUX_VMALLOC_H */
diff --git a/mm/vmalloc.c b/mm/vmalloc.c
index ae7d20b447ff..293889d7f482 100644
--- a/mm/vmalloc.c
+++ b/mm/vmalloc.c
@@ -21,6 +21,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -344,6 +345,8 @@ static void __insert_vmap_area(struct vmap_area *va)
 
 static void purge_vmap_area_lazy(void);
 
+static BLOCKING_NOTIFIER_HEAD(vmap_notify_list);
+
 /*
  * Allocate a region of KVA of the specified size and alignment, within the
  * vstart and vend.
@@ -363,6 +366,8 @@ static struct vmap_area *alloc_vmap_area(unsigned long size,
BUG_ON(offset_in_page(size));
BUG_ON(!is_power_of_2(align));
 
+   might_sleep_if(gfpflags_allow_blocking(gfp_mask));
+
va = kmalloc_node(sizeof(struct vmap_area),
gfp_mask & GFP_RECLAIM_MASK, node);
if (unlikely(!va))
@@ -468,6 +473,16 @@ overflow:
purged = 1;
goto retry;
}
+
+   if (gfpflags_allow_blocking(gfp_mask)) {
+   unsigned long freed = 0;
+   blocking_notifier_call_chain(_notify_list, 0, );
+   if (freed > 0) {
+   purged = 0;
+   goto retry;
+   }
+   }
+
if (printk_ratelimit())
pr_warn("vmap allocation for size %lu failed: use 
vmalloc= to increase size\n",
size);
@@ -475,6 +490,18 @@ overflow:
return ERR_PTR(-EBUSY);
 }
 
+int register_vmap_purge_notifier(struct notifier_block *nb)
+{
+   return blocking_notifier_chain_register(_notify_list, nb);
+}
+EXPORT_SYMBOL_GPL(register_vmap_purge_notifier);
+
+int unregister_vmap_purge_notifier(struct notifier_block *nb)
+{
+   return blocking_notifier_chain_unregister(_notify_list, nb);
+}
+EXPORT_SYMBOL_GPL(unregister_vmap_purge_notifier);
+
 static void __free_vmap_area(struct vmap_area *va)
 {
BUG_ON(RB_EMPTY_NODE(>rb_node));
-- 
2.8.0.rc3

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH v2 1/3] drm/i915/shrinker: Account for unshrinkable unbound pages

[Chris Wilson]

Since we only attempt to purge an object if can_release_pages() report
true, we should also only add it to the count of potential recoverable
pages when can_release_pages() is true.

Signed-off-by: Chris Wilson 
Cc: Joonas Lahtinen 
Cc: Tvrtko Ursulin 
Cc: Akash Goel 
---
 drivers/gpu/drm/i915/i915_gem_shrinker.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_gem_shrinker.c 
b/drivers/gpu/drm/i915/i915_gem_shrinker.c
index d3c473ffb90a..e391ee3ec486 100644
--- a/drivers/gpu/drm/i915/i915_gem_shrinker.c
+++ b/drivers/gpu/drm/i915/i915_gem_shrinker.c
@@ -246,7 +246,7 @@ i915_gem_shrinker_count(struct shrinker *shrinker, struct 
shrink_control *sc)
 
count = 0;
list_for_each_entry(obj, _priv->mm.unbound_list, global_list)
-   if (obj->pages_pin_count == 0)
+   if (can_release_pages(obj))
count += obj->base.size >> PAGE_SHIFT;
 
list_for_each_entry(obj, _priv->mm.bound_list, global_list) {
-- 
2.8.0.rc3

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH i-g-t] test/gem_mocs_settings: Testing MOCS register settings

[Peter Antoine]

The MOCS registers were added in Gen9 and define the caching policy.
The registers are split into two sets. The first set controls the
EDRAM policy and have a set for each engine, the second set controls
the L3 policy. The two sets use the same index.

The RCS registers and the L3CC registers are stored in the RCS context.

The test checks that the registers are correct by checking the values by
directly reading them via MMIO, then again it tests them by reading them
from within a batch buffer. RCS engine is tested last as it programs the
registers via a batch buffer and this will invalidate the test for
workloads that don't use the render ring or don't run a render batch
first.

Signed-off-by: Peter Antoine 
---
 tests/Makefile.sources|   1 +
 tests/gem_mocs_settings.c | 408 ++
 2 files changed, 409 insertions(+)
 create mode 100644 tests/gem_mocs_settings.c

diff --git a/tests/Makefile.sources b/tests/Makefile.sources
index 43f232f..d483c9e 100644
--- a/tests/Makefile.sources
+++ b/tests/Makefile.sources
@@ -148,6 +148,7 @@ TESTS_progs = \
gem_lut_handle \
gem_mmap_offset_exhaustion \
gem_media_fill \
+   gem_mocs_settings \
gem_gpgpu_fill \
gem_pin \
gem_reg_read \
diff --git a/tests/gem_mocs_settings.c b/tests/gem_mocs_settings.c
new file mode 100644
index 000..7db64c1
--- /dev/null
+++ b/tests/gem_mocs_settings.c
@@ -0,0 +1,408 @@
+/*
+ * 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.
+ *
+ */
+
+/** @file gem_mocs_settings.c
+ *
+ * Check that the MOCs cache settings are valid.
+ */
+
+#include "igt.h"
+#include "igt_gt.h"
+
+#define MAX_NUMBER_MOCS_REGISTERS  (64)
+
+enum {
+   NONE,
+   RESET,
+   SUSPEND,
+   HIBERNATE
+};
+
+#define GEN9_LNCFCMOCS0(0xB020)/* L3 Cache Control 
base */
+#define GEN9_GFX_MOCS_0(0xc800)/* Graphics MOCS base 
register*/
+#define GEN9_MFX0_MOCS_0   (0xc900)/* Media 0 MOCS base register*/
+#define GEN9_MFX1_MOCS_0   (0xcA00)/* Media 1 MOCS base register*/
+#define GEN9_VEBOX_MOCS_0  (0xcB00)/* Video MOCS base register*/
+#define GEN9_BLT_MOCS_0(0xcc00)/* Blitter MOCS base 
register*/
+
+#define ENGINE_GFX (I915_EXEC_RENDER)
+#define ENGINE_MFX0(I915_EXEC_BSD)
+#define ENGINE_MFX0_ALT(I915_EXEC_BSD | 1 << 13)
+#define ENGINE_MFX1(I915_EXEC_BSD | 2 << 13)
+#define ENGINE_BLT (I915_EXEC_BLT)
+#define ENGINE_VEBOX   (I915_EXEC_VEBOX)
+
+struct mocs_entry {
+   uint32_tcontrol_value;
+   uint16_tl3cc_value;
+};
+
+struct mocs_table {
+   uint32_tsize;
+   const struct mocs_entry *table;
+};
+
+static const struct mocs_entry skylake_mocs_table[] = {
+   { 0x0009, 0x0010 },
+   { 0x0038, 0x0030 },
+   { 0x003b, 0x0030 },
+};
+
+static const struct mocs_entry broxton_mocs_table[] = {
+   { 0x0009, 0x0010 },
+   { 0x0038, 0x0030 },
+   { 0x003b, 0x0030 },
+};
+
+static bool get_mocs_settings(uint32_t devid, struct mocs_table *table)
+{
+   bool result = false;
+
+   if (IS_SKYLAKE(devid) || IS_KABYLAKE(devid)) {
+   table->size  = ARRAY_SIZE(skylake_mocs_table);
+   table->table = skylake_mocs_table;
+   result = true;
+   } else if (IS_BROXTON(devid)) {
+   table->size  = ARRAY_SIZE(broxton_mocs_table);
+   table->table = broxton_mocs_table;
+   result = true;
+   }
+
+   return result;
+}
+
+static uint32_t get_engine_base(uint32_t engine)
+{
+   uint32_t result = 0;
+
+   switch(engine) {
+   case ENGINE_MFX0:
+   case ENGINE_MFX0_ALT:   result = GEN9_MFX0_MOCS_0;  break;
+   case ENGINE_GFX: 

[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [01/12] drm: Add helper for DP++ adaptors

[Patchwork]

== Series Details ==

Series: series starting with [01/12] drm: Add helper for DP++ adaptors
URL   : https://patchwork.freedesktop.org/series/5273/
State : failure

== Summary ==

Series 5273v1 Series without cover letter
http://patchwork.freedesktop.org/api/1.0/series/5273/revisions/1/mbox/

Test pm_rpm:
Subgroup basic-rte:
pass   -> DMESG-WARN (byt-nuc) UNSTABLE

bdw-nuci7total:196  pass:184  dwarn:0   dfail:0   fail:0   skip:12 
bdw-ultratotal:196  pass:175  dwarn:0   dfail:0   fail:0   skip:21 
bsw-nuc-2total:196  pass:159  dwarn:0   dfail:0   fail:0   skip:37 
byt-nuc  total:196  pass:160  dwarn:1   dfail:0   fail:0   skip:35 
hsw-brixbox  total:196  pass:174  dwarn:0   dfail:0   fail:0   skip:22 
hsw-gt2  total:196  pass:179  dwarn:0   dfail:0   fail:0   skip:17 
ilk-hp8440p  total:196  pass:132  dwarn:0   dfail:0   fail:0   skip:64 
ivb-t430stotal:196  pass:171  dwarn:0   dfail:0   fail:0   skip:25 
snb-x220ttotal:164  pass:139  dwarn:0   dfail:0   fail:0   skip:25 
BOOT FAILED for skl-i7k-2
BOOT FAILED for skl-nuci5
BOOT FAILED for snb-dellxps

Results at /archive/results/CI_IGT_test/Patchwork_1788/

3e353ec38c8fe68e9a243a9388389a8815115451 drm-intel-nightly: 
2016y-04m-04d-11h-13m-54s UTC integration manifest
42274b6522e88e7efec0eb1266424f75f5342706 DO_NOT_MERGE: drm/i915: Hack to enable 
lspcon initialization
cb2a8679cb098c4f7006d6af69ef5158adcad4a4 drm/i915: Add lspcon hpd handler
d3e68835b36c7376325fe0479578c4025afbfaf5 drm/i915: Add lspcon core functions
774a8bdf98e49645e026ea1a2a54ae191251157c drm/i915: Add and register lspcon 
connector functions
903d5afde26b1ccdf32ef274110b1bec97bfe3c2 drm: Add lspcon (custom type2 
dp->hdmi) support
427b454fba08ac71964b0272fd7bb07481ff7f40 drm/i915: Add and initialize lspcon 
connector
0a15f3af6d3075ac6ae2acd06547a799c1969601 drm/i915: Add new lspcon file
dcf5003f1e48e4ff3bee7caa80910c5b64a66cc3 drm/i915: Add lspcon data structures
0e3d1b93f904915352c8e2084db59bb6cd9b9f6f drm/i915: Determine DP++ type 1 DVI 
adaptor presence based on VBT
6eb0111dbcfca1f81bd1b7aa09b5caf6ed6d40c3 drm/i915: Enable/disable TMDS output 
buffers in DP++ adaptor as needed
de089b451d3807e321dd9b544d0d904074db710e drm/i915: Respect DP++ adaptor TMDS 
clock limit
1e9985bd5082f57571f3da12e3f06a55886c9522 drm: Add helper for DP++ adaptors

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] System freeze apparently due to GPU memory exhaustion - why?

[Adam Nielsen]

> That seems like a legit bug. If you can reproduce it with drm-intel-
> nightly, could you please open a bug at freedesktop.org bugzilla?

Just had this happen after running drm-intel-nightly for 18 days, so I
have opened a bug here:

https://bugs.freedesktop.org/show_bug.cgi?id=94814

> Have you tried running the I-G-T testing suite on your hardware?

No I haven't - do I just install intel-gpu-tools and find some test
program to run?

Since it takes at least two weeks for this issue to appear, I'm not
sure the tests would fail unless I run them after the issue has first
appeared.  But I'm happy to try this.

Many thanks,
Adam.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH v4 2/2] drm/i915: Make GPU pages movable

[Chris Wilson]

From: Akash Goel 

On a long run of more than 2-3 days, physical memory tends to get
fragmented severely, which considerably slows down the system. In such a
scenario, the shrinker is also unable to help as lack of memory is not
the actual problem, since it has been observed that there are enough free
pages of 0 order. This also manifests itself when an indiviual zone in
the mm runs out of pages and if we cannot migrate pages between zones,
the kernel hits an out-of-memory even though there are free pages (and
often all of swap) available.

To address the issue of external fragementation, kernel does a compaction
(which involves migration of pages) but it's efficacy depends upon how
many pages are marked as MOVABLE, as only those pages can be migrated.

Currently the backing pages for GFX buffers are allocated from shmemfs
with GFP_RECLAIMABLE flag, in units of 4KB pages.  In the case of limited
swap space, it may not be possible always to reclaim or swap-out pages of
all the inactive objects, to make way for free space allowing formation
of higher order groups of physically-contiguous pages on compaction.

Just marking the GPU pages as MOVABLE will not suffice, as i915.ko has to
pin the pages if they are in use by GPU, which will prevent their
migration. So the migratepage callback in shmem is also hooked up to get
a notification when kernel initiates the page migration. On the
notification, i915.ko appropriately unpin the pages.  With this we can
effectively mark the GPU pages as MOVABLE and hence mitigate the
fragmentation problem.

v2:
 - Rename the migration routine to gem_shrink_migratepage, move it to the
   shrinker file, and use the existing constructs (Chris)
 - To cleanup, add a new helper function to encapsulate all page migration
   skip conditions (Chris)
 - Add a new local helper function in shrinker file, for dropping the
   backing pages, and call the same from gem_shrink() also (Chris)

v3:
 - Fix/invert the check on the return value of unsafe_drop_pages (Chris)

v4:
 - Minor tidy

Testcase: igt/gem_shrink
Bugzilla: (e.g.) https://bugs.freedesktop.org/show_bug.cgi?id=90254
Cc: Hugh Dickins 
Cc: linux...@kvack.org
Signed-off-by: Sourab Gupta 
Signed-off-by: Akash Goel 
Reviewed-by: Chris Wilson 
---
 drivers/gpu/drm/i915/i915_drv.h  |   3 +
 drivers/gpu/drm/i915/i915_gem.c  |  13 ++-
 drivers/gpu/drm/i915/i915_gem_shrinker.c | 174 ---
 3 files changed, 175 insertions(+), 15 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index dd187727c813..2c1d5c3af780 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -52,6 +52,7 @@
 #include 
 #include 
 #include 
+#include 
 #include "intel_guc.h"
 #include "intel_dpll_mgr.h"
 
@@ -1234,6 +1235,8 @@ struct intel_l3_parity {
 };
 
 struct i915_gem_mm {
+   struct shmem_dev_info shmem_info;
+
/** Memory allocator for GTT stolen memory */
struct drm_mm stolen;
/** Protects the usage of the GTT stolen memory allocator. This is
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index ca96fc12cdf4..7cef03efb539 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -2206,6 +2206,7 @@ i915_gem_object_put_pages_gtt(struct drm_i915_gem_object 
*obj)
if (obj->madv == I915_MADV_WILLNEED)
mark_page_accessed(page);
 
+   set_page_private(page, 0);
page_cache_release(page);
}
obj->dirty = 0;
@@ -2320,6 +2321,7 @@ i915_gem_object_get_pages_gtt(struct drm_i915_gem_object 
*obj)
sg->length += PAGE_SIZE;
}
last_pfn = page_to_pfn(page);
+   set_page_private(page, (unsigned long)obj);
 
/* Check that the i965g/gm workaround works. */
WARN_ON((gfp & __GFP_DMA32) && (last_pfn >= 0x0010UL));
@@ -2345,8 +2347,11 @@ i915_gem_object_get_pages_gtt(struct drm_i915_gem_object 
*obj)
 
 err_pages:
sg_mark_end(sg);
-   for_each_sg_page(st->sgl, _iter, st->nents, 0)
-   page_cache_release(sg_page_iter_page(_iter));
+   for_each_sg_page(st->sgl, _iter, st->nents, 0) {
+   page = sg_page_iter_page(_iter);
+   set_page_private(page, 0);
+   page_cache_release(page);
+   }
sg_free_table(st);
kfree(st);
 
@@ -4468,6 +4473,7 @@ static const struct drm_i915_gem_object_ops 
i915_gem_object_ops = {
 struct drm_i915_gem_object *i915_gem_alloc_object(struct drm_device *dev,
  size_t size)
 {
+   struct drm_i915_private *dev_priv = to_i915(dev);
struct drm_i915_gem_object *obj;
struct address_space *mapping;
gfp_t mask;
@@ -4481,7 

[Intel-gfx] [PATCH v4 1/2] shmem: Support for registration of driver/file owner specific ops

[Chris Wilson]

From: Akash Goel 

This provides support for the drivers or shmem file owners to register
a set of callbacks, which can be invoked from the address space
operations methods implemented by shmem.  This allow the file owners to
hook into the shmem address space operations to do some extra/custom
operations in addition to the default ones.

The private_data field of address_space struct is used to store the
pointer to driver specific ops.  Currently only one ops field is defined,
which is migratepage, but can be extended on an as-needed basis.

The need for driver specific operations arises since some of the
operations (like migratepage) may not be handled completely within shmem,
so as to be effective, and would need some driver specific handling also.
Specifically, i915.ko would like to participate in migratepage().
i915.ko uses shmemfs to provide swappable backing storage for its user
objects, but when those objects are in use by the GPU it must pin the
entire object until the GPU is idle.  As a result, large chunks of memory
can be arbitrarily withdrawn from page migration, resulting in premature
out-of-memory due to fragmentation.  However, if i915.ko can receive the
migratepage() request, it can then flush the object from the GPU, remove
its pin and thus enable the migration.

Since gfx allocations are one of the major consumer of system memory, its
imperative to have such a mechanism to effectively deal with
fragmentation.  And therefore the need for such a provision for initiating
driver specific actions during address space operations.

Cc: Hugh Dickins 
Cc: linux...@kvack.org
Cc: linux-ker...@vger.linux.org
Signed-off-by: Sourab Gupta 
Signed-off-by: Akash Goel 
Reviewed-by: Chris Wilson 
---
 include/linux/shmem_fs.h | 17 +
 mm/shmem.c   | 17 -
 2 files changed, 33 insertions(+), 1 deletion(-)

diff --git a/include/linux/shmem_fs.h b/include/linux/shmem_fs.h
index 4d4780c00d34..d7925b66c240 100644
--- a/include/linux/shmem_fs.h
+++ b/include/linux/shmem_fs.h
@@ -34,11 +34,28 @@ struct shmem_sb_info {
struct mempolicy *mpol; /* default memory policy for mappings */
 };
 
+struct shmem_dev_info {
+   void *dev_private_data;
+   int (*dev_migratepage)(struct address_space *mapping,
+  struct page *newpage, struct page *page,
+  enum migrate_mode mode, void *dev_priv_data);
+};
+
 static inline struct shmem_inode_info *SHMEM_I(struct inode *inode)
 {
return container_of(inode, struct shmem_inode_info, vfs_inode);
 }
 
+static inline int shmem_set_device_ops(struct address_space *mapping,
+  struct shmem_dev_info *info)
+{
+   if (mapping->private_data != NULL)
+   return -EEXIST;
+
+   mapping->private_data = info;
+   return 0;
+}
+
 /*
  * Functions in mm/shmem.c called directly from elsewhere:
  */
diff --git a/mm/shmem.c b/mm/shmem.c
index 9428c51ab2d6..6ed953193883 100644
--- a/mm/shmem.c
+++ b/mm/shmem.c
@@ -947,6 +947,21 @@ redirty:
return 0;
 }
 
+#ifdef CONFIG_MIGRATION
+static int shmem_migratepage(struct address_space *mapping,
+struct page *newpage, struct page *page,
+enum migrate_mode mode)
+{
+   struct shmem_dev_info *dev_info = mapping->private_data;
+
+   if (dev_info && dev_info->dev_migratepage)
+   return dev_info->dev_migratepage(mapping, newpage, page,
+   mode, dev_info->dev_private_data);
+
+   return migrate_page(mapping, newpage, page, mode);
+}
+#endif
+
 #ifdef CONFIG_NUMA
 #ifdef CONFIG_TMPFS
 static void shmem_show_mpol(struct seq_file *seq, struct mempolicy *mpol)
@@ -3161,7 +3176,7 @@ static const struct address_space_operations shmem_aops = 
{
.write_end  = shmem_write_end,
 #endif
 #ifdef CONFIG_MIGRATION
-   .migratepage= migrate_page,
+   .migratepage= shmem_migratepage,
 #endif
.error_remove_page = generic_error_remove_page,
 };
-- 
2.8.0.rc3

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [1/2] shmem: Support for registration of Driver/file owner specific ops (rev3)

[Patchwork]

== Series Details ==

Series: series starting with [1/2] shmem: Support for registration of 
Driver/file owner specific ops (rev3)
URL   : https://patchwork.freedesktop.org/series/4780/
State : failure

== Summary ==

Series 4780v3 Series without cover letter
http://patchwork.freedesktop.org/api/1.0/series/4780/revisions/3/mbox/

Test gem_sync:
Subgroup basic-all:
pass   -> DMESG-FAIL (ilk-hp8440p)
Test kms_flip:
Subgroup basic-flip-vs-dpms:
pass   -> DMESG-WARN (ilk-hp8440p) UNSTABLE
Subgroup basic-flip-vs-modeset:
pass   -> DMESG-WARN (skl-i7k-2)
Test kms_pipe_crc_basic:
Subgroup nonblocking-crc-pipe-a-frame-sequence:
pass   -> FAIL   (ilk-hp8440p)
Subgroup suspend-read-crc-pipe-a:
incomplete -> PASS   (skl-nuci5)
Test pm_rpm:
Subgroup basic-rte:
pass   -> DMESG-WARN (bsw-nuc-2)

bdw-nuci7total:196  pass:184  dwarn:0   dfail:0   fail:0   skip:12 
bdw-ultratotal:196  pass:175  dwarn:0   dfail:0   fail:0   skip:21 
bsw-nuc-2total:196  pass:158  dwarn:1   dfail:0   fail:0   skip:37 
byt-nuc  total:196  pass:161  dwarn:0   dfail:0   fail:0   skip:35 
hsw-brixbox  total:196  pass:174  dwarn:0   dfail:0   fail:0   skip:22 
hsw-gt2  total:196  pass:179  dwarn:0   dfail:0   fail:0   skip:17 
ilk-hp8440p  total:196  pass:129  dwarn:1   dfail:1   fail:1   skip:64 
ivb-t430stotal:196  pass:171  dwarn:0   dfail:0   fail:0   skip:25 
skl-i7k-2total:196  pass:172  dwarn:1   dfail:0   fail:0   skip:23 
skl-nuci5total:196  pass:185  dwarn:0   dfail:0   fail:0   skip:11 
snb-dellxps  total:196  pass:162  dwarn:0   dfail:0   fail:0   skip:34 
snb-x220ttotal:164  pass:139  dwarn:0   dfail:0   fail:0   skip:25 

Results at /archive/results/CI_IGT_test/Patchwork_1787/

3e353ec38c8fe68e9a243a9388389a8815115451 drm-intel-nightly: 
2016y-04m-04d-11h-13m-54s UTC integration manifest
60d6976c7880f278c3421853a46d1a9110c786cf drm/i915: Make pages of GFX 
allocations movable
3c45c2f983dd2c991fc4f2a4aa54653a4f6b56df shmem: Support for registration of 
Driver/file owner specific ops

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Move execlists irq handler to a bottom half (rev4)

[Tvrtko Ursulin]

On 04/04/16 13:53, Chris Wilson wrote:

On Mon, Apr 04, 2016 at 01:42:06PM +0100, Tvrtko Ursulin wrote:



On 04/04/16 13:33, Patchwork wrote:

== Series Details ==

Series: drm/i915: Move execlists irq handler to a bottom half (rev4)
URL   : https://patchwork.freedesktop.org/series/4764/
State : failure

== Summary ==

Series 4764v4 drm/i915: Move execlists irq handler to a bottom half
http://patchwork.freedesktop.org/api/1.0/series/4764/revisions/4/mbox/

Test gem_sync:
 Subgroup basic-bsd:
 pass   -> DMESG-FAIL (ilk-hp8440p)


Unrelated hangcheck timer elapsed on ILK:
https://bugs.freedesktop.org/show_bug.cgi?id=94307


Test kms_pipe_crc_basic:
 Subgroup suspend-read-crc-pipe-a:
 incomplete -> PASS   (skl-nuci5)

bdw-nuci7total:196  pass:184  dwarn:0   dfail:0   fail:0   skip:12
bdw-ultratotal:196  pass:175  dwarn:0   dfail:0   fail:0   skip:21
bsw-nuc-2total:196  pass:159  dwarn:0   dfail:0   fail:0   skip:37
byt-nuc  total:196  pass:161  dwarn:0   dfail:0   fail:0   skip:35
hsw-brixbox  total:196  pass:174  dwarn:0   dfail:0   fail:0   skip:22
hsw-gt2  total:196  pass:179  dwarn:0   dfail:0   fail:0   skip:17
ilk-hp8440p  total:196  pass:131  dwarn:0   dfail:1   fail:0   skip:64
ivb-t430stotal:196  pass:171  dwarn:0   dfail:0   fail:0   skip:25
skl-i7k-2total:196  pass:173  dwarn:0   dfail:0   fail:0   skip:23
skl-nuci5total:105  pass:100  dwarn:0   dfail:0   fail:0   skip:4
snb-dellxps  total:196  pass:162  dwarn:0   dfail:0   fail:0   skip:34
snb-x220ttotal:164  pass:139  dwarn:0   dfail:0   fail:0   skip:25

Results at /archive/results/CI_IGT_test/Patchwork_1786/

3e353ec38c8fe68e9a243a9388389a8815115451 drm-intel-nightly: 
2016y-04m-04d-11h-13m-54s UTC integration manifest
95dc10d4f71a6cf473aa874b0a74036f251aef8c drm/i915: Move execlists irq handler 
to a bottom half


So cross fingers and merge?


Yes!


Okay, it's done, we'll see what happens next. :)

Regards,

Tvrtko
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] System freeze apparently due to GPU memory exhaustion - why?

[Adam Nielsen]

> > Have you tried running the I-G-T testing suite on your hardware?  
> 
> No I haven't - do I just install intel-gpu-tools and find some test
> program to run?

I cloned the git repo for this and tried to run the tests as best I
could understand from the readme, but no luck:

  intel-gpu-tools/tests$ ../scripts/run-tests.sh
  Fatal Error: Cannot overwrite existing folder without the -o/--overwrite 
option being set.

  intel-gpu-tools/tests$ ../scripts/run-tests.sh -o
  Unknown option: -o

So I tried running piglit - the README says "./piglit" but for me
it was "./piglit/piglit" instead:

  intel-gpu-tools$ ./piglit/piglit
  Traceback (most recent call last):
File "./piglit/piglit", line 165, in 
  main()
File "./piglit/piglit", line 160, in main
  returncode = parsed.func(args)
  AttributeError: 'Namespace' object has no attribute 'func'

Thinking it might not be Python 3 compatible, I tried as Python 2:

  intel-gpu-tools$ python2 ./piglit/piglit run igt output
  ./piglit/framework/test/base.py:76: UserWarning: Timeouts are not available
warnings.warn('Timeouts are not available')

  Traceback (most recent call last):
File "./piglit/piglit", line 165, in 
  main()
File "./piglit/piglit", line 160, in main
  returncode = parsed.func(args)
File "./piglit/framework/exceptions.py", line 50, in _inner
  func(*args, **kwargs)
File "./piglit/framework/programs/run.py", line 280, in run
  profile = framework.profile.merge_test_profiles(args.test_profile)
File "./piglit/framework/profile.py", line 444, in merge_test_profiles
  profile = load_test_profile(profiles.pop())
File "./piglit/framework/profile.py", line 422, in load_test_profile
  os.path.splitext(os.path.basename(filename))[0]))
File "/usr/lib/python2.7/importlib/__init__.py", line 37, in import_module
  __import__(name)
File "./piglit/tests/igt.py", line 177, in 
  populate_profile()
File "./piglit/tests/igt.py", line 174, in populate_profile
  add_subtest_cases(test)
File "./piglit/tests/igt.py", line 150, in add_subtest_cases
  universal_newlines=True)
File "/usr/lib/python2.7/subprocess.py", line 566, in check_output
  process = Popen(stdout=PIPE, *popenargs, **kwargs)
File "/usr/lib/python2.7/subprocess.py", line 710, in __init__
  errread, errwrite)
File "/usr/lib/python2.7/subprocess.py", line 1231, in _execute_child
  self.pid = os.fork()
  OSError: [Errno 12] Cannot allocate memory

Not sure why fork() is throwing an error - the system isn't *that*
broken...

Any suggestions what to try next, assuming you want these tests run
after the GPU error has occurred?

Thanks,
Adam.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v2 08/16] drm/i915/skl: Unexport skl_pw1_misc_io_init

[Patrik Jakobsson]

On Mon, Apr 04, 2016 at 03:42:57PM +0300, Imre Deak wrote:
> On Broxton we need to enable/disable power well 1 during the init/unit display
> sequence similarly to Skylake/Kabylake. The code for this will be added in a
> follow-up patch, but to prepare for that unexport skl_pw1_misc_io_init(). It's
> a simple function called only from a single place and having it inlined in the
> Skylake display core init/unit functions will make it easier to compare it
> with its Broxton counterpart.
> 
> No functional change.
> 
> v2:
> - Fix incorrect enable vs. disable power well call in
>   skl_display_core_uninit() (Patrik)
> 
> CC: Patrik Jakobsson 
> Signed-off-by: Imre Deak 
> ---
>  drivers/gpu/drm/i915/intel_drv.h|  2 --
>  drivers/gpu/drm/i915/intel_runtime_pm.c | 49 
> -
>  2 files changed, 18 insertions(+), 33 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_drv.h 
> b/drivers/gpu/drm/i915/intel_drv.h
> index 9255b56..8ba2ac3 100644
> --- a/drivers/gpu/drm/i915/intel_drv.h
> +++ b/drivers/gpu/drm/i915/intel_drv.h
> @@ -1460,8 +1460,6 @@ int intel_power_domains_init(struct drm_i915_private *);
>  void intel_power_domains_fini(struct drm_i915_private *);
>  void intel_power_domains_init_hw(struct drm_i915_private *dev_priv, bool 
> resume);
>  void intel_power_domains_suspend(struct drm_i915_private *dev_priv);
> -void skl_pw1_misc_io_init(struct drm_i915_private *dev_priv);
> -void skl_pw1_misc_io_fini(struct drm_i915_private *dev_priv);
>  void intel_runtime_pm_enable(struct drm_i915_private *dev_priv);
>  const char *
>  intel_display_power_domain_str(enum intel_display_power_domain domain);
> diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c 
> b/drivers/gpu/drm/i915/intel_runtime_pm.c
> index b16315e..8d401bb 100644
> --- a/drivers/gpu/drm/i915/intel_runtime_pm.c
> +++ b/drivers/gpu/drm/i915/intel_runtime_pm.c
> @@ -1921,34 +1921,6 @@ static struct i915_power_well skl_power_wells[] = {
>   },
>  };
>  
> -void skl_pw1_misc_io_init(struct drm_i915_private *dev_priv)
> -{
> - struct i915_power_well *well;
> -
> - if (!(IS_SKYLAKE(dev_priv) || IS_KABYLAKE(dev_priv)))
> - return;
> -
> - well = lookup_power_well(dev_priv, SKL_DISP_PW_1);
> - intel_power_well_enable(dev_priv, well);
> -
> - well = lookup_power_well(dev_priv, SKL_DISP_PW_MISC_IO);
> - intel_power_well_enable(dev_priv, well);
> -}
> -
> -void skl_pw1_misc_io_fini(struct drm_i915_private *dev_priv)
> -{
> - struct i915_power_well *well;
> -
> - if (!(IS_SKYLAKE(dev_priv) || IS_KABYLAKE(dev_priv)))
> - return;
> -
> - well = lookup_power_well(dev_priv, SKL_DISP_PW_1);
> - intel_power_well_disable(dev_priv, well);
> -
> - well = lookup_power_well(dev_priv, SKL_DISP_PW_MISC_IO);
> - intel_power_well_disable(dev_priv, well);
> -}
> -
>  static struct i915_power_well bxt_power_wells[] = {
>   {
>   .name = "always-on",
> @@ -2139,9 +2111,10 @@ static void intel_power_domains_sync_hw(struct 
> drm_i915_private *dev_priv)
>  }
>  
>  static void skl_display_core_init(struct drm_i915_private *dev_priv,
> -   bool resume)
> +bool resume)
>  {
>   struct i915_power_domains *power_domains = _priv->power_domains;
> + struct i915_power_well *well;
>   uint32_t val;
>  
>   gen9_set_dc_state(dev_priv, DC_STATE_DISABLE);
> @@ -2152,7 +2125,13 @@ static void skl_display_core_init(struct 
> drm_i915_private *dev_priv,
>  
>   /* enable PG1 and Misc I/O */
>   mutex_lock(_domains->lock);
> - skl_pw1_misc_io_init(dev_priv);
> +
> + well = lookup_power_well(dev_priv, SKL_DISP_PW_1);
> + intel_power_well_enable(dev_priv, well);
> +
> + well = lookup_power_well(dev_priv, SKL_DISP_PW_MISC_IO);
> + intel_power_well_enable(dev_priv, well);
> +
>   mutex_unlock(_domains->lock);
>  
>   if (!resume)
> @@ -2167,6 +2146,7 @@ static void skl_display_core_init(struct 
> drm_i915_private *dev_priv,
>  static void skl_display_core_uninit(struct drm_i915_private *dev_priv)
>  {
>   struct i915_power_domains *power_domains = _priv->power_domains;
> + struct i915_power_well *well;
>  
>   gen9_set_dc_state(dev_priv, DC_STATE_DISABLE);
>  
> @@ -2174,8 +2154,15 @@ static void skl_display_core_uninit(struct 
> drm_i915_private *dev_priv)
>  
>   /* The spec doesn't call for removing the reset handshake flag */
>   /* disable PG1 and Misc I/O */
> +
>   mutex_lock(_domains->lock);
> - skl_pw1_misc_io_fini(dev_priv);
> +
> + well = lookup_power_well(dev_priv, SKL_DISP_PW_MISC_IO);
> + intel_power_well_disable(dev_priv, well);
> +
> + well = lookup_power_well(dev_priv, SKL_DISP_PW_1);
> + intel_power_well_disable(dev_priv, well);
> +

I see you've flipped the order here. Probably for the better since I'm guessing
the old behaviour was by 

Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Move execlists irq handler to a bottom half (rev4)

[Chris Wilson]

On Mon, Apr 04, 2016 at 01:42:06PM +0100, Tvrtko Ursulin wrote:
> 
> 
> On 04/04/16 13:33, Patchwork wrote:
> >== Series Details ==
> >
> >Series: drm/i915: Move execlists irq handler to a bottom half (rev4)
> >URL   : https://patchwork.freedesktop.org/series/4764/
> >State : failure
> >
> >== Summary ==
> >
> >Series 4764v4 drm/i915: Move execlists irq handler to a bottom half
> >http://patchwork.freedesktop.org/api/1.0/series/4764/revisions/4/mbox/
> >
> >Test gem_sync:
> > Subgroup basic-bsd:
> > pass   -> DMESG-FAIL (ilk-hp8440p)
> 
> Unrelated hangcheck timer elapsed on ILK:
> https://bugs.freedesktop.org/show_bug.cgi?id=94307
> 
> >Test kms_pipe_crc_basic:
> > Subgroup suspend-read-crc-pipe-a:
> > incomplete -> PASS   (skl-nuci5)
> >
> >bdw-nuci7total:196  pass:184  dwarn:0   dfail:0   fail:0   skip:12
> >bdw-ultratotal:196  pass:175  dwarn:0   dfail:0   fail:0   skip:21
> >bsw-nuc-2total:196  pass:159  dwarn:0   dfail:0   fail:0   skip:37
> >byt-nuc  total:196  pass:161  dwarn:0   dfail:0   fail:0   skip:35
> >hsw-brixbox  total:196  pass:174  dwarn:0   dfail:0   fail:0   skip:22
> >hsw-gt2  total:196  pass:179  dwarn:0   dfail:0   fail:0   skip:17
> >ilk-hp8440p  total:196  pass:131  dwarn:0   dfail:1   fail:0   skip:64
> >ivb-t430stotal:196  pass:171  dwarn:0   dfail:0   fail:0   skip:25
> >skl-i7k-2total:196  pass:173  dwarn:0   dfail:0   fail:0   skip:23
> >skl-nuci5total:105  pass:100  dwarn:0   dfail:0   fail:0   skip:4
> >snb-dellxps  total:196  pass:162  dwarn:0   dfail:0   fail:0   skip:34
> >snb-x220ttotal:164  pass:139  dwarn:0   dfail:0   fail:0   skip:25
> >
> >Results at /archive/results/CI_IGT_test/Patchwork_1786/
> >
> >3e353ec38c8fe68e9a243a9388389a8815115451 drm-intel-nightly: 
> >2016y-04m-04d-11h-13m-54s UTC integration manifest
> >95dc10d4f71a6cf473aa874b0a74036f251aef8c drm/i915: Move execlists irq 
> >handler to a bottom half
> 
> So cross fingers and merge?

Yes!
-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 v4] drm/i915: Move execlists irq handler to a bottom half

[Tvrtko Ursulin]

On 04/04/16 12:27, Chris Wilson wrote:

On Mon, Apr 04, 2016 at 12:11:56PM +0100, Tvrtko Ursulin wrote:

From: Tvrtko Ursulin 

Doing a lot of work in the interrupt handler introduces huge
latencies to the system as a whole.

Most dramatic effect can be seen by running an all engine
stress test like igt/gem_exec_nop/all where, when the kernel
config is lean enough, the whole system can be brought into
multi-second periods of complete non-interactivty. That can
look for example like this:

  NMI watchdog: BUG: soft lockup - CPU#0 stuck for 23s! [kworker/u8:3:143]
  Modules linked in: [redacted for brevity]
  CPU: 0 PID: 143 Comm: kworker/u8:3 Tainted: G U   L  4.5.0-160321+ 
#183
  Hardware name: Intel Corporation Broadwell Client platform/WhiteTip Mountain 1
  Workqueue: i915 gen6_pm_rps_work [i915]
  task: 8800aae88000 ti: 8800aae9 task.ti: 8800aae9
  RIP: 0010:[]  [] __do_softirq+0x72/0x1d0
  RSP: :88014f403f38  EFLAGS: 0206
  RAX: 8800aae94000 RBX:  RCX: 06e0
  RDX: 0020 RSI: 04208060 RDI: 00215d80
  RBP: 88014f403f80 R08: 000b1b42c180 R09: 0022
  R10: 0004 R11:  R12: a030
  R13: 0082 R14: 8800aa4d0080 R15: 0082
  FS:  () GS:88014f40() knlGS:
  CS:  0010 DS:  ES:  CR0: 80050033
  CR2: 7fa53b90c000 CR3: 01a0a000 CR4: 001406f0
  DR0:  DR1:  DR2: 
  DR3:  DR6: fffe0ff0 DR7: 0400
  Stack:
   042080601b33869f 8800aae94000 fffc2678 8801000a
    a030 5302 8800aa4d0080
   0206 88014f403f90 8104a716 88014f403fa8
  Call Trace:
   
   [] irq_exit+0x86/0x90
   [] smp_apic_timer_interrupt+0x3d/0x50
   [] apic_timer_interrupt+0x7c/0x90
   
   [] ? gen8_write64+0x1a0/0x1a0 [i915]
   [] ? _raw_spin_unlock_irqrestore+0x9/0x20
   [] gen8_write32+0x104/0x1a0 [i915]
   [] ? n_tty_receive_buf_common+0x372/0xae0
   [] gen6_set_rps_thresholds+0x1be/0x330 [i915]
   [] gen6_set_rps+0x70/0x200 [i915]
   [] intel_set_rps+0x25/0x30 [i915]
   [] gen6_pm_rps_work+0x10d/0x2e0 [i915]
   [] ? finish_task_switch+0x72/0x1c0
   [] process_one_work+0x139/0x350
   [] worker_thread+0x126/0x490
   [] ? rescuer_thread+0x320/0x320
   [] kthread+0xc4/0xe0
   [] ? kthread_create_on_node+0x170/0x170
   [] ret_from_fork+0x3f/0x70
   [] ? kthread_create_on_node+0x170/0x170

I could not explain, or find a code path, which would explain
a +20 second lockup, but from some instrumentation it was
apparent the interrupts off proportion of time was between
10-25% under heavy load which is quite bad.

When a interrupt "cliff" is reached, which was >~320k irq/s on
my machine, the whole system goes into a terrible state of the
above described multi-second lockups.

By moving the GT interrupt handling to a tasklet in a most
simple way, the problem above disappears completely.

Testing the effect on sytem-wide latencies using
igt/gem_syslatency shows the following before this patch:

gem_syslatency: cycles=1532739, latency mean=416531.829us max=2499237us
gem_syslatency: cycles=1839434, latency mean=1458099.157us max=4998944us
gem_syslatency: cycles=1432570, latency mean=2688.451us max=1201185us
gem_syslatency: cycles=1533543, latency mean=416520.499us max=2498886us

This shows that the unrelated process is experiencing huge
delays in its wake-up latency. After the patch the results
look like this:

gem_syslatency: cycles=808907, latency mean=53.133us max=1640us
gem_syslatency: cycles=862154, latency mean=62.778us max=2117us
gem_syslatency: cycles=856039, latency mean=58.079us max=2123us
gem_syslatency: cycles=841683, latency mean=56.914us max=1667us

Showing a huge improvement in the unrelated process wake-up
latency. It also shows an approximate halving in the number
of total empty batches submitted during the test. This may
not be worrying since the test puts the driver under
a very unrealistic load with ncpu threads doing empty batch
submission to all GPU engines each.

Another benefit compared to the hard-irq handling is that now
work on all engines can be dispatched in parallel since we can
have up to number of CPUs active tasklets. (While previously
a single hard-irq would serially dispatch on one engine after
another.)

More interesting scenario with regards to throughput is
"gem_latency -n 100" which  shows 25% better throughput and
CPU usage, and 14% better dispatch latencies.

I did not find any gains or regressions with Synmark2 or
GLbench under light testing. More benchmarking is certainly
required.

v2:
* execlists_lock should be taken as spin_lock_bh when
  queuing work from userspace now. (Chris Wilson)
* uncore.lock must be taken with spin_lock_irq when
  

[Intel-gfx] [PATCH v2 08/16] drm/i915/skl: Unexport skl_pw1_misc_io_init

[Imre Deak]

On Broxton we need to enable/disable power well 1 during the init/unit display
sequence similarly to Skylake/Kabylake. The code for this will be added in a
follow-up patch, but to prepare for that unexport skl_pw1_misc_io_init(). It's
a simple function called only from a single place and having it inlined in the
Skylake display core init/unit functions will make it easier to compare it
with its Broxton counterpart.

No functional change.

v2:
- Fix incorrect enable vs. disable power well call in
  skl_display_core_uninit() (Patrik)

CC: Patrik Jakobsson 
Signed-off-by: Imre Deak 
---
 drivers/gpu/drm/i915/intel_drv.h|  2 --
 drivers/gpu/drm/i915/intel_runtime_pm.c | 49 -
 2 files changed, 18 insertions(+), 33 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 9255b56..8ba2ac3 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -1460,8 +1460,6 @@ int intel_power_domains_init(struct drm_i915_private *);
 void intel_power_domains_fini(struct drm_i915_private *);
 void intel_power_domains_init_hw(struct drm_i915_private *dev_priv, bool 
resume);
 void intel_power_domains_suspend(struct drm_i915_private *dev_priv);
-void skl_pw1_misc_io_init(struct drm_i915_private *dev_priv);
-void skl_pw1_misc_io_fini(struct drm_i915_private *dev_priv);
 void intel_runtime_pm_enable(struct drm_i915_private *dev_priv);
 const char *
 intel_display_power_domain_str(enum intel_display_power_domain domain);
diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c 
b/drivers/gpu/drm/i915/intel_runtime_pm.c
index b16315e..8d401bb 100644
--- a/drivers/gpu/drm/i915/intel_runtime_pm.c
+++ b/drivers/gpu/drm/i915/intel_runtime_pm.c
@@ -1921,34 +1921,6 @@ static struct i915_power_well skl_power_wells[] = {
},
 };
 
-void skl_pw1_misc_io_init(struct drm_i915_private *dev_priv)
-{
-   struct i915_power_well *well;
-
-   if (!(IS_SKYLAKE(dev_priv) || IS_KABYLAKE(dev_priv)))
-   return;
-
-   well = lookup_power_well(dev_priv, SKL_DISP_PW_1);
-   intel_power_well_enable(dev_priv, well);
-
-   well = lookup_power_well(dev_priv, SKL_DISP_PW_MISC_IO);
-   intel_power_well_enable(dev_priv, well);
-}
-
-void skl_pw1_misc_io_fini(struct drm_i915_private *dev_priv)
-{
-   struct i915_power_well *well;
-
-   if (!(IS_SKYLAKE(dev_priv) || IS_KABYLAKE(dev_priv)))
-   return;
-
-   well = lookup_power_well(dev_priv, SKL_DISP_PW_1);
-   intel_power_well_disable(dev_priv, well);
-
-   well = lookup_power_well(dev_priv, SKL_DISP_PW_MISC_IO);
-   intel_power_well_disable(dev_priv, well);
-}
-
 static struct i915_power_well bxt_power_wells[] = {
{
.name = "always-on",
@@ -2139,9 +2111,10 @@ static void intel_power_domains_sync_hw(struct 
drm_i915_private *dev_priv)
 }
 
 static void skl_display_core_init(struct drm_i915_private *dev_priv,
- bool resume)
+  bool resume)
 {
struct i915_power_domains *power_domains = _priv->power_domains;
+   struct i915_power_well *well;
uint32_t val;
 
gen9_set_dc_state(dev_priv, DC_STATE_DISABLE);
@@ -2152,7 +2125,13 @@ static void skl_display_core_init(struct 
drm_i915_private *dev_priv,
 
/* enable PG1 and Misc I/O */
mutex_lock(_domains->lock);
-   skl_pw1_misc_io_init(dev_priv);
+
+   well = lookup_power_well(dev_priv, SKL_DISP_PW_1);
+   intel_power_well_enable(dev_priv, well);
+
+   well = lookup_power_well(dev_priv, SKL_DISP_PW_MISC_IO);
+   intel_power_well_enable(dev_priv, well);
+
mutex_unlock(_domains->lock);
 
if (!resume)
@@ -2167,6 +2146,7 @@ static void skl_display_core_init(struct drm_i915_private 
*dev_priv,
 static void skl_display_core_uninit(struct drm_i915_private *dev_priv)
 {
struct i915_power_domains *power_domains = _priv->power_domains;
+   struct i915_power_well *well;
 
gen9_set_dc_state(dev_priv, DC_STATE_DISABLE);
 
@@ -2174,8 +2154,15 @@ static void skl_display_core_uninit(struct 
drm_i915_private *dev_priv)
 
/* The spec doesn't call for removing the reset handshake flag */
/* disable PG1 and Misc I/O */
+
mutex_lock(_domains->lock);
-   skl_pw1_misc_io_fini(dev_priv);
+
+   well = lookup_power_well(dev_priv, SKL_DISP_PW_MISC_IO);
+   intel_power_well_disable(dev_priv, well);
+
+   well = lookup_power_well(dev_priv, SKL_DISP_PW_1);
+   intel_power_well_disable(dev_priv, well);
+
mutex_unlock(_domains->lock);
 }
 
-- 
2.5.0

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Move execlists irq handler to a bottom half (rev4)

[Tvrtko Ursulin]

On 04/04/16 13:33, Patchwork wrote:

== Series Details ==

Series: drm/i915: Move execlists irq handler to a bottom half (rev4)
URL   : https://patchwork.freedesktop.org/series/4764/
State : failure

== Summary ==

Series 4764v4 drm/i915: Move execlists irq handler to a bottom half
http://patchwork.freedesktop.org/api/1.0/series/4764/revisions/4/mbox/

Test gem_sync:
 Subgroup basic-bsd:
 pass   -> DMESG-FAIL (ilk-hp8440p)


Unrelated hangcheck timer elapsed on ILK: 
https://bugs.freedesktop.org/show_bug.cgi?id=94307



Test kms_pipe_crc_basic:
 Subgroup suspend-read-crc-pipe-a:
 incomplete -> PASS   (skl-nuci5)

bdw-nuci7total:196  pass:184  dwarn:0   dfail:0   fail:0   skip:12
bdw-ultratotal:196  pass:175  dwarn:0   dfail:0   fail:0   skip:21
bsw-nuc-2total:196  pass:159  dwarn:0   dfail:0   fail:0   skip:37
byt-nuc  total:196  pass:161  dwarn:0   dfail:0   fail:0   skip:35
hsw-brixbox  total:196  pass:174  dwarn:0   dfail:0   fail:0   skip:22
hsw-gt2  total:196  pass:179  dwarn:0   dfail:0   fail:0   skip:17
ilk-hp8440p  total:196  pass:131  dwarn:0   dfail:1   fail:0   skip:64
ivb-t430stotal:196  pass:171  dwarn:0   dfail:0   fail:0   skip:25
skl-i7k-2total:196  pass:173  dwarn:0   dfail:0   fail:0   skip:23
skl-nuci5total:105  pass:100  dwarn:0   dfail:0   fail:0   skip:4
snb-dellxps  total:196  pass:162  dwarn:0   dfail:0   fail:0   skip:34
snb-x220ttotal:164  pass:139  dwarn:0   dfail:0   fail:0   skip:25

Results at /archive/results/CI_IGT_test/Patchwork_1786/

3e353ec38c8fe68e9a243a9388389a8815115451 drm-intel-nightly: 
2016y-04m-04d-11h-13m-54s UTC integration manifest
95dc10d4f71a6cf473aa874b0a74036f251aef8c drm/i915: Move execlists irq handler 
to a bottom half


So cross fingers and merge?

Regards,

Tvrtko

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 08/16] drm/i915/skl: Unexport skl_pw1_misc_io_init

[Imre Deak]

On ma, 2016-04-04 at 14:30 +0200, Patrik Jakobsson wrote:
> On Fri, Apr 01, 2016 at 04:02:39PM +0300, Imre Deak wrote:
> > On Broxton we need to enable/disable power well 1 during the
> > init/unit display
> > sequence similarly to Skylake/Kabylake. The code for this will be
> > added in a
> > follow-up patch, but to prepare for that unexport
> > skl_pw1_misc_io_init(). It's
> > a simple function called only from a single place and having it
> > inlined in the
> > Skylake display core init/unit functions will make it easier to
> > compare it
> > with its Broxton counterpart.
> > 
> > No functional change.
> > 
> > Signed-off-by: Imre Deak 
> > ---
> >  drivers/gpu/drm/i915/intel_drv.h|  2 --
> >  drivers/gpu/drm/i915/intel_runtime_pm.c | 49 -
> > 
> >  2 files changed, 18 insertions(+), 33 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/intel_drv.h
> > b/drivers/gpu/drm/i915/intel_drv.h
> > index 9255b56..8ba2ac3 100644
> > --- a/drivers/gpu/drm/i915/intel_drv.h
> > +++ b/drivers/gpu/drm/i915/intel_drv.h
> > @@ -1460,8 +1460,6 @@ int intel_power_domains_init(struct
> > drm_i915_private *);
> >  void intel_power_domains_fini(struct drm_i915_private *);
> >  void intel_power_domains_init_hw(struct drm_i915_private
> > *dev_priv, bool resume);
> >  void intel_power_domains_suspend(struct drm_i915_private
> > *dev_priv);
> > -void skl_pw1_misc_io_init(struct drm_i915_private *dev_priv);
> > -void skl_pw1_misc_io_fini(struct drm_i915_private *dev_priv);
> >  void intel_runtime_pm_enable(struct drm_i915_private *dev_priv);
> >  const char *
> >  intel_display_power_domain_str(enum intel_display_power_domain
> > domain);
> > diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c
> > b/drivers/gpu/drm/i915/intel_runtime_pm.c
> > index b16315e..58ed8bc 100644
> > --- a/drivers/gpu/drm/i915/intel_runtime_pm.c
> > +++ b/drivers/gpu/drm/i915/intel_runtime_pm.c
> > @@ -1921,34 +1921,6 @@ static struct i915_power_well
> > skl_power_wells[] = {
> >     },
> >  };
> >  
> > -void skl_pw1_misc_io_init(struct drm_i915_private *dev_priv)
> > -{
> > -   struct i915_power_well *well;
> > -
> > -   if (!(IS_SKYLAKE(dev_priv) || IS_KABYLAKE(dev_priv)))
> > -   return;
> > -
> > -   well = lookup_power_well(dev_priv, SKL_DISP_PW_1);
> > -   intel_power_well_enable(dev_priv, well);
> > -
> > -   well = lookup_power_well(dev_priv, SKL_DISP_PW_MISC_IO);
> > -   intel_power_well_enable(dev_priv, well);
> > -}
> > -
> > -void skl_pw1_misc_io_fini(struct drm_i915_private *dev_priv)
> > -{
> > -   struct i915_power_well *well;
> > -
> > -   if (!(IS_SKYLAKE(dev_priv) || IS_KABYLAKE(dev_priv)))
> > -   return;
> > -
> > -   well = lookup_power_well(dev_priv, SKL_DISP_PW_1);
> > -   intel_power_well_disable(dev_priv, well);
> > -
> > -   well = lookup_power_well(dev_priv, SKL_DISP_PW_MISC_IO);
> > -   intel_power_well_disable(dev_priv, well);
> > -}
> > -
> >  static struct i915_power_well bxt_power_wells[] = {
> >     {
> >     .name = "always-on",
> > @@ -2139,9 +2111,10 @@ static void
> > intel_power_domains_sync_hw(struct drm_i915_private *dev_priv)
> >  }
> >  
> >  static void skl_display_core_init(struct drm_i915_private
> > *dev_priv,
> > -     bool resume)
> > +      bool resume)
> >  {
> >     struct i915_power_domains *power_domains = _priv-
> > >power_domains;
> > +   struct i915_power_well *well;
> >     uint32_t val;
> >  
> >     gen9_set_dc_state(dev_priv, DC_STATE_DISABLE);
> > @@ -2152,7 +2125,13 @@ static void skl_display_core_init(struct
> > drm_i915_private *dev_priv,
> >  
> >     /* enable PG1 and Misc I/O */
> >     mutex_lock(_domains->lock);
> > -   skl_pw1_misc_io_init(dev_priv);
> > +
> > +   well = lookup_power_well(dev_priv, SKL_DISP_PW_1);
> > +   intel_power_well_enable(dev_priv, well);
> > +
> > +   well = lookup_power_well(dev_priv, SKL_DISP_PW_MISC_IO);
> > +   intel_power_well_enable(dev_priv, well);
> > +
> >     mutex_unlock(_domains->lock);
> >  
> >     if (!resume)
> > @@ -2167,6 +2146,7 @@ static void skl_display_core_init(struct
> > drm_i915_private *dev_priv,
> >  static void skl_display_core_uninit(struct drm_i915_private
> > *dev_priv)
> >  {
> >     struct i915_power_domains *power_domains = _priv-
> > >power_domains;
> > +   struct i915_power_well *well;
> >  
> >     gen9_set_dc_state(dev_priv, DC_STATE_DISABLE);
> >  
> > @@ -2174,8 +2154,15 @@ static void skl_display_core_uninit(struct
> > drm_i915_private *dev_priv)
> >  
> >     /* The spec doesn't call for removing the reset handshake
> > flag */
> >     /* disable PG1 and Misc I/O */
> > +
> >     mutex_lock(_domains->lock);
> > -   skl_pw1_misc_io_fini(dev_priv);
> > +
> > +   well = lookup_power_well(dev_priv, SKL_DISP_PW_MISC_IO);
> > +   intel_power_well_enable(dev_priv, well);
> 
> Should be intel_power_well_disable(...)
> 
> > +
> > +   well = lookup_power_well(dev_priv, SKL_DISP_PW_1);
> > 

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Move execlists irq handler to a bottom half (rev4)

[Patchwork]

== Series Details ==

Series: drm/i915: Move execlists irq handler to a bottom half (rev4)
URL   : https://patchwork.freedesktop.org/series/4764/
State : failure

== Summary ==

Series 4764v4 drm/i915: Move execlists irq handler to a bottom half
http://patchwork.freedesktop.org/api/1.0/series/4764/revisions/4/mbox/

Test gem_sync:
Subgroup basic-bsd:
pass   -> DMESG-FAIL (ilk-hp8440p)
Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-a:
incomplete -> PASS   (skl-nuci5)

bdw-nuci7total:196  pass:184  dwarn:0   dfail:0   fail:0   skip:12 
bdw-ultratotal:196  pass:175  dwarn:0   dfail:0   fail:0   skip:21 
bsw-nuc-2total:196  pass:159  dwarn:0   dfail:0   fail:0   skip:37 
byt-nuc  total:196  pass:161  dwarn:0   dfail:0   fail:0   skip:35 
hsw-brixbox  total:196  pass:174  dwarn:0   dfail:0   fail:0   skip:22 
hsw-gt2  total:196  pass:179  dwarn:0   dfail:0   fail:0   skip:17 
ilk-hp8440p  total:196  pass:131  dwarn:0   dfail:1   fail:0   skip:64 
ivb-t430stotal:196  pass:171  dwarn:0   dfail:0   fail:0   skip:25 
skl-i7k-2total:196  pass:173  dwarn:0   dfail:0   fail:0   skip:23 
skl-nuci5total:105  pass:100  dwarn:0   dfail:0   fail:0   skip:4  
snb-dellxps  total:196  pass:162  dwarn:0   dfail:0   fail:0   skip:34 
snb-x220ttotal:164  pass:139  dwarn:0   dfail:0   fail:0   skip:25 

Results at /archive/results/CI_IGT_test/Patchwork_1786/

3e353ec38c8fe68e9a243a9388389a8815115451 drm-intel-nightly: 
2016y-04m-04d-11h-13m-54s UTC integration manifest
95dc10d4f71a6cf473aa874b0a74036f251aef8c drm/i915: Move execlists irq handler 
to a bottom half

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 08/16] drm/i915/skl: Unexport skl_pw1_misc_io_init

[Patrik Jakobsson]

On Fri, Apr 01, 2016 at 04:02:39PM +0300, Imre Deak wrote:
> On Broxton we need to enable/disable power well 1 during the init/unit display
> sequence similarly to Skylake/Kabylake. The code for this will be added in a
> follow-up patch, but to prepare for that unexport skl_pw1_misc_io_init(). It's
> a simple function called only from a single place and having it inlined in the
> Skylake display core init/unit functions will make it easier to compare it
> with its Broxton counterpart.
> 
> No functional change.
> 
> Signed-off-by: Imre Deak 
> ---
>  drivers/gpu/drm/i915/intel_drv.h|  2 --
>  drivers/gpu/drm/i915/intel_runtime_pm.c | 49 
> -
>  2 files changed, 18 insertions(+), 33 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_drv.h 
> b/drivers/gpu/drm/i915/intel_drv.h
> index 9255b56..8ba2ac3 100644
> --- a/drivers/gpu/drm/i915/intel_drv.h
> +++ b/drivers/gpu/drm/i915/intel_drv.h
> @@ -1460,8 +1460,6 @@ int intel_power_domains_init(struct drm_i915_private *);
>  void intel_power_domains_fini(struct drm_i915_private *);
>  void intel_power_domains_init_hw(struct drm_i915_private *dev_priv, bool 
> resume);
>  void intel_power_domains_suspend(struct drm_i915_private *dev_priv);
> -void skl_pw1_misc_io_init(struct drm_i915_private *dev_priv);
> -void skl_pw1_misc_io_fini(struct drm_i915_private *dev_priv);
>  void intel_runtime_pm_enable(struct drm_i915_private *dev_priv);
>  const char *
>  intel_display_power_domain_str(enum intel_display_power_domain domain);
> diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c 
> b/drivers/gpu/drm/i915/intel_runtime_pm.c
> index b16315e..58ed8bc 100644
> --- a/drivers/gpu/drm/i915/intel_runtime_pm.c
> +++ b/drivers/gpu/drm/i915/intel_runtime_pm.c
> @@ -1921,34 +1921,6 @@ static struct i915_power_well skl_power_wells[] = {
>   },
>  };
>  
> -void skl_pw1_misc_io_init(struct drm_i915_private *dev_priv)
> -{
> - struct i915_power_well *well;
> -
> - if (!(IS_SKYLAKE(dev_priv) || IS_KABYLAKE(dev_priv)))
> - return;
> -
> - well = lookup_power_well(dev_priv, SKL_DISP_PW_1);
> - intel_power_well_enable(dev_priv, well);
> -
> - well = lookup_power_well(dev_priv, SKL_DISP_PW_MISC_IO);
> - intel_power_well_enable(dev_priv, well);
> -}
> -
> -void skl_pw1_misc_io_fini(struct drm_i915_private *dev_priv)
> -{
> - struct i915_power_well *well;
> -
> - if (!(IS_SKYLAKE(dev_priv) || IS_KABYLAKE(dev_priv)))
> - return;
> -
> - well = lookup_power_well(dev_priv, SKL_DISP_PW_1);
> - intel_power_well_disable(dev_priv, well);
> -
> - well = lookup_power_well(dev_priv, SKL_DISP_PW_MISC_IO);
> - intel_power_well_disable(dev_priv, well);
> -}
> -
>  static struct i915_power_well bxt_power_wells[] = {
>   {
>   .name = "always-on",
> @@ -2139,9 +2111,10 @@ static void intel_power_domains_sync_hw(struct 
> drm_i915_private *dev_priv)
>  }
>  
>  static void skl_display_core_init(struct drm_i915_private *dev_priv,
> -   bool resume)
> +bool resume)
>  {
>   struct i915_power_domains *power_domains = _priv->power_domains;
> + struct i915_power_well *well;
>   uint32_t val;
>  
>   gen9_set_dc_state(dev_priv, DC_STATE_DISABLE);
> @@ -2152,7 +2125,13 @@ static void skl_display_core_init(struct 
> drm_i915_private *dev_priv,
>  
>   /* enable PG1 and Misc I/O */
>   mutex_lock(_domains->lock);
> - skl_pw1_misc_io_init(dev_priv);
> +
> + well = lookup_power_well(dev_priv, SKL_DISP_PW_1);
> + intel_power_well_enable(dev_priv, well);
> +
> + well = lookup_power_well(dev_priv, SKL_DISP_PW_MISC_IO);
> + intel_power_well_enable(dev_priv, well);
> +
>   mutex_unlock(_domains->lock);
>  
>   if (!resume)
> @@ -2167,6 +2146,7 @@ static void skl_display_core_init(struct 
> drm_i915_private *dev_priv,
>  static void skl_display_core_uninit(struct drm_i915_private *dev_priv)
>  {
>   struct i915_power_domains *power_domains = _priv->power_domains;
> + struct i915_power_well *well;
>  
>   gen9_set_dc_state(dev_priv, DC_STATE_DISABLE);
>  
> @@ -2174,8 +2154,15 @@ static void skl_display_core_uninit(struct 
> drm_i915_private *dev_priv)
>  
>   /* The spec doesn't call for removing the reset handshake flag */
>   /* disable PG1 and Misc I/O */
> +
>   mutex_lock(_domains->lock);
> - skl_pw1_misc_io_fini(dev_priv);
> +
> + well = lookup_power_well(dev_priv, SKL_DISP_PW_MISC_IO);
> + intel_power_well_enable(dev_priv, well);

Should be intel_power_well_disable(...)

> +
> + well = lookup_power_well(dev_priv, SKL_DISP_PW_1);
> + intel_power_well_enable(dev_priv, well);

Same here.

> +
>   mutex_unlock(_domains->lock);
>  }
>  
> -- 
> 2.5.0
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> 

[Intel-gfx] [PATCH 12/12] DO_NOT_MERGE: drm/i915: Hack to enable lspcon initialization

[Shashank Sharma]

This patch adds a hack to enable lspcon on GEN9 devices.
This should not be merged, and the hack must be replaced
by proper VBT parsing logic.

Expecting this patch to enable lspcon bits in VBT:
https://lists.freedesktop.org/archives/intel-gfx/2016-March/089541.html

Signed-off-by: Shashank Sharma 
---
 drivers/gpu/drm/i915/intel_ddi.c| 15 +++
 drivers/gpu/drm/i915/intel_drv.h|  4 
 drivers/gpu/drm/i915/intel_lspcon.c | 10 ++
 3 files changed, 29 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index 91654ff..f6c2869 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -2169,6 +2169,21 @@ void intel_ddi_init(struct drm_device *dev, enum port 
port)
intel_encoder->crtc_mask = (1 << 0) | (1 << 1) | (1 << 2);
intel_encoder->cloneable = 0;
 
+
+   /* Check if LSPCON is configured on this port */
+   if (is_lspcon_present_on_port(dev_priv, intel_dig_port->port)) {
+   if (!intel_lspcon_init_connector(intel_dig_port)) {
+   DRM_DEBUG_KMS("LSPCON configured for port %c\n",
+   port_name(intel_dig_port->port));
+   return;
+   } else {
+   DRM_ERROR("Can't set LSPCON(port %c), falling to 
DP/HDMI\n",
+   port_name(intel_dig_port->port));
+   init_dp = true;
+   init_hdmi = true;
+   }
+   }
+
if (init_dp) {
if (!intel_ddi_init_dp_connector(intel_dig_port))
goto err;
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index a6ec946..922852c 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -1345,6 +1345,10 @@ void intel_dsi_init(struct drm_device *dev);
 /* intel_dvo.c */
 void intel_dvo_init(struct drm_device *dev);
 
+/* intel_lspcon.c */
+int intel_lspcon_init_connector(struct intel_digital_port *intel_dig_port);
+bool is_lspcon_present_on_port(struct drm_i915_private * dev_priv,
+   enum port port);
 
 /* legacy fbdev emulation in intel_fbdev.c */
 #ifdef CONFIG_DRM_FBDEV_EMULATION
diff --git a/drivers/gpu/drm/i915/intel_lspcon.c 
b/drivers/gpu/drm/i915/intel_lspcon.c
index 20f90e0..96e4c71 100644
--- a/drivers/gpu/drm/i915/intel_lspcon.c
+++ b/drivers/gpu/drm/i915/intel_lspcon.c
@@ -397,6 +397,16 @@ static const struct drm_connector_helper_funcs 
lspcon_connector_helper_funcs = {
.best_encoder = intel_best_encoder,
 };
 
+bool is_lspcon_present_on_port(struct drm_i915_private *dev_priv, enum port 
port)
+{
+   /*
+   * TODO: HACK
+   * Replace this with proper VBT child dev config check
+   * logic once that patch is available in tree
+   */
+   return IS_GEN9(dev_priv->dev) && (port == PORT_B);
+}
+
 int intel_lspcon_init_connector(struct intel_digital_port *intel_dig_port)
 {
int ret;
-- 
1.9.1

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 07/12] drm/i915: Add and initialize lspcon connector

[Shashank Sharma]

lspcon is a device which acts as DP in some cases
and as HDMI in some. Here is how:
- lspcon needs DP(aux) for all the i2c_ove_aux read/write
  transitions so it needs to have some DP level initializations
- lspcon is detected by userspace/sink as HDMI device, so
  it needs to be detectd as HDMI device.

This patch adds a custom connector for lspcon device, which
can pick and chose what it wants from existing functionality.

This patch also adds functions to initialize dp and hdmi connectors
and structures to the minimum required levels, and then play around.

Signed-off-by: Shashank Sharma 
---
 drivers/gpu/drm/i915/intel_dp.c | 31 +++
 drivers/gpu/drm/i915/intel_drv.h|  4 ++
 drivers/gpu/drm/i915/intel_hdmi.c   | 17 
 drivers/gpu/drm/i915/intel_lspcon.c | 79 +
 4 files changed, 131 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index ba4da0c..f3df1c6 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -5900,6 +5900,37 @@ fail:
return false;
 }
 
+int intel_dp_init_minimum(struct intel_digital_port *intel_dig_port,
+   struct intel_connector *intel_connector)
+{
+   int ret;
+   enum port port = intel_dig_port->port;
+   struct intel_dp *intel_dp = _dig_port->dp;
+   struct drm_device *dev = intel_dig_port->base.base.dev;
+   struct drm_i915_private *dev_priv = dev->dev_private;
+
+   intel_dig_port->dp.output_reg = DDI_BUF_CTL(port);
+   if (WARN(intel_dig_port->max_lanes < 1,
+"Not enough lanes (%d) for DP on port %c\n",
+intel_dig_port->max_lanes, port_name(port)))
+   return -EINVAL;
+
+   intel_dp->pps_pipe = INVALID_PIPE;
+   intel_dp->get_aux_clock_divider = skl_get_aux_clock_divider;
+   intel_dp->get_aux_send_ctl = skl_get_aux_send_ctl;
+   intel_dp->prepare_link_retrain = intel_ddi_prepare_link_retrain;
+   intel_dp->DP = I915_READ(intel_dp->output_reg);
+   intel_dp->attached_connector = intel_connector;
+   INIT_DELAYED_WORK(_dp->panel_vdd_work,
+ edp_panel_vdd_work);
+
+   ret = intel_dp_aux_init(intel_dp, intel_connector);
+   if (ret)
+   DRM_ERROR("Aux init for LSPCON failed\n");
+
+   return ret;
+}
+
 void
 intel_dp_init(struct drm_device *dev,
  i915_reg_t output_reg, enum port port)
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 6e309ea..d38db7d 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -1332,6 +1332,8 @@ void intel_dp_compute_rate(struct intel_dp *intel_dp, int 
port_clock,
 bool intel_dp_source_supports_hbr2(struct intel_dp *intel_dp);
 bool
 intel_dp_get_link_status(struct intel_dp *intel_dp, uint8_t 
link_status[DP_LINK_STATUS_SIZE]);
+int intel_dp_init_minimum(struct intel_digital_port *intel_dig_port,
+   struct intel_connector *intel_connector);
 
 /* intel_dp_mst.c */
 int intel_dp_mst_encoder_init(struct intel_digital_port *intel_dig_port, int 
conn_id);
@@ -1397,6 +1399,8 @@ void intel_fbc_cleanup_cfb(struct drm_i915_private 
*dev_priv);
 void intel_hdmi_init(struct drm_device *dev, i915_reg_t hdmi_reg, enum port 
port);
 void intel_hdmi_init_connector(struct intel_digital_port *intel_dig_port,
   struct intel_connector *intel_connector);
+int intel_hdmi_init_minimum(struct intel_digital_port *intel_dig_port,
+   struct intel_connector *intel_connector);
 struct intel_hdmi *enc_to_intel_hdmi(struct drm_encoder *encoder);
 bool intel_hdmi_compute_config(struct intel_encoder *encoder,
   struct intel_crtc_state *pipe_config);
diff --git a/drivers/gpu/drm/i915/intel_hdmi.c 
b/drivers/gpu/drm/i915/intel_hdmi.c
index 22b5a7e..92f5094 100644
--- a/drivers/gpu/drm/i915/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/intel_hdmi.c
@@ -2128,6 +2128,23 @@ intel_hdmi_add_properties(struct intel_hdmi *intel_hdmi, 
struct drm_connector *c
intel_hdmi->aspect_ratio = HDMI_PICTURE_ASPECT_NONE;
 }
 
+int intel_hdmi_init_minimum(struct intel_digital_port *intel_dig_port,
+  struct intel_connector *intel_connector)
+{
+   struct intel_hdmi *intel_hdmi = _dig_port->hdmi;
+
+   if (WARN(intel_dig_port->max_lanes < 4,
+   "Not enough lanes (%d) for HDMI on port %c\n",
+   intel_dig_port->max_lanes, port_name(intel_dig_port->port)))
+   return -EINVAL;
+
+   intel_hdmi->write_infoframe = hsw_write_infoframe;
+   intel_hdmi->set_infoframes = hsw_set_infoframes;
+   intel_hdmi->infoframe_enabled = hsw_infoframe_enabled;
+   intel_hdmi->attached_connector = intel_connector;
+   return 0;
+}
+
 void intel_hdmi_init_connector(struct intel_digital_port *intel_dig_port,
  

[Intel-gfx] [PATCH 09/12] drm/i915: Add and register lspcon connector functions

[Shashank Sharma]

This patch adds various lspcon connector functions. Some
of the functions are newly written, to meet the specific
needs of lspcon HW, whereas few of them are just an
abstraction layer on existing HDMI connector functions.

Signed-off-by: Shashank Sharma 
---
 drivers/gpu/drm/i915/intel_drv.h |  11 +-
 drivers/gpu/drm/i915/intel_hdmi.c|   8 +-
 drivers/gpu/drm/i915/intel_hotplug.c |   2 +-
 drivers/gpu/drm/i915/intel_lspcon.c  | 195 ++-
 4 files changed, 207 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index d38db7d..a6ec946 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -1404,7 +1404,12 @@ int intel_hdmi_init_minimum(struct intel_digital_port 
*intel_dig_port,
 struct intel_hdmi *enc_to_intel_hdmi(struct drm_encoder *encoder);
 bool intel_hdmi_compute_config(struct intel_encoder *encoder,
   struct intel_crtc_state *pipe_config);
-
+int intel_hdmi_get_modes(struct drm_connector *connector);
+int intel_hdmi_set_property(struct drm_connector *connector,
+   struct drm_property *property, uint64_t val);
+void intel_hdmi_destroy(struct drm_connector *connector);
+void intel_hdmi_add_properties(struct intel_hdmi *intel_hdmi,
+   struct drm_connector *connector);
 
 /* intel_lvds.c */
 void intel_lvds_init(struct drm_device *dev);
@@ -1493,6 +1498,10 @@ bool intel_display_power_get_if_enabled(struct 
drm_i915_private *dev_priv,
 void intel_display_power_put(struct drm_i915_private *dev_priv,
 enum intel_display_power_domain domain);
 
+/* intel_hotplug.c */
+bool intel_hpd_irq_event(struct drm_device *dev,
+   struct drm_connector *connector);
+
 static inline void
 assert_rpm_device_not_suspended(struct drm_i915_private *dev_priv)
 {
diff --git a/drivers/gpu/drm/i915/intel_hdmi.c 
b/drivers/gpu/drm/i915/intel_hdmi.c
index 92f5094..3f7919d 100644
--- a/drivers/gpu/drm/i915/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/intel_hdmi.c
@@ -1540,7 +1540,7 @@ intel_hdmi_force(struct drm_connector *connector)
hdmi_to_dig_port(intel_hdmi)->base.type = INTEL_OUTPUT_HDMI;
 }
 
-static int intel_hdmi_get_modes(struct drm_connector *connector)
+int intel_hdmi_get_modes(struct drm_connector *connector)
 {
struct edid *edid;
 
@@ -1564,7 +1564,7 @@ intel_hdmi_detect_audio(struct drm_connector *connector)
return has_audio;
 }
 
-static int
+int
 intel_hdmi_set_property(struct drm_connector *connector,
struct drm_property *property,
uint64_t val)
@@ -2089,7 +2089,7 @@ static void chv_hdmi_pre_enable(struct intel_encoder 
*encoder)
}
 }
 
-static void intel_hdmi_destroy(struct drm_connector *connector)
+void intel_hdmi_destroy(struct drm_connector *connector)
 {
kfree(to_intel_connector(connector)->detect_edid);
drm_connector_cleanup(connector);
@@ -2118,7 +2118,7 @@ static const struct drm_encoder_funcs 
intel_hdmi_enc_funcs = {
.destroy = intel_encoder_destroy,
 };
 
-static void
+void
 intel_hdmi_add_properties(struct intel_hdmi *intel_hdmi, struct drm_connector 
*connector)
 {
intel_attach_force_audio_property(connector);
diff --git a/drivers/gpu/drm/i915/intel_hotplug.c 
b/drivers/gpu/drm/i915/intel_hotplug.c
index bee6730..11a3e02 100644
--- a/drivers/gpu/drm/i915/intel_hotplug.c
+++ b/drivers/gpu/drm/i915/intel_hotplug.c
@@ -226,7 +226,7 @@ static void intel_hpd_irq_storm_reenable_work(struct 
work_struct *work)
intel_runtime_pm_put(dev_priv);
 }
 
-static bool intel_hpd_irq_event(struct drm_device *dev,
+bool intel_hpd_irq_event(struct drm_device *dev,
struct drm_connector *connector)
 {
enum drm_connector_status old_status;
diff --git a/drivers/gpu/drm/i915/intel_lspcon.c 
b/drivers/gpu/drm/i915/intel_lspcon.c
index e179758..c3c1cd2 100644
--- a/drivers/gpu/drm/i915/intel_lspcon.c
+++ b/drivers/gpu/drm/i915/intel_lspcon.c
@@ -55,6 +55,178 @@ struct intel_lspcon *enc_to_lspcon(struct drm_encoder 
*encoder)
return _dig_port->lspcon;
 }
 
+static struct intel_lspcon
+*intel_attached_lspcon(struct drm_connector *connector)
+{
+   return enc_to_lspcon(_attached_encoder(connector)->base);
+}
+
+struct edid *lspcon_get_edid(struct intel_lspcon *lspcon, struct drm_connector
+   *connector)
+{
+   struct edid *edid = NULL;
+   struct intel_digital_port *dig_port = lspcon_to_dig_port(lspcon);
+   struct i2c_adapter *adapter = _port->dp.aux.ddc;
+
+   if (lspcon->mode_of_op != lspcon_mode_ls) {
+   DRM_ERROR("EDID read supported in LS mode only\n");
+   return false;
+   }
+
+   /* LS mode, getting EDID using I2C over Aux */
+   edid = drm_do_get_edid(connector, drm_dp_dual_mode_get_edid,
+   

[Intel-gfx] [PATCH 06/12] drm/i915: Add new lspcon file

[Shashank Sharma]

This patch adds a new file for lspcon with
some basic stuff like:
- Some read/wrire addresses for lspcon device
- Basic read/write functions, using i2c over aux channel
- Utility functions to get lspcon/encoder/connector

Signed-off-by: Shashank Sharma 
Signed-off-by: Akashdeep Sharma 
---
 drivers/gpu/drm/i915/Makefile   |  3 +-
 drivers/gpu/drm/i915/intel_lspcon.c | 56 +
 2 files changed, 58 insertions(+), 1 deletion(-)
 create mode 100644 drivers/gpu/drm/i915/intel_lspcon.c

diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 5558a03..00a531a 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -90,7 +90,8 @@ i915-y += dvo_ch7017.o \
  intel_lvds.o \
  intel_panel.o \
  intel_sdvo.o \
- intel_tv.o
+ intel_tv.o \
+ intel_lspcon.o
 
 # virtual gpu code
 i915-y += i915_vgpu.o
diff --git a/drivers/gpu/drm/i915/intel_lspcon.c 
b/drivers/gpu/drm/i915/intel_lspcon.c
new file mode 100644
index 000..5a1993b
--- /dev/null
+++ b/drivers/gpu/drm/i915/intel_lspcon.c
@@ -0,0 +1,56 @@
+/*
+ * 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.
+ *
+ * Authors:
+ * Shashank Sharma 
+ * Akashdeep Sharma 
+ *
+ */
+#include 
+#include 
+#include 
+#include "intel_drv.h"
+
+#define LSPCON_I2C_ADDRESS 0x80
+#define LSPCON_MODE_CHANGE_OFFSET  0x40
+#define LSPCON_MODE_CHECK_OFFSET   0x41
+#define LSPCON_ADAPTER_SIGN_OFFSET 0x00
+#define LSPCON_IDENTIFIER_OFFSET   0x10
+#define LSPCON_IDENTIFIER_LENGTH   0x10
+#define LSPCON_MODE_MASK   0x1
+
+struct intel_digital_port *lspcon_to_dig_port(struct intel_lspcon *lspcon)
+{
+   return container_of(lspcon, struct intel_digital_port, lspcon);
+}
+
+struct intel_hdmi *lspcon_to_hdmi(struct intel_lspcon *lspcon)
+{
+   return _to_dig_port(lspcon)->hdmi;
+}
+
+struct intel_lspcon *enc_to_lspcon(struct drm_encoder *encoder)
+{
+   struct intel_digital_port *intel_dig_port =
+   container_of(encoder, struct intel_digital_port, base.base);
+   return _dig_port->lspcon;
+}
-- 
1.9.1

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 05/12] drm/i915: Add lspcon data structures

[Shashank Sharma]

This patch adds lspcon structure in intel_dig_port.
These strucres will be used to check runtime status
of LSPCON device.

Signed-off-by: Shashank Sharma 
Signed-off-by: Akashdeep Sharma 
---
 drivers/gpu/drm/i915/intel_drv.h | 16 
 1 file changed, 16 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 26ef950..6e309ea 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -859,12 +859,28 @@ struct intel_dp {
bool compliance_test_active;
 };
 
+/* LSPCON possibe modes of operation */
+enum lspcon_mode {
+   /* Invalid */
+   lspcon_mode_invalid,
+   /* level shifter mode */
+   lspcon_mode_ls,
+   /* protocol converter mode */
+   lspcon_mode_pcon,
+};
+
+struct intel_lspcon {
+   bool active;
+   enum lspcon_mode mode_of_op;
+};
+
 struct intel_digital_port {
struct intel_encoder base;
enum port port;
u32 saved_port_bits;
struct intel_dp dp;
struct intel_hdmi hdmi;
+   struct intel_lspcon lspcon;
enum irqreturn (*hpd_pulse)(struct intel_digital_port *, bool);
bool release_cl2_override;
uint8_t max_lanes;
-- 
1.9.1

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 10/12] drm/i915: Add lspcon core functions

[Shashank Sharma]

This patch adds lspcon's internal functions, which work
on the probe layer, and indicate the working status of
lspcon, which are mostly:

probe: A lspcon device is probed only once, during boot
time, as its always present with the device, next to port.
So the i2c_over_aux channel is alwyas read/writeable if DC is
powered on. If VBT says that this port contains lspcon, we
check and probe the HW to verify and initialize it.

get_mode: This function indicates the current mode of operation
of lspcon (ls or pcon mode)

change_mode: This function can change the lspcon's mode of
operation to desired mode.

Signed-off-by: Shashank Sharma 
Signed-off-by: Akashdeep Sharma 
---
 drivers/gpu/drm/i915/intel_lspcon.c | 145 
 1 file changed, 145 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_lspcon.c 
b/drivers/gpu/drm/i915/intel_lspcon.c
index c3c1cd2..617fe3f 100644
--- a/drivers/gpu/drm/i915/intel_lspcon.c
+++ b/drivers/gpu/drm/i915/intel_lspcon.c
@@ -61,6 +61,144 @@ static struct intel_lspcon
return enc_to_lspcon(_attached_encoder(connector)->base);
 }
 
+enum lspcon_mode lspcon_get_current_mode(struct intel_lspcon *lspcon)
+{
+   u8 data;
+   int err = 0;
+   struct intel_digital_port *dig_port = lspcon_to_dig_port(lspcon);
+   struct i2c_adapter *adapter = _port->dp.aux.ddc;
+
+   /* Read Status: i2c over aux */
+   err = drm_dp_dual_mode_ioa_read(adapter, ,
+   LSPCON_MODE_CHECK_OFFSET, sizeof(data));
+   if (err < 0) {
+   DRM_ERROR("LSPCON read mode ioa (0x80, 0x41) failed\n");
+   return lspcon_mode_invalid;
+   }
+
+   DRM_DEBUG_DRIVER("LSPCON mode (0x80, 0x41) = %x\n", (unsigned int)data);
+   return data & LSPCON_MODE_MASK ? lspcon_mode_pcon : lspcon_mode_ls;
+}
+
+int lspcon_change_mode(struct intel_lspcon *lspcon,
+   enum lspcon_mode mode, bool force)
+{
+   u8 data;
+   int err;
+   int time_out = 200;
+   enum lspcon_mode current_mode;
+   struct intel_digital_port *dig_port = lspcon_to_dig_port(lspcon);
+
+   current_mode = lspcon_get_current_mode(lspcon);
+   if (current_mode == lspcon_mode_invalid) {
+   DRM_ERROR("Failed to get current LSPCON mode\n");
+   return -EFAULT;
+   }
+
+   if (current_mode == mode && !force) {
+   DRM_DEBUG_DRIVER("Current mode = desired LSPCON mode\n");
+   return 0;
+   }
+
+   if (mode == lspcon_mode_ls)
+   data = ~LSPCON_MODE_MASK;
+   else
+   data = LSPCON_MODE_MASK;
+
+   /* Change mode */
+   err = drm_dp_dual_mode_ioa_write(_port->dp.aux.ddc, ,
+   LSPCON_MODE_CHANGE_OFFSET, sizeof(data));
+   if (err < 0) {
+   DRM_ERROR("LSPCON mode change failed\n");
+   return err;
+   }
+
+   /*
+   * Confirm mode change by reading the status bit.
+   * Sometimes, it takes a while to change the mode,
+   * so wait and retry until time out or done.
+   */
+   while (time_out) {
+   current_mode = lspcon_get_current_mode(lspcon);
+   if (current_mode != mode) {
+   mdelay(10);
+   time_out -= 10;
+   } else {
+   lspcon->mode_of_op = mode;
+   DRM_DEBUG_DRIVER("LSPCON mode changed to %s\n",
+   mode == lspcon_mode_ls ? "LS" : "PCON");
+   return 0;
+   }
+   }
+
+   DRM_ERROR("LSPCON mode change timed out\n");
+   return -EFAULT;
+}
+
+bool lspcon_detect_identifier(struct intel_lspcon *lspcon)
+{
+   enum drm_dp_dual_mode_type adaptor_type;
+   struct intel_digital_port *dig_port = lspcon_to_dig_port(lspcon);
+   struct i2c_adapter *adapter = _port->dp.aux.ddc;
+
+   /* Lets probe the adaptor and check its type */
+   adaptor_type = drm_dp_dual_mode_detect(adapter);
+   if (adaptor_type != DRM_DP_DUAL_MODE_TYPE2_LSPCON) {
+   DRM_DEBUG_DRIVER("No LSPCON detected, found %s\n",
+   drm_dp_get_dual_mode_type_name(adaptor_type));
+   return false;
+   }
+
+   /* Yay ... got a LSPCON device */
+   DRM_DEBUG_DRIVER("LSPCON detected\n");
+   return true;
+}
+
+enum lspcon_mode lspcon_probe(struct intel_lspcon *lspcon)
+{
+   enum lspcon_mode current_mode;
+
+   /* Detect a valid lspcon */
+   if (!lspcon_detect_identifier(lspcon)) {
+   DRM_DEBUG_DRIVER("Failed to find LSPCON identifier\n");
+   return false;
+   }
+
+   /* LSPCON's mode of operation */
+   current_mode = lspcon_get_current_mode(lspcon);
+   if (current_mode == lspcon_mode_invalid) {
+   DRM_ERROR("Failed to read LSPCON mode\n");
+   return false;
+   }
+
+   /* All is well */
+ 

[Intel-gfx] [PATCH 11/12] drm/i915: Add lspcon hpd handler

[Shashank Sharma]

This patch adds a new hpd handler for lspcon.
As lspcon has its own way of reading EDID and detecting
the device, it wont be efficient to use the existing hpd
functions to handle the hot_plug scenarios. This new function
reads the EDID and checks the status of the sink device.

Signed-off-by: Shashank Sharma 
---
 drivers/gpu/drm/i915/intel_lspcon.c | 35 +++
 1 file changed, 35 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_lspcon.c 
b/drivers/gpu/drm/i915/intel_lspcon.c
index 617fe3f..20f90e0 100644
--- a/drivers/gpu/drm/i915/intel_lspcon.c
+++ b/drivers/gpu/drm/i915/intel_lspcon.c
@@ -61,6 +61,38 @@ static struct intel_lspcon
return enc_to_lspcon(_attached_encoder(connector)->base);
 }
 
+enum irqreturn
+lspcon_hpd_pulse(struct intel_digital_port *intel_dig_port, bool long_hpd)
+{
+   struct drm_device *dev = intel_dig_port->base.base.dev;
+   struct intel_encoder *intel_encoder = _dig_port->base;
+   struct intel_connector *intel_connector;
+   bool changed = false;
+
+   mutex_lock(>mode_config.mutex);
+   if (intel_encoder->hot_plug)
+   intel_encoder->hot_plug(intel_encoder);
+
+   for_each_intel_connector(dev, intel_connector) {
+   if (intel_connector->encoder == intel_encoder) {
+   struct drm_connector *connector =
+   _connector->base;
+
+   DRM_DEBUG_DRIVER("Hptplug: Connector %s (pin %i).\n",
+   connector->name, intel_encoder->hpd_pin);
+   if (intel_hpd_irq_event(dev, connector))
+   changed = true;
+   }
+   }
+   mutex_unlock(>mode_config.mutex);
+
+   if (changed) {
+   DRM_DEBUG_DRIVER("Sending event for change\n");
+   drm_kms_helper_hotplug_event(dev);
+   }
+   return IRQ_HANDLED;
+}
+
 enum lspcon_mode lspcon_get_current_mode(struct intel_lspcon *lspcon)
 {
u8 data;
@@ -396,6 +428,9 @@ int intel_lspcon_init_connector(struct intel_digital_port 
*intel_dig_port)
intel_connector->get_hw_state = intel_ddi_connector_get_hw_state;
i915_debugfs_connector_add(connector);
 
+   /* HPD handler */
+   intel_dig_port->hpd_pulse = lspcon_hpd_pulse;
+
/* init DP */
ret = intel_dp_init_minimum(intel_dig_port, intel_connector);
if (ret) {
-- 
1.9.1

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 08/12] drm: Add lspcon (custom type2 dp->hdmi) support

[Shashank Sharma]

This patch adds support for LSPCON devices in dp++ adaptor
helper layer. LSPCON is DP++ type-2 adaptor with some customized
functionalities, to provide additional features in Intel Gen9 HW.

LSPCON needs I2C-over-aux support to read/write control and
data registers. This patch adds following:
  - Functions for I2C over aux read/write
  - Function to read EDID using I2c-over-aux
  - Function to identify LSPCON among type-2 DP adaptors

Signed-off-by: Shashank Sharma 
---
 drivers/gpu/drm/drm_dp_dual_mode_helper.c | 100 ++
 include/drm/drm_dp_dual_mode_helper.h |  10 +++
 2 files changed, 110 insertions(+)

diff --git a/drivers/gpu/drm/drm_dp_dual_mode_helper.c 
b/drivers/gpu/drm/drm_dp_dual_mode_helper.c
index b72b7bb..ce8e11c 100644
--- a/drivers/gpu/drm/drm_dp_dual_mode_helper.c
+++ b/drivers/gpu/drm/drm_dp_dual_mode_helper.c
@@ -132,6 +132,99 @@ ssize_t drm_dp_dual_mode_write(struct i2c_adapter *adapter,
 }
 EXPORT_SYMBOL(drm_dp_dual_mode_write);
 
+int drm_dp_dual_mode_get_edid(void *data,
+   u8 *buf, unsigned int block, size_t len)
+{
+   struct i2c_adapter *adapter = data;
+   unsigned char start = block * EDID_LENGTH;
+   unsigned char segment = block >> 1;
+   unsigned char xfers = segment ? 3 : 2;
+   int ret, retries = 5;
+
+   do {
+   struct i2c_msg msgs[] = {
+   {
+   .addr   = DP_DUAL_MODE_DDC_SEGMENT_ADDR,
+   .flags  = 0,
+   .len= 1,
+   .buf= ,
+   }, {
+   .addr   = DDC_ADDR,
+   .flags  = 0,
+   .len= 1,
+   .buf= ,
+   }, {
+   .addr   = DDC_ADDR,
+   .flags  = I2C_M_RD,
+   .len= len,
+   .buf= buf,
+   }
+   };
+
+   ret = adapter->algo->master_xfer(adapter, [3 - xfers],
+   xfers);
+
+   if (ret == -ENXIO) {
+   DRM_ERROR("Non-existent adapter %s\n",
+   adapter->name);
+   break;
+   }
+   } while (ret != xfers && --retries);
+
+   return ret == xfers ? 0 : -1;
+}
+EXPORT_SYMBOL(drm_dp_dual_mode_get_edid);
+
+/*
+* drm_dp_dual_mode_ioa_xfer
+* Few dp->hdmi type 2 adaptors allow i2c_over_aux read/write
+* to the control and status registers. These functions help
+* to read/write from those.
+*/
+static int drm_dp_dual_mode_ioa_xfer(struct i2c_adapter *adapter,
+   u8 *buffer, u8 offset, u8 no_of_bytes, u8 rw_flag)
+{
+   int err = 0;
+
+   struct i2c_msg msgs[] = {
+   {
+   .addr   = DP_DUAL_MODE_SLAVE_ADDRESS,
+   .flags  = 0,
+   .len= 1,
+   .buf= ,
+   }, {
+   .addr   = DP_DUAL_MODE_SLAVE_ADDRESS,
+   .flags  = rw_flag,
+   .len= no_of_bytes,
+   .buf= buffer,
+   }
+   };
+
+   /* I2C over AUX here */
+   err = adapter->algo->master_xfer(adapter, msgs, 2);
+   if (err < 0)
+   DRM_ERROR("LSPCON: Failed I2C over Aux read(addr=0x%x)\n",
+   (unsigned int)offset);
+
+   return err;
+}
+
+int drm_dp_dual_mode_ioa_read(struct i2c_adapter *adapter, u8 *buffer,
+   u8 offset, u8 no_of_bytes)
+{
+   return drm_dp_dual_mode_ioa_xfer(adapter, buffer, offset,
+   no_of_bytes, I2C_M_RD);
+}
+EXPORT_SYMBOL(drm_dp_dual_mode_ioa_read);
+
+int drm_dp_dual_mode_ioa_write(struct i2c_adapter *adapter, u8 *buffer,
+   u8 offset, u8 no_of_bytes)
+{
+   return drm_dp_dual_mode_ioa_xfer(adapter, buffer, offset,
+   no_of_bytes, 0);
+}
+EXPORT_SYMBOL(drm_dp_dual_mode_ioa_write);
+
 static bool is_hdmi_adaptor(const char hdmi_id[DP_DUAL_MODE_HDMI_ID_LEN])
 {
static const char dp_dual_mode_hdmi_id[DP_DUAL_MODE_HDMI_ID_LEN] =
@@ -141,6 +234,11 @@ static bool is_hdmi_adaptor(const char 
hdmi_id[DP_DUAL_MODE_HDMI_ID_LEN])
  sizeof(dp_dual_mode_hdmi_id)) == 0;
 }
 
+bool is_lspcon_adaptor(const uint8_t adaptor_id)
+{
+   return adaptor_id == 0xa8;
+}
+
 /**
  * drm_dp_dual_mode_detect - Identyfy the DP dual mode adaptor
  * adapter: I2C adapter for the DDC bus
@@ -197,6 +295,8 @@ enum drm_dp_dual_mode_type drm_dp_dual_mode_detect(struct 
i2c_adapter *adapter)
_id, sizeof(adaptor_id));
if (ret || (adaptor_id 

[Intel-gfx] [PATCH 03/12] drm/i915: Enable/disable TMDS output buffers in DP++ adaptor as needed

[Shashank Sharma]

From: Ville Syrjälä 

MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

To save a bit of power, let's try to turn off the TMDS output buffers
in DP++ adaptors when we're not driving the port.

Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/intel_drv.h  |  1 +
 drivers/gpu/drm/i915/intel_hdmi.c | 25 +
 2 files changed, 26 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index d456bed..ab514bd 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -746,6 +746,7 @@ struct intel_hdmi {
int ddc_bus;
struct {
int max_tmds_clock;
+   bool tmds_output_control;
} dp_dual_mode;
bool limited_color_range;
bool color_range_auto;
diff --git a/drivers/gpu/drm/i915/intel_hdmi.c 
b/drivers/gpu/drm/i915/intel_hdmi.c
index bdbdb69..3a93337 100644
--- a/drivers/gpu/drm/i915/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/intel_hdmi.c
@@ -846,6 +846,13 @@ static void intel_hdmi_prepare(struct intel_encoder 
*encoder)
const struct drm_display_mode *adjusted_mode = 
>config->base.adjusted_mode;
u32 hdmi_val;
 
+   if (intel_hdmi->dp_dual_mode.tmds_output_control) {
+   struct i2c_adapter *adapter =
+   intel_gmbus_get_adapter(dev_priv, intel_hdmi->ddc_bus);
+
+   drm_dp_dual_mode_set_tmds_output(adapter, true);
+   }
+
hdmi_val = SDVO_ENCODING_HDMI;
if (!HAS_PCH_SPLIT(dev) && crtc->config->limited_color_range)
hdmi_val |= HDMI_COLOR_RANGE_16_235;
@@ -1141,6 +1148,13 @@ static void intel_disable_hdmi(struct intel_encoder 
*encoder)
}
 
intel_hdmi->set_infoframes(>base, false, NULL);
+
+   if (intel_hdmi->dp_dual_mode.tmds_output_control) {
+   struct i2c_adapter *adapter =
+   intel_gmbus_get_adapter(dev_priv, intel_hdmi->ddc_bus);
+
+   drm_dp_dual_mode_set_tmds_output(adapter, false);
+   }
 }
 
 static void g4x_disable_hdmi(struct intel_encoder *encoder)
@@ -1366,6 +1380,7 @@ intel_hdmi_unset_edid(struct drm_connector *connector)
intel_hdmi->rgb_quant_range_selectable = false;
 
intel_hdmi->dp_dual_mode.max_tmds_clock = 0;
+   intel_hdmi->dp_dual_mode.tmds_output_control = false;
 
kfree(to_intel_connector(connector)->detect_edid);
to_intel_connector(connector)->detect_edid = NULL;
@@ -1389,15 +1404,25 @@ intel_hdmi_dp_dual_mode_detect(struct drm_connector 
*connector)
 */
if (type == DRM_DP_DUAL_MODE_TYPE2_DVI ||
type == DRM_DP_DUAL_MODE_TYPE2_HDMI) {
+   bool tmds_enabled;
+
hdmi->dp_dual_mode.max_tmds_clock =
drm_dp_dual_mode_max_tmds_clock(adapter);
+   hdmi->dp_dual_mode.tmds_output_control =
+   drm_dp_dual_mode_get_tmds_output(adapter,
+   _enabled) == 0 &&
+   drm_dp_dual_mode_set_tmds_output(adapter,
+   tmds_enabled) == 0;
} else {
hdmi->dp_dual_mode.max_tmds_clock = 165000;
+   hdmi->dp_dual_mode.tmds_output_control = false;
}
 
DRM_DEBUG_KMS("Adaptor (%s) detected (max TMDS clock: %d kHz)\n",
  drm_dp_get_dual_mode_type_name(type),
  hdmi->dp_dual_mode.max_tmds_clock);
+   DRM_DEBUG_KMS("TMDS OE# control: %s)\n",
+   yesno(hdmi->dp_dual_mode.tmds_output_control));
 }
 
 static bool
-- 
1.9.1

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 04/12] drm/i915: Determine DP++ type 1 DVI adaptor presence based on VBT

[Shashank Sharma]

From: Ville Syrjälä 

MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

DP dual mode type 1 DVI adaptors aren't required to implement any
registers, so it's a bit hard to detect them. The best way would
be to check the state of the CONFIG1 pin, but we have no way to
do that. So as a last resort, check the VBT to see if the HDMI
port is in fact a dual mode capable DP port.

Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/i915_drv.h   |  2 ++
 drivers/gpu/drm/i915/intel_bios.c | 32 
 drivers/gpu/drm/i915/intel_dp.c   |  5 +
 drivers/gpu/drm/i915/intel_drv.h  |  1 +
 drivers/gpu/drm/i915/intel_hdmi.c | 23 +--
 drivers/gpu/drm/i915/intel_vbt_defs.h |  3 +++
 6 files changed, 64 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index f330a53..65bb83f 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -3373,6 +3373,8 @@ bool intel_bios_is_tv_present(struct drm_i915_private 
*dev_priv);
 bool intel_bios_is_lvds_present(struct drm_i915_private *dev_priv, u8 
*i2c_pin);
 bool intel_bios_is_port_edp(struct drm_i915_private *dev_priv, enum port port);
 bool intel_bios_is_dsi_present(struct drm_i915_private *dev_priv, enum port 
*port);
+bool intel_bios_is_dp_dual_mode(struct drm_i915_private *dev_priv,
+   enum port port);
 
 /* intel_opregion.c */
 #ifdef CONFIG_ACPI
diff --git a/drivers/gpu/drm/i915/intel_bios.c 
b/drivers/gpu/drm/i915/intel_bios.c
index 083003b..39c520a 100644
--- a/drivers/gpu/drm/i915/intel_bios.c
+++ b/drivers/gpu/drm/i915/intel_bios.c
@@ -1550,6 +1550,38 @@ bool intel_bios_is_port_edp(struct drm_i915_private 
*dev_priv, enum port port)
return false;
 }
 
+bool intel_bios_is_dp_dual_mode(struct drm_i915_private *dev_priv,
+   enum port port)
+{
+   const union child_device_config *p_child;
+   int i;
+   static const short port_mapping[] = {
+   [PORT_B] = DVO_PORT_DPB,
+   [PORT_C] = DVO_PORT_DPC,
+   [PORT_D] = DVO_PORT_DPD,
+   [PORT_E] = DVO_PORT_DPE,
+   };
+
+   if (port == PORT_A || port >= ARRAY_SIZE(port_mapping))
+   return false;
+
+   if (!dev_priv->vbt.child_dev_num)
+   return false;
+
+   for (i = 0; i < dev_priv->vbt.child_dev_num; i++) {
+   p_child = _priv->vbt.child_dev[i];
+
+   if (p_child->common.dvo_port == port_mapping[port] &&
+   (p_child->common.device_type &
+   DEVICE_TYPE_DP_DUAL_MODE_BITS) ==
+   (DEVICE_TYPE_DP_DUAL_MODE &
+   DEVICE_TYPE_DP_DUAL_MODE_BITS))
+   return true;
+   }
+   return false;
+}
+
+
 /**
  * intel_bios_is_dsi_present - is DSI present in VBT
  * @dev_priv:  i915 device instance
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 3ff8f1d..ba4da0c 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -5007,6 +5007,11 @@ bool intel_dp_is_edp(struct drm_device *dev, enum port 
port)
return intel_bios_is_port_edp(dev_priv, port);
 }
 
+bool intel_dp_is_dual_mode(struct drm_i915_private *dev_priv, enum port port)
+{
+   return intel_bios_is_dp_dual_mode(dev_priv, port);
+}
+
 void
 intel_dp_add_properties(struct intel_dp *intel_dp, struct drm_connector 
*connector)
 {
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index ab514bd..26ef950 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -1276,6 +1276,7 @@ int intel_dp_sink_crc(struct intel_dp *intel_dp, u8 *crc);
 bool intel_dp_compute_config(struct intel_encoder *encoder,
 struct intel_crtc_state *pipe_config);
 bool intel_dp_is_edp(struct drm_device *dev, enum port port);
+bool intel_dp_is_dual_mode(struct drm_i915_private *dev_priv, enum port port);
 enum irqreturn intel_dp_hpd_pulse(struct intel_digital_port *intel_dig_port,
  bool long_hpd);
 void intel_edp_backlight_on(struct intel_dp *intel_dp);
diff --git a/drivers/gpu/drm/i915/intel_hdmi.c 
b/drivers/gpu/drm/i915/intel_hdmi.c
index 3a93337..22b5a7e 100644
--- a/drivers/gpu/drm/i915/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/intel_hdmi.c
@@ -1387,14 +1387,33 @@ intel_hdmi_unset_edid(struct drm_connector *connector)
 }
 
 static void
-intel_hdmi_dp_dual_mode_detect(struct drm_connector *connector)
+intel_hdmi_dp_dual_mode_detect(struct drm_connector *connector, bool has_edid)
 {
struct drm_i915_private *dev_priv = to_i915(connector->dev);
struct intel_hdmi *hdmi = 

[Intel-gfx] [PATCH 02/12] drm/i915: Respect DP++ adaptor TMDS clock limit

[Shashank Sharma]

From: Ville Syrjälä 

MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Try to detect the max TMDS clock limit for the DP++ adaptor (if any)
and take it into account when checking the port clock.

Note that as with the sink (HDMI vs. DVI) TMDS clock limit we'll ignore
the adaptor TMDS clock limit in the modeset path, in case users are
already "overclocking" their TMDS links. One subtle change here is that
we'll have to respect the adaptor TMDS clock limit when we decide whether
to do 12bpc or 8bpc, otherwise we might end up picking 12bpc and
accidentally driving the TMDS link out of spec even when the user chose
a mode that fits wihting the limits at 8bpc. This means you can't
"overclock" your DP++ dongle at 12bpc anymore, but you can continue to
do so at 8bpc.

Note that for simplicity we'll use the I2C access method for all dual
mode adaptors including type 2. Otherwise we'd have to start mixing
DP AUX and HDMI together. In the future we may need to do that if we
come across any board designs that don't hook up the DDC pins to the
DP++ connectors. Such boards would obviously only work with type 2
dual mode adaptors, and not type 1.

Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/intel_drv.h  |  3 ++
 drivers/gpu/drm/i915/intel_hdmi.c | 65 ++-
 2 files changed, 60 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 5136eef..d456bed 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -744,6 +744,9 @@ struct cxsr_latency {
 struct intel_hdmi {
i915_reg_t hdmi_reg;
int ddc_bus;
+   struct {
+   int max_tmds_clock;
+   } dp_dual_mode;
bool limited_color_range;
bool color_range_auto;
bool has_hdmi_sink;
diff --git a/drivers/gpu/drm/i915/intel_hdmi.c 
b/drivers/gpu/drm/i915/intel_hdmi.c
index e2dab48..bdbdb69 100644
--- a/drivers/gpu/drm/i915/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/intel_hdmi.c
@@ -34,6 +34,7 @@
 #include 
 #include 
 #include 
+#include 
 #include "intel_drv.h"
 #include 
 #include "i915_drv.h"
@@ -1165,27 +1166,42 @@ static void pch_post_disable_hdmi(struct intel_encoder 
*encoder)
intel_disable_hdmi(encoder);
 }
 
-static int hdmi_port_clock_limit(struct intel_hdmi *hdmi, bool 
respect_dvi_limit)
+static int intel_hdmi_source_max_tmds_clock(struct drm_i915_private *dev_priv)
 {
-   struct drm_device *dev = intel_hdmi_to_dev(hdmi);
-
-   if ((respect_dvi_limit && !hdmi->has_hdmi_sink) || IS_G4X(dev))
+   if (IS_G4X(dev_priv))
return 165000;
-   else if (IS_HASWELL(dev) || INTEL_INFO(dev)->gen >= 8)
+   else if (IS_HASWELL(dev_priv) || INTEL_INFO(dev_priv)->gen >= 8)
return 30;
else
return 225000;
 }
 
+static int hdmi_port_clock_limit(struct intel_hdmi *hdmi,
+bool respect_downstream_limits)
+{
+   struct drm_device *dev = intel_hdmi_to_dev(hdmi);
+   int max_tmds_clock = intel_hdmi_source_max_tmds_clock(to_i915(dev));
+
+   if (respect_downstream_limits) {
+   if (hdmi->dp_dual_mode.max_tmds_clock)
+   max_tmds_clock = min(max_tmds_clock,
+hdmi->dp_dual_mode.max_tmds_clock);
+   if (!hdmi->has_hdmi_sink)
+   max_tmds_clock = min(max_tmds_clock, 165000);
+   }
+
+   return max_tmds_clock;
+}
+
 static enum drm_mode_status
 hdmi_port_clock_valid(struct intel_hdmi *hdmi,
- int clock, bool respect_dvi_limit)
+ int clock, bool respect_downstream_limits)
 {
struct drm_device *dev = intel_hdmi_to_dev(hdmi);
 
if (clock < 25000)
return MODE_CLOCK_LOW;
-   if (clock > hdmi_port_clock_limit(hdmi, respect_dvi_limit))
+   if (clock > hdmi_port_clock_limit(hdmi, respect_downstream_limits))
return MODE_CLOCK_HIGH;
 
/* BXT DPLL can't generate 223-240 MHz */
@@ -1309,7 +1325,7 @@ bool intel_hdmi_compute_config(struct intel_encoder 
*encoder,
 * within limits.
 */
if (pipe_config->pipe_bpp > 8*3 && pipe_config->has_hdmi_sink &&
-   hdmi_port_clock_valid(intel_hdmi, clock_12bpc, false) == MODE_OK &&
+   hdmi_port_clock_valid(intel_hdmi, clock_12bpc, true) == MODE_OK &&
hdmi_12bpc_possible(pipe_config)) {
DRM_DEBUG_KMS("picking bpc to 12 for HDMI output\n");
desired_bpp = 12*3;
@@ -1349,10 +1365,41 @@ intel_hdmi_unset_edid(struct drm_connector *connector)
intel_hdmi->has_audio = false;
intel_hdmi->rgb_quant_range_selectable = false;
 
+   intel_hdmi->dp_dual_mode.max_tmds_clock = 0;
+
kfree(to_intel_connector(connector)->detect_edid);

[Intel-gfx] [PATCH 01/12] drm: Add helper for DP++ adaptors

[Shashank Sharma]

From: Ville Syrjälä 

MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Add a helper which aids in he identification of DP dual mode (aka. DP++)
adaptors. There are several types of adaptors specified:
type 1 DVI, type 1 HDMI, type 2 DVI, type 2 HDMI

Type 1 adaptors have a max TMDS clock limit of 165MHz, type 2 adaptors
may go as high as 300MHz and they provide a register informing the
source device what the actual limit is. Supposedly also type 1 adaptors
may optionally implement this register. This TMDS clock limit is the
main reason why we need to identify these adaptors.

Type 1 adaptors provide access to their internal registers and the sink
DDC bus through I2C. Type 2 adaptors provide this access both via I2C
and I2C-over-AUX. A type 2 source device may choose to implement either
or both of these methods. If a source device implements only the
I2C-over-AUX method, then the driver will obviously need specific
support for such adaptors since the port is driven like an HDMI port,
but DDC communication happes over the AUX channel.

This helper should be enough to identify the adaptor type (some
type 1 DVI adaptors may be a slight exception) and the maximum TMDS
clock limit. Another feature that may be available is control over
the TMDS output buffers on the adaptor, possibly allowing for some
power saving when the TMDS link is down.

Other user controllable features that may be available in the adaptors
are downstream i2c bus speed control when using i2c-over-aux, and
some control over the CEC pin. I chose not to provide any helper
functions for those since I have no use for them in i915 at this time.
The rest of the registers in the adaptor are mostly just information,
eg. IEEE OUI, hardware and firmware revision, etc.

Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/Makefile  |   2 +-
 drivers/gpu/drm/drm_dp_dual_mode_helper.c | 331 ++
 include/drm/drm_dp_dual_mode_helper.h |  84 
 3 files changed, 416 insertions(+), 1 deletion(-)
 create mode 100644 drivers/gpu/drm/drm_dp_dual_mode_helper.c
 create mode 100644 include/drm/drm_dp_dual_mode_helper.h

diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index 6eb94fc..8ef 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -23,7 +23,7 @@ drm-$(CONFIG_AGP) += drm_agpsupport.o
 
 drm_kms_helper-y := drm_crtc_helper.o drm_dp_helper.o drm_probe_helper.o \
drm_plane_helper.o drm_dp_mst_topology.o drm_atomic_helper.o \
-   drm_kms_helper_common.o
+   drm_kms_helper_common.o drm_dp_dual_mode_helper.o
 
 drm_kms_helper-$(CONFIG_DRM_LOAD_EDID_FIRMWARE) += drm_edid_load.o
 drm_kms_helper-$(CONFIG_DRM_FBDEV_EMULATION) += drm_fb_helper.o
diff --git a/drivers/gpu/drm/drm_dp_dual_mode_helper.c 
b/drivers/gpu/drm/drm_dp_dual_mode_helper.c
new file mode 100644
index 000..b72b7bb
--- /dev/null
+++ b/drivers/gpu/drm/drm_dp_dual_mode_helper.c
@@ -0,0 +1,331 @@
+/*
+ * 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 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 COPYRIGHT HOLDER(S) OR AUTHOR(S) 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 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/**
+ * DOC: DP dual mode (aka. DP++) adaptor helpers
+ *
+ * Helper functions to deal with DP dual mode adaptors.
+ *
+ * Type 1:
+ * Adaptor registers (if any) and the sink DDC bus may be accessed via I2C.
+ *
+ * Type 2:
+ * Adaptor registers and sink DDC bus can be accessed either via I2C or
+ * I2C-over-AUX. Source devices may choose to implement either one or
+ * both of these access methods.
+ */
+
+#define DP_DUAL_MODE_SLAVE_ADDRESS 0x40
+
+/**
+ * drm_dp_dual_mode_read - Read from the 

Re: [Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/5] drm/i915: Splitting intel_dp_detect

[Tvrtko Ursulin]

On 04/04/16 12:08, Jani Nikula wrote:

On Mon, 04 Apr 2016, Tvrtko Ursulin  wrote:

On 01/04/16 08:41, Ander Conselvan De Oliveira wrote:

On Thu, 2016-03-31 at 12:38 +, Patchwork wrote:

== Series Details ==

Series: series starting with [1/5] drm/i915: Splitting intel_dp_detect
URL   : https://patchwork.freedesktop.org/series/5044/
State : success


I pushed those to dinq.


This series seems to break eDP detection on BDW RVP.


I presume this is due to the sink count check. Can you add debug logging
to print intel_dp->sink_count after it's been read in
intel_dp_get_dpcd() please?


intel_dp->sink_count is zero here. (raw value, before the 
DP_GET_SINK_COUNT.)


Also, intel_dp_dpcd_read_wake suggests a possibility for reading garbage 
with not overly confident wording for the workaround there.



Then the question is, is this just because you have an RVP with who
knows what panel, or do we have to take into account potentially broken
panels too? Then I assume the fix would be to to ignore sink count for
eDP.


No idea. :)

Regards,

Tvrtko
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v4] drm/i915: Move execlists irq handler to a bottom half

[Chris Wilson]

On Mon, Apr 04, 2016 at 12:11:56PM +0100, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin 
> 
> Doing a lot of work in the interrupt handler introduces huge
> latencies to the system as a whole.
> 
> Most dramatic effect can be seen by running an all engine
> stress test like igt/gem_exec_nop/all where, when the kernel
> config is lean enough, the whole system can be brought into
> multi-second periods of complete non-interactivty. That can
> look for example like this:
> 
>  NMI watchdog: BUG: soft lockup - CPU#0 stuck for 23s! [kworker/u8:3:143]
>  Modules linked in: [redacted for brevity]
>  CPU: 0 PID: 143 Comm: kworker/u8:3 Tainted: G U   L  4.5.0-160321+ 
> #183
>  Hardware name: Intel Corporation Broadwell Client platform/WhiteTip Mountain 
> 1
>  Workqueue: i915 gen6_pm_rps_work [i915]
>  task: 8800aae88000 ti: 8800aae9 task.ti: 8800aae9
>  RIP: 0010:[]  [] __do_softirq+0x72/0x1d0
>  RSP: :88014f403f38  EFLAGS: 0206
>  RAX: 8800aae94000 RBX:  RCX: 06e0
>  RDX: 0020 RSI: 04208060 RDI: 00215d80
>  RBP: 88014f403f80 R08: 000b1b42c180 R09: 0022
>  R10: 0004 R11:  R12: a030
>  R13: 0082 R14: 8800aa4d0080 R15: 0082
>  FS:  () GS:88014f40() knlGS:
>  CS:  0010 DS:  ES:  CR0: 80050033
>  CR2: 7fa53b90c000 CR3: 01a0a000 CR4: 001406f0
>  DR0:  DR1:  DR2: 
>  DR3:  DR6: fffe0ff0 DR7: 0400
>  Stack:
>   042080601b33869f 8800aae94000 fffc2678 8801000a
>    a030 5302 8800aa4d0080
>   0206 88014f403f90 8104a716 88014f403fa8
>  Call Trace:
>   
>   [] irq_exit+0x86/0x90
>   [] smp_apic_timer_interrupt+0x3d/0x50
>   [] apic_timer_interrupt+0x7c/0x90
>   
>   [] ? gen8_write64+0x1a0/0x1a0 [i915]
>   [] ? _raw_spin_unlock_irqrestore+0x9/0x20
>   [] gen8_write32+0x104/0x1a0 [i915]
>   [] ? n_tty_receive_buf_common+0x372/0xae0
>   [] gen6_set_rps_thresholds+0x1be/0x330 [i915]
>   [] gen6_set_rps+0x70/0x200 [i915]
>   [] intel_set_rps+0x25/0x30 [i915]
>   [] gen6_pm_rps_work+0x10d/0x2e0 [i915]
>   [] ? finish_task_switch+0x72/0x1c0
>   [] process_one_work+0x139/0x350
>   [] worker_thread+0x126/0x490
>   [] ? rescuer_thread+0x320/0x320
>   [] kthread+0xc4/0xe0
>   [] ? kthread_create_on_node+0x170/0x170
>   [] ret_from_fork+0x3f/0x70
>   [] ? kthread_create_on_node+0x170/0x170
> 
> I could not explain, or find a code path, which would explain
> a +20 second lockup, but from some instrumentation it was
> apparent the interrupts off proportion of time was between
> 10-25% under heavy load which is quite bad.
> 
> When a interrupt "cliff" is reached, which was >~320k irq/s on
> my machine, the whole system goes into a terrible state of the
> above described multi-second lockups.
> 
> By moving the GT interrupt handling to a tasklet in a most
> simple way, the problem above disappears completely.
> 
> Testing the effect on sytem-wide latencies using
> igt/gem_syslatency shows the following before this patch:
> 
> gem_syslatency: cycles=1532739, latency mean=416531.829us max=2499237us
> gem_syslatency: cycles=1839434, latency mean=1458099.157us max=4998944us
> gem_syslatency: cycles=1432570, latency mean=2688.451us max=1201185us
> gem_syslatency: cycles=1533543, latency mean=416520.499us max=2498886us
> 
> This shows that the unrelated process is experiencing huge
> delays in its wake-up latency. After the patch the results
> look like this:
> 
> gem_syslatency: cycles=808907, latency mean=53.133us max=1640us
> gem_syslatency: cycles=862154, latency mean=62.778us max=2117us
> gem_syslatency: cycles=856039, latency mean=58.079us max=2123us
> gem_syslatency: cycles=841683, latency mean=56.914us max=1667us
> 
> Showing a huge improvement in the unrelated process wake-up
> latency. It also shows an approximate halving in the number
> of total empty batches submitted during the test. This may
> not be worrying since the test puts the driver under
> a very unrealistic load with ncpu threads doing empty batch
> submission to all GPU engines each.
> 
> Another benefit compared to the hard-irq handling is that now
> work on all engines can be dispatched in parallel since we can
> have up to number of CPUs active tasklets. (While previously
> a single hard-irq would serially dispatch on one engine after
> another.)
> 
> More interesting scenario with regards to throughput is
> "gem_latency -n 100" which  shows 25% better throughput and
> CPU usage, and 14% better dispatch latencies.
> 
> I did not find any gains or regressions with Synmark2 or
> GLbench under light testing. More benchmarking is certainly
> required.
> 
> v2:
>* execlists_lock should be taken as 

Re: [Intel-gfx] [PATCH 07/16] drm/i915/bxt: Suspend power domains during suspend-to-idle

[Patrik Jakobsson]

On Fri, Apr 01, 2016 at 04:02:38PM +0300, Imre Deak wrote:
> On SKL/KBL suspend-to-idle (aka freeze/s0ix) is performed with DMC
> firmware assistance where the target display power state is DC6. On
> Broxton on the other hand we don't use the firmware for this, but rely
> instead on a manual DC9 flow. For this we have to uninitialize the
> display following the BSpec display uninit sequence, just as during
> S3/S4, so make sure we follow this sequence.
> 
> CC: Patrik Jakobsson 
> Signed-off-by: Imre Deak 

Reviewed-by: Patrik Jakobsson 

> ---
>  drivers/gpu/drm/i915/i915_drv.c | 6 --
>  1 file changed, 4 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
> index 020a31c..aa7df10 100644
> --- a/drivers/gpu/drm/i915/i915_drv.c
> +++ b/drivers/gpu/drm/i915/i915_drv.c
> @@ -657,7 +657,8 @@ static int i915_drm_suspend_late(struct drm_device 
> *drm_dev, bool hibernation)
>  
>   disable_rpm_wakeref_asserts(dev_priv);
>  
> - fw_csr = suspend_to_idle(dev_priv) && dev_priv->csr.dmc_payload;
> + fw_csr = !IS_BROXTON(dev_priv) &&
> + suspend_to_idle(dev_priv) && dev_priv->csr.dmc_payload;
>   /*
>* In case of firmware assisted context save/restore don't manually
>* deinit the power domains. This also means the CSR/DMC firmware will
> @@ -837,7 +838,8 @@ static int i915_drm_resume_early(struct drm_device *dev)
>  
>   intel_uncore_sanitize(dev);
>  
> - if (!(dev_priv->suspended_to_idle && dev_priv->csr.dmc_payload))
> + if (IS_BROXTON(dev_priv) ||
> + !(dev_priv->suspended_to_idle && dev_priv->csr.dmc_payload))
>   intel_power_domains_init_hw(dev_priv, true);
>  
>  out:
> -- 
> 2.5.0
> 

-- 
---
Intel Sweden AB Registered Office: Knarrarnasgatan 15, 164 40 Kista, Stockholm, 
Sweden Registration Number: 556189-6027 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH v3 2/2] drm/i915: Make pages of GFX allocations movable

[akash . goel]

From: Chris Wilson 

On a long run of more than 2-3 days, physical memory tends to get fragmented
severely, which considerably slows down the system. In such a scenario,
Shrinker is also unable to help as lack of memory is not the actual problem,
since it has been observed that there are enough free pages of 0 order.

To address the issue of external fragementation, kernel does a compaction
(which involves migration of pages) but it's efficacy depends upon how many
pages are marked as MOVABLE, as only those pages can be migrated.

Currently the backing pages for GFX buffers are allocated from shmemfs
with GFP_RECLAIMABLE flag, in units of 4KB pages.
In the case of limited Swap space, it may not be possible always to reclaim
or swap-out pages of all the inactive objects, to make way for free space
allowing formation of higher order groups of physically-contiguous pages
on compaction.

Just marking the GFX pages as MOVABLE will not suffice, as i915 Driver
has to pin the pages if they are in use by GPU, which will prevent their
migration. So the migratepage callback in shmem is also hooked up to get a
notification when kernel initiates the page migration. On the notification,
i915 Driver appropriately unpin the pages.
With this Driver can effectively mark the GFX pages as MOVABLE and hence
mitigate the fragmentation problem.

v2:
 - Rename the migration routine to gem_shrink_migratepage, move it to the
   shrinker file, and use the existing constructs (Chris)
 - To cleanup, add a new helper function to encapsulate all page migration
   skip conditions (Chris)
 - Add a new local helper function in shrinker file, for dropping the
   backing pages, and call the same from gem_shrink() also (Chris)

v3:
 - Fix/invert the check on the return value of unsafe_drop_pages (Chris)

Cc: Hugh Dickins 
Cc: linux...@kvack.org
Signed-off-by: Sourab Gupta 
Signed-off-by: Akash Goel 
---
 drivers/gpu/drm/i915/i915_drv.h  |   3 +
 drivers/gpu/drm/i915/i915_gem.c  |  16 ++-
 drivers/gpu/drm/i915/i915_gem_shrinker.c | 173 ---
 3 files changed, 177 insertions(+), 15 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index dd18772..83415f0 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -52,6 +52,7 @@
 #include 
 #include 
 #include 
+#include 
 #include "intel_guc.h"
 #include "intel_dpll_mgr.h"
 
@@ -1979,6 +1980,8 @@ struct drm_i915_private {
 
struct intel_encoder *dig_port_map[I915_MAX_PORTS];
 
+   struct shmem_dev_info  migrate_info;
+
/*
 * NOTE: This is the dri1/ums dungeon, don't add stuff here. Your patch
 * will be rejected. Instead look for a better place.
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index ca96fc1..88b717c 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -2206,6 +2206,7 @@ i915_gem_object_put_pages_gtt(struct drm_i915_gem_object 
*obj)
if (obj->madv == I915_MADV_WILLNEED)
mark_page_accessed(page);
 
+   set_page_private(page, 0);
page_cache_release(page);
}
obj->dirty = 0;
@@ -2320,6 +2321,7 @@ i915_gem_object_get_pages_gtt(struct drm_i915_gem_object 
*obj)
sg->length += PAGE_SIZE;
}
last_pfn = page_to_pfn(page);
+   set_page_private(page, (unsigned long)obj);
 
/* Check that the i965g/gm workaround works. */
WARN_ON((gfp & __GFP_DMA32) && (last_pfn >= 0x0010UL));
@@ -2345,8 +2347,11 @@ i915_gem_object_get_pages_gtt(struct drm_i915_gem_object 
*obj)
 
 err_pages:
sg_mark_end(sg);
-   for_each_sg_page(st->sgl, _iter, st->nents, 0)
-   page_cache_release(sg_page_iter_page(_iter));
+   for_each_sg_page(st->sgl, _iter, st->nents, 0) {
+   page = sg_page_iter_page(_iter);
+   set_page_private(page, 0);
+   page_cache_release(page);
+   }
sg_free_table(st);
kfree(st);
 
@@ -4468,6 +4473,7 @@ static const struct drm_i915_gem_object_ops 
i915_gem_object_ops = {
 struct drm_i915_gem_object *i915_gem_alloc_object(struct drm_device *dev,
  size_t size)
 {
+   struct drm_i915_private *dev_priv = dev->dev_private;
struct drm_i915_gem_object *obj;
struct address_space *mapping;
gfp_t mask;
@@ -4481,7 +4487,7 @@ struct drm_i915_gem_object *i915_gem_alloc_object(struct 
drm_device *dev,
return NULL;
}
 
-   mask = GFP_HIGHUSER | __GFP_RECLAIMABLE;
+   mask = GFP_HIGHUSER_MOVABLE;
if (IS_CRESTLINE(dev) || IS_BROADWATER(dev)) {
/* 965gm cannot relocate objects above 4GiB. */
mask &= 

Re: [Intel-gfx] Fi.CI.BAT: failure for drm/i915: implement WaClearTdlStateAckDirtyBits

[Gore, Tim]

Pasted below are Bat results (don't seem to get an email from Bat anymore).


> Series 4282v3 drm/i915: implement WaClearTdlStateAckDirtyBits
> http://patchwork.freedesktop.org/api/1.0/series/4282/revisions/3/mbox/
>
> Test kms_flip:
> Subgroup basic-flip-vs-wf_vblank:
> pass   -> DMESG-WARN (hsw-brixbox) 

device suspended during HW access, see 
https://bugs.freedesktop.org/show_bug.cgi?id=94349

> Subgroup basic-plain-flip:
> pass   -> DMESG-WARN (snb-x220t)

device suspended during HW access, see 
https://bugs.freedesktop.org/show_bug.cgi?id=94349

> dmesg-warn -> PASS   (bdw-ultra)
> Test kms_pipe_crc_basic:
> Subgroup read-crc-pipe-c-frame-sequence:
> pass   -> SKIP   (hsw-brixbox)

No connector found for pipe 2. Also seen in ci-drm-1156. See 
https://bugs.freedesktop.org/show_bug.cgi?id=93769

> Subgroup suspend-read-crc-pipe-c:
> dmesg-warn -> PASS   (bsw-nuc-2)
> Test pm_rpm:
> Subgroup basic-pci-d3-state:
> pass   -> DMESG-WARN (snb-dellxps)

device suspended during HW access, see 
https://bugs.freedesktop.org/show_bug.cgi?id=94349

> pass   -> DMESG-WARN (byt-nuc)

Unclaimed Access detected, see 
https://bugs.freedesktop.org/show_bug.cgi?id=94164. Note priority is not 
"highest"

> Subgroup basic-rte:
> dmesg-warn -> PASS   (snb-x220t)
> pass   -> DMESG-WARN (bsw-nuc-2)

Unclaimed Access detected - , see 
https://bugs.freedesktop.org/show_bug.cgi?id=94164. Note priority is not 
"highest"

>
> dmesg-warn -> PASS   (snb-dellxps)
> dmesg-warn -> PASS   (byt-nuc) UNSTABLE

bdw-nuci7total:192  pass:180  dwarn:0   dfail:0   fail:0   skip:12 
bdw-ultratotal:192  pass:171  dwarn:0   dfail:0   fail:0   skip:21 
bsw-nuc-2total:192  pass:154  dwarn:1   dfail:0   fail:0   skip:37 
byt-nuc  total:192  pass:156  dwarn:1   dfail:0   fail:0   skip:35 
hsw-brixbox  total:192  pass:168  dwarn:1   dfail:0   fail:0   skip:23 
ilk-hp8440p  total:192  pass:128  dwarn:1   dfail:0   fail:0   skip:63 
ivb-t430stotal:192  pass:167  dwarn:0   dfail:0   fail:0   skip:25 
skl-i5k-2total:192  pass:169  dwarn:0   dfail:0   fail:0   skip:23 
skl-i7k-2total:192  pass:169  dwarn:0   dfail:0   fail:0   skip:23 
snb-dellxps  total:192  pass:157  dwarn:1   dfail:0   fail:0   skip:34 
snb-x220ttotal:192  pass:157  dwarn:1   dfail:0   fail:1   skip:33 

Results at /archive/results/CI_IGT_test/Patchwork_1663/

4b39223f6e3bef4dfa678f7239dcd87c38e20e96 drm-intel-nightly: 
2016y-03m-21d-18h-43m-18s UTC integration manifest
8c4bb61d48749011ec44eaa2f908c1f4d48b601c drm/i915: implement 
WaClearTdlStateAckDirtyBits

Tim Gore 
Intel Corporation (UK) Ltd. - Co. Reg. #1134945 - Pipers Way, Swindon SN3 1RJ


> -Original Message-
> From: Gore, Tim
> Sent: Monday, March 21, 2016 2:37 PM
> To: intel-gfx@lists.freedesktop.org
> Cc: arun.siluv...@linux.intel.com; Gore, Tim
> Subject: [PATCH v4] drm/i915: implement WaClearTdlStateAckDirtyBits
> 
> From: Tim Gore 
> 
> This is to fix a GPU hang seen with mid thread pre-emption and pooled EUs.
> 
> v2. Use IS_BXT_REVID instead of IS_BROXTON and INTEL_REVID
> 
> v3. And use correct type for register addresses
> 
> Signed-off-by: Tim Gore 
> ---
>  drivers/gpu/drm/i915/i915_reg.h  | 12 
> drivers/gpu/drm/i915/intel_lrc.c | 19 +++
>  2 files changed, 31 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/i915_reg.h
> b/drivers/gpu/drm/i915/i915_reg.h index 06fb589..c54190b 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -1783,6 +1783,18 @@ enum skl_disp_power_wells {
>  #define   GEN9_IZ_HASHING_MASK(slice)(0x3 <<
> ((slice) * 2))
>  #define   GEN9_IZ_HASHING(slice, val)((val) <<
> ((slice) * 2))
> 
> +/* WaClearTdlStateAckDirtyBits */
> +#define GEN8_STATE_ACK   _MMIO(0x20F0)
> +#define GEN9_STATE_ACK_SLICE1_MMIO(0x20F8)
> +#define GEN9_STATE_ACK_SLICE2_MMIO(0x2100)
> +#define   GEN9_STATE_ACK_TDL0 (1 << 12)
> +#define   GEN9_STATE_ACK_TDL1 (1 << 13)
> +#define   GEN9_STATE_ACK_TDL2 (1 << 14)
> +#define   GEN9_STATE_ACK_TDL3 (1 << 15)
> +#define   GEN9_SUBSLICE_TDL_ACK_BITS \
> + (GEN9_STATE_ACK_TDL3 | GEN9_STATE_ACK_TDL2 | \
> +  GEN9_STATE_ACK_TDL1 | GEN9_STATE_ACK_TDL0)
> +
>  #define GFX_MODE _MMIO(0x2520)
>  #define GFX_MODE_GEN7_MMIO(0x229c)
>  #define RING_MODE_GEN7(ring) _MMIO((ring)->mmio_base+0x29c)
> diff --git a/drivers/gpu/drm/i915/intel_lrc.c
> b/drivers/gpu/drm/i915/intel_lrc.c
> index 3a23b95..b6dcd4d 100644
> --- a/drivers/gpu/drm/i915/intel_lrc.c
> +++ b/drivers/gpu/drm/i915/intel_lrc.c
> @@ -1450,6 +1450,25 @@ static int 

[Intel-gfx] [PATCH v4] drm/i915: Move execlists irq handler to a bottom half

[Tvrtko Ursulin]

From: Tvrtko Ursulin 

Doing a lot of work in the interrupt handler introduces huge
latencies to the system as a whole.

Most dramatic effect can be seen by running an all engine
stress test like igt/gem_exec_nop/all where, when the kernel
config is lean enough, the whole system can be brought into
multi-second periods of complete non-interactivty. That can
look for example like this:

 NMI watchdog: BUG: soft lockup - CPU#0 stuck for 23s! [kworker/u8:3:143]
 Modules linked in: [redacted for brevity]
 CPU: 0 PID: 143 Comm: kworker/u8:3 Tainted: G U   L  4.5.0-160321+ #183
 Hardware name: Intel Corporation Broadwell Client platform/WhiteTip Mountain 1
 Workqueue: i915 gen6_pm_rps_work [i915]
 task: 8800aae88000 ti: 8800aae9 task.ti: 8800aae9
 RIP: 0010:[]  [] __do_softirq+0x72/0x1d0
 RSP: :88014f403f38  EFLAGS: 0206
 RAX: 8800aae94000 RBX:  RCX: 06e0
 RDX: 0020 RSI: 04208060 RDI: 00215d80
 RBP: 88014f403f80 R08: 000b1b42c180 R09: 0022
 R10: 0004 R11:  R12: a030
 R13: 0082 R14: 8800aa4d0080 R15: 0082
 FS:  () GS:88014f40() knlGS:
 CS:  0010 DS:  ES:  CR0: 80050033
 CR2: 7fa53b90c000 CR3: 01a0a000 CR4: 001406f0
 DR0:  DR1:  DR2: 
 DR3:  DR6: fffe0ff0 DR7: 0400
 Stack:
  042080601b33869f 8800aae94000 fffc2678 8801000a
   a030 5302 8800aa4d0080
  0206 88014f403f90 8104a716 88014f403fa8
 Call Trace:
  
  [] irq_exit+0x86/0x90
  [] smp_apic_timer_interrupt+0x3d/0x50
  [] apic_timer_interrupt+0x7c/0x90
  
  [] ? gen8_write64+0x1a0/0x1a0 [i915]
  [] ? _raw_spin_unlock_irqrestore+0x9/0x20
  [] gen8_write32+0x104/0x1a0 [i915]
  [] ? n_tty_receive_buf_common+0x372/0xae0
  [] gen6_set_rps_thresholds+0x1be/0x330 [i915]
  [] gen6_set_rps+0x70/0x200 [i915]
  [] intel_set_rps+0x25/0x30 [i915]
  [] gen6_pm_rps_work+0x10d/0x2e0 [i915]
  [] ? finish_task_switch+0x72/0x1c0
  [] process_one_work+0x139/0x350
  [] worker_thread+0x126/0x490
  [] ? rescuer_thread+0x320/0x320
  [] kthread+0xc4/0xe0
  [] ? kthread_create_on_node+0x170/0x170
  [] ret_from_fork+0x3f/0x70
  [] ? kthread_create_on_node+0x170/0x170

I could not explain, or find a code path, which would explain
a +20 second lockup, but from some instrumentation it was
apparent the interrupts off proportion of time was between
10-25% under heavy load which is quite bad.

When a interrupt "cliff" is reached, which was >~320k irq/s on
my machine, the whole system goes into a terrible state of the
above described multi-second lockups.

By moving the GT interrupt handling to a tasklet in a most
simple way, the problem above disappears completely.

Testing the effect on sytem-wide latencies using
igt/gem_syslatency shows the following before this patch:

gem_syslatency: cycles=1532739, latency mean=416531.829us max=2499237us
gem_syslatency: cycles=1839434, latency mean=1458099.157us max=4998944us
gem_syslatency: cycles=1432570, latency mean=2688.451us max=1201185us
gem_syslatency: cycles=1533543, latency mean=416520.499us max=2498886us

This shows that the unrelated process is experiencing huge
delays in its wake-up latency. After the patch the results
look like this:

gem_syslatency: cycles=808907, latency mean=53.133us max=1640us
gem_syslatency: cycles=862154, latency mean=62.778us max=2117us
gem_syslatency: cycles=856039, latency mean=58.079us max=2123us
gem_syslatency: cycles=841683, latency mean=56.914us max=1667us

Showing a huge improvement in the unrelated process wake-up
latency. It also shows an approximate halving in the number
of total empty batches submitted during the test. This may
not be worrying since the test puts the driver under
a very unrealistic load with ncpu threads doing empty batch
submission to all GPU engines each.

Another benefit compared to the hard-irq handling is that now
work on all engines can be dispatched in parallel since we can
have up to number of CPUs active tasklets. (While previously
a single hard-irq would serially dispatch on one engine after
another.)

More interesting scenario with regards to throughput is
"gem_latency -n 100" which  shows 25% better throughput and
CPU usage, and 14% better dispatch latencies.

I did not find any gains or regressions with Synmark2 or
GLbench under light testing. More benchmarking is certainly
required.

v2:
   * execlists_lock should be taken as spin_lock_bh when
 queuing work from userspace now. (Chris Wilson)
   * uncore.lock must be taken with spin_lock_irq when
 submitting requests since that now runs from either
 softirq or process context.

v3:
   * Expanded commit message with more testing data;
   * converted 

Re: [Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/5] drm/i915: Splitting intel_dp_detect

[Jani Nikula]

On Mon, 04 Apr 2016, Tvrtko Ursulin  wrote:
> On 01/04/16 08:41, Ander Conselvan De Oliveira wrote:
>> On Thu, 2016-03-31 at 12:38 +, Patchwork wrote:
>>> == Series Details ==
>>>
>>> Series: series starting with [1/5] drm/i915: Splitting intel_dp_detect
>>> URL   : https://patchwork.freedesktop.org/series/5044/
>>> State : success
>> 
>> I pushed those to dinq.
>
> This series seems to break eDP detection on BDW RVP.

I presume this is due to the sink count check. Can you add debug logging
to print intel_dp->sink_count after it's been read in
intel_dp_get_dpcd() please?

Then the question is, is this just because you have an RVP with who
knows what panel, or do we have to take into account potentially broken
panels too? Then I assume the fix would be to to ignore sink count for
eDP.

BR,
Jani.


>
> Old kernel:
>
> [1.554183] [drm:intel_dp_init_connector] Adding eDP connector on port A
> [1.554245] [drm:intel_dp_init_panel_power_sequencer] cur t1_t3 2000 t8 0 
> t9 2000 t10 500 t11_t12 6000
> [1.554254] [drm:intel_dp_init_panel_power_sequencer] vbt t1_t3 2000 t8 10 
> t9 2000 t10 500 t11_t12 5000
> [1.554263] [drm:intel_dp_init_panel_power_sequencer] panel power up delay 
> 200, power down delay 50, power cycle delay 600
> [1.554271] [drm:intel_dp_init_panel_power_sequencer] backlight on delay 
> 1, off delay 200
> [1.554279] [drm:intel_dp_aux_init] registering DPDDC-A bus for card0-eDP-1
> [1.554530] [drm:edp_panel_vdd_on] Turning eDP port A VDD on
> [1.554562] [drm:edp_panel_vdd_on] PP_STATUS: 0x8008 PP_CONTROL: 
> 0xabcd000f
> [1.556670] [drm:intel_dp_get_dpcd] DPCD: 11 0a 02 00 00 00 00 00 00 00 00 
> 00 00 00 00
> [1.557617] [drm:intel_dp_get_dpcd] Display Port TPS3 support: source yes, 
> sink no
> [1.557627] [drm:intel_dp_print_rates] source rates: 162000, 27, 54
> [1.557633] [drm:intel_dp_print_rates] sink rates: 162000, 27
> [1.557638] [drm:intel_dp_print_rates] common rates: 162000, 27
> [1.557651] [drm:intel_dp_init_panel_power_sequencer_registers] panel 
> power sequencer register settings: PP_ON 0x7d1, PP_OFF 0x1f40001, PP_DIV 
> 0x4af06
> [1.567299] [drm:drm_edid_to_eld] ELD: no CEA Extension found
> [1.567308] [drm:intel_dp_drrs_init] VBT doesn't support DRRS
> [1.567319] [drm:intel_panel_setup_backlight] Connector eDP-1 backlight 
> initialized, enabled, brightness 937/937
>
>
> Todays nightly:
>
> [4.306321] [drm:intel_dp_init_connector] Adding eDP connector on port A
> [4.306370] [drm:intel_dp_init_panel_power_sequencer] cur t1_t3 2000 t8 0 
> t9 2000 t10 500 t11_t12 6000
> [4.306371] [drm:intel_dp_init_panel_power_sequencer] vbt t1_t3 2000 t8 10 
> t9 2000 t10 500 t11_t12 5000
> [4.306373] [drm:intel_dp_init_panel_power_sequencer] panel power up delay 
> 200, power down delay 50, power cycle delay 600
> [4.306374] [drm:intel_dp_init_panel_power_sequencer] backlight on delay 
> 1, off delay 200
> [4.306375] [drm:intel_dp_aux_init] registering DPDDC-A bus for card0-eDP-1
> [4.306402] [drm:edp_panel_vdd_on] Turning eDP port A VDD on
> [4.306413] [drm:edp_panel_vdd_on] PP_STATUS: 0x8008 PP_CONTROL: 
> 0xabcd000f
> [4.319361] [drm:intel_dp_get_dpcd] DPCD: 11 0a 02 00 00 00 00 00 00 00 00 
> 00 00 00 00
> [4.331840] [drm] failed to retrieve link info, disabling eDP
> [4.331862] [drm:edp_panel_vdd_off_sync] Turning eDP port A VDD off
>
> Series reverted:
>
> [4.770004] [drm:intel_dp_init_connector] Adding eDP connector on port A
> [4.777651] [drm:intel_dp_init_panel_power_sequencer] cur t1_t3 2000 t8 0 
> t9 2000 t10 500 t11_t12 6000
> [4.788222] [drm:intel_dp_init_panel_power_sequencer] vbt t1_t3 2000 t8 10 
> t9 2000 t10 500 t11_t12 5000
> [4.798890] [drm:intel_dp_init_panel_power_sequencer] panel power up delay 
> 200, power down delay 50, power cycle delay 600
> [4.811424] [drm:intel_dp_init_panel_power_sequencer] backlight on delay 
> 1, off delay 200
> [4.820705] [drm:intel_dp_aux_init] registering DPDDC-A bus for card0-eDP-1
> [4.828631] [drm:edp_panel_vdd_on] Turning eDP port A VDD on
> [4.835061] [drm:edp_panel_vdd_on] PP_STATUS: 0x8008 PP_CONTROL: 
> 0xabcd000f
> [4.843757] [drm:intel_dp_get_dpcd] DPCD: 11 0a 02 00 00 00 00 00 00 00 00 
> 00 00 00 00
> [4.853032] [drm:intel_dp_get_dpcd] Display Port TPS3 support: source yes, 
> sink no
> [4.861624] [drm:intel_dp_print_rates] source rates: 162000, 27, 54
> [4.869551] [drm:intel_dp_print_rates] sink rates: 162000, 27
> [4.876558] [drm:intel_dp_print_rates] common rates: 162000, 27
> [4.883812] [drm:intel_dp_init_panel_power_sequencer_registers] panel 
> power sequencer register settings: PP_ON 0x7d1, PP_OFF 0x1f40001, PP_DIV 
> 0x4af06
> [4.900522] asix 1-2:1.0 eth0: register 'asix' at usb-:00:14.0-2, ASIX 
> AX88772 USB 2.0 Ethernet, b6:c3:97:fe:06:71
> [4.905379] 

Re: [Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/5] drm/i915: Splitting intel_dp_detect

[Shubhangi Shrivastava]

On Friday 01 April 2016 01:11 PM, Ander Conselvan De Oliveira wrote:

On Thu, 2016-03-31 at 12:38 +, Patchwork wrote:

== Series Details ==

Series: series starting with [1/5] drm/i915: Splitting intel_dp_detect
URL   : https://patchwork.freedesktop.org/series/5044/
State : success

I pushed those to dinq.

I fixed a couple of "Alignment should match open parenthesis" errors from
checkpatch. I should have pointed those out during review, but I missed them.


Ohh.. Apology for the inconvenience caused..
Thanks for fixing these errors..

Shubhangi


For future reference, in a expression like below,

DRM_DEBUG_KMS("debug message %d",
  number),

the second line should be aligned with the opening '('.

Ander



Sure.. Will ensure that in future patches..

Shubhangi

== Summary ==

Series 5044v1 Series without cover letter
http://patchwork.freedesktop.org/api/1.0/series/5044/revisions/1/mbox/

Test kms_pipe_crc_basic:
 Subgroup suspend-read-crc-pipe-c:
 dmesg-warn -> PASS   (bsw-nuc-2)

bdw-nuci7total:196  pass:184  dwarn:0   dfail:0   fail:0   skip:12
bdw-ultratotal:196  pass:175  dwarn:0   dfail:0   fail:0   skip:21
bsw-nuc-2total:196  pass:159  dwarn:0   dfail:0   fail:0   skip:37
byt-nuc  total:196  pass:161  dwarn:0   dfail:0   fail:0   skip:35
hsw-brixbox  total:196  pass:174  dwarn:0   dfail:0   fail:0   skip:22
hsw-gt2  total:27   pass:24   dwarn:0   dfail:0   fail:0   skip:2
skl-i7k-2total:196  pass:173  dwarn:0   dfail:0   fail:0   skip:23
skl-nuci5total:196  pass:185  dwarn:0   dfail:0   fail:0   skip:11
snb-dellxps  total:79   pass:68   dwarn:0   dfail:0   fail:0   skip:10

Results at /archive/results/CI_IGT_test/Patchwork_1753/

03c0f854e93263563f559d2bc8e47fb51adae697 drm-intel-nightly: 2016y-03m-31d-10h
-50m-15s UTC integration manifest
c448c6c059ae7bcdb7345feafd5324dd6dd164a7 drm/i915: force full detect on sink
count change
c1a69603958ccde4084f379f6c1a02314b8f5245 drm/i915: Read sink_count dpcd always
5f91fb8d635f35130714bf60601948996ee976e3 drm/i915: Reorganizing
intel_dp_check_link_status
950d50e19edac435bed7a08f6147af55cd2c8835 drm/i915: Cleaning up
intel_dp_hpd_pulse
41fd654a2ac9ffc2d59ccf2353b28f6271b1 drm/i915: Splitting intel_dp_detect

___
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] [PATCH 06/16] drm/i915/gen9: Fix DMC/DC state asserts

[Patrik Jakobsson]

On Fri, Apr 01, 2016 at 04:02:37PM +0300, Imre Deak wrote:
> The display power well support and DC state management doesn't depend on
> runtime PM support, so remove the incorrect asserts about this.
> 
> Also Broxton does support DC5, so the related assert in
> assert_can_enable_dc5() is incorrect. There is a more generic and
> correct assert for this already in gen9_set_dc_state(), so we can remove
> all the other ones.
> 
> At the same time convert WARNs to WARN_ONCE for consistency with the
> other DC state asserts.
> 
> CC: Patrik Jakobsson 
> Signed-off-by: Imre Deak 

Reviewed-by: Patrik Jakobsson 

> ---
>  drivers/gpu/drm/i915/intel_runtime_pm.c | 32 +++-
>  1 file changed, 11 insertions(+), 21 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c 
> b/drivers/gpu/drm/i915/intel_runtime_pm.c
> index f5f6e89..b16315e 100644
> --- a/drivers/gpu/drm/i915/intel_runtime_pm.c
> +++ b/drivers/gpu/drm/i915/intel_runtime_pm.c
> @@ -443,15 +443,13 @@ static void hsw_set_power_well(struct drm_i915_private 
> *dev_priv,
>  
>  static void assert_can_enable_dc9(struct drm_i915_private *dev_priv)
>  {
> - struct drm_device *dev = dev_priv->dev;
> -
> - WARN(!IS_BROXTON(dev), "Platform doesn't support DC9.\n");
> - WARN((I915_READ(DC_STATE_EN) & DC_STATE_EN_DC9),
> - "DC9 already programmed to be enabled.\n");
> - WARN(I915_READ(DC_STATE_EN) & DC_STATE_EN_UPTO_DC5,
> - "DC5 still not disabled to enable DC9.\n");
> - WARN(I915_READ(HSW_PWR_WELL_DRIVER), "Power well on.\n");
> - WARN(intel_irqs_enabled(dev_priv), "Interrupts not disabled yet.\n");
> + WARN_ONCE((I915_READ(DC_STATE_EN) & DC_STATE_EN_DC9),
> +   "DC9 already programmed to be enabled.\n");
> + WARN_ONCE(I915_READ(DC_STATE_EN) & DC_STATE_EN_UPTO_DC5,
> +   "DC5 still not disabled to enable DC9.\n");
> + WARN_ONCE(I915_READ(HSW_PWR_WELL_DRIVER), "Power well on.\n");
> + WARN_ONCE(intel_irqs_enabled(dev_priv),
> +   "Interrupts not disabled yet.\n");
>  
>/*
> * TODO: check for the following to verify the conditions to enter DC9
> @@ -464,9 +462,10 @@ static void assert_can_enable_dc9(struct 
> drm_i915_private *dev_priv)
>  
>  static void assert_can_disable_dc9(struct drm_i915_private *dev_priv)
>  {
> - WARN(intel_irqs_enabled(dev_priv), "Interrupts not disabled yet.\n");
> - WARN(I915_READ(DC_STATE_EN) & DC_STATE_EN_UPTO_DC5,
> - "DC5 still not disabled.\n");
> + WARN_ONCE(intel_irqs_enabled(dev_priv),
> +   "Interrupts not disabled yet.\n");
> + WARN_ONCE(I915_READ(DC_STATE_EN) & DC_STATE_EN_UPTO_DC5,
> +   "DC5 still not disabled.\n");
>  
>/*
> * TODO: check for the following to verify DC9 state was indeed
> @@ -573,13 +572,9 @@ static void assert_csr_loaded(struct drm_i915_private 
> *dev_priv)
>  
>  static void assert_can_enable_dc5(struct drm_i915_private *dev_priv)
>  {
> - struct drm_device *dev = dev_priv->dev;
>   bool pg2_enabled = intel_display_power_well_is_enabled(dev_priv,
>   SKL_DISP_PW_2);
>  
> - WARN_ONCE(!IS_SKYLAKE(dev) && !IS_KABYLAKE(dev),
> -   "Platform doesn't support DC5.\n");
> - WARN_ONCE(!HAS_RUNTIME_PM(dev), "Runtime PM not enabled.\n");
>   WARN_ONCE(pg2_enabled, "PG2 not disabled to enable DC5.\n");
>  
>   WARN_ONCE((I915_READ(DC_STATE_EN) & DC_STATE_EN_UPTO_DC5),
> @@ -600,11 +595,6 @@ static void gen9_enable_dc5(struct drm_i915_private 
> *dev_priv)
>  
>  static void assert_can_enable_dc6(struct drm_i915_private *dev_priv)
>  {
> - struct drm_device *dev = dev_priv->dev;
> -
> - WARN_ONCE(!IS_SKYLAKE(dev) && !IS_KABYLAKE(dev),
> -   "Platform doesn't support DC6.\n");
> - WARN_ONCE(!HAS_RUNTIME_PM(dev), "Runtime PM not enabled.\n");
>   WARN_ONCE(I915_READ(UTIL_PIN_CTL) & UTIL_PIN_ENABLE,
> "Backlight is not disabled.\n");
>   WARN_ONCE((I915_READ(DC_STATE_EN) & DC_STATE_EN_UPTO_DC6),
> -- 
> 2.5.0
> 

-- 
---
Intel Sweden AB Registered Office: Knarrarnasgatan 15, 164 40 Kista, Stockholm, 
Sweden Registration Number: 556189-6027 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 05/16] drm/i915/gen9: Make power well disabling synchronous

[Patrik Jakobsson]

On Fri, Apr 01, 2016 at 04:02:36PM +0300, Imre Deak wrote:
> So far we only power well enabling was synchronous not disabling. Since
> we don't exactly know how the firmware (both DMC and PCU) synchronizes
> against the actual power well state during DC transitions, make the
> disabling also synchronous.
> 
> CC: Mika Kuoppala 
> CC: Patrik Jakobsson 
> Signed-off-by: Imre Deak 

Reviewed-by: Patrik Jakobsson 

> ---
>  drivers/gpu/drm/i915/intel_runtime_pm.c | 9 +
>  1 file changed, 5 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c 
> b/drivers/gpu/drm/i915/intel_runtime_pm.c
> index d20fd8f..f5f6e89 100644
> --- a/drivers/gpu/drm/i915/intel_runtime_pm.c
> +++ b/drivers/gpu/drm/i915/intel_runtime_pm.c
> @@ -720,10 +720,6 @@ static void skl_set_power_well(struct drm_i915_private 
> *dev_priv,
>  
>   if (!is_enabled) {
>   DRM_DEBUG_KMS("Enabling %s\n", power_well->name);
> - if (wait_for((I915_READ(HSW_PWR_WELL_DRIVER) &
> - state_mask), 1))
> - DRM_ERROR("%s enable timeout\n",
> - power_well->name);
>   check_fuse_status = true;
>   }
>   } else {
> @@ -737,6 +733,11 @@ static void skl_set_power_well(struct drm_i915_private 
> *dev_priv,
>   bxt_sanitize_power_well_requests(dev_priv, power_well);
>   }
>  
> + if (wait_for(!!(I915_READ(HSW_PWR_WELL_DRIVER) & state_mask) == enable,
> +  1))
> + DRM_ERROR("%s %s timeout\n",
> +   power_well->name, enable ? "enable" : "disable");
> +
>   if (check_fuse_status) {
>   if (power_well->data == SKL_DISP_PW_1) {
>   if (wait_for((I915_READ(SKL_FUSE_STATUS) &
> -- 
> 2.5.0
> 

-- 
---
Intel Sweden AB Registered Office: Knarrarnasgatan 15, 164 40 Kista, Stockholm, 
Sweden Registration Number: 556189-6027 
___
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 series starting with [1/5] drm/i915: Splitting intel_dp_detect

[Tvrtko Ursulin]

On 01/04/16 08:41, Ander Conselvan De Oliveira wrote:
> On Thu, 2016-03-31 at 12:38 +, Patchwork wrote:
>> == Series Details ==
>>
>> Series: series starting with [1/5] drm/i915: Splitting intel_dp_detect
>> URL   : https://patchwork.freedesktop.org/series/5044/
>> State : success
> 
> I pushed those to dinq.

This series seems to break eDP detection on BDW RVP.

Old kernel:

[1.554183] [drm:intel_dp_init_connector] Adding eDP connector on port A
[1.554245] [drm:intel_dp_init_panel_power_sequencer] cur t1_t3 2000 t8 0 t9 
2000 t10 500 t11_t12 6000
[1.554254] [drm:intel_dp_init_panel_power_sequencer] vbt t1_t3 2000 t8 10 
t9 2000 t10 500 t11_t12 5000
[1.554263] [drm:intel_dp_init_panel_power_sequencer] panel power up delay 
200, power down delay 50, power cycle delay 600
[1.554271] [drm:intel_dp_init_panel_power_sequencer] backlight on delay 1, 
off delay 200
[1.554279] [drm:intel_dp_aux_init] registering DPDDC-A bus for card0-eDP-1
[1.554530] [drm:edp_panel_vdd_on] Turning eDP port A VDD on
[1.554562] [drm:edp_panel_vdd_on] PP_STATUS: 0x8008 PP_CONTROL: 
0xabcd000f
[1.556670] [drm:intel_dp_get_dpcd] DPCD: 11 0a 02 00 00 00 00 00 00 00 00 
00 00 00 00
[1.557617] [drm:intel_dp_get_dpcd] Display Port TPS3 support: source yes, 
sink no
[1.557627] [drm:intel_dp_print_rates] source rates: 162000, 27, 54
[1.557633] [drm:intel_dp_print_rates] sink rates: 162000, 27
[1.557638] [drm:intel_dp_print_rates] common rates: 162000, 27
[1.557651] [drm:intel_dp_init_panel_power_sequencer_registers] panel power 
sequencer register settings: PP_ON 0x7d1, PP_OFF 0x1f40001, PP_DIV 0x4af06
[1.567299] [drm:drm_edid_to_eld] ELD: no CEA Extension found
[1.567308] [drm:intel_dp_drrs_init] VBT doesn't support DRRS
[1.567319] [drm:intel_panel_setup_backlight] Connector eDP-1 backlight 
initialized, enabled, brightness 937/937


Todays nightly:

[4.306321] [drm:intel_dp_init_connector] Adding eDP connector on port A
[4.306370] [drm:intel_dp_init_panel_power_sequencer] cur t1_t3 2000 t8 0 t9 
2000 t10 500 t11_t12 6000
[4.306371] [drm:intel_dp_init_panel_power_sequencer] vbt t1_t3 2000 t8 10 
t9 2000 t10 500 t11_t12 5000
[4.306373] [drm:intel_dp_init_panel_power_sequencer] panel power up delay 
200, power down delay 50, power cycle delay 600
[4.306374] [drm:intel_dp_init_panel_power_sequencer] backlight on delay 1, 
off delay 200
[4.306375] [drm:intel_dp_aux_init] registering DPDDC-A bus for card0-eDP-1
[4.306402] [drm:edp_panel_vdd_on] Turning eDP port A VDD on
[4.306413] [drm:edp_panel_vdd_on] PP_STATUS: 0x8008 PP_CONTROL: 
0xabcd000f
[4.319361] [drm:intel_dp_get_dpcd] DPCD: 11 0a 02 00 00 00 00 00 00 00 00 
00 00 00 00
[4.331840] [drm] failed to retrieve link info, disabling eDP
[4.331862] [drm:edp_panel_vdd_off_sync] Turning eDP port A VDD off

Series reverted:

[4.770004] [drm:intel_dp_init_connector] Adding eDP connector on port A
[4.777651] [drm:intel_dp_init_panel_power_sequencer] cur t1_t3 2000 t8 0 t9 
2000 t10 500 t11_t12 6000
[4.788222] [drm:intel_dp_init_panel_power_sequencer] vbt t1_t3 2000 t8 10 
t9 2000 t10 500 t11_t12 5000
[4.798890] [drm:intel_dp_init_panel_power_sequencer] panel power up delay 
200, power down delay 50, power cycle delay 600
[4.811424] [drm:intel_dp_init_panel_power_sequencer] backlight on delay 1, 
off delay 200
[4.820705] [drm:intel_dp_aux_init] registering DPDDC-A bus for card0-eDP-1
[4.828631] [drm:edp_panel_vdd_on] Turning eDP port A VDD on
[4.835061] [drm:edp_panel_vdd_on] PP_STATUS: 0x8008 PP_CONTROL: 
0xabcd000f
[4.843757] [drm:intel_dp_get_dpcd] DPCD: 11 0a 02 00 00 00 00 00 00 00 00 
00 00 00 00
[4.853032] [drm:intel_dp_get_dpcd] Display Port TPS3 support: source yes, 
sink no
[4.861624] [drm:intel_dp_print_rates] source rates: 162000, 27, 54
[4.869551] [drm:intel_dp_print_rates] sink rates: 162000, 27
[4.876558] [drm:intel_dp_print_rates] common rates: 162000, 27
[4.883812] [drm:intel_dp_init_panel_power_sequencer_registers] panel power 
sequencer register settings: PP_ON 0x7d1, PP_OFF 0x1f40001, PP_DIV 0x4af06
[4.900522] asix 1-2:1.0 eth0: register 'asix' at usb-:00:14.0-2, ASIX 
AX88772 USB 2.0 Ethernet, b6:c3:97:fe:06:71
[4.905379] [drm:drm_edid_to_eld] ELD: no CEA Extension found
[4.905380] [drm:intel_dp_drrs_init] VBT doesn't support DRRS
[4.905385] [drm:intel_panel_setup_backlight] Connector eDP-1 backlight 
initialized, enabled, brightness 937/937

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/ddi: Silence compiler warning for unknown output type

[Jani Nikula]

On Mon, 04 Apr 2016, Joonas Lahtinen  wrote:
> Well, enumeration values *known* not to be acceptable should cause a
> ERR_PTR(-EINVAL) or along that route, and there should be a
> MISSING_CASE for rest totally unexpected values.

In this case, they're all the same. No use returning errors when this
shouldn't happen to begin with.

J.


-- 
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 i-g-t 4/5] tests: fix spelling mistakes

[Dave Gordon]

On 03/04/16 17:35, Eric Engestrom wrote:

Signed-off-by: Eric Engestrom 
---
  tests/gem_concurrent_all.c | 2 +-
  tests/gem_cpu_reloc.c  | 2 +-
  tests/gem_flink_race.c | 2 +-
  tests/gem_seqno_wrap.c | 2 +-
  tests/gem_tiled_wb.c   | 2 +-
  tests/prime_nv_api.c   | 2 +-
  tests/prime_nv_pcopy.c | 2 +-
  tests/prime_self_import.c  | 4 ++--
  8 files changed, 9 insertions(+), 9 deletions(-)


[snip]


diff --git a/tests/prime_nv_api.c b/tests/prime_nv_api.c
index 054a1ec..6bf891a 100644
--- a/tests/prime_nv_api.c
+++ b/tests/prime_nv_api.c
@@ -1,4 +1,4 @@
-/* wierd use of API tests */
+/* weird use of API tests */

  /* test1- export buffer from intel, import same fd twice into nouveau,
 check handles match
diff --git a/tests/prime_nv_pcopy.c b/tests/prime_nv_pcopy.c
index b5ceabf..99eaeea 100644
--- a/tests/prime_nv_pcopy.c
+++ b/tests/prime_nv_pcopy.c
@@ -673,7 +673,7 @@ static void check3(const uint32_t *p, uint32_t pitch, 
uint32_t lines,
}
  }

-/* copy from nvidia bo to intel bo and copy to a linear bo to check if tiling 
went succesful */
+/* copy from nvidia bo to intel bo and copy to a linear bo to check if tiling 
went successful */


Might as well correct the grammar here too - I'd suggest "was 
successful", or else "went successfully", but the latter still seems 
rather clumsy.


Apart from that, they all look good, so

Reviewed-by: Dave Gordon 

IIRC there's a tool ("codespell"?) that can help find these typos; 
perhaps it would be worth adding the most recurrent of them (e,g, 
intruction->instruction) to the dictionary?


.Dave.

PS: Found the tool: https://github.com/lucasdemarchi/codespell
Dictionary is /usr/share/codespell/dictionary.txt

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915/ddi: Silence compiler warning for unknown output type

[Joonas Lahtinen]

On ma, 2016-04-04 at 10:00 +0100, Chris Wilson wrote:
> On Mon, Apr 04, 2016 at 11:45:26AM +0300, Jani Nikula wrote:
> > 
> > On Mon, 04 Apr 2016, Chris Wilson  wrote:
> > > 
> > > On Mon, Apr 04, 2016 at 09:20:27AM +0300, Joonas Lahtinen wrote:
> > > > 
> > > > On su, 2016-04-03 at 21:59 +0100, Chris Wilson wrote:
> > > > > 
> > > > > Silences
> > > > > 
> > > > >   src/drivers/gpu/drm/i915/intel_ddi.c: warning: 'port' may be 
> > > > > used uninitialized in this function [-Wuninitialized]
> > > > > 
> > > > > Reported-by: Geert Uytterhoeven 
> > > > > Signed-off-by: Chris Wilson 
> > > > > ---
> > > > >  drivers/gpu/drm/i915/intel_ddi.c | 6 +++---
> > > > >  1 file changed, 3 insertions(+), 3 deletions(-)
> > > > > 
> > > > > diff --git a/drivers/gpu/drm/i915/intel_ddi.c 
> > > > > b/drivers/gpu/drm/i915/intel_ddi.c
> > > > > index 766156f88ef4..921edf183d22 100644
> > > > > --- a/drivers/gpu/drm/i915/intel_ddi.c
> > > > > +++ b/drivers/gpu/drm/i915/intel_ddi.c
> > > > > @@ -315,6 +315,9 @@ static void ddi_get_encoder_port(struct 
> > > > > intel_encoder *intel_encoder,
> > > > >   *dig_port = enc_to_mst(encoder)->primary;
> > > > >   *port = (*dig_port)->port;
> > > > >   break;
> > > > > + default:
> > > > > + WARN(1, "Invalid DDI encoder type %d\n", 
> > > > > intel_encoder->type);
> > > > > + /* fallthrough and treat as unknown */
> > > > While touching it, might as well fix into MISSING_CASE. With that;
> > > I was tempted, I wasn't sure if not using MISSING_CASE was deliberate
> > > (trying not to confuse semantics between adding support for a new
> > > generation versus an unknown DDI)? So I left it for whoever has to make
> > > that fix (and kept the change as small as possible for a minor
> > > buglet).
> > Hitting MISSING_CASE here would, IMO, imply that the fix is to add the
> > missing case, but we have plenty of intel_output_type enums that simply
> > should not be handled here at all, and we should ensure we don't end up
> > here with the wrong output types. Thus I think keeping the WARN is the
> > way to go.
> > 
> > I'm just slightly concerned about the fix here though. So we're screwed
> > anyway if the output type is not handled, and we might use an
> > uninitialized variable... but the assumption that using *dig_port =
> > enc_to_dig_port(encoder) will result in any more meaningful result is
> > wrong.

Well, enumeration values *known* not to be acceptable should cause a
ERR_PTR(-EINVAL) or along that route, and there should be a
MISSING_CASE for rest totally unexpected values.

How to actually handle that situation outside of the function to make
system bootable, is an entirely different question :P

Regards, Joonas

> Hobson's choice, we're fubar anyway. The only question is whether or not
> we can make a choice that prevents us from locking the machine up during
> boot. I was tempted by using INTEL_OUTPUT_VGA instead, would that be
> better?
> -Chris
> 
-- 
Joonas Lahtinen
Open Source Technology Center
Intel Corporation
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 2/2] drm/i915/BXT: Get pipe conf from the port registers

[Ramalingam C]

Jani/Daniel,

I am working on implementing the pipe_config compare as suggested by 
daniel at 
https://lists.freedesktop.org/archives/intel-gfx/2016-March/091148.html


But I think this patch need not wait for that change. Either way this 
patch is required. We can continue review on this and proceed further.


On Wednesday 30 March 2016 07:23 PM, Ramalingam C wrote:

At BXT DSI, PIPE registers are inactive. So we can't get the
PIPE's mode parameters from them. The possible option is
retriving them from the PORT registers.

The required changes are added for BXT in intel_dsi_get_config
(encoder->get_config).

v2: Addressed the Jani's comments
 -removed the redundant call to encoder->get_config
 -read bpp from port register
 -removed retrival of src_size from encoder->get_config

Signed-off-by: Ramalingam C 
Signed-off-by: Uma Shankar 
---
Previously reviewed at https://patchwork.freedesktop.org/patch/75301/

  drivers/gpu/drm/i915/intel_dsi.c |   99 ++
  1 file changed, 99 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_dsi.c b/drivers/gpu/drm/i915/intel_dsi.c
index 0de74e1..2117187 100644
--- a/drivers/gpu/drm/i915/intel_dsi.c
+++ b/drivers/gpu/drm/i915/intel_dsi.c
@@ -46,6 +46,11 @@ static const struct {
},
  };
  
+enum mipi_dsi_pixel_format reg_to_pixel_format(u32 fmt)

+{
+   return pixel_format_from_vbt(fmt);
+}
+
  static void wait_for_dsi_fifo_empty(struct intel_dsi *intel_dsi, enum port 
port)
  {
struct drm_encoder *encoder = _dsi->base.base;
@@ -740,14 +745,108 @@ out_put_power:
return active;
  }
  
+/* return pixels equvalent to txbyteclkhs */

+static u16 pixels_from_txbyteclkhs(u16 clk_hs, int bpp, int lane_count,
+  u16 burst_mode_ratio)
+{
+   return DIV_ROUND_UP((clk_hs * lane_count * 8 * 100),
+   (bpp * burst_mode_ratio));
+}
+
+static void bxt_dsi_get_pipe_config(struct intel_encoder *encoder,
+struct intel_crtc_state *pipe_config)
+{
+   struct drm_device *dev = encoder->base.dev;
+   struct drm_i915_private *dev_priv = dev->dev_private;
+   struct drm_display_mode *adjusted_mode =
+   _config->base.adjusted_mode;
+   struct intel_dsi *intel_dsi = enc_to_intel_dsi(>base);
+   unsigned int lane_count = intel_dsi->lane_count;
+   unsigned int bpp, fmt;
+   enum port port;
+   u16 hactive, hfp, hsync, hbp, vfp, vsync, vbp;
+
+   /*
+* Atleast one port is active as encoder->get_config called only if
+* encoder->get_hw_state() returns true.
+*/
+   for_each_dsi_port(port, intel_dsi->ports) {
+   if (!(I915_READ(BXT_MIPI_PORT_CTRL(port)) & DPI_ENABLE))
+   continue;
+   break;
+   }
+
+   fmt = I915_READ(MIPI_DSI_FUNC_PRG(port)) & VID_MODE_FORMAT_MASK;
+   pipe_config->pipe_bpp = reg_to_pixel_format(fmt);
+
+   bpp = mipi_dsi_pixel_format_to_bpp(pipe_config->pipe_bpp);
+
+   /* In terms of pixels */
+   adjusted_mode->crtc_hdisplay =
+   I915_READ(BXT_MIPI_TRANS_HACTIVE(port));
+   adjusted_mode->crtc_vdisplay =
+   I915_READ(BXT_MIPI_TRANS_VACTIVE(port));
+   adjusted_mode->crtc_vtotal =
+   I915_READ(BXT_MIPI_TRANS_VTOTAL(port));
+
+   hactive = adjusted_mode->crtc_hdisplay;
+   hfp = I915_READ(MIPI_HFP_COUNT(port));
+
+   /*
+* meaningful for video mode non-burst sync pulse mode only,
+* can be zero for non-burst sync events and burst modes
+*/
+   hsync = I915_READ(MIPI_HSYNC_PADDING_COUNT(port));
+   hbp = I915_READ(MIPI_HBP_COUNT(port));
+
+   /* horizontal values are in terms of high speed byte clock */
+   hfp = pixels_from_txbyteclkhs(hfp, bpp, lane_count,
+   intel_dsi->burst_mode_ratio);
+   hsync = pixels_from_txbyteclkhs(hsync, bpp, lane_count,
+   intel_dsi->burst_mode_ratio);
+   hbp = pixels_from_txbyteclkhs(hbp, bpp, lane_count,
+   intel_dsi->burst_mode_ratio);
+
+   if (intel_dsi->dual_link) {
+   hfp *= 2;
+   hsync *= 2;
+   hbp *= 2;
+   }
+
+   /* vertical values are in terms of lines */
+   vfp = I915_READ(MIPI_VFP_COUNT(port));
+   vsync = I915_READ(MIPI_VSYNC_PADDING_COUNT(port));
+   vbp = I915_READ(MIPI_VBP_COUNT(port));
+
+   adjusted_mode->crtc_htotal = hactive + hfp + hsync + hbp;
+   adjusted_mode->crtc_hsync_start =
+   hfp + adjusted_mode->crtc_hdisplay;
+   adjusted_mode->crtc_hsync_end =
+   hsync + adjusted_mode->crtc_hsync_start;
+   adjusted_mode->crtc_hblank_start = 

Re: [Intel-gfx] [PATCH] drm/i915/ddi: Silence compiler warning for unknown output type

[Chris Wilson]

On Mon, Apr 04, 2016 at 11:45:26AM +0300, Jani Nikula wrote:
> On Mon, 04 Apr 2016, Chris Wilson  wrote:
> > On Mon, Apr 04, 2016 at 09:20:27AM +0300, Joonas Lahtinen wrote:
> >> On su, 2016-04-03 at 21:59 +0100, Chris Wilson wrote:
> >> > Silences
> >> > 
> >> >  src/drivers/gpu/drm/i915/intel_ddi.c: warning: 'port' may be used 
> >> > uninitialized in this function [-Wuninitialized]
> >> > 
> >> > Reported-by: Geert Uytterhoeven 
> >> > Signed-off-by: Chris Wilson 
> >> > ---
> >> >  drivers/gpu/drm/i915/intel_ddi.c | 6 +++---
> >> >  1 file changed, 3 insertions(+), 3 deletions(-)
> >> > 
> >> > diff --git a/drivers/gpu/drm/i915/intel_ddi.c 
> >> > b/drivers/gpu/drm/i915/intel_ddi.c
> >> > index 766156f88ef4..921edf183d22 100644
> >> > --- a/drivers/gpu/drm/i915/intel_ddi.c
> >> > +++ b/drivers/gpu/drm/i915/intel_ddi.c
> >> > @@ -315,6 +315,9 @@ static void ddi_get_encoder_port(struct 
> >> > intel_encoder *intel_encoder,
> >> >  *dig_port = enc_to_mst(encoder)->primary;
> >> >  *port = (*dig_port)->port;
> >> >  break;
> >> > +default:
> >> > +WARN(1, "Invalid DDI encoder type %d\n", 
> >> > intel_encoder->type);
> >> > +/* fallthrough and treat as unknown */
> >> 
> >> While touching it, might as well fix into MISSING_CASE. With that;
> >
> > I was tempted, I wasn't sure if not using MISSING_CASE was deliberate
> > (trying not to confuse semantics between adding support for a new
> > generation versus an unknown DDI)? So I left it for whoever has to make
> > that fix (and kept the change as small as possible for a minor
> > buglet).
> 
> Hitting MISSING_CASE here would, IMO, imply that the fix is to add the
> missing case, but we have plenty of intel_output_type enums that simply
> should not be handled here at all, and we should ensure we don't end up
> here with the wrong output types. Thus I think keeping the WARN is the
> way to go.
> 
> I'm just slightly concerned about the fix here though. So we're screwed
> anyway if the output type is not handled, and we might use an
> uninitialized variable... but the assumption that using *dig_port =
> enc_to_dig_port(encoder) will result in any more meaningful result is
> wrong.

Hobson's choice, we're fubar anyway. The only question is whether or not
we can make a choice that prevents us from locking the machine up during
boot. I was tempted by using INTEL_OUTPUT_VGA instead, would that be
better?
-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/ddi: Silence compiler warning for unknown output type

[Jani Nikula]

On Mon, 04 Apr 2016, Chris Wilson  wrote:
> On Mon, Apr 04, 2016 at 09:20:27AM +0300, Joonas Lahtinen wrote:
>> On su, 2016-04-03 at 21:59 +0100, Chris Wilson wrote:
>> > Silences
>> > 
>> >src/drivers/gpu/drm/i915/intel_ddi.c: warning: 'port' may be used 
>> > uninitialized in this function [-Wuninitialized]
>> > 
>> > Reported-by: Geert Uytterhoeven 
>> > Signed-off-by: Chris Wilson 
>> > ---
>> >  drivers/gpu/drm/i915/intel_ddi.c | 6 +++---
>> >  1 file changed, 3 insertions(+), 3 deletions(-)
>> > 
>> > diff --git a/drivers/gpu/drm/i915/intel_ddi.c 
>> > b/drivers/gpu/drm/i915/intel_ddi.c
>> > index 766156f88ef4..921edf183d22 100644
>> > --- a/drivers/gpu/drm/i915/intel_ddi.c
>> > +++ b/drivers/gpu/drm/i915/intel_ddi.c
>> > @@ -315,6 +315,9 @@ static void ddi_get_encoder_port(struct intel_encoder 
>> > *intel_encoder,
>> >    *dig_port = enc_to_mst(encoder)->primary;
>> >    *port = (*dig_port)->port;
>> >    break;
>> > +  default:
>> > +  WARN(1, "Invalid DDI encoder type %d\n", intel_encoder->type);
>> > +  /* fallthrough and treat as unknown */
>> 
>> While touching it, might as well fix into MISSING_CASE. With that;
>
> I was tempted, I wasn't sure if not using MISSING_CASE was deliberate
> (trying not to confuse semantics between adding support for a new
> generation versus an unknown DDI)? So I left it for whoever has to make
> that fix (and kept the change as small as possible for a minor
> buglet).

Hitting MISSING_CASE here would, IMO, imply that the fix is to add the
missing case, but we have plenty of intel_output_type enums that simply
should not be handled here at all, and we should ensure we don't end up
here with the wrong output types. Thus I think keeping the WARN is the
way to go.

I'm just slightly concerned about the fix here though. So we're screwed
anyway if the output type is not handled, and we might use an
uninitialized variable... but the assumption that using *dig_port =
enc_to_dig_port(encoder) will result in any more meaningful result is
wrong.

BR,
Jani.


>  
>> Reviewed-by: Joonas Lahtinen 
>
> Thanks,
> -Chris

-- 
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 i-g-t 4/5] tests: fix spelling mistakes

[Eric Engestrom]

Signed-off-by: Eric Engestrom 
---
 tests/gem_concurrent_all.c | 2 +-
 tests/gem_cpu_reloc.c  | 2 +-
 tests/gem_flink_race.c | 2 +-
 tests/gem_seqno_wrap.c | 2 +-
 tests/gem_tiled_wb.c   | 2 +-
 tests/prime_nv_api.c   | 2 +-
 tests/prime_nv_pcopy.c | 2 +-
 tests/prime_self_import.c  | 4 ++--
 8 files changed, 9 insertions(+), 9 deletions(-)

diff --git a/tests/gem_concurrent_all.c b/tests/gem_concurrent_all.c
index 10e5357..688eecb 100644
--- a/tests/gem_concurrent_all.c
+++ b/tests/gem_concurrent_all.c
@@ -1530,7 +1530,7 @@ run_mode(const char *prefix,
  p->copy, h->hang);
}
 
-   /* and finally try to trick the kernel into loosing the 
pending write */
+   /* and finally try to trick the kernel into losing the 
pending write */
igt_subtest_f("%s-%s-%s-gpu-read-after-write%s%s", 
prefix, mode->name, p->prefix, suffix, h->suffix) {
buffers_create();
run_wrap_func(,
diff --git a/tests/gem_cpu_reloc.c b/tests/gem_cpu_reloc.c
index 520030a..7324c4c 100644
--- a/tests/gem_cpu_reloc.c
+++ b/tests/gem_cpu_reloc.c
@@ -232,7 +232,7 @@ static void run_test(int fd, int count)
igt_progress("gem_cpu_reloc: ", 2*count+i, 3*count);
}
 
-   igt_info("Subtest suceeded, cleanup up - this might take a while.\n");
+   igt_info("Subtest succeeded, cleanup up - this might take a while.\n");
for (i = 0; i < count; i++) {
gem_close(fd, handles[i]);
}
diff --git a/tests/gem_flink_race.c b/tests/gem_flink_race.c
index 30e33f6..5937bc0 100644
--- a/tests/gem_flink_race.c
+++ b/tests/gem_flink_race.c
@@ -143,7 +143,7 @@ static void test_flink_close(void)
void *status;
int fake;
 
-   /* Allocate exit handler fds in here so that we dont screw
+   /* Allocate exit handler fds in here so that we don't screw
 * up the counts */
fake = drm_open_driver(DRIVER_INTEL);
 
diff --git a/tests/gem_seqno_wrap.c b/tests/gem_seqno_wrap.c
index f6320f4..e4a6277 100644
--- a/tests/gem_seqno_wrap.c
+++ b/tests/gem_seqno_wrap.c
@@ -485,7 +485,7 @@ int main(int argc, char **argv)
"  -t --timeout=sec  set timeout to wait for testrun to sec 
seconds\n"
"  -d --dontwrap don't wrap just run the test\n"
"  -p --prewrap=nset seqno to WRAP - n for each 
testrun\n"
-   "  -r --norandom dont randomize prewrap space\n"
+   "  -r --norandom don't randomize prewrap space\n"
"  -i --buffers  number of buffers to copy\n";
 
options.rounds = SLOW_QUICK(50, 2);
diff --git a/tests/gem_tiled_wb.c b/tests/gem_tiled_wb.c
index 67d54bd..2919736 100644
--- a/tests/gem_tiled_wb.c
+++ b/tests/gem_tiled_wb.c
@@ -68,7 +68,7 @@ create_bo(int fd)
handle = gem_create(fd, SIZE);
gem_set_tiling(fd, handle, I915_TILING_X, WIDTH * sizeof(uint32_t));
 
-   /* Write throught the fence to tiled the data.
+   /* Write through the fence to tile the data.
 * We then manually detile on reading back through the mmap(wc).
 */
data = gem_mmap__gtt(fd, handle, SIZE, PROT_READ | PROT_WRITE);
diff --git a/tests/prime_nv_api.c b/tests/prime_nv_api.c
index 054a1ec..6bf891a 100644
--- a/tests/prime_nv_api.c
+++ b/tests/prime_nv_api.c
@@ -1,4 +1,4 @@
-/* wierd use of API tests */
+/* weird use of API tests */
 
 /* test1- export buffer from intel, import same fd twice into nouveau,
check handles match
diff --git a/tests/prime_nv_pcopy.c b/tests/prime_nv_pcopy.c
index b5ceabf..99eaeea 100644
--- a/tests/prime_nv_pcopy.c
+++ b/tests/prime_nv_pcopy.c
@@ -673,7 +673,7 @@ static void check3(const uint32_t *p, uint32_t pitch, 
uint32_t lines,
}
 }
 
-/* copy from nvidia bo to intel bo and copy to a linear bo to check if tiling 
went succesful */
+/* copy from nvidia bo to intel bo and copy to a linear bo to check if tiling 
went successful */
 static void test3_base(int tile_src, int tile_dst)
 {
struct nouveau_bo *bo_intel = NULL, *bo_nvidia = NULL, *bo_linear = 
NULL;
diff --git a/tests/prime_self_import.c b/tests/prime_self_import.c
index 992334d..5ec0baa 100644
--- a/tests/prime_self_import.c
+++ b/tests/prime_self_import.c
@@ -239,7 +239,7 @@ static void test_reimport_close_race(void)
uint32_t handle;
int fake;
 
-   /* Allocate exit handler fds in here so that we dont screw
+   /* Allocate exit handler fds in here so that we don't screw
 * up the counts */
fake = drm_open_driver(DRIVER_INTEL);
 
@@ -329,7 +329,7 @@ static void test_export_close_race(void)
 
threads = calloc(num_threads, sizeof(pthread_t));
 
-   /* Allocate exit handler fds in here so that we dont screw
+   /* Allocate exit handler fds in 

[Intel-gfx] [PATCH i-g-t 2/5] assembler: fix spelling mistakes

[Eric Engestrom]

Signed-off-by: Eric Engestrom 
---
 assembler/brw_defines.h| 2 +-
 assembler/brw_eu_compact.c | 2 +-
 assembler/brw_eu_emit.c| 4 ++--
 assembler/gen4asm.h| 4 ++--
 4 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/assembler/brw_defines.h b/assembler/brw_defines.h
index 24e5e30..637b716 100644
--- a/assembler/brw_defines.h
+++ b/assembler/brw_defines.h
@@ -1239,7 +1239,7 @@ enum brw_message_target {
 # define GEN6_CLIP_XY_TEST (1 << 28)
 # define GEN6_CLIP_Z_TEST  (1 << 27)
 # define GEN6_CLIP_GB_TEST (1 << 26)
-/** 8-bit field of which user clip distances to clip aganist. */
+/** 8-bit field of which user clip distances to clip against. */
 # define GEN6_USER_CLIP_CLIP_DISTANCES_SHIFT   16
 # define GEN6_CLIP_MODE_NORMAL (0 << 13)
 # define GEN6_CLIP_MODE_REJECT_ALL (3 << 13)
diff --git a/assembler/brw_eu_compact.c b/assembler/brw_eu_compact.c
index d362ed3..c747e0f 100644
--- a/assembler/brw_eu_compact.c
+++ b/assembler/brw_eu_compact.c
@@ -727,7 +727,7 @@ brw_compact_instructions(struct brw_compile *p)
 dst = store + offset;
  }
 
- /* If we didn't compact this intruction, we need to move it down into
+ /* If we didn't compact this instruction, we need to move it down into
   * place.
   */
  if (offset != src_offset) {
diff --git a/assembler/brw_eu_emit.c b/assembler/brw_eu_emit.c
index 23f0da5..1f51037 100644
--- a/assembler/brw_eu_emit.c
+++ b/assembler/brw_eu_emit.c
@@ -1164,7 +1164,7 @@ get_inner_do_insn(struct brw_compile *p)
  *
  * When the matching 'else' instruction is reached (presumably by
  * countdown of the instruction count patched in by our ELSE/ENDIF
- * functions), the relevent flags are inverted.
+ * functions), the relevant flags are inverted.
  *
  * When the matching 'endif' instruction is reached, the flags are
  * popped off.  If the stack is now empty, normal execution resumes.
@@ -1431,7 +1431,7 @@ brw_ENDIF(struct brw_compile *p)
   emit_endif = false;
 
/*
-* A single next_insn() may change the base adress of instruction store
+* A single next_insn() may change the base address of instruction store
 * memory(p->store), so call it first before referencing the instruction
 * store pointer from an index
 */
diff --git a/assembler/gen4asm.h b/assembler/gen4asm.h
index 6b957e2..1e75126 100644
--- a/assembler/gen4asm.h
+++ b/assembler/gen4asm.h
@@ -173,9 +173,9 @@ static inline char *label_name(struct 
brw_program_instruction *i)
 return i->insn.label.name;
 }
 
-static inline bool is_relocatable(struct brw_program_instruction *intruction)
+static inline bool is_relocatable(struct brw_program_instruction *instruction)
 {
-return intruction->type == GEN4ASM_INSTRUCTION_GEN_RELOCATABLE;
+return instruction->type == GEN4ASM_INSTRUCTION_GEN_RELOCATABLE;
 }
 
 /**
-- 
2.8.0

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx