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

2016-04-05 Thread Thulasimani, Sivakumar
dont want to hijack thread but wanted to point out a possible regression 
in the

previous patches of this series.

intel_fbc_can_choose: returns true for gen 4/5/6/7. (possible bug)

so intel_crtc_state->enable_fbc = true; will be executed for first crtc
everytime intel_fbc_choose_crtc is called. Although there is check to
handle fbc already enabled, it may fail when we fbc is disabled and
we are working on non supported panel.

regards,
Sivakumar

On 4/5/2016 2:47 AM, Paulo Zanoni wrote:

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(-)



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


[Intel-gfx] [PATCH 6/7] drm/i915: Reset engine->last_submitted_seqno

2016-04-05 Thread Chris Wilson
When we change the current seqno, we also need to remember to reset the
last_submitted_seqno for the engine.

Testcase: igt/gem_exec_whisper
Signed-off-by: Chris Wilson 
Cc: Mika Kuoppala 
Cc: Joonas Lahtinen 
---
 drivers/gpu/drm/i915/intel_ringbuffer.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c 
b/drivers/gpu/drm/i915/intel_ringbuffer.c
index c7023d6ca0b7..be73c1b415e2 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.c
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
@@ -2574,6 +2574,7 @@ void intel_ring_init_seqno(struct intel_engine_cs 
*engine, u32 seqno)
}
 
engine->set_seqno(engine, seqno);
+   engine->last_submitted_seqno = seqno;
 
engine->hangcheck.seqno = seqno;
 }
-- 
2.8.0.rc3

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


[Intel-gfx] [PATCH 7/7] drm/i915: Simplify check for idleness in hangcheck

2016-04-05 Thread Chris Wilson
Having fixed the tracking of the engine's last_submitted_seqno, we can
now rely on it for detecting when the engine is idle (and not have to
touch the requests pointer).

Testcase: igt/gem_exec_whisper
Signed-off-by: Chris Wilson 
Cc: Mika Kuoppala 
Cc: Joonas Lahtinen 
---
 drivers/gpu/drm/i915/i915_irq.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index c85eb8dec2dc..a56be4f92264 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -2805,8 +2805,7 @@ static void gen8_disable_vblank(struct drm_device *dev, 
unsigned int pipe)
 static bool
 ring_idle(struct intel_engine_cs *engine, u32 seqno)
 {
-   return (list_empty(>request_list) ||
-   i915_seqno_passed(seqno, engine->last_submitted_seqno));
+   return i915_seqno_passed(seqno, engine->last_submitted_seqno);
 }
 
 static bool
-- 
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/7] drm/i915: Move the hw semaphore initialisation from GEM to the engine

2016-04-05 Thread Chris Wilson
Since we are setting engine local values that are tied to the hardware,
move it out of i915_gem_init_seqno() into the intel_ring_init_seqno()
backend, next to where the other hw semaphore registers are written.

Signed-off-by: Chris Wilson 
Cc: Mika Kuoppala 
Cc: Joonas Lahtinen 
---
 drivers/gpu/drm/i915/i915_gem.c | 8 ++--
 drivers/gpu/drm/i915/intel_ringbuffer.c | 7 +++
 2 files changed, 9 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 3e9e6f9b66f5..65f18f583ae1 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -2468,7 +2468,7 @@ i915_gem_init_seqno(struct drm_device *dev, u32 seqno)
 {
struct drm_i915_private *dev_priv = dev->dev_private;
struct intel_engine_cs *engine;
-   int ret, j;
+   int ret;
 
/* Carefully retire all requests without writing to the rings */
for_each_engine(engine, dev_priv) {
@@ -2479,13 +2479,9 @@ i915_gem_init_seqno(struct drm_device *dev, u32 seqno)
i915_gem_retire_requests(dev);
 
/* Finally reset hw state */
-   for_each_engine(engine, dev_priv) {
+   for_each_engine(engine, dev_priv)
intel_ring_init_seqno(engine, seqno);
 
-   for (j = 0; j < ARRAY_SIZE(engine->semaphore.sync_seqno); j++)
-   engine->semaphore.sync_seqno[j] = 0;
-   }
-
return 0;
 }
 
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c 
b/drivers/gpu/drm/i915/intel_ringbuffer.c
index 371f4c1fc33c..fb304df8085d 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.c
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
@@ -2552,14 +2552,21 @@ void intel_ring_init_seqno(struct intel_engine_cs 
*engine, u32 seqno)
 {
struct drm_i915_private *dev_priv = to_i915(engine->dev);
 
+   /* Semaphores are strictly monotonic, so whenever we reset the seqno,
+* so long as we reset the tracking semaphore value to 0, it will
+* always be before the next request's seqno.
+*/
if (INTEL_INFO(dev_priv)->gen == 6 || INTEL_INFO(dev_priv)->gen == 7) {
I915_WRITE(RING_SYNC_0(engine->mmio_base), 0);
I915_WRITE(RING_SYNC_1(engine->mmio_base), 0);
if (HAS_VEBOX(dev_priv))
I915_WRITE(RING_SYNC_2(engine->mmio_base), 0);
}
+   memset(engine->semaphore.sync_seqno, 0,
+  sizeof(engine->semaphore.sync_seqno));
 
engine->set_seqno(engine, seqno);
+
engine->hangcheck.seqno = seqno;
 }
 
-- 
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/7] drm/i915: Include engine->last_submitted_seqno in GPU error state

2016-04-05 Thread Chris Wilson
It's useful to look at the last seqno submitted on a particular engine
and compare it against the HWS value to check for irregularities.

Signed-off-by: Chris Wilson 
Cc: Mika Kuoppala 
Cc: Joonas Lahtinen 
---
 drivers/gpu/drm/i915/i915_debugfs.c   | 6 --
 drivers/gpu/drm/i915/i915_drv.h   | 1 +
 drivers/gpu/drm/i915/i915_gpu_error.c | 2 ++
 3 files changed, 7 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index a2e3af02c292..906e5424e488 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -1363,8 +1363,10 @@ static int i915_hangcheck_info(struct seq_file *m, void 
*unused)
 
for_each_engine_id(engine, dev_priv, id) {
seq_printf(m, "%s:\n", engine->name);
-   seq_printf(m, "\tseqno = %x [current %x]\n",
-  engine->hangcheck.seqno, seqno[id]);
+   seq_printf(m, "\tseqno = %x [current %x, last %x]\n",
+  engine->hangcheck.seqno,
+  seqno[id],
+  engine->last_submitted_seqno);
seq_printf(m, "\tACTHD = 0x%08llx [current 0x%08llx]\n",
   (long long)engine->hangcheck.acthd,
   (long long)acthd[id]);
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 313bc3576d87..fad8e0d5a216 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -495,6 +495,7 @@ struct drm_i915_error_state {
u32 cpu_ring_head;
u32 cpu_ring_tail;
 
+   u32 last_seqno;
u32 semaphore_seqno[I915_NUM_ENGINES - 1];
 
/* Register state */
diff --git a/drivers/gpu/drm/i915/i915_gpu_error.c 
b/drivers/gpu/drm/i915/i915_gpu_error.c
index 9b55409d91b3..9463cb4e9323 100644
--- a/drivers/gpu/drm/i915/i915_gpu_error.c
+++ b/drivers/gpu/drm/i915/i915_gpu_error.c
@@ -296,6 +296,7 @@ static void i915_ring_error_state(struct 
drm_i915_error_state_buf *m,
}
}
err_printf(m, "  seqno: 0x%08x\n", ring->seqno);
+   err_printf(m, "  last_seqno: 0x%08x\n", ring->last_seqno);
err_printf(m, "  waiting: %s\n", yesno(ring->waiting));
err_printf(m, "  ring->head: 0x%08x\n", ring->cpu_ring_head);
err_printf(m, "  ring->tail: 0x%08x\n", ring->cpu_ring_tail);
@@ -931,6 +932,7 @@ static void i915_record_ring_state(struct drm_device *dev,
ering->instpm = I915_READ(RING_INSTPM(engine->mmio_base));
ering->seqno = engine->get_seqno(engine, false);
ering->acthd = intel_ring_get_active_head(engine);
+   ering->last_seqno = engine->last_submitted_seqno;
ering->start = I915_READ_START(engine);
ering->head = I915_READ_HEAD(engine);
ering->tail = I915_READ_TAIL(engine);
-- 
2.8.0.rc3

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


[Intel-gfx] [PATCH 5/7] drm/i915: Reset semaphore page for gen8

2016-04-05 Thread Chris Wilson
An oversight is that when we wrap the seqno, we need to reset the hw
semaphore counters to 0. We did this for gen6 and gen7 and forgot to do
so for the new implementation required for gen8 (legacy).

Signed-off-by: Chris Wilson 
Cc: Mika Kuoppala 
Cc: Joonas Lahtinen 
---
 drivers/gpu/drm/i915/intel_ringbuffer.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c 
b/drivers/gpu/drm/i915/intel_ringbuffer.c
index fb304df8085d..c7023d6ca0b7 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.c
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
@@ -2564,6 +2564,14 @@ void intel_ring_init_seqno(struct intel_engine_cs 
*engine, u32 seqno)
}
memset(engine->semaphore.sync_seqno, 0,
   sizeof(engine->semaphore.sync_seqno));
+   if (dev_priv->semaphore_obj) {
+   struct drm_i915_gem_object *obj = dev_priv->semaphore_obj;
+   struct page *page = i915_gem_object_get_dirty_page(obj, 0);
+   uint64_t *semaphores = kmap(page);
+   memset(semaphores + engine->id * I915_NUM_ENGINES, 0,
+  sizeof(*semaphores) * I915_NUM_ENGINES);
+   kunmap(page);
+   }
 
engine->set_seqno(engine, seqno);
 
-- 
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/7] drm/i915: Remove unneeded drm_device pointer from intel_ring_init_seqno()

2016-04-05 Thread Chris Wilson
We only use drm_i915_private within the function, so delete the unneeded
drm_device local.

Signed-off-by: Chris Wilson 
Cc: Mika Kuoppala 
Cc: Joonas Lahtinen 
---
 drivers/gpu/drm/i915/intel_ringbuffer.c | 7 +++
 1 file changed, 3 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c 
b/drivers/gpu/drm/i915/intel_ringbuffer.c
index 2e864b7a528b..371f4c1fc33c 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.c
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
@@ -2550,13 +2550,12 @@ int intel_ring_cacheline_align(struct 
drm_i915_gem_request *req)
 
 void intel_ring_init_seqno(struct intel_engine_cs *engine, u32 seqno)
 {
-   struct drm_device *dev = engine->dev;
-   struct drm_i915_private *dev_priv = dev->dev_private;
+   struct drm_i915_private *dev_priv = to_i915(engine->dev);
 
-   if (INTEL_INFO(dev)->gen == 6 || INTEL_INFO(dev)->gen == 7) {
+   if (INTEL_INFO(dev_priv)->gen == 6 || INTEL_INFO(dev_priv)->gen == 7) {
I915_WRITE(RING_SYNC_0(engine->mmio_base), 0);
I915_WRITE(RING_SYNC_1(engine->mmio_base), 0);
-   if (HAS_VEBOX(dev))
+   if (HAS_VEBOX(dev_priv))
I915_WRITE(RING_SYNC_2(engine->mmio_base), 0);
}
 
-- 
2.8.0.rc3

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


[Intel-gfx] [PATCH 2/7] drm/i915: On GPU reset, set the HWS breadcrumb to the last seqno

2016-04-05 Thread Chris Wilson
After the GPU reset and we discard all of the incomplete requests, mark
the GPU as having advanced to the last_submitted_seqno (as having
completed the requests and ready for fresh work). The impact of this is
negligible, as all the requests will be considered completed by this
point, it just brings the HWS into line with expectations for external
viewers.

Signed-off-by: Chris Wilson 
Cc: Mika Kuoppala 
Cc: Joonas Lahtinen 
---
 drivers/gpu/drm/i915/i915_gem.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 40f90c7e718a..3e9e6f9b66f5 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -2882,6 +2882,8 @@ static void i915_gem_reset_engine_cleanup(struct 
drm_i915_private *dev_priv,
buffer->last_retired_head = buffer->tail;
intel_ring_update_space(buffer);
}
+
+   intel_ring_init_seqno(engine, engine->last_submitted_seqno);
 }
 
 void i915_gem_reset(struct drm_device *dev)
-- 
2.8.0.rc3

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


[Intel-gfx] Solving vlv hpd issues by holding power wells?

2016-04-05 Thread Lyude
Hi. Currently I'm working on a bug in the i915 driver where hotplugging seems to
break if we power on the machine without any connectors attached:

https://bugzilla.redhat.com/show_bug.cgi?id=1277863

So the main cause of the issue seems to be that we're not keeping the right
power wells on for HPD to work. Booting with say, HDMI, seems to result in the
POWER_DOMAIN_AUDIO domain getting ref'd (even when it's unplugged, which seems
to be another bug in the driver I've seen on a few systems at this point), which
stops the entire display domain from being shut off and subsequently keeps hpd
working. Without anything plugged in nothing turns on any power wells and the
hpd is non-functional.

Of course my first thought was to just keep the power wells required for HPD on
for as long as we have HPD enabled in the driver. I'm not entirely sure of how
this can be done though, as disabling hotplugging interrupts is done in a
context where IRQs are disabled and as such it's impossible to grab a reference
to the power domain we need since that requires us to grab a mutex. I don't see
any pre/post uninstall hooks for this either, so just having the power well
turned on and off whenever hpd is toggled doesn't seem very easy.

On top of this, after talking to a few coworkers I'm not sure if holding a power
ref as long as hpd interrupts are enabled is the right solution either, since it
could be costly in terms of power usage. He suggested that I enable polling for
each connector in the situation where all the power domains are disabled, but
having hotplugging disabled doesn't sound right to me either.

So I guess my questions are:
   1. Should we be falling back to polling when the required power wells for
  hotplug detection aren't enabled, instead of keeping them enabled to make
  hotplugging work?
   2. If polling isn't the right way to go, what is the best way to go about
  keeping a ref to the required power wells and dropping it whenever
  hotplugging is disabled?

-- 
Cheers,
Lyude

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


Re: [Intel-gfx] [PATCH] drm/i915/bxt: Set max cdclk frequency properly

2016-04-05 Thread Matt Roper
On Tue, Apr 05, 2016 at 02:37:19PM -0700, Matt Roper wrote:
> intel_update_max_cdclk() doesn't have a switch case for Broxton, so
> dev_priv->max_cdclk_freq gets set to whatever clock frequency we're
> currently running at (e.g., 144 MHz) rather than the true maximum.  This
> causes our max dotclock to also be set too low and in turn leads mode
> verification to reject perfectly valid modes while loading EDID firmware
> blobs.
> 
> Cc: Imre Deak 
> Signed-off-by: Matt Roper 
> ---

One thing I should have mentioned is that it's unclear to me whether we
should be looking at the cdclk limit bits in the DFSM register like we
do on SKL/KBL.  The bspec seems to indicate that the register in general
applies to gen9, including BXT, but the actual meaning of the bits
doesn't match up with the frequencies we have on BXT.


Matt

>  drivers/gpu/drm/i915/intel_display.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/intel_display.c 
> b/drivers/gpu/drm/i915/intel_display.c
> index af74cdb..924d851 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -5261,6 +5261,8 @@ static void intel_update_max_cdclk(struct drm_device 
> *dev)
>   dev_priv->max_cdclk_freq = 45;
>   else
>   dev_priv->max_cdclk_freq = 337500;
> + } else if (IS_BROXTON(dev)) {
> + dev_priv->max_cdclk_freq = 624000;
>   } else if (IS_BROADWELL(dev))  {
>   /*
>* FIXME with extra cooling we can allow
> -- 
> 2.1.4
> 

-- 
Matt Roper
Graphics Software Engineer
IoTG Platform Enabling & Development
Intel Corporation
(916) 356-2795
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] [PATCH] drm/i915/bxt: Set max cdclk frequency properly

2016-04-05 Thread Matt Roper
intel_update_max_cdclk() doesn't have a switch case for Broxton, so
dev_priv->max_cdclk_freq gets set to whatever clock frequency we're
currently running at (e.g., 144 MHz) rather than the true maximum.  This
causes our max dotclock to also be set too low and in turn leads mode
verification to reject perfectly valid modes while loading EDID firmware
blobs.

Cc: Imre Deak 
Signed-off-by: Matt Roper 
---
 drivers/gpu/drm/i915/intel_display.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index af74cdb..924d851 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -5261,6 +5261,8 @@ static void intel_update_max_cdclk(struct drm_device *dev)
dev_priv->max_cdclk_freq = 45;
else
dev_priv->max_cdclk_freq = 337500;
+   } else if (IS_BROXTON(dev)) {
+   dev_priv->max_cdclk_freq = 624000;
} else if (IS_BROADWELL(dev))  {
/*
 * FIXME with extra cooling we can allow
-- 
2.1.4

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


[Intel-gfx] [PATCH 0/3] Minor i915_dp_mst_info output enhancements

2016-04-05 Thread Jim Bride
While writing a utility that parses information from the debugfs file
i915_dp_mst_info and formats it in a more easily human-readable fashion,
I noticed a few things missing from the debug output that would be nice to
have.  Most notably, there was not an easy way to associate a particular
sink device with a virtual channel in an obvious way.  While I was testing
my changes I discovered that my MST branch device actually has a '\0'
embedded in its devid info that was wreaking havoc with my string parsing
so I prevented that character from being written to debugfs.

Jim Bride (3):
  drm/edid: Add drm_edid_get_monitor_name()
  drm/dp/mst: Enhance DP MST debugfs output
  drm/i915/dp/mst: Add source port info to debugfs output

 drivers/gpu/drm/drm_dp_mst_topology.c | 35 ++-
 drivers/gpu/drm/drm_edid.c| 28 
 drivers/gpu/drm/i915/i915_debugfs.c   |  3 ++-
 include/drm/drm_crtc.h|  1 +
 4 files changed, 61 insertions(+), 6 deletions(-)

-- 
2.5.0

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


[Intel-gfx] [PATCH 1/3] drm/edid: Add drm_edid_get_monitor_name()

2016-04-05 Thread Jim Bride
In order to include monitor name information in debugfs
output we needed to add a function that would extract the
monitor name from the EDID, and that function needed to
reside in the file  where the rest of the EDID helper
functions are implemented.

cc: dri-de...@lists.freedesktop.org
Signed-off-by: Jim Bride 
---
 drivers/gpu/drm/drm_edid.c | 28 
 include/drm/drm_crtc.h |  1 +
 2 files changed, 29 insertions(+)

diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 558ef9f..fc69a46 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -3569,6 +3569,34 @@ struct drm_connector *drm_select_eld(struct drm_encoder 
*encoder)
 EXPORT_SYMBOL(drm_select_eld);
 
 /**
+ * drm_edid_get_monitor_name - fetch the monitor name from the edid
+ * @edid: monitor EDID information
+ * @name: pointer to a character array of at least 13 chars to hold the name
+ *
+ * Return: True if the name could be extracted, false otherwise
+ */
+bool drm_edid_get_monitor_name(struct edid *edid, char *name)
+{
+   char *edid_name = NULL;
+   int mnl;
+
+   if (!edid || !name)
+   return false;
+
+   drm_for_each_detailed_block((u8 *)edid, monitor_name, _name);
+   for (mnl = 0; edid_name && mnl < 13; mnl++) {
+   if (edid_name[mnl] == 0x0a) {
+   name[mnl] = '\0';
+   break;
+   }
+   name[mnl] = edid_name[mnl];
+   }
+
+   return mnl ? true : false;
+}
+EXPORT_SYMBOL(drm_edid_get_monitor_name);
+
+/**
  * drm_detect_hdmi_monitor - detect whether monitor is HDMI
  * @edid: monitor EDID information
  *
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index 8cb377c..2590168 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -2500,6 +2500,7 @@ extern int drm_edid_header_is_valid(const u8 *raw_edid);
 extern bool drm_edid_block_valid(u8 *raw_edid, int block, bool print_bad_edid,
 bool *edid_corrupt);
 extern bool drm_edid_is_valid(struct edid *edid);
+extern bool drm_edid_get_monitor_name(struct edid *edid, char *name);
 
 extern struct drm_tile_group *drm_mode_create_tile_group(struct drm_device 
*dev,
 char topology[8]);
-- 
2.5.0

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


[Intel-gfx] [PATCH 2/3] drm/dp/mst: Enhance DP MST debugfs output

2016-04-05 Thread Jim Bride
Add some additional information (input vs. output port, sink associated
with VC, peer device type, max number of VCs supported) and ensure that
any embedded '\0' characters in a branch device's devid string are not
written to debugfs.

cc: dri-de...@lists.freedesktop.org
Signed-off-by: Jim Bride 
---
 drivers/gpu/drm/drm_dp_mst_topology.c | 35 ++-
 1 file changed, 30 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c 
b/drivers/gpu/drm/drm_dp_mst_topology.c
index 27fbd79..1afa36d 100644
--- a/drivers/gpu/drm/drm_dp_mst_topology.c
+++ b/drivers/gpu/drm/drm_dp_mst_topology.c
@@ -2729,7 +2729,7 @@ static void drm_dp_mst_dump_mstb(struct seq_file *m,
 
seq_printf(m, "%smst: %p, %d\n", prefix, mstb, mstb->num_ports);
list_for_each_entry(port, >ports, next) {
-   seq_printf(m, "%sport: %d: ddps: %d ldps: %d, sdp: %d/%d, %p, 
conn: %p\n", prefix, port->port_num, port->ddps, port->ldps, 
port->num_sdp_streams, port->num_sdp_stream_sinks, port, port->connector);
+   seq_printf(m, "%sport: %d: input: %d: pdt: %d, ddps: %d ldps: 
%d, sdp: %d/%d, %p, conn: %p\n", prefix, port->port_num, port->input, 
port->pdt, port->ddps, port->ldps, port->num_sdp_streams, 
port->num_sdp_stream_sinks, port, port->connector);
if (port->mstb)
drm_dp_mst_dump_mstb(m, port->mstb);
}
@@ -2750,6 +2750,17 @@ static bool dump_dp_payload_table(struct 
drm_dp_mst_topology_mgr *mgr,
return false;
 }
 
+static bool fetch_monitor_name(struct drm_dp_mst_topology_mgr *mgr,
+  struct drm_dp_mst_port *port, char *name)
+{
+   struct edid *mst_edid = NULL;
+
+   mst_edid = drm_dp_mst_get_edid(port->connector, mgr, port);
+   if (mst_edid == NULL)
+   return false;
+   return drm_edid_get_monitor_name(mst_edid, name);
+}
+
 /**
  * drm_dp_mst_dump_topology(): dump topology to seq file.
  * @m: seq_file to dump output to
@@ -2762,6 +2773,8 @@ void drm_dp_mst_dump_topology(struct seq_file *m,
 {
int i;
struct drm_dp_mst_port *port;
+   bool mname_valid = false;
+
mutex_lock(>lock);
if (mgr->mst_primary)
drm_dp_mst_dump_mstb(m, mgr->mst_primary);
@@ -2770,14 +2783,22 @@ void drm_dp_mst_dump_topology(struct seq_file *m,
mutex_unlock(>lock);
 
mutex_lock(>payload_lock);
-   seq_printf(m, "vcpi: %lx %lx\n", mgr->payload_mask, mgr->vcpi_mask);
+   seq_printf(m, "vcpi: %lx %lx %d\n", mgr->payload_mask, mgr->vcpi_mask,
+   mgr->max_payloads);
 
for (i = 0; i < mgr->max_payloads; i++) {
if (mgr->proposed_vcpis[i]) {
+   char name[13];
+
+   memset(name, 0, 13 * sizeof(char));
port = container_of(mgr->proposed_vcpis[i], struct 
drm_dp_mst_port, vcpi);
-   seq_printf(m, "vcpi %d: %d %d %d\n", i, port->port_num, 
port->vcpi.vcpi, port->vcpi.num_slots);
+   mname_valid = fetch_monitor_name(mgr, port, name);
+   seq_printf(m, "vcpi %d: %d %d %d sink name: %s\n", i,
+  port->port_num, port->vcpi.vcpi,
+  port->vcpi.num_slots, mname_valid ? name :
+  "Unknown");
} else
-   seq_printf(m, "vcpi %d:unsed\n", i);
+   seq_printf(m, "vcpi %d:unused\n", i);
}
for (i = 0; i < mgr->max_payloads; i++) {
seq_printf(m, "payload %d: %d, %d, %d\n",
@@ -2818,7 +2839,11 @@ void drm_dp_mst_dump_topology(struct seq_file *m,
seq_printf(m, "%02x", buf[i]);
seq_printf(m, " devid: ");
for (i = 0x3; i < 0x8; i++)
-   seq_printf(m, "%c", buf[i]);
+   if (buf[i] != '\0')
+   seq_printf(m, "%c", buf[i]);
+   else
+   break;
+
seq_printf(m, " revision: hw: %x.%x sw: %x.%x", buf[0x9] >> 4, 
buf[0x9] & 0xf, buf[0xa], buf[0xb]);
seq_printf(m, "\n");
bret = dump_dp_payload_table(mgr, buf);
-- 
2.5.0

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


[Intel-gfx] [PATCH 3/3] drm/i915/dp/mst: Add source port info to debugfs output

2016-04-05 Thread Jim Bride
Modify the debugfs output for i915_dp_mst_info to list the source port for
the DP MST topology in question.

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

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index a2e3af0..192f399 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -3441,7 +3441,8 @@ static int i915_dp_mst_info(struct seq_file *m, void 
*unused)
intel_dig_port = enc_to_dig_port(encoder);
if (!intel_dig_port->dp.can_mst)
continue;
-
+   seq_printf(m, "MST Source Port %c\n",
+  port_name(intel_dig_port->port));
drm_dp_mst_dump_topology(m, _dig_port->dp.mst_mgr);
}
drm_modeset_unlock_all(dev);
-- 
2.5.0

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


[Intel-gfx] [PATCH v3 6/6] drm/i915/bxt: add bxt dsi gpio element support

2016-04-05 Thread Jani Nikula
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 

---

I didn't address review comments to this one yet, but I'm including the
rebased patch for completeness.
---
 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 5e2c31d9a748..d76592eb6f5b 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 gpio_map vlv_gpio_table[] = {
 #define  CHV_GPIO_GPIOCFG_HIZ  (3 << 8)
 #define  CHV_GPIO_GPIOTXSTATE(state)   ((!!(state)) << 1)
 
+#define BXT_HV_DDI0_DDC_SDA_PIN187
+#define BXT_HV_DDI0_DDC_SCL_PIN188
+#define BXT_HV_DDI1_DDC_SDA_PIN189
+#define BXT_HV_DDI1_DDC_SCL_PIN190
+#define BXT_DBI_SDA_PIN191
+#define BXT_DBI_SCL_PIN192
+#define BXT_PANEL0_VDDEN_PIN   193
+#define BXT_PANEL0_BKLTEN_PIN  194
+#define BXT_PANEL0_BKLTCTL_PIN 195
+#define BXT_PANEL1_VDDEN_PIN   196
+#define BXT_PANEL1_BKLTEN_PIN  197
+#define BXT_PANEL1_BKLTCTL_PIN 198
+#define BXT_DBI_CSX_PIN199
+#define BXT_DBI_RESX_PIN   200
+#define BXT_GP_INTD_DSI_TE1_PIN201
+#define BXT_GP_INTD_DSI_TE2_PIN202
+#define BXT_USB_OC0_B_PIN  203
+#define BXT_USB_OC1_B_PIN  204
+#define BXT_MEX_WAKE0_B_PIN205
+#define BXT_MEX_WAKE1_B_PIN206
+#define BXT_EMMC0_CLK_PIN  156
+#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_PIN  165
+#define BXT_SDIO_CLK_PIN   166
+#define BXT_SDIO_D0_PIN167
+#define BXT_SDIO_D1_PIN168
+#define BXT_SDIO_D2_PIN169
+#define BXT_SDIO_D3_PIN170
+#define BXT_SDIO_CMD_PIN   171
+#define BXT_SDCARD_CLK_PIN 172
+#define BXT_SDCARD_D0_PIN  173
+#define BXT_SDCARD_D1_PIN  174
+#define BXT_SDCARD_D2_PIN  175
+#define BXT_SDCARD_D3_PIN  176
+#define BXT_SDCARD_CD_B_PIN177
+#define BXT_SDCARD_CMD_PIN 178
+#define BXT_SDCARD_LVL_CLK_FB_PIN  179
+#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_PIN183
+#define BXT_SDCARD_PWR_DOWN_B_PIN  184
+#define BXT_SDCARD_LVL_SEL_PIN 185
+#define BXT_SDCARD_LVL_WP_PIN  186
+#define BXT_LPSS_I2C0_SDA_PIN  124
+#define BXT_LPSS_I2C0_SCL_PIN  125
+#define BXT_LPSS_I2C1_SDA_PIN  126
+#define BXT_LPSS_I2C1_SCL_PIN  127
+#define BXT_LPSS_I2C2_SDA_PIN  128
+#define BXT_LPSS_I2C2_SCL_PIN  129
+#define BXT_LPSS_I2C3_SDA_PIN  130
+#define BXT_LPSS_I2C3_SCL_PIN  131
+#define BXT_LPSS_I2C4_SDA_PIN  132
+#define BXT_LPSS_I2C4_SCL_PIN  133
+#define BXT_LPSS_I2C5_SDA_PIN  134
+#define BXT_LPSS_I2C5_SCL_PIN  135
+#define BXT_LPSS_I2C6_SDA_PIN  136
+#define BXT_LPSS_I2C6_SCL_PIN  137
+#define BXT_LPSS_I2C7_SDA_PIN  138
+#define BXT_LPSS_I2C7_SCL_PIN  139
+#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 BXT_ISH_GPIO_5_PIN 151
+#define BXT_ISH_GPIO_6_PIN 152
+#define BXT_ISH_GPIO_7_PIN 153
+#define BXT_ISH_GPIO_8_PIN 154
+#define BXT_ISH_GPIO_9_PIN 155
+#define BXT_AVS_I2S1_MCLK_PIN  74
+#define BXT_AVS_I2S1_BCLK_PIN  75
+#define BXT_AVS_I2S1_WS_SYNC_PIN   76
+#define BXT_AVS_I2S1_SDI_PIN   77
+#define BXT_AVS_I2S1_SDO_PIN   78

[Intel-gfx] [PATCH v3 3/6] drm/i915/dsi: use a temp variable for referencing the gpio table

2016-04-05 Thread Jani Nikula
The shorthand is easier. Also change the struct name. No functional
changes.

Signed-off-by: Jani Nikula 
---
 drivers/gpu/drm/i915/intel_dsi_panel_vbt.c | 15 +--
 1 file changed, 9 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c 
b/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
index 6c2774ceb69f..ff0731420677 100644
--- a/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
+++ b/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
@@ -75,12 +75,12 @@ 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 gpio_map {
u16 base_offset;
bool init;
 };
 
-static struct gpio_table vlv_gpio_table[] = {
+static struct gpio_map 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 },
@@ -190,6 +190,7 @@ static const u8 *mipi_exec_delay(struct intel_dsi 
*intel_dsi, const u8 *data)
 static void vlv_exec_gpio(struct drm_i915_private *dev_priv,
  u8 gpio_source, u8 gpio_index, bool value)
 {
+   struct gpio_map *map;
u16 pconf0, padval;
u32 tmp;
u8 port;
@@ -199,6 +200,8 @@ static void vlv_exec_gpio(struct drm_i915_private *dev_priv,
return;
}
 
+   map = _gpio_table[gpio_index];
+
if (dev_priv->vbt.dsi.seq_version >= 3) {
DRM_DEBUG_KMS("GPIO element v3 not supported\n");
return;
@@ -213,13 +216,13 @@ static void vlv_exec_gpio(struct drm_i915_private 
*dev_priv,
}
}
 
-   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) {
vlv_iosf_sb_write(dev_priv, port, pconf0, 0x2000CC00);
-   vlv_gpio_table[gpio_index].init = true;
+   map->init = true;
}
 
tmp = 0x4 | value;
-- 
2.1.4

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


[Intel-gfx] [PATCH v3 2/6] drm/i915/dsi: abstract VLV gpio element execution to a separate function

2016-04-05 Thread Jani Nikula
Prepare for future. No functional changes.

v2: Move earlier in the series. Use bool for gpio value.

Signed-off-by: Jani Nikula 
---
 drivers/gpu/drm/i915/intel_dsi_panel_vbt.c | 68 +++---
 1 file changed, 35 insertions(+), 33 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c 
b/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
index 21964ba0bf34..6c2774ceb69f 100644
--- a/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
+++ b/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
@@ -187,41 +187,21 @@ static const u8 *mipi_exec_delay(struct intel_dsi 
*intel_dsi, const u8 *data)
return data;
 }
 
-static const u8 *mipi_exec_gpio(struct intel_dsi *intel_dsi, const u8 *data)
+static void vlv_exec_gpio(struct drm_i915_private *dev_priv,
+ u8 gpio_source, u8 gpio_index, bool value)
 {
-   u8 gpio_source, gpio_index, action, port;
u16 pconf0, padval;
-   u32 val;
-   struct drm_device *dev = intel_dsi->base.base.dev;
-   struct drm_i915_private *dev_priv = dev->dev_private;
-
-   if (dev_priv->vbt.dsi.seq_version >= 3)
-   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;
+   u32 tmp;
+   u8 port;
 
if (gpio_index >= ARRAY_SIZE(vlv_gpio_table)) {
DRM_DEBUG_KMS("unknown gpio index %u\n", gpio_index);
-   goto out;
-   }
-
-   if (!IS_VALLEYVIEW(dev_priv)) {
-   DRM_DEBUG_KMS("GPIO element not supported on this platform\n");
-   goto out;
+   return;
}
 
if (dev_priv->vbt.dsi.seq_version >= 3) {
DRM_DEBUG_KMS("GPIO element v3 not supported\n");
-   goto out;
+   return;
} else {
if (gpio_source == 0) {
port = IOSF_PORT_GPIO_NC;
@@ -229,7 +209,7 @@ static const u8 *mipi_exec_gpio(struct intel_dsi 
*intel_dsi, const u8 *data)
port = IOSF_PORT_GPIO_SC;
} else {
DRM_DEBUG_KMS("unknown gpio source %u\n", gpio_source);
-   goto out;
+   return;
}
}
 
@@ -238,19 +218,41 @@ static const u8 *mipi_exec_gpio(struct intel_dsi 
*intel_dsi, const u8 *data)
 
mutex_lock(_priv->sb_lock);
if (!vlv_gpio_table[gpio_index].init) {
-   /* program the function */
-   /* FIXME: remove constant below */
vlv_iosf_sb_write(dev_priv, port, pconf0, 0x2000CC00);
vlv_gpio_table[gpio_index].init = true;
}
 
-   val = 0x4 | action;
+   tmp = 0x4 | value;
+   vlv_iosf_sb_write(dev_priv, port, padval, tmp);
+   mutex_unlock(_priv->sb_lock);
+}
+
+static const u8 *mipi_exec_gpio(struct intel_dsi *intel_dsi, const u8 *data)
+{
+   struct drm_device *dev = intel_dsi->base.base.dev;
+   struct drm_i915_private *dev_priv = dev->dev_private;
+   u8 gpio_source, gpio_index;
+   bool value;
+
+   if (dev_priv->vbt.dsi.seq_version >= 3)
+   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 */
-   vlv_iosf_sb_write(dev_priv, port, padval, val);
-   mutex_unlock(_priv->sb_lock);
+   value = *data++ & 1;
+
+   if (IS_VALLEYVIEW(dev_priv))
+   vlv_exec_gpio(dev_priv, gpio_source, gpio_index, value);
+   else
+   DRM_DEBUG_KMS("GPIO element not supported on this platform\n");
 
-out:
return data;
 }
 
-- 
2.1.4

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


[Intel-gfx] [PATCH v3 5/6] drm/i915/dsi: add support for gpio elements on CHV

2016-04-05 Thread Jani Nikula
Add support for CHV gpio programming in DSI gpio elements.

v2: Overhaul macros according to Ville's review.

[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 | 64 ++
 1 file changed, 64 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c 
b/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
index 98583f37f5c7..5e2c31d9a748 100644
--- a/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
+++ b/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
@@ -96,6 +96,24 @@ static struct gpio_map vlv_gpio_table[] = {
{ .port = IOSF_PORT_GPIO_NC, .base_offset = 
VLV_GPIO_NC_11_PANEL1_BKLTCTL },
 };
 
+#define CHV_GPIO_IDX_START_N   0
+#define CHV_GPIO_IDX_START_SE  73
+#define CHV_GPIO_IDX_START_SW  100
+#define CHV_GPIO_IDX_START_E   198
+
+#define CHV_VBT_MAX_PINS_PER_FMLY  15
+
+#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_GPIO_CFGLOCK  (1 << 31)
+#define  CHV_GPIO_GPIOEN   (1 << 15)
+#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_GPIOTXSTATE(state)   ((!!(state)) << 1)
+
 static inline enum port intel_dsi_seq_port_to_port(u8 port)
 {
return port ? PORT_C : PORT_A;
@@ -233,6 +251,50 @@ 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, bool value)
+{
+   u16 cfg0, cfg1;
+   u16 family_num;
+   u8 port;
+
+   if (dev_priv->vbt.dsi.seq_version >= 3) {
+   if (gpio_index >= CHV_GPIO_IDX_START_E) {
+   gpio_index -= CHV_GPIO_IDX_START_E;
+   port = CHV_IOSF_PORT_GPIO_E;
+   } else if (gpio_index >= CHV_GPIO_IDX_START_SW) {
+   gpio_index -= CHV_GPIO_IDX_START_SW;
+   port = CHV_IOSF_PORT_GPIO_SW;
+   } else if (gpio_index >= CHV_GPIO_IDX_START_SE) {
+   gpio_index -= CHV_GPIO_IDX_START_SE;
+   port = CHV_IOSF_PORT_GPIO_SE;
+   } else {
+   port = CHV_IOSF_PORT_GPIO_N;
+   }
+   } 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);
+   return;
+   }
+   }
+
+   family_num = gpio_index / CHV_VBT_MAX_PINS_PER_FMLY;
+   gpio_index = gpio_index % CHV_VBT_MAX_PINS_PER_FMLY;
+
+   cfg0 = CHV_GPIO_PAD_CFG0(family_num, gpio_index);
+   cfg1 = CHV_GPIO_PAD_CFG1(family_num, gpio_index);
+
+   mutex_lock(_priv->sb_lock);
+   vlv_iosf_sb_write(dev_priv, port, cfg0, 0);
+   vlv_iosf_sb_write(dev_priv, port, cfg1,
+ CHV_GPIO_GPIOCFG_HIZ | CHV_GPIO_GPIOTXSTATE(value));
+   mutex_unlock(_priv->sb_lock);
+}
+
 static const u8 *mipi_exec_gpio(struct intel_dsi *intel_dsi, const u8 *data)
 {
struct drm_device *dev = intel_dsi->base.base.dev;
@@ -256,6 +318,8 @@ static const u8 *mipi_exec_gpio(struct intel_dsi 
*intel_dsi, const u8 *data)
 
if (IS_VALLEYVIEW(dev_priv))
vlv_exec_gpio(dev_priv, gpio_source, gpio_index, value);
+   else if (IS_CHERRYVIEW(dev_priv))
+   chv_exec_gpio(dev_priv, gpio_source, gpio_index, value);
else
DRM_DEBUG_KMS("GPIO element not supported on this platform\n");
 
-- 
2.1.4

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


[Intel-gfx] [PATCH v3 1/6] drm/i915/dsi: clean up vlv gpio table and definitions

2016-04-05 Thread Jani Nikula
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.

v3: Use the names Ville dug up in the specs.

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..21964ba0bf34 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_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_BKLTEN0x4150
+#define VLV_GPIO_NC_5_PANEL0_BKLTCTL   0x4160
+#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_BKLTEN   0x40E0
+#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_BKLTEN },
+   { VLV_GPIO_NC_5_PANEL0_BKLTCTL },
+   { VLV_GPIO_NC_6_HV_DDI1_HPD },
+   { VLV_GPIO_NC_7_HV_DDI1_DDC_SDA },
+   { VLV_GPIO_NC_8_HV_DDI1_DDC_SCL },
+   { VLV_GPIO_NC_9_PANEL1_VDDEN },
+   { VLV_GPIO_NC_10_PANEL1_BKLTEN },
+   { VLV_GPIO_NC_11_PANEL1_BKLTCTL },
 };
 
 static inline enum port intel_dsi_seq_port_to_port(u8 port)
@@ -199,7 +190,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_source, gpio_index, action, port;
-   u16 function, pad;
+   u16 pconf0, padval;
u32 val;
struct drm_device *dev = intel_dsi->base.base.dev;
struct drm_i915_private *dev_priv = dev->dev_private;
@@ -218,7 +209,7 @@ 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(gtable)) {
+   if (gpio_index >= ARRAY_SIZE(vlv_gpio_table)) {
DRM_DEBUG_KMS("unknown gpio index %u\n", gpio_index);
goto out;
}
@@ 

[Intel-gfx] [PATCH v3 4/6] drm/i915/dsi: add support for sequence block v3 gpio for VLV

2016-04-05 Thread Jani Nikula
Just put the iosf port in the gpio table. The table might include some
duplication, but this approach keeps the code the cleanest.

v2: pack the struct better (Ville), use designated initializers, add
debug logging for mismatching ports

Signed-off-by: Jani Nikula 
---
 drivers/gpu/drm/i915/intel_dsi_panel_vbt.c | 31 --
 1 file changed, 17 insertions(+), 14 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c 
b/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
index ff0731420677..98583f37f5c7 100644
--- a/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
+++ b/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
@@ -77,22 +77,23 @@ static inline struct vbt_panel *to_vbt_panel(struct 
drm_panel *panel)
 
 struct gpio_map {
u16 base_offset;
+   u8 port;
bool init;
 };
 
 static struct gpio_map 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_BKLTEN },
-   { VLV_GPIO_NC_5_PANEL0_BKLTCTL },
-   { VLV_GPIO_NC_6_HV_DDI1_HPD },
-   { VLV_GPIO_NC_7_HV_DDI1_DDC_SDA },
-   { VLV_GPIO_NC_8_HV_DDI1_DDC_SCL },
-   { VLV_GPIO_NC_9_PANEL1_VDDEN },
-   { VLV_GPIO_NC_10_PANEL1_BKLTEN },
-   { VLV_GPIO_NC_11_PANEL1_BKLTCTL },
+   { .port = IOSF_PORT_GPIO_NC, .base_offset = VLV_GPIO_NC_0_HV_DDI0_HPD },
+   { .port = IOSF_PORT_GPIO_NC, .base_offset = 
VLV_GPIO_NC_1_HV_DDI0_DDC_SDA },
+   { .port = IOSF_PORT_GPIO_NC, .base_offset = 
VLV_GPIO_NC_2_HV_DDI0_DDC_SCL },
+   { .port = IOSF_PORT_GPIO_NC, .base_offset = VLV_GPIO_NC_3_PANEL0_VDDEN 
},
+   { .port = IOSF_PORT_GPIO_NC, .base_offset = VLV_GPIO_NC_4_PANEL0_BKLTEN 
},
+   { .port = IOSF_PORT_GPIO_NC, .base_offset = 
VLV_GPIO_NC_5_PANEL0_BKLTCTL },
+   { .port = IOSF_PORT_GPIO_NC, .base_offset = VLV_GPIO_NC_6_HV_DDI1_HPD },
+   { .port = IOSF_PORT_GPIO_NC, .base_offset = 
VLV_GPIO_NC_7_HV_DDI1_DDC_SDA },
+   { .port = IOSF_PORT_GPIO_NC, .base_offset = 
VLV_GPIO_NC_8_HV_DDI1_DDC_SCL },
+   { .port = IOSF_PORT_GPIO_NC, .base_offset = VLV_GPIO_NC_9_PANEL1_VDDEN 
},
+   { .port = IOSF_PORT_GPIO_NC, .base_offset = 
VLV_GPIO_NC_10_PANEL1_BKLTEN },
+   { .port = IOSF_PORT_GPIO_NC, .base_offset = 
VLV_GPIO_NC_11_PANEL1_BKLTCTL },
 };
 
 static inline enum port intel_dsi_seq_port_to_port(u8 port)
@@ -203,8 +204,7 @@ static void vlv_exec_gpio(struct drm_i915_private *dev_priv,
map = _gpio_table[gpio_index];
 
if (dev_priv->vbt.dsi.seq_version >= 3) {
-   DRM_DEBUG_KMS("GPIO element v3 not supported\n");
-   return;
+   port = map->port;
} else {
if (gpio_source == 0) {
port = IOSF_PORT_GPIO_NC;
@@ -214,6 +214,9 @@ static void vlv_exec_gpio(struct drm_i915_private *dev_priv,
DRM_DEBUG_KMS("unknown gpio source %u\n", gpio_source);
return;
}
+
+   if (port != map->port)
+   DRM_DEBUG_KMS("suspect gpio source %u\n", gpio_source);
}
 
pconf0 = VLV_GPIO_PCONF0(map->base_offset);
-- 
2.1.4

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


[Intel-gfx] [PATCH v3 0/6] drm/i915/dsi: improved gpio element support for vlv/chv/bxt

2016-04-05 Thread Jani Nikula
Next iteration after [1]. Last patch merely rebased, and review comments
not addressed, but included here for completeness.

BR,
Jani.

[1] http://mid.gmane.org/cover.1458299160.git.jani.nik...@intel.com


Jani Nikula (6):
  drm/i915/dsi: clean up vlv gpio table and definitions
  drm/i915/dsi: abstract VLV gpio element execution to a separate
function
  drm/i915/dsi: use a temp variable for referencing the gpio table
  drm/i915/dsi: add support for sequence block v3 gpio for VLV
  drm/i915/dsi: add support for gpio elements on CHV
  drm/i915/bxt: add bxt dsi gpio element support

 drivers/gpu/drm/i915/intel_dsi_panel_vbt.c | 886 ++---
 1 file changed, 807 insertions(+), 79 deletions(-)

-- 
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 GPLL ref clock to calculate GPU freqs on VLV/CHV

2016-04-05 Thread Ville Syrjälä
On Wed, Mar 16, 2016 at 07:47:06PM +0200, Ville Syrjälä wrote:
> On Wed, Mar 16, 2016 at 07:17:51PM +0200, Imre Deak wrote:
> > On Fri, 2016-03-04 at 21:43 +0200, ville.syrj...@linux.intel.com wrote:
> > > From: Ville Syrjälä 
> > > 
> > > Extract the GPLL reference frequency from CCK and use it in the
> > > GPU freq<->opcode conversions on VLV/CHV. This eliminates all the
> > > assumptions we have about which divider is used for which czclk
> > > frequency.
> > > 
> > > Note that unlike most clocks from CCK, the GPLL ref clock is a divided
> > > down version of the CZ clock rather than the HPLL clock. CZ clock itself
> > > is a divided down version of the HPLL clock though, so in effect it just
> > > gets divided down twice.
> > > 
> > > While at it, throw in a few comments explaining the remaining constants
> > > for anyone who later wants to compare this to the spreadsheets.
> > > 
> > > Signed-off-by: Ville Syrjälä 
> > 
> > Looks ok. The relevant info is spread across multiple documents but
> > based on what I gathered this is ok and the old and new way of
> > calculation matches, so:
> > Reviewed-by: Imre Deak 
> > 
> > Some notes:
> > For clarity, I'd rename *_gpu_freq to *_gpu_opcode_to_freq and
> > *_freq_opcode to *_gpu_freq_to_opcode and mention that the CHV CU/CU2X
> > clocks are also known as slow/fast clock, so it better matches the VLV
> > code.
> 
> Well I think the slow/fast names might be more of a leftover from VLV,
> ie. someone just forgot to update the names in bunch of the docs for
> CHV. But adding a note might be prudent to avoid people having to
> wonder about it.

Changed the comment to
"CU (slow) = CU2x (fast) / 2 = GPLL ref * N / 2"

and pushed the first two patches from the series to dinq.
Thanks for the review.

> 
> > 
> > The entries for VLV 320/400MHz CZ clock are missing from the tables
> > that I saw, which is one justification for this change, since we don't
> > know if vlv_gpu_freq_div() was correct.
> 
> I don't think VLV had 320 or 400 SKUs.
> 
> > 
> > --Imre
> > 
> > 
> > 
> > > ---
> > >  drivers/gpu/drm/i915/i915_drv.h  |  1 +
> > >  drivers/gpu/drm/i915/i915_reg.h  |  1 +
> > >  drivers/gpu/drm/i915/intel_display.c | 19 ++---
> > >  drivers/gpu/drm/i915/intel_drv.h |  2 +
> > >  drivers/gpu/drm/i915/intel_pm.c  | 74 
> > > +---
> > >  5 files changed, 44 insertions(+), 53 deletions(-)
> > > 
> > > diff --git a/drivers/gpu/drm/i915/i915_drv.h 
> > > b/drivers/gpu/drm/i915/i915_drv.h
> > > index f37ac120a29d..95f77cd0ce17 100644
> > > --- a/drivers/gpu/drm/i915/i915_drv.h
> > > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > > @@ -1166,6 +1166,7 @@ struct intel_gen6_power_mgmt {
> > >   u8 efficient_freq;  /* AKA RPe. Pre-determined balanced frequency */
> > >   u8 rp1_freq;/* "less than" RP0 power/freqency */
> > >   u8 rp0_freq;/* Non-overclocked max frequency. */
> > > + u16 gpll_ref_freq;  /* vlv/chv GPLL reference frequency */
> > >  
> > >   u8 up_threshold; /* Current %busy required to uplock */
> > >   u8 down_threshold; /* Current %busy required to downclock */
> > > diff --git a/drivers/gpu/drm/i915/i915_reg.h 
> > > b/drivers/gpu/drm/i915/i915_reg.h
> > > index 7dfc4007f3fa..aa21bfc06a24 100644
> > > --- a/drivers/gpu/drm/i915/i915_reg.h
> > > +++ b/drivers/gpu/drm/i915/i915_reg.h
> > > @@ -785,6 +785,7 @@ enum skl_disp_power_wells {
> > >  #define  DSI_PLL_M1_DIV_SHIFT0
> > >  #define  DSI_PLL_M1_DIV_MASK (0x1ff << 0)
> > >  #define CCK_CZ_CLOCK_CONTROL 0x62
> > > +#define CCK_GPLL_CLOCK_CONTROL   0x67
> > >  #define CCK_DISPLAY_CLOCK_CONTROL0x6b
> > >  #define CCK_DISPLAY_REF_CLOCK_CONTROL0x6c
> > >  #define  CCK_TRUNK_FORCE_ON  (1 << 17)
> > > diff --git a/drivers/gpu/drm/i915/intel_display.c 
> > > b/drivers/gpu/drm/i915/intel_display.c
> > > index 62d36a7b3398..ba50de534f9a 100644
> > > --- a/drivers/gpu/drm/i915/intel_display.c
> > > +++ b/drivers/gpu/drm/i915/intel_display.c
> > > @@ -147,15 +147,12 @@ static int valleyview_get_vco(struct 
> > > drm_i915_private *dev_priv)
> > >   return vco_freq[hpll_freq] * 1000;
> > >  }
> > >  
> > > -static int vlv_get_cck_clock_hpll(struct drm_i915_private *dev_priv,
> > > -   const char *name, u32 reg)
> > > +int vlv_get_cck_clock(struct drm_i915_private *dev_priv,
> > > +   const char *name, u32 reg, int ref_freq)
> > >  {
> > >   u32 val;
> > >   int divider;
> > >  
> > > - if (dev_priv->hpll_freq == 0)
> > > - dev_priv->hpll_freq = valleyview_get_vco(dev_priv);
> > > -
> > >   mutex_lock(_priv->sb_lock);
> > >   val = vlv_cck_read(dev_priv, reg);
> > >   mutex_unlock(_priv->sb_lock);
> > > @@ -166,7 +163,17 @@ static int vlv_get_cck_clock_hpll(struct 
> > > drm_i915_private 

[Intel-gfx] [PATCH i-g-t] tests/pm_rps: Increase timeouts to 15 seconds

2016-04-05 Thread ville . syrjala
From: Ville Syrjälä 

My BSW takes ~12 seconds to go back to idle after high load, so the
current 10s timeouts are too short. Bump them up to 15s.

Signed-off-by: Ville Syrjälä 
---
 tests/pm_rps.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/tests/pm_rps.c b/tests/pm_rps.c
index 484db0b58bde..c3d4417d9c28 100644
--- a/tests/pm_rps.c
+++ b/tests/pm_rps.c
@@ -464,7 +464,7 @@ static void basic_check(void)
 }
 
 #define IDLE_WAIT_TIMESTEP_MSEC 100
-#define IDLE_WAIT_TIMEOUT_MSEC 1
+#define IDLE_WAIT_TIMEOUT_MSEC 15000
 static void idle_check(void)
 {
int freqs[NUMFREQ];
@@ -510,7 +510,7 @@ static void loaded_check(void)
 }
 
 #define STABILIZE_WAIT_TIMESTEP_MSEC 100
-#define STABILIZE_WAIT_TIMEOUT_MSEC 1
+#define STABILIZE_WAIT_TIMEOUT_MSEC 15000
 static void stabilize_check(int *freqs)
 {
int wait = 0;
-- 
2.7.4

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


Re: [Intel-gfx] [PATCH v5 00/12] Enable GPU switching on pre-retina?MacBook Pro

2016-04-05 Thread Lukas Wunner
Hi Bastien,

On Tue, Apr 05, 2016 at 06:59:40PM +0200, Bastien Nocera wrote:
> I tested the runtime patches for Radeon on top of 4.6.0-rc2, and
> writing DIGD failed. I also saw a number of messages with the
> vga_switcheroo core in the kernel trying to switch GPUs but failed
> because "client 1" was keeping it busy.
> 
> Is there any way to see what this "client 1" actually is? I'm guessing
> plymouth. In any case, once I'm logged in, the "DIS" is powered and
> used, and the IGD is powered as well.

Client 1 is the discrete GPU, see enum vga_switcheroo_client_id in
include/linux/vga_switcheroo.h:
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/include/linux/vga_switcheroo.h#n75

The vga_switcheroo documentation explains how to find out which
user space process is blocking the switch:
https://01.org/linuxgraphics/gfx-docs/drm/modes_of_use.html

"Prerequisite is that no user space processes (e.g. Xorg, alsactl)
have opened device files of the GPUs or the audio client. If the
switch fails, the user may invoke lsof(8) or fuser(1) on /dev/dri/
and /dev/snd/controlC1 to identify processes blocking the switch."

HTH,

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


Re: [Intel-gfx] [PATCH i-g-t] tests/gem_concurrent_all: Please the compiler regarding fscanfs unused result.

2016-04-05 Thread Chris Wilson
On Tue, Apr 05, 2016 at 08:34:02PM +0300, Marius Vlad wrote:
> On Tue, Apr 05, 2016 at 06:23:21PM +0100, Chris Wilson wrote:
> > On Tue, Apr 05, 2016 at 08:13:23PM +0300, Marius Vlad wrote:
> > > Signed-off-by: Marius Vlad 
> > > ---
> > >  tests/gem_concurrent_all.c | 2 +-
> > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > > 
> > > diff --git a/tests/gem_concurrent_all.c b/tests/gem_concurrent_all.c
> > > index 10e5357..e84ded3 100644
> > > --- a/tests/gem_concurrent_all.c
> > > +++ b/tests/gem_concurrent_all.c
> > > @@ -650,7 +650,7 @@ static int read_sysctl(const char *path)
> > >   FILE *file = fopen(path, "r");
> > >   int max = 0;
> > >   if (file) {
> > > - fscanf(file, "%d", );
> > > + igt_assert(fscanf(file, "%d", ) == 1);
> > 
> > But the code is written in case fscanf() actually fails...
> It will never fail...
> 
> Would (void) fscanf() be better?

Not sure if that silences the compiler though. Last I recall having to
do

int ignored = fscanf();
(void) ignored;

and then you get compiler warnings about set-but-not-used variables!

#define ignore(x) if ((x)) {} else {}
#define ignore(x) ((x) ?: 0)

/o\
-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] tests/gem_concurrent_all: Please the compiler regarding fscanfs unused result.

2016-04-05 Thread Marius Vlad
On Tue, Apr 05, 2016 at 06:23:21PM +0100, Chris Wilson wrote:
> On Tue, Apr 05, 2016 at 08:13:23PM +0300, Marius Vlad wrote:
> > Signed-off-by: Marius Vlad 
> > ---
> >  tests/gem_concurrent_all.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/tests/gem_concurrent_all.c b/tests/gem_concurrent_all.c
> > index 10e5357..e84ded3 100644
> > --- a/tests/gem_concurrent_all.c
> > +++ b/tests/gem_concurrent_all.c
> > @@ -650,7 +650,7 @@ static int read_sysctl(const char *path)
> > FILE *file = fopen(path, "r");
> > int max = 0;
> > if (file) {
> > -   fscanf(file, "%d", );
> > +   igt_assert(fscanf(file, "%d", ) == 1);
> 
> But the code is written in case fscanf() actually fails...
It will never fail...

Would (void) fscanf() be better?

> -Chris
> 
> -- 
> Chris Wilson, Intel Open Source Technology Centre


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


Re: [Intel-gfx] [PATCH i-g-t] tests/gem_concurrent_all: Please the compiler regarding fscanfs unused result.

2016-04-05 Thread Chris Wilson
On Tue, Apr 05, 2016 at 08:13:23PM +0300, Marius Vlad wrote:
> Signed-off-by: Marius Vlad 
> ---
>  tests/gem_concurrent_all.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/tests/gem_concurrent_all.c b/tests/gem_concurrent_all.c
> index 10e5357..e84ded3 100644
> --- a/tests/gem_concurrent_all.c
> +++ b/tests/gem_concurrent_all.c
> @@ -650,7 +650,7 @@ static int read_sysctl(const char *path)
>   FILE *file = fopen(path, "r");
>   int max = 0;
>   if (file) {
> - fscanf(file, "%d", );
> + igt_assert(fscanf(file, "%d", ) == 1);

But the code is written in case fscanf() actually fails...
-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 i-g-t] tests/gem_concurrent_all: Please the compiler regarding fscanfs unused result.

2016-04-05 Thread Marius Vlad
Signed-off-by: Marius Vlad 
---
 tests/gem_concurrent_all.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tests/gem_concurrent_all.c b/tests/gem_concurrent_all.c
index 10e5357..e84ded3 100644
--- a/tests/gem_concurrent_all.c
+++ b/tests/gem_concurrent_all.c
@@ -650,7 +650,7 @@ static int read_sysctl(const char *path)
FILE *file = fopen(path, "r");
int max = 0;
if (file) {
-   fscanf(file, "%d", );
+   igt_assert(fscanf(file, "%d", ) == 1);
fclose(file);
}
return max;
-- 
2.8.0.rc3

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


Re: [Intel-gfx] [PATCH v5 00/12] Enable GPU switching on pre-retina?MacBook Pro

2016-04-05 Thread Bastien Nocera
On Mon, 2016-03-14 at 13:41 +0100, Lukas Wunner wrote:
> 

> > So I'd push DIGD to the switch sysfs entry on boot. But I'm
> > guessing
> > that won't turn off the other output we're not interested in.
> IGD and DIGD switch to the integrated GPU and also turn off the
> discrete
> GPU. However if the machine is already switched to the integrated
> GPU,
> the commands are no-ops and the discrete GPU is not turned off.
> 
> In other words you need to check (by reading the switch file) which
> GPU
> the machine is switched to. If it's the integrated GPU, write OFF to
> the
> switch file. If it's the discrete GPU, write DIGD to the switch file.
> 
> Once runtime pm works, writing DIGD is sufficient.

I tested the runtime patches for Radeon on top of 4.6.0-rc2, and
writing DIGD failed. I also saw a number of messages with the
vga_switcheroo core in the kernel trying to switch GPUs but failed
because "client 1" was keeping it busy.

Is there any way to see what this "client 1" actually is? I'm guessing
plymouth. In any case, once I'm logged in, the "DIS" is powered and
used, and the IGD is powered as well.

Cheers
___
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 [v2,3/3] drm/i915/userptr: Store i915 backpointer for i915_mm_struct (rev4)

2016-04-05 Thread Patchwork
== Series Details ==

Series: series starting with [v2,3/3] drm/i915/userptr: Store i915 backpointer 
for i915_mm_struct (rev4)
URL   : https://patchwork.freedesktop.org/series/5240/
State : failure

== Summary ==

Series 5240v4 Series without cover letter
http://patchwork.freedesktop.org/api/1.0/series/5240/revisions/4/mbox/

Test gem_mmap:
Subgroup basic:
pass   -> DMESG-WARN (bsw-nuc-2)
Test gem_mmap_gtt:
Subgroup basic:
pass   -> DMESG-WARN (bsw-nuc-2)
Test gem_sync:
Subgroup basic-all:
pass   -> DMESG-FAIL (bsw-nuc-2)
Subgroup basic-bsd:
pass   -> SKIP   (bsw-nuc-2)
Subgroup basic-render:
pass   -> DMESG-FAIL (ivb-t430s)
Test kms_addfb_basic:
Subgroup bad-pitch-65536:
pass   -> DMESG-WARN (bsw-nuc-2)
Subgroup unused-handle:
pass   -> DMESG-WARN (bsw-nuc-2)
Test kms_flip:
Subgroup basic-flip-vs-wf_vblank:
pass   -> FAIL   (bsw-nuc-2)
Test kms_pipe_crc_basic:
Subgroup read-crc-pipe-c-frame-sequence:
pass   -> DMESG-FAIL (bsw-nuc-2)
Test pm_rpm:
Subgroup basic-rte:
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:151  dwarn:4   dfail:2   fail:1   skip:38 
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:170  dwarn:0   dfail:1   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:161  dwarn:0   dfail:0   fail:2   skip:33 

Results at /archive/results/CI_IGT_test/Patchwork_1807/

48d2a0497cd1d0630fbb59fb7871e4d678458307 drm-intel-nightly: 
2016y-04m-05d-12h-30m-42s UTC integration manifest
cd06d64af3bce9a0e6c670c1557be52f8dae7b8d drm/i915/userptr: Hold mmref whilst 
calling get-user-pages
016e2d4be4df8ceddd6812915c3c855b228d696d drm/i915/userptr: Store i915 
backpointer for i915_mm_struct

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


Re: [Intel-gfx] [PATCH v2 2/2] drm/i915: resize the GuC WOPCM for rc6

2016-04-05 Thread Rodrigo Vivi
Hi Peter,

This patch is required for the BXT firmware loading.  (Maybe/Probably
something similar for KBL is also required)
Do you have plans to fix this interpretation as Dave pointed and send
a new version?

Thanks,
Rodrigo.

On Wed, Feb 3, 2016 at 7:39 AM, Dave Gordon  wrote:
> On 21/01/16 21:41, Jeff McGee wrote:
>>
>> On Thu, Jan 21, 2016 at 06:11:01PM +, Peter Antoine wrote:
>>>
>>> This patch resizes the GuC WOPCM to so that the GuC and the RC6 memory
>>> spaces do not overlap.
>>>
>>> Issue: https://jira01.devtools.intel.com/browse/VIZ-6638
>>> Signed-off-by: Peter Antoine 
>>> ---
>>>   drivers/gpu/drm/i915/i915_guc_reg.h | 3 ++-
>>>   drivers/gpu/drm/i915/intel_guc_loader.c | 6 +-
>>>   2 files changed, 7 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/i915/i915_guc_reg.h
>>> b/drivers/gpu/drm/i915/i915_guc_reg.h
>>> index 685c799..cb938b0 100644
>>> --- a/drivers/gpu/drm/i915/i915_guc_reg.h
>>> +++ b/drivers/gpu/drm/i915/i915_guc_reg.h
>>> @@ -58,7 +58,8 @@
>>>   #define GUC_MAX_IDLE_COUNT_MMIO(0xC3E4)
>>>
>>>   #define GUC_WOPCM_SIZE_MMIO(0xc050)
>>> -#define   GUC_WOPCM_SIZE_VALUE   (0x80 << 12)  /* 512KB */
>>> +#define   GUC_WOPCM_SIZE_VALUE (0x80 << 12)/* 512KB */
>>> +#define   BXT_GUC_WOPCM_SIZE_VALUE (0x70 << 12)/* 448KB */
>>>
>>>   /* GuC addresses below GUC_WOPCM_TOP don't map through the GTT */
>>>   #define   GUC_WOPCM_TOP   (GUC_WOPCM_SIZE_VALUE)
>>
>> Should GUC_WOPCM_TOP be dynamically assigned the proper value, or is it
>> sufficient to leave at the max possible WOPCM size? If the later, might be
>> worth a comment.
>> -Jeff
>
>
> This isn't the right interpretation of these values.
>
> GUC_WOPCM_TOP is the value defining the top of the GTT address range NOT
> available to the GuC and hence where GuC-accessible objects must NOT be
> placed.
>
> GUC_WOPCM_SIZE_VALUE is the value written to the GUC_WOPCM_SIZE register,
> defining how much WOPCM space CAN be used.
>
> The former is an architectural constant (512K); the latter is a
> software-defined boundary between areas of memory within that range that are
> used for different purposes.
>
> Therefore, GUC_WOPCM_TOP must NOT be defined in terms of
> GUC_WOPCM_SIZE_VALUE, but GUC_WOPCM_SIZE_VALUE could be defined in terms of
> GUC_WOPCM_TOP, in particular as (GUC_WOPCM_TOP-reserved).
>
> .Dave.
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx



-- 
Rodrigo Vivi
Blog: http://blog.vivi.eng.br
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] ✓ Fi.CI.BAT: success for DPCD Backlight Control

2016-04-05 Thread Patchwork
== Series Details ==

Series: DPCD Backlight Control
URL   : https://patchwork.freedesktop.org/series/5330/
State : success

== Summary ==

Series 5330v1 DPCD Backlight Control
http://patchwork.freedesktop.org/api/1.0/series/5330/revisions/1/mbox/

Test kms_flip:
Subgroup basic-flip-vs-wf_vblank:
fail   -> PASS   (snb-x220t)
Test pm_rpm:
Subgroup basic-rte:
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: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: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_1806/

48d2a0497cd1d0630fbb59fb7871e4d678458307 drm-intel-nightly: 
2016y-04m-05d-12h-30m-42s UTC integration manifest
620eb0fd51589952544ec11e966b81f9df936942 drm/i915: Add Backlight Control using 
DPCD for eDP connectors (v9)
3fb7e0f5288b71cb6279b4449604f979e2d42309 drm/i915: Read eDP Display control 
capability registers
0e9292b69292b56fadefdc1bdb803d6d81029ea7 drm/dp: Add definition for Display 
Control DPCD Registers capability size

___
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/6] drm/i915/dmabuf: Tighten struct_mutex for unmap_dma_buf

2016-04-05 Thread Patchwork
== Series Details ==

Series: series starting with [1/6] drm/i915/dmabuf: Tighten struct_mutex for 
unmap_dma_buf
URL   : https://patchwork.freedesktop.org/series/5325/
State : failure

== Summary ==

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

Test drv_module_reload_basic:
pass   -> INCOMPLETE (hsw-brixbox)
Test kms_flip:
Subgroup basic-flip-vs-dpms:
pass   -> DMESG-WARN (ilk-hp8440p) UNSTABLE
Subgroup basic-flip-vs-wf_vblank:
fail   -> PASS   (snb-x220t)
Test pm_rpm:
Subgroup basic-rte:
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:135  pass:119  dwarn:0   dfail:0   fail:0   skip:15 
hsw-gt2  total:196  pass:179  dwarn:0   dfail:0   fail:0   skip:17 
ilk-hp8440p  total:196  pass:131  dwarn:1   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_1805/

48d2a0497cd1d0630fbb59fb7871e4d678458307 drm-intel-nightly: 
2016y-04m-05d-12h-30m-42s UTC integration manifest
6f826022acd130aa83d30319e478a3ae104d0184 drm/i915: Avoid allocating a vmap 
arena for a single page
366ed67bbb44c347ef88481b14ed7fca2b564f5c drm,i915: Introduce drm_malloc_gfp()
bf183e22422866f4cbbd5beb09b33d7b0c9c7ad8 drm/i915/shrinker: Restrict vmap purge 
to objects with vmaps
53fb89e12fc2c54d3e32898f4b50e69df4dc7984 drm/i915: Refactor duplicate object 
vmap functions
f0b43f7cf1a1f807b8aa5210b853049b1ff1ec95 drm/i915: Consolidate common error 
handling in intel_pin_and_map_ringbuffer_obj
d4f6a386b819281e94c18511af9ac439ed943236 drm/i915/dmabuf: Tighten struct_mutex 
for unmap_dma_buf

___
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/skl: Fix spurious gpu hang with gt3/gt4 revs

2016-04-05 Thread Ben Widawsky
On Tue, Apr 05, 2016 at 03:56:17PM +0300, Mika Kuoppala wrote:
> Experiments with heaven 4.0 benchmark and skylake gt3e (rev 0xa)
> suggest that WaForceContextSaveRestoreNonCoherent is needed for all
> revs. Extending this to all revs cures a gpu hang with rev 0xa when
> running heaven4.0 gpu benchmark.
> 
> We have been here before, with problems enabling gt4e and extending
> up to revision F0 instead of false claims of bspec of E0 only. See
> commit  ("drm/i915/skl: Default to noncoherent access
> up to F0"). In retrospect we should have covered this with this big
> blanket back then already, as E0 vs F0 discrepancy was suspicious
> enough.
> 
> Previously the WaForceEnableNonCoherent has been tied to
> context non-coherence, atleast in relevant hsds. So keep this tie
> and extended this alongside.
> 
> Cc: Abdiel Janulgue 
> Cc: Ben Widawsky 
> Cc: Timo Aaltonen 
> Cc: sta...@vger.kernel.org
> Reported-by: Mike Lothian 
> References: https://bugs.freedesktop.org/show_bug.cgi?id=93491
> Signed-off-by: Mika Kuoppala 

I don't have a reproducible hang, but both are:
Reviewed-by: Ben Widawsky 

-- 
Ben Widawsky, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/2] drm/i915/skl: Fix rc6 based gpu/system hang

2016-04-05 Thread Patchwork
== Series Details ==

Series: series starting with [1/2] drm/i915/skl: Fix rc6 based gpu/system hang
URL   : https://patchwork.freedesktop.org/series/5324/
State : success

== Summary ==

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

Test kms_flip:
Subgroup basic-flip-vs-wf_vblank:
fail   -> PASS   (snb-x220t)
Test kms_force_connector_basic:
Subgroup force-load-detect:
pass   -> SKIP   (ivb-t430s)
Test pm_rpm:
Subgroup basic-rte:
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 
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:170  dwarn:0   dfail:0   fail:0   skip:26 
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_1804/

48d2a0497cd1d0630fbb59fb7871e4d678458307 drm-intel-nightly: 
2016y-04m-05d-12h-30m-42s UTC integration manifest
e437d16cf08cd6caa4a96664277eddcfb3021dc6 drm/i915/skl: Fix spurious gpu hang 
with gt3/gt4 revs
fddfb442a80b260240eb2ece0edc368691ff62a4 drm/i915/skl: Fix rc6 based gpu/system 
hang

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


Re: [Intel-gfx] [PATCH v2 1/3] drm/i915/userptr: Flush cancellations before mmu-notifier invalidate returns

2016-04-05 Thread Tvrtko Ursulin


On 05/04/16 14:59, Chris Wilson wrote:

In order to ensure that all invalidations are completed before the
operation returns to userspace (i.e. before the munmap() syscall returns)
we need to wait upon the outstanding operations.

We are allowed to block inside the invalidate_range_start callback, and
as struct_mutex is the inner lock with mmap_sem we can wait upon the
struct_mutex without provoking lockdep into warning about a deadlock.
However, we don't actually want to wait upon outstanding rendering
whilst holding the struct_mutex if we can help it otherwise we also
block other processes from submitting work to the GPU. So first we do a
wait without the lock and then when we reacquire the lock, we double
check that everything is ready for removing the invalidated pages.

Finally to wait upon the outstanding unpinning tasks, we create a
private workqueue as a means to conveniently wait upon all at once. The
drawback is that this workqueue is per-mm, so any threads concurrently
invalidating objects will wait upon each other. The advantage of using
the workqueue is that we can wait in parallel for completion of
rendering and unpinning of several objects (of particular importance if
the process terminates with a whole mm full of objects).

v2: Apply a cup of tea to the changelog.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=94699
Testcase: igt/gem_userptr_blits/sync-unmap-cycles
Signed-off-by: Chris Wilson 
Cc: Tvrtko Ursulin 
Cc: Michał Winiarski 
---
  drivers/gpu/drm/i915/i915_gem_userptr.c | 48 -
  1 file changed, 47 insertions(+), 1 deletion(-)


Looks OK to me.

Reviewed-by: Tvrtko Ursulin 

Regards,

Tvrtko


diff --git a/drivers/gpu/drm/i915/i915_gem_userptr.c 
b/drivers/gpu/drm/i915/i915_gem_userptr.c
index 291a9393493d..92b39186b05a 100644
--- a/drivers/gpu/drm/i915/i915_gem_userptr.c
+++ b/drivers/gpu/drm/i915/i915_gem_userptr.c
@@ -49,6 +49,7 @@ struct i915_mmu_notifier {
struct hlist_node node;
struct mmu_notifier mn;
struct rb_root objects;
+   struct workqueue_struct *wq;
  };

  struct i915_mmu_object {
@@ -60,6 +61,40 @@ struct i915_mmu_object {
bool attached;
  };

+static void wait_rendering(struct drm_i915_gem_object *obj)
+{
+   struct drm_device *dev = obj->base.dev;
+   struct drm_i915_gem_request *requests[I915_NUM_ENGINES];
+   unsigned reset_counter;
+   int i, n;
+
+   if (!obj->active)
+   return;
+
+   n = 0;
+   for (i = 0; i < I915_NUM_ENGINES; i++) {
+   struct drm_i915_gem_request *req;
+
+   req = obj->last_read_req[i];
+   if (req == NULL)
+   continue;
+
+   requests[n++] = i915_gem_request_reference(req);
+   }
+
+   reset_counter = atomic_read(_i915(dev)->gpu_error.reset_counter);
+   mutex_unlock(>struct_mutex);
+
+   for (i = 0; i < n; i++)
+   __i915_wait_request(requests[i], reset_counter, false,
+   NULL, NULL);
+
+   mutex_lock(>struct_mutex);
+
+   for (i = 0; i < n; i++)
+   i915_gem_request_unreference(requests[i]);
+}
+
  static void cancel_userptr(struct work_struct *work)
  {
struct i915_mmu_object *mo = container_of(work, typeof(*mo), work);
@@ -75,6 +110,8 @@ static void cancel_userptr(struct work_struct *work)
struct i915_vma *vma, *tmp;
bool was_interruptible;

+   wait_rendering(obj);
+
was_interruptible = dev_priv->mm.interruptible;
dev_priv->mm.interruptible = false;

@@ -140,7 +177,7 @@ static void 
i915_gem_userptr_mn_invalidate_range_start(struct mmu_notifier *_mn,
 */
mo = container_of(it, struct i915_mmu_object, it);
if (kref_get_unless_zero(>obj->base.refcount))
-   schedule_work(>work);
+   queue_work(mn->wq, >work);

list_add(>link, );
it = interval_tree_iter_next(it, start, end);
@@ -148,6 +185,8 @@ static void 
i915_gem_userptr_mn_invalidate_range_start(struct mmu_notifier *_mn,
list_for_each_entry(mo, , link)
del_object(mo);
spin_unlock(>lock);
+
+   flush_workqueue(mn->wq);
  }

  static const struct mmu_notifier_ops i915_gem_userptr_notifier = {
@@ -167,10 +206,16 @@ i915_mmu_notifier_create(struct mm_struct *mm)
spin_lock_init(>lock);
mn->mn.ops = _gem_userptr_notifier;
mn->objects = RB_ROOT;
+   mn->wq = alloc_workqueue("i915-userptr-release", WQ_UNBOUND, 0);
+   if (mn->wq == NULL) {
+   kfree(mn);
+   return ERR_PTR(-ENOMEM);
+   }

 /* Protected by mmap_sem (write-lock) */
ret = __mmu_notifier_register(>mn, mm);
if (ret) {
+   

Re: [Intel-gfx] [PATCH 045/190] drm/i915: Move releasing of the GEM request from free to retire/cancel

2016-04-05 Thread Chris Wilson
On Tue, Apr 05, 2016 at 02:42:16PM +0100, Tvrtko Ursulin wrote:
> >>@@ -587,9 +587,6 @@ static int execlists_context_queue(struct
> >>drm_i915_gem_request *request)
> >>  struct drm_i915_gem_request *cursor;
> >>  int num_elements = 0;
> >>
> >>-if (request->ctx != ring->default_context)
> >>-intel_lr_context_pin(request);
> >>-
> >
> >Since you remove LRC pin from queue, the lifetime is now either:
> >
> >1. From request create to cancel.
> >2. From request create to execlist retirement.
> >
> >Would it be more logical to leave the LRC pin in queue, but remove it
> >from request creation instead? That would make the LRC pin lifetime only
> >a single possibility, from queue to execlist retire.

Well what we actually need in request allocation is pinning the
ringbuffer. At the moment we do that by pinning the request. We also
need to pin the VM in order to manipulate it. We could leave pinning the
logical context object til actual submission.

> I felt was so close in getting rid of execlist_retired_req_queue,
> using this patch as a starting point, when I realised this patch
> does not play nicely with the GuC. Back to the drawing board. :(

If you mean what happens if the GuC executes requests out-of-order - it
can't in the current model since we only have a single timeline and that
would break it badly - then nothing changes. We are only moving the
release in time, not decoupling it from any serialisation.
-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/2] drm/i915/skl: Fix spurious gpu hang with gt3/gt4 revs

2016-04-05 Thread Jani Nikula
On Tue, 05 Apr 2016, Mika Kuoppala  wrote:
> Experiments with heaven 4.0 benchmark and skylake gt3e (rev 0xa)
> suggest that WaForceContextSaveRestoreNonCoherent is needed for all
> revs. Extending this to all revs cures a gpu hang with rev 0xa when
> running heaven4.0 gpu benchmark.
>
> We have been here before, with problems enabling gt4e and extending
> up to revision F0 instead of false claims of bspec of E0 only. See
> commit  ("drm/i915/skl: Default to noncoherent access
> up to F0"). In retrospect we should have covered this with this big
> blanket back then already, as E0 vs F0 discrepancy was suspicious
> enough.
>
> Previously the WaForceEnableNonCoherent has been tied to
> context non-coherence, atleast in relevant hsds. So keep this tie
> and extended this alongside.
>
> Cc: Abdiel Janulgue 
> Cc: Ben Widawsky 
> Cc: Timo Aaltonen 
> Cc: sta...@vger.kernel.org
> Reported-by: Mike Lothian 
> References: https://bugs.freedesktop.org/show_bug.cgi?id=93491
> Signed-off-by: Mika Kuoppala 
> ---
>  drivers/gpu/drm/i915/intel_ringbuffer.c | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c 
> b/drivers/gpu/drm/i915/intel_ringbuffer.c
> index 45ce45a5e122..7fce1e6afcbc 100644
> --- a/drivers/gpu/drm/i915/intel_ringbuffer.c
> +++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
> @@ -968,7 +968,7 @@ static int gen9_init_workarounds(struct intel_engine_cs 
> *ring)
>  
>   /* WaForceContextSaveRestoreNonCoherent:skl,bxt */
>   tmp = HDC_FORCE_CONTEXT_SAVE_RESTORE_NON_COHERENT;
> - if (IS_SKL_REVID(dev, SKL_REVID_F0, SKL_REVID_F0) ||
> + if (IS_SKL_REVID(dev, SKL_REVID_F0, REVID_FOREVER) ||

Side note only slightly related to this patch: We need to start dropping
support for old steppings, only leaving production steppings in place.

BR,
Jani.


>   IS_BXT_REVID(dev, BXT_REVID_B0, REVID_FOREVER))
>   tmp |= HDC_FORCE_CSR_NON_COHERENT_OVR_DISABLE;
>   WA_SET_BIT_MASKED(HDC_CHICKEN0, tmp);
> @@ -1085,7 +1085,8 @@ static int skl_init_workarounds(struct intel_engine_cs 
> *ring)
>   WA_SET_BIT_MASKED(HIZ_CHICKEN,
> BDW_HIZ_POWER_COMPILER_CLOCK_GATING_DISABLE);
>  
> - if (IS_SKL_REVID(dev, 0, SKL_REVID_F0)) {
> + /* This is tied to WaForceContextSaveRestoreNonCoherent */
> + if (IS_SKL_REVID(dev, 0, REVID_FOREVER)) {
>   /*
>*Use Force Non-Coherent whenever executing a 3D context. This
>* is a workaround for a possible hang in the unlikely event

-- 
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] drm/i915/hdmi: Fix weak connector detection

2016-04-05 Thread Ezequiel Garcia
(Adding Jani again, who got dropped for some reason)

On 1 April 2016 at 16:50, Ezequiel Garcia  wrote:
> On 01 Apr 06:46 PM, Ville Syrjälä wrote:
>> On Fri, Apr 01, 2016 at 12:38:11PM -0300, Ezequiel Garcia wrote:
>> > El abr. 1, 2016 11:47 AM, "Ville Syrjälä" 
>> > escribió:
>> > >
>> > > On Thu, Mar 31, 2016 at 05:55:03PM -0300, Ezequiel Garcia wrote:
>> > > > Currently, our implementation of drm_connector_funcs.detect is
>> > > > based on getting a valid EDID.
>> > > >
>> > > > This requirement makes the driver fail to detect connected
>> > > > connectors in case of EDID corruption, which prevents from falling
>> > > > back to modes provided by builtin or user-provided EDIDs.
>> > >
>> > > So why are you getting corrupted EDIDs?
>> > >
>> >
>> > Does it matter?
>>
>> Yes. We should fix the real cause (if possible) instead of adding
>> more duct tape.
>>
>
> So, there are two things involved in this patch:
>
> 1.
> There are several reasons why EDID can get screwed, this is
> documented at length [1], and it's the motivation for
> CONFIG_DRM_LOAD_EDID_FIRMWARE to exist.
>
> You can find lots of reports on the internet of people getting
> corrupt EDID from their monitors. For instance, here's one [2].
>
> And even if no firmware is provided using CONFIG_DRM_LOAD_EDID_FIRMWARE,
> the DRM core will provide a 1024x768 fallback mode:
>
> int drm_helper_probe_single_connector_modes(struct drm_connector *connector,
> uint32_t maxX, uint32_t maxY)
> {
> [..]
> if (count == 0 && connector->status == connector_status_connected)
> count = drm_add_modes_noedid(connector, 1024, 768);
>
> But, this only works if the connector is detected.
>
> Since I'm interested in backporting this patch to apply it on the kernels
> I maintain (which are currently deployed on hundreds of machines), I tried
> to find a simple solution. Hence, this patch.
>
> There's no issue to fix here, because broken hardware is a fact of life,
> and not something we can fix or ignore [3].
>
> 2.
> On the other side, the i915 implementation looks suspicious. IMHO,
> drm_connector_funcs.detect should not try to read a valid EDID,
> and just try to detect if the connector is connected or disconnected.
>
> The EDID can be read in drm_connector_helper_funcs.get_modes, as other
> drm/connector drivers are doing (tda998x, tfp410, tegra).
>
> However, I think it's safer to get a simple fix now, and do this
> as follow-up patches.
>
> How does it sound?
>
> [1] Documentation/EDID/HOWTO.txt
> [2] 
> http://www.blaicher.com/2012/06/howto-fixing-a-broken-edid-eeprom-with-a-bus-pirate-v4/
> [3] https://marc.info/?l=linux-kernel=112838038415265=4
> --
> Ezequiel Garcia, VanguardiaSur
> www.vanguardiasur.com.ar



-- 
Ezequiel García, VanguardiaSur
www.vanguardiasur.com.ar
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] ✗ Fi.CI.BAT: failure for HPD support during suspend.

2016-04-05 Thread Patchwork
== Series Details ==

Series: HPD support during suspend.
URL   : https://patchwork.freedesktop.org/series/5322/
State : failure

== Summary ==

Series 5322v1 HPD support during suspend.
http://patchwork.freedesktop.org/api/1.0/series/5322/revisions/1/mbox/

Test drv_getparams_basic:
Subgroup basic-subslice-total:
pass   -> DMESG-WARN (bsw-nuc-2)
Test gem_ctx_exec:
Subgroup basic:
pass   -> DMESG-WARN (bsw-nuc-2)
Test gem_ctx_param_basic:
Subgroup basic:
pass   -> DMESG-WARN (bsw-nuc-2)
Subgroup invalid-size-set:
pass   -> DMESG-WARN (bsw-nuc-2)
Subgroup non-root-set-no-zeromap:
pass   -> DMESG-WARN (bsw-nuc-2)
Subgroup root-set-no-zeromap-disabled:
pass   -> DMESG-WARN (bsw-nuc-2)
Test gem_exec_basic:
Subgroup basic-blt:
pass   -> SKIP   (bsw-nuc-2)
Subgroup basic-default:
pass   -> SKIP   (bsw-nuc-2)
Subgroup basic-render:
pass   -> SKIP   (bsw-nuc-2)
Subgroup gtt-vebox:
pass   -> SKIP   (bsw-nuc-2)
Subgroup readonly-bsd:
pass   -> SKIP   (bsw-nuc-2)
Subgroup readonly-vebox:
pass   -> SKIP   (bsw-nuc-2)
Test gem_exec_store:
Subgroup basic-default:
pass   -> SKIP   (bsw-nuc-2)
Subgroup basic-render:
pass   -> SKIP   (bsw-nuc-2)
Test gem_exec_suspend:
Subgroup basic:
pass   -> SKIP   (bsw-nuc-2)
Test gem_exec_whisper:
Subgroup basic:
pass   -> DMESG-FAIL (bsw-nuc-2)
Test gem_mmap_gtt:
Subgroup basic-copy:
pass   -> DMESG-WARN (bsw-nuc-2)
Subgroup basic-short:
pass   -> DMESG-WARN (bsw-nuc-2)
Subgroup basic-write-read:
pass   -> DMESG-WARN (bsw-nuc-2)
Subgroup basic-write-read-distinct:
pass   -> DMESG-WARN (bsw-nuc-2)
Test gem_pwrite:
Subgroup basic:
pass   -> INCOMPLETE (bsw-nuc-2)
Test gem_storedw_loop:
Subgroup basic-default:
pass   -> SKIP   (bsw-nuc-2)
Test gem_sync:
Subgroup basic-blt:
pass   -> SKIP   (bsw-nuc-2)
Subgroup basic-each:
pass   -> DMESG-WARN (bsw-nuc-2)
Subgroup basic-vebox:
pass   -> SKIP   (bsw-nuc-2)
Test kms_addfb_basic:
Subgroup addfb25-bad-modifier:
pass   -> DMESG-WARN (bsw-nuc-2)
Subgroup addfb25-yf-tiled:
pass   -> DMESG-WARN (bsw-nuc-2)
Subgroup bad-pitch-1024:
pass   -> DMESG-WARN (bsw-nuc-2)
Subgroup basic:
pass   -> DMESG-WARN (bsw-nuc-2)
Subgroup framebuffer-vs-set-tiling:
pass   -> DMESG-WARN (bsw-nuc-2)
Subgroup size-max:
pass   -> DMESG-WARN (bsw-nuc-2)
Subgroup small-bo:
pass   -> DMESG-WARN (bsw-nuc-2)
Subgroup too-wide:
pass   -> DMESG-WARN (bsw-nuc-2)
Test kms_flip:
Subgroup basic-flip-vs-wf_vblank:
fail   -> PASS   (snb-x220t)
pass   -> DMESG-FAIL (bsw-nuc-2)
Subgroup basic-plain-flip:
pass   -> DMESG-FAIL (bsw-nuc-2)
Test kms_pipe_crc_basic:
Subgroup read-crc-pipe-a:
pass   -> DMESG-WARN (ilk-hp8440p)
Test prime_self_import:
Subgroup basic-llseek-size:
pass   -> DMESG-WARN (bsw-nuc-2)
Subgroup basic-with_fd_dup:
pass   -> DMESG-WARN (bsw-nuc-2)

bdw-ultratotal:196  pass:175  dwarn:0   dfail:0   fail:0   skip:21 
bsw-nuc-2total:113  pass:55   dwarn:21  dfail:3   fail:0   skip:33 
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:1   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_1802/

48d2a0497cd1d0630fbb59fb7871e4d678458307 drm-intel-nightly: 
2016y-04m-05d-12h-30m-42s UTC integration manifest
be31d0b4db8731ec0071b3e124cd9771669f1e21 drm/i915/bxt: Enable HPD during 
suspend.

Re: [Intel-gfx] [PATCH 045/190] drm/i915: Move releasing of the GEM request from free to retire/cancel

2016-04-05 Thread Chris Wilson
On Tue, Apr 05, 2016 at 03:27:24PM +0100, Chris Wilson wrote:
> On Tue, Apr 05, 2016 at 03:17:30PM +0100, Tvrtko Ursulin wrote:
> > 
> > On 05/04/16 15:09, Chris Wilson wrote:
> > >On Tue, Apr 05, 2016 at 02:42:16PM +0100, Tvrtko Ursulin wrote:
> > @@ -587,9 +587,6 @@ static int execlists_context_queue(struct
> > drm_i915_gem_request *request)
> >   struct drm_i915_gem_request *cursor;
> >   int num_elements = 0;
> > 
> > -if (request->ctx != ring->default_context)
> > -intel_lr_context_pin(request);
> > -
> > >>>
> > >>>Since you remove LRC pin from queue, the lifetime is now either:
> > >>>
> > >>>1. From request create to cancel.
> > >>>2. From request create to execlist retirement.
> > >>>
> > >>>Would it be more logical to leave the LRC pin in queue, but remove it
> > >>>from request creation instead? That would make the LRC pin lifetime only
> > >>>a single possibility, from queue to execlist retire.
> > >
> > >Well what we actually need in request allocation is pinning the
> > >ringbuffer. At the moment we do that by pinning the request. We also
> > >need to pin the VM in order to manipulate it. We could leave pinning the
> > >logical context object til actual submission.
> > 
> > Hmmm, yes. Have to think how complicated or not would that be.
> > 
> > >>I felt was so close in getting rid of execlist_retired_req_queue,
> > >>using this patch as a starting point, when I realised this patch
> > >>does not play nicely with the GuC. Back to the drawing board. :(
> > >
> > >If you mean what happens if the GuC executes requests out-of-order - it
> > >can't in the current model since we only have a single timeline and that
> > >would break it badly - then nothing changes. We are only moving the
> > >release in time, not decoupling it from any serialisation.
> > 
> > No, there is no LRC unpin, it is unbalanced in the GuC mode with
> > this patch. Unless I am missing something... ?
> 
> Under GuC submission mode, we acquire the context with
> 
> i915_gem_request_alloc ->
>   intel_logical_ring_alloc_request_extras ->
>   intel_lr_context_pin
> 
> intel_logical_ring_advance_and_submit() keeps track of last_context for
> both execlists and GuC
> 
> and we release the context from
> 
> i915_gem_request_retire or i915_gem_request_cancel ->
>   __i915_gem_request_release ->
>   intel_lr_context_unpin
> 
> (We need to fix that piece of insider knowlege.)
> 
> i.e. GuC submission LRC tracking behaves identically to execlists.
> There's no feedback from requests to the GuC at the moment to track
> active GuC clients though.

From IRC, this is what is in my tree not what is at the time of the
patch. Sorry, so what I need to rebalance context-pinning is your
suggestion of tracking the pinned-context on the request:

https://cgit.freedesktop.org/~ickle/linux-2.6/commit/?h=tasklet=5c57c9d270b5fcbf9e89804c623c96027746ed86

Thanks, I hope that will slot in nicely
-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] kms_atomic: Skip rather than fail on non-atomic drivers

2016-04-05 Thread Matt Roper
On Tue, Apr 05, 2016 at 02:02:38PM +0100, Daniel Stone wrote:
> Hi,
> 
> On 4 April 2016 at 22:17, Matt Roper  wrote:
> > 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.
> 
> That was certainly the intention.
> 
> Reviewed-by: Daniel Stone 
> 
> Cheers,
> Daniel

Thanks for the review; pushed.


Matt

-- 
Matt Roper
Graphics Software Engineer
IoTG Platform Enabling & Development
Intel Corporation
(916) 356-2795
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] ✗ Fi.CI.BAT: failure for DPCD Backlight Control

2016-04-05 Thread Patchwork
== Series Details ==

Series: DPCD Backlight Control
URL   : https://patchwork.freedesktop.org/series/5323/
State : failure

== Summary ==

  LD  drivers/pci/built-in.o
  CC  drivers/usb/storage/option_ms.o
  CC  drivers/usb/host/ehci-pci.o
  LD  drivers/usb/gadget/libcomposite.o
  LD  drivers/usb/gadget/built-in.o
  CC  drivers/usb/storage/usual-tables.o
  CC  drivers/usb/host/ohci-hcd.o
  LD [M]  drivers/net/ethernet/intel/igb/igb.o
  CC  drivers/usb/host/ohci-pci.o
  LD  drivers/video/fbdev/built-in.o
  CC  drivers/usb/host/uhci-hcd.o
  CC  drivers/usb/host/xhci.o
  LD  drivers/video/built-in.o
  CC  drivers/usb/host/xhci-mem.o
  CC  drivers/usb/host/xhci-ring.o
  CC  drivers/usb/host/xhci-hub.o
  CC  drivers/usb/host/xhci-dbg.o
  CC  drivers/usb/host/xhci-trace.o
  CC  drivers/usb/host/xhci-pci.o
  LD  drivers/usb/storage/usb-storage.o
  LD  drivers/usb/storage/built-in.o
  LD [M]  drivers/usb/serial/usbserial.o
  LD [M]  drivers/net/ethernet/intel/igbvf/igbvf.o
  LD  drivers/net/ethernet/built-in.o
  LD  drivers/net/built-in.o
  LD  drivers/usb/host/xhci-hcd.o
  LD  drivers/usb/host/built-in.o
  LD  drivers/usb/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 3/6] drm/i915/bxt: Corrected the guid for bxt.

2016-04-05 Thread kbuild test robot
Hi Animesh,

[auto build test WARNING on drm-intel/for-linux-next]
[also build test WARNING on next-20160405]
[cannot apply to v4.6-rc2]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improving the system]

url:
https://github.com/0day-ci/linux/commits/Animesh-Manna/HPD-support-during-suspend/20160405-204154
base:   git://anongit.freedesktop.org/drm-intel for-linux-next
config: i386-randconfig-n0-201614 (attached as .config)
reproduce:
# save the attached .config to linux build tree
make ARCH=i386 

All warnings (new ones prefixed by >>):

>> WARNING: drivers/gpu/built-in.o(.text+0x22ff8e): Section mismatch in 
>> reference from the function intel_dsm_detect() to the variable 
>> .init.data:intel_bxt_dsm_guid
   The function intel_dsm_detect() references
   the variable __initdata intel_bxt_dsm_guid.
   This is often because intel_dsm_detect lacks a __initdata
   annotation or the annotation of intel_bxt_dsm_guid is wrong.

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: Binary data
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH 045/190] drm/i915: Move releasing of the GEM request from free to retire/cancel

2016-04-05 Thread Chris Wilson
On Tue, Apr 05, 2016 at 03:17:30PM +0100, Tvrtko Ursulin wrote:
> 
> On 05/04/16 15:09, Chris Wilson wrote:
> >On Tue, Apr 05, 2016 at 02:42:16PM +0100, Tvrtko Ursulin wrote:
> @@ -587,9 +587,6 @@ static int execlists_context_queue(struct
> drm_i915_gem_request *request)
>   struct drm_i915_gem_request *cursor;
>   int num_elements = 0;
> 
> -if (request->ctx != ring->default_context)
> -intel_lr_context_pin(request);
> -
> >>>
> >>>Since you remove LRC pin from queue, the lifetime is now either:
> >>>
> >>>1. From request create to cancel.
> >>>2. From request create to execlist retirement.
> >>>
> >>>Would it be more logical to leave the LRC pin in queue, but remove it
> >>>from request creation instead? That would make the LRC pin lifetime only
> >>>a single possibility, from queue to execlist retire.
> >
> >Well what we actually need in request allocation is pinning the
> >ringbuffer. At the moment we do that by pinning the request. We also
> >need to pin the VM in order to manipulate it. We could leave pinning the
> >logical context object til actual submission.
> 
> Hmmm, yes. Have to think how complicated or not would that be.
> 
> >>I felt was so close in getting rid of execlist_retired_req_queue,
> >>using this patch as a starting point, when I realised this patch
> >>does not play nicely with the GuC. Back to the drawing board. :(
> >
> >If you mean what happens if the GuC executes requests out-of-order - it
> >can't in the current model since we only have a single timeline and that
> >would break it badly - then nothing changes. We are only moving the
> >release in time, not decoupling it from any serialisation.
> 
> No, there is no LRC unpin, it is unbalanced in the GuC mode with
> this patch. Unless I am missing something... ?

Under GuC submission mode, we acquire the context with

i915_gem_request_alloc ->
intel_logical_ring_alloc_request_extras ->
intel_lr_context_pin

intel_logical_ring_advance_and_submit() keeps track of last_context for
both execlists and GuC

and we release the context from

i915_gem_request_retire or i915_gem_request_cancel ->
__i915_gem_request_release ->
intel_lr_context_unpin

(We need to fix that piece of insider knowlege.)

i.e. GuC submission LRC tracking behaves identically to execlists.
There's no feedback from requests to the GuC at the moment to track
active GuC clients though.
-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 2/3] drm/i915: Read eDP Display control capability registers

2016-04-05 Thread Yetunde Adebisi
Add new edp_dpcd variable to intel_dp.
Read and save eDP Display control capability registers to edp_dpcd.

Signed-off-by: Yetunde Adebisi 
---
 drivers/gpu/drm/i915/intel_dp.c  | 15 ++-
 drivers/gpu/drm/i915/intel_drv.h |  1 +
 2 files changed, 11 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index da0c3d2..ad2c7d6 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -3777,7 +3777,6 @@ intel_dp_get_dpcd(struct intel_dp *intel_dp)
struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp);
struct drm_device *dev = dig_port->base.base.dev;
struct drm_i915_private *dev_priv = dev->dev_private;
-   uint8_t rev;
 
if (intel_dp_dpcd_read_wake(_dp->aux, 0x000, intel_dp->dpcd,
sizeof(intel_dp->dpcd)) < 0)
@@ -3834,6 +3833,15 @@ intel_dp_get_dpcd(struct intel_dp *intel_dp)
DRM_DEBUG_KMS("PSR2 %s on sink",
dev_priv->psr.psr2_support ? "supported" : "not 
supported");
}
+
+   /* Read the eDP Display control capabilities registers */
+   memset(intel_dp->edp_dpcd, 0, sizeof(intel_dp->edp_dpcd));
+   if ((intel_dp->dpcd[DP_EDP_CONFIGURATION_CAP] & 
DP_DPCD_DISPLAY_CONTROL_CAPABLE) &&
+   (intel_dp_dpcd_read_wake(_dp->aux, 
DP_EDP_DPCD_REV,
+   intel_dp->edp_dpcd, 
sizeof(intel_dp->edp_dpcd)) ==
+   
sizeof(intel_dp->edp_dpcd)))
+   DRM_DEBUG_KMS("EDP DPCD : %*ph\n", (int) 
sizeof(intel_dp->edp_dpcd),
+   intel_dp->edp_dpcd);
}
 
DRM_DEBUG_KMS("Display Port TPS3 support: source %s, sink %s\n",
@@ -3841,10 +3849,7 @@ intel_dp_get_dpcd(struct intel_dp *intel_dp)
  yesno(drm_dp_tps3_supported(intel_dp->dpcd)));
 
/* Intermediate frequency support */
-   if (is_edp(intel_dp) &&
-   (intel_dp->dpcd[DP_EDP_CONFIGURATION_CAP] & 
DP_DPCD_DISPLAY_CONTROL_CAPABLE) &&
-   (intel_dp_dpcd_read_wake(_dp->aux, DP_EDP_DPCD_REV, , 1) 
== 1) &&
-   (rev >= 0x03)) { /* eDp v1.4 or higher */
+   if (is_edp(intel_dp) && (intel_dp->edp_dpcd[0] >= 0x03)) { /* eDp v1.4 
or higher */
__le16 sink_rates[DP_MAX_SUPPORTED_RATES];
int i;
 
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 9255b56..b14e515 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -805,6 +805,7 @@ struct intel_dp {
uint8_t dpcd[DP_RECEIVER_CAP_SIZE];
uint8_t psr_dpcd[EDP_PSR_RECEIVER_CAP_SIZE];
uint8_t downstream_ports[DP_MAX_DOWNSTREAM_PORTS];
+   uint8_t edp_dpcd[EDP_DISPLAY_CTL_CAP_SIZE];
/* sink rates as reported by DP_SUPPORTED_LINK_RATES */
uint8_t num_sink_rates;
int sink_rates[DP_MAX_SUPPORTED_RATES];
-- 
1.9.3

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


[Intel-gfx] [PATCH 1/3] drm/dp: Add definition for Display Control DPCD Registers capability size

2016-04-05 Thread Yetunde Adebisi
This is used when reading Display Control capability Registers on the sink
device.

cc: dri-de...@lists.freedesktop.org
Signed-off-by: Yetunde Adebisi 
Reviewed-by: Jani Nikula 
---
 include/drm/drm_dp_helper.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
index 1252108..92d9a52 100644
--- a/include/drm/drm_dp_helper.h
+++ b/include/drm/drm_dp_helper.h
@@ -621,6 +621,7 @@ u8 drm_dp_get_adjust_request_pre_emphasis(const u8 
link_status[DP_LINK_STATUS_SI
 #define DP_BRANCH_OUI_HEADER_SIZE  0xc
 #define DP_RECEIVER_CAP_SIZE   0xf
 #define EDP_PSR_RECEIVER_CAP_SIZE  2
+#define EDP_DISPLAY_CTL_CAP_SIZE   3
 
 void drm_dp_link_train_clock_recovery_delay(const u8 
dpcd[DP_RECEIVER_CAP_SIZE]);
 void drm_dp_link_train_channel_eq_delay(const u8 dpcd[DP_RECEIVER_CAP_SIZE]);
-- 
1.9.3

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


Re: [Intel-gfx] [PATCH 045/190] drm/i915: Move releasing of the GEM request from free to retire/cancel

2016-04-05 Thread Tvrtko Ursulin


On 05/04/16 15:09, Chris Wilson wrote:

On Tue, Apr 05, 2016 at 02:42:16PM +0100, Tvrtko Ursulin wrote:

@@ -587,9 +587,6 @@ static int execlists_context_queue(struct
drm_i915_gem_request *request)
  struct drm_i915_gem_request *cursor;
  int num_elements = 0;

-if (request->ctx != ring->default_context)
-intel_lr_context_pin(request);
-


Since you remove LRC pin from queue, the lifetime is now either:

1. From request create to cancel.
2. From request create to execlist retirement.

Would it be more logical to leave the LRC pin in queue, but remove it

>from request creation instead? That would make the LRC pin lifetime only

a single possibility, from queue to execlist retire.


Well what we actually need in request allocation is pinning the
ringbuffer. At the moment we do that by pinning the request. We also
need to pin the VM in order to manipulate it. We could leave pinning the
logical context object til actual submission.


Hmmm, yes. Have to think how complicated or not would that be.


I felt was so close in getting rid of execlist_retired_req_queue,
using this patch as a starting point, when I realised this patch
does not play nicely with the GuC. Back to the drawing board. :(


If you mean what happens if the GuC executes requests out-of-order - it
can't in the current model since we only have a single timeline and that
would break it badly - then nothing changes. We are only moving the
release in time, not decoupling it from any serialisation.


No, there is no LRC unpin, it is unbalanced in the GuC mode with this 
patch. Unless I am missing something... ?


Regards,

Tvrtko

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


[Intel-gfx] [PATCH 3/3] drm/i915: Add Backlight Control using DPCD for eDP connectors (v9)

2016-04-05 Thread Yetunde Adebisi
This patch adds support for eDP backlight control using DPCD registers to
backlight hooks in intel_panel.

It checks for backlight control over AUX channel capability and sets up
function pointers to get and set the backlight brightness level if
supported.

v2: Moved backlight functions from intel_dp.c into a new file
intel_dp_aux_backlight.c. Also moved reading of eDP display control
registers to intel_dp_get_dpcd

v3: Correct some formatting mistakes

v4: Updated to use AUX backlight control if PWM control is not possible
(Jani)
v5: Moved call to initialize backlight registers to dp_aux_setup_backlight
v6: Check DP_EDP_BACKLIGHT_PIN_ENABLE_CAP is disabled before setting up AUX
backlight control. To fix BLM_PWM_ENABLE igt test warnings on bdw_ultra
v7: Add enable_dpcd_backlight module parameter.
v8: Rebase onto latest drm-intel-nightly branch
v9: Remove changes to intel_dp_dpcd_read_wake
Split addition edp_dpcd variable into a separate patch

Cc: Bob Paauwe 
Cc: Jani Nikula 
Signed-off-by: Yetunde Adebisi 
---
 drivers/gpu/drm/i915/Makefile |   1 +
 drivers/gpu/drm/i915/i915_params.c|   4 +
 drivers/gpu/drm/i915/i915_params.h|   1 +
 drivers/gpu/drm/i915/intel_dp_aux_backlight.c | 173 ++
 drivers/gpu/drm/i915/intel_drv.h  |   3 +
 drivers/gpu/drm/i915/intel_panel.c|   4 +
 6 files changed, 186 insertions(+)
 create mode 100644 drivers/gpu/drm/i915/intel_dp_aux_backlight.c

diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 7ffb51b..11cc3e6 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -79,6 +79,7 @@ i915-y += dvo_ch7017.o \
  dvo_tfp410.o \
  intel_crt.o \
  intel_ddi.o \
+ intel_dp_aux_backlight.o \
  intel_dp_link_training.o \
  intel_dp_mst.o \
  intel_dp.o \
diff --git a/drivers/gpu/drm/i915/i915_params.c 
b/drivers/gpu/drm/i915/i915_params.c
index 1779f02..383c076 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_dpcd_backlight = false,
 };
 
 module_param_named(modeset, i915.modeset, int, 0400);
@@ -210,3 +211,6 @@ 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(enable_dpcd_backlight, i915.enable_dpcd_backlight, bool, 
0600);
+MODULE_PARM_DESC(enable_dpcd_backlight,
+   "Enable support for DPCD backlight control (default:false)");
diff --git a/drivers/gpu/drm/i915/i915_params.h 
b/drivers/gpu/drm/i915/i915_params.h
index 02bc278..65e73dd 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_dpcd_backlight;
 };
 
 extern struct i915_params i915 __read_mostly;
diff --git a/drivers/gpu/drm/i915/intel_dp_aux_backlight.c 
b/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
new file mode 100644
index 000..984fb0d
--- /dev/null
+++ b/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
@@ -0,0 +1,173 @@
+/*
+ * Copyright © 2015 Intel Corporation
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
+ * IN THE SOFTWARE.
+ *
+ */
+
+#include "intel_drv.h"
+
+static void set_aux_backlight_enable(struct intel_dp *intel_dp, bool enable)
+{
+   uint8_t reg_val = 0;
+
+   if (drm_dp_dpcd_readb(_dp->aux, 

[Intel-gfx] [PATCH 0/3] DPCD Backlight Control

2016-04-05 Thread Yetunde Adebisi
These patches add support for Backlight Control using DPCD registers on eDP 
displays.

- Patch 1 Adds macro for DPCD registers capability size to drm_dp_helper.h
- Patch 2 Reads the eDP DPCD Display Control capability registers.
- Patch 2 Implements functionaly for DPCD Backlight Control 

Yetunde Adebisi (3):
  drm/dp: Add definition for Display Control DPCD Registers capability
size
  drm/i915: Read eDP Display control capability registers
  drm/i915: Add Backlight Control using DPCD for eDP connectors (v9)

 drivers/gpu/drm/i915/Makefile |   1 +
 drivers/gpu/drm/i915/i915_params.c|   4 +
 drivers/gpu/drm/i915/i915_params.h|   1 +
 drivers/gpu/drm/i915/intel_dp.c   |  15 ++-
 drivers/gpu/drm/i915/intel_dp_aux_backlight.c | 173 ++
 drivers/gpu/drm/i915/intel_drv.h  |   4 +
 drivers/gpu/drm/i915/intel_panel.c|   4 +
 include/drm/drm_dp_helper.h   |   1 +
 8 files changed, 198 insertions(+), 5 deletions(-)
 create mode 100644 drivers/gpu/drm/i915/intel_dp_aux_backlight.c

-- 
1.9.3

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


Re: [Intel-gfx] [PATCH 045/190] drm/i915: Move releasing of the GEM request from free to retire/cancel

2016-04-05 Thread Chris Wilson
On Tue, Apr 05, 2016 at 02:42:16PM +0100, Tvrtko Ursulin wrote:
> I felt was so close in getting rid of execlist_retired_req_queue,
> using this patch as a starting point, when I realised this patch
> does not play nicely with the GuC. Back to the drawing board. :(

I will also say that we need to rid requests of struct_mutex far more
than we need the GuC.
-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 1/3] drm/i915/userptr: Flush cancellations before mmu-notifier invalidate returns

2016-04-05 Thread Chris Wilson
In order to ensure that all invalidations are completed before the
operation returns to userspace (i.e. before the munmap() syscall returns)
we need to wait upon the outstanding operations.

We are allowed to block inside the invalidate_range_start callback, and
as struct_mutex is the inner lock with mmap_sem we can wait upon the
struct_mutex without provoking lockdep into warning about a deadlock.
However, we don't actually want to wait upon outstanding rendering
whilst holding the struct_mutex if we can help it otherwise we also
block other processes from submitting work to the GPU. So first we do a
wait without the lock and then when we reacquire the lock, we double
check that everything is ready for removing the invalidated pages.

Finally to wait upon the outstanding unpinning tasks, we create a
private workqueue as a means to conveniently wait upon all at once. The
drawback is that this workqueue is per-mm, so any threads concurrently
invalidating objects will wait upon each other. The advantage of using
the workqueue is that we can wait in parallel for completion of
rendering and unpinning of several objects (of particular importance if
the process terminates with a whole mm full of objects).

v2: Apply a cup of tea to the changelog.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=94699
Testcase: igt/gem_userptr_blits/sync-unmap-cycles
Signed-off-by: Chris Wilson 
Cc: Tvrtko Ursulin 
Cc: Michał Winiarski 
---
 drivers/gpu/drm/i915/i915_gem_userptr.c | 48 -
 1 file changed, 47 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_gem_userptr.c 
b/drivers/gpu/drm/i915/i915_gem_userptr.c
index 291a9393493d..92b39186b05a 100644
--- a/drivers/gpu/drm/i915/i915_gem_userptr.c
+++ b/drivers/gpu/drm/i915/i915_gem_userptr.c
@@ -49,6 +49,7 @@ struct i915_mmu_notifier {
struct hlist_node node;
struct mmu_notifier mn;
struct rb_root objects;
+   struct workqueue_struct *wq;
 };
 
 struct i915_mmu_object {
@@ -60,6 +61,40 @@ struct i915_mmu_object {
bool attached;
 };
 
+static void wait_rendering(struct drm_i915_gem_object *obj)
+{
+   struct drm_device *dev = obj->base.dev;
+   struct drm_i915_gem_request *requests[I915_NUM_ENGINES];
+   unsigned reset_counter;
+   int i, n;
+
+   if (!obj->active)
+   return;
+
+   n = 0;
+   for (i = 0; i < I915_NUM_ENGINES; i++) {
+   struct drm_i915_gem_request *req;
+
+   req = obj->last_read_req[i];
+   if (req == NULL)
+   continue;
+
+   requests[n++] = i915_gem_request_reference(req);
+   }
+
+   reset_counter = atomic_read(_i915(dev)->gpu_error.reset_counter);
+   mutex_unlock(>struct_mutex);
+
+   for (i = 0; i < n; i++)
+   __i915_wait_request(requests[i], reset_counter, false,
+   NULL, NULL);
+
+   mutex_lock(>struct_mutex);
+
+   for (i = 0; i < n; i++)
+   i915_gem_request_unreference(requests[i]);
+}
+
 static void cancel_userptr(struct work_struct *work)
 {
struct i915_mmu_object *mo = container_of(work, typeof(*mo), work);
@@ -75,6 +110,8 @@ static void cancel_userptr(struct work_struct *work)
struct i915_vma *vma, *tmp;
bool was_interruptible;
 
+   wait_rendering(obj);
+
was_interruptible = dev_priv->mm.interruptible;
dev_priv->mm.interruptible = false;
 
@@ -140,7 +177,7 @@ static void 
i915_gem_userptr_mn_invalidate_range_start(struct mmu_notifier *_mn,
 */
mo = container_of(it, struct i915_mmu_object, it);
if (kref_get_unless_zero(>obj->base.refcount))
-   schedule_work(>work);
+   queue_work(mn->wq, >work);
 
list_add(>link, );
it = interval_tree_iter_next(it, start, end);
@@ -148,6 +185,8 @@ static void 
i915_gem_userptr_mn_invalidate_range_start(struct mmu_notifier *_mn,
list_for_each_entry(mo, , link)
del_object(mo);
spin_unlock(>lock);
+
+   flush_workqueue(mn->wq);
 }
 
 static const struct mmu_notifier_ops i915_gem_userptr_notifier = {
@@ -167,10 +206,16 @@ i915_mmu_notifier_create(struct mm_struct *mm)
spin_lock_init(>lock);
mn->mn.ops = _gem_userptr_notifier;
mn->objects = RB_ROOT;
+   mn->wq = alloc_workqueue("i915-userptr-release", WQ_UNBOUND, 0);
+   if (mn->wq == NULL) {
+   kfree(mn);
+   return ERR_PTR(-ENOMEM);
+   }
 
 /* Protected by mmap_sem (write-lock) */
ret = __mmu_notifier_register(>mn, mm);
if (ret) {
+   destroy_workqueue(mn->wq);
kfree(mn);
return ERR_PTR(ret);
}
@@ -256,6 +301,7 @@ 

Re: [Intel-gfx] [PATCH 1/6] drm/i915/bxt: VBT changes for hpd as wakeup feature

2016-04-05 Thread Jani Nikula
On Tue, 05 Apr 2016, Animesh Manna  wrote:
> To support hpd during sleep a new feature flag is
> added in vbt and also in dev_priv for enabling/disabling
> inside deiver. By default this feature will be
> diabled and based on oem request this feature can
> be enabled by changing vbt feature flag.
>
> Signed-off-by: Animesh Manna 
> Signed-off-by: A.Sunil Kamath 
> ---
>  drivers/gpu/drm/i915/i915_drv.h   | 8 
>  drivers/gpu/drm/i915/i915_reg.h   | 1 +
>  drivers/gpu/drm/i915/intel_vbt_defs.h | 3 ++-
>  3 files changed, 11 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index dd18772..445b80b 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -1429,6 +1429,11 @@ enum psr_lines_to_wait {
>   PSR_8_LINES_TO_WAIT
>  };
>  
> +enum hpd_wakeup_state {
> + DISABLE_HOT_PLUG_AS_WAKE_EVENT = 0,
> + ENABLE_HOT_PLUG_AS_WAKE_EVENT
> +};

Any reason to use an enum when a bool will do? In fact, you use it as a
bool in the following patches.

> +
>  struct intel_vbt_data {
>   struct drm_display_mode *lfp_lvds_vbt_mode; /* if any */
>   struct drm_display_mode *sdvo_lvds_vbt_mode; /* if any */
> @@ -1485,6 +1490,9 @@ struct intel_vbt_data {
>   const u8 *sequence[MIPI_SEQ_MAX];
>   } dsi;
>  
> + /* HPD as wakesoure for DC9 BXT */
> + enum hpd_wakeup_state hpd_wakeup_enabled;
> +

Why don't you initialize the field in this patch? Patch 6/6 should be
part of this patch.

>   int crt_ddc_pin;
>  
>   int child_dev_num;
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 12f5103..cc42bd9 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -6119,6 +6119,7 @@ enum skl_disp_power_wells {
>SDE_PORTB_HOTPLUG |\
>SDE_PORTC_HOTPLUG |\
>SDE_PORTD_HOTPLUG)
> +

Superfluous whitespace change.

>  #define SDE_TRANSB_CRC_DONE  (1 << 5)
>  #define SDE_TRANSB_CRC_ERR   (1 << 4)
>  #define SDE_TRANSB_FIFO_UNDER(1 << 3)
> diff --git a/drivers/gpu/drm/i915/intel_vbt_defs.h 
> b/drivers/gpu/drm/i915/intel_vbt_defs.h
> index 749dcea..8e2b765 100644
> --- a/drivers/gpu/drm/i915/intel_vbt_defs.h
> +++ b/drivers/gpu/drm/i915/intel_vbt_defs.h
> @@ -547,7 +547,8 @@ struct bdb_driver_features {
>   u16 tbt_enabled:1;
>   u16 psr_enabled:1;
>   u16 ips_enabled:1;
> - u16 reserved3:4;
> + u16 reserved3:3;
> + u16 hpd_wakeup_source:1;
>   u16 pc_feature_valid:1;
>  } __packed;

-- 
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 v2 3/3] drm/i915/userptr: Store i915 backpointer for i915_mm_struct

2016-04-05 Thread Chris Wilson
Since we only ever use the drm_i915_private from the stored
i915_mm_struct->dev, save some electrons by storing the right
backpointer.

Signed-off-by: Chris Wilson 
Cc: Tvrtko Ursulin 
Cc: Michał Winiarski 
Reviewed-by: Michał Winiarski 
---
 drivers/gpu/drm/i915/i915_gem_userptr.c | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem_userptr.c 
b/drivers/gpu/drm/i915/i915_gem_userptr.c
index 960bb37f458f..cb41919063d2 100644
--- a/drivers/gpu/drm/i915/i915_gem_userptr.c
+++ b/drivers/gpu/drm/i915/i915_gem_userptr.c
@@ -34,7 +34,7 @@
 
 struct i915_mm_struct {
struct mm_struct *mm;
-   struct drm_device *dev;
+   struct drm_i915_private *i915;
struct i915_mmu_notifier *mn;
struct hlist_node node;
struct kref kref;
@@ -250,13 +250,13 @@ i915_mmu_notifier_find(struct i915_mm_struct *mm)
return mn;
 
down_write(>mm->mmap_sem);
-   mutex_lock(_i915(mm->dev)->mm_lock);
+   mutex_lock(>i915->mm_lock);
if ((mn = mm->mn) == NULL) {
mn = i915_mmu_notifier_create(mm->mm);
if (!IS_ERR(mn))
mm->mn = mn;
}
-   mutex_unlock(_i915(mm->dev)->mm_lock);
+   mutex_unlock(>i915->mm_lock);
up_write(>mm->mmap_sem);
 
return mn;
@@ -373,7 +373,7 @@ i915_gem_userptr_init__mm_struct(struct drm_i915_gem_object 
*obj)
}
 
kref_init(>kref);
-   mm->dev = obj->base.dev;
+   mm->i915 = to_i915(obj->base.dev);
 
mm->mm = current->mm;
atomic_inc(>mm->mm_count);
@@ -408,7 +408,7 @@ __i915_mm_struct_free(struct kref *kref)
 
/* Protected by dev_priv->mm_lock */
hash_del(>node);
-   mutex_unlock(_i915(mm->dev)->mm_lock);
+   mutex_unlock(>i915->mm_lock);
 
INIT_WORK(>work, __i915_mm_struct_free__worker);
schedule_work(>work);
-- 
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 2/3] drm/i915/userptr: Hold mmref whilst calling get-user-pages

2016-04-05 Thread Chris Wilson
Holding a reference to the containing task_struct is not sufficient to
prevent the mm_struct from being reaped under memory pressure. If this
happens whilst we are calling get_user_pages(), explosions erupt -
sometimes an immediate GPF, sometimes page flag corruption. To prevent
the target mm from being reaped as we are reading from it, acquire a
reference before we begin.

Testcase: igt/gem_shrink/*userptr
Signed-off-by: Chris Wilson 
Cc: Tvrtko Ursulin 
Cc: Michał Winiarski 
Cc: sta...@vger.kernel.org
Reviewed-by: Michał Winiarski 
---
 drivers/gpu/drm/i915/i915_gem_userptr.c | 29 +
 1 file changed, 17 insertions(+), 12 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem_userptr.c 
b/drivers/gpu/drm/i915/i915_gem_userptr.c
index 92b39186b05a..960bb37f458f 100644
--- a/drivers/gpu/drm/i915/i915_gem_userptr.c
+++ b/drivers/gpu/drm/i915/i915_gem_userptr.c
@@ -547,19 +547,24 @@ __i915_gem_userptr_get_pages_worker(struct work_struct 
*_work)
if (pvec != NULL) {
struct mm_struct *mm = obj->userptr.mm->mm;
 
-   down_read(>mmap_sem);
-   while (pinned < npages) {
-   ret = get_user_pages_remote(work->task, mm,
-   obj->userptr.ptr + pinned * PAGE_SIZE,
-   npages - pinned,
-   !obj->userptr.read_only, 0,
-   pvec + pinned, NULL);
-   if (ret < 0)
-   break;
-
-   pinned += ret;
+   ret = -EFAULT;
+   if (atomic_inc_not_zero(>mm_users)) {
+   down_read(>mmap_sem);
+   while (pinned < npages) {
+   ret = get_user_pages_remote
+   (work->task, mm,
+obj->userptr.ptr + pinned * PAGE_SIZE,
+npages - pinned,
+!obj->userptr.read_only, 0,
+pvec + pinned, NULL);
+   if (ret < 0)
+   break;
+
+   pinned += ret;
+   }
+   up_read(>mmap_sem);
+   mmput(mm);
}
-   up_read(>mmap_sem);
}
 
mutex_lock(>struct_mutex);
-- 
2.8.0.rc3

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


Re: [Intel-gfx] [PATCH i-g-t] tools/intel_reg: Fix builtin register spec for gen4

2016-04-05 Thread Jani Nikula
On Tue, 05 Apr 2016, ville.syrj...@linux.intel.com wrote:
> [ text/plain ]
> From: Ville Syrjälä 
>
> Actually use the builtin register spec on gen4. Makes intel_reg dump
> actually do something on gen4.
>
> Signed-off-by: Ville Syrjälä 
> ---
>  tools/intel_reg_decode.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/tools/intel_reg_decode.c b/tools/intel_reg_decode.c
> index bb8f5b30311f..470fecc165c6 100644
> --- a/tools/intel_reg_decode.c
> +++ b/tools/intel_reg_decode.c
> @@ -2580,7 +2580,7 @@ static bool is_945gm(uint32_t devid, uint32_t pch)
>  
>  static bool is_gen234(uint32_t devid, uint32_t pch)
>  {
> - return IS_GEN2(devid) || IS_GEN3(devid) || IS_GEN3(devid);
> + return IS_GEN2(devid) || IS_GEN3(devid) || IS_GEN4(devid);

Facepalm-by: Jani Nikula 


>  }
>  
>  #define DECLARE_REGS(d,r,m)  \

-- 
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 1/3] drm/dp: Add definition for Display Control DPCD Registers capability size

2016-04-05 Thread Yetunde Adebisi
This is used when reading Display Control capability Registers on the sink
device.

cc: Jani Nikula 
cc: dri-de...@lists.freedesktop.org
Signed-off-by: Yetunde Adebisi 
---
 include/drm/drm_dp_helper.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
index 1252108..92d9a52 100644
--- a/include/drm/drm_dp_helper.h
+++ b/include/drm/drm_dp_helper.h
@@ -621,6 +621,7 @@ u8 drm_dp_get_adjust_request_pre_emphasis(const u8 
link_status[DP_LINK_STATUS_SI
 #define DP_BRANCH_OUI_HEADER_SIZE  0xc
 #define DP_RECEIVER_CAP_SIZE   0xf
 #define EDP_PSR_RECEIVER_CAP_SIZE  2
+#define EDP_DISPLAY_CTL_CAP_SIZE   3
 
 void drm_dp_link_train_clock_recovery_delay(const u8 
dpcd[DP_RECEIVER_CAP_SIZE]);
 void drm_dp_link_train_channel_eq_delay(const u8 dpcd[DP_RECEIVER_CAP_SIZE]);
-- 
1.9.3

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


[Intel-gfx] [PATCH 0/3] DPCD Backlight Control

2016-04-05 Thread Yetunde Adebisi
These patches add support for Backlight Control using DPCD registers on eDP 
displays.

- Patch 1 Adds macro for DPCD registers capability size to drm_dp_helper.h
- Patch 2 Reads the eDP DPCD Display Control capability registers.
- Patch 2 Implements functionaly for DPCD Backlight Control 

Yetunde Adebisi (3):
  drm/dp: Add definition for Display Control DPCD Registers capability
size
  drm/i915: Read eDP Display control capability registers
  drm/i915: Add Backlight Control using DPCD for eDP connectors (v9)

 drivers/gpu/drm/i915/Makefile |   1 +
 drivers/gpu/drm/i915/i915_params.c|   4 +
 drivers/gpu/drm/i915/i915_params.h|   1 +
 drivers/gpu/drm/i915/intel_dp.c   |  15 ++-
 drivers/gpu/drm/i915/intel_dp_aux_backlight.c | 173 ++
 drivers/gpu/drm/i915/intel_drv.h  |   4 +
 drivers/gpu/drm/i915/intel_panel.c|   4 +
 include/drm/drm_dp_helper.h   |   1 +
 8 files changed, 198 insertions(+), 5 deletions(-)
 create mode 100644 drivers/gpu/drm/i915/intel_dp_aux_backlight.c

-- 
1.9.3

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


[Intel-gfx] [PATCH 3/3] drm/i915: Add Backlight Control using DPCD for eDP connectors (v9)

2016-04-05 Thread Yetunde Adebisi
This patch adds support for eDP backlight control using DPCD registers to
backlight hooks in intel_panel.

It checks for backlight control over AUX channel capability and sets up
function pointers to get and set the backlight brightness level if
supported.

v2: Moved backlight functions from intel_dp.c into a new file
intel_dp_aux_backlight.c. Also moved reading of eDP display control
registers to intel_dp_get_dpcd

v3: Correct some formatting mistakes

v4: Updated to use AUX backlight control if PWM control is not possible
(Jani)
v5: Moved call to initialize backlight registers to dp_aux_setup_backlight
v6: Check DP_EDP_BACKLIGHT_PIN_ENABLE_CAP is disabled before setting up AUX
backlight control. To fix BLM_PWM_ENABLE igt test warnings on bdw_ultra
v7: Add enable_dpcd_backlight module parameter.
v8: Rebase onto latest drm-intel-nightly branch
v9: Remove changes to intel_dp_dpcd_read_wake
Split addition edp_dpcd variable into a separate patch

Cc: Bob Paauwe 
Cc: Jani Nikula 
Signed-off-by: Yetunde Adebisi 
---
 drivers/gpu/drm/i915/Makefile |   1 +
 drivers/gpu/drm/i915/i915_params.c|   4 +
 drivers/gpu/drm/i915/i915_params.h|   1 +
 drivers/gpu/drm/i915/intel_dp_aux_backlight.c | 173 ++
 drivers/gpu/drm/i915/intel_drv.h  |   3 +
 drivers/gpu/drm/i915/intel_panel.c|   4 +
 6 files changed, 186 insertions(+)
 create mode 100644 drivers/gpu/drm/i915/intel_dp_aux_backlight.c

diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 7ffb51b..11cc3e6 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -79,6 +79,7 @@ i915-y += dvo_ch7017.o \
  dvo_tfp410.o \
  intel_crt.o \
  intel_ddi.o \
+ intel_dp_aux_backlight.o \
  intel_dp_link_training.o \
  intel_dp_mst.o \
  intel_dp.o \
diff --git a/drivers/gpu/drm/i915/i915_params.c 
b/drivers/gpu/drm/i915/i915_params.c
index 1779f02..383c076 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_dpcd_backlight = false,
 };
 
 module_param_named(modeset, i915.modeset, int, 0400);
@@ -210,3 +211,6 @@ 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(enable_dpcd_backlight, i915.enable_dpcd_backlight, bool, 
0600);
+MODULE_PARM_DESC(enable_dpcd_backlight,
+   "Enable support for DPCD backlight control (default:false)");
diff --git a/drivers/gpu/drm/i915/i915_params.h 
b/drivers/gpu/drm/i915/i915_params.h
index 02bc278..65e73dd 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_dpcd_backlight;
 };
 
 extern struct i915_params i915 __read_mostly;
diff --git a/drivers/gpu/drm/i915/intel_dp_aux_backlight.c 
b/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
new file mode 100644
index 000..984fb0d
--- /dev/null
+++ b/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
@@ -0,0 +1,173 @@
+/*
+ * Copyright © 2015 Intel Corporation
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
+ * IN THE SOFTWARE.
+ *
+ */
+
+#include "intel_drv.h"
+
+static void set_aux_backlight_enable(struct intel_dp *intel_dp, bool enable)
+{
+   uint8_t reg_val = 0;
+
+   if (drm_dp_dpcd_readb(_dp->aux, 

[Intel-gfx] [PATCH 2/3] drm/i915: Read eDP Display control capability registers

2016-04-05 Thread Yetunde Adebisi
Add new edp_dpcd variable to intel_dp.
Read and save eDP Display control capability registers to edp_dpcd.

Signed-off-by: Yetunde Adebisi 
---
 drivers/gpu/drm/i915/intel_dp.c  | 15 ++-
 drivers/gpu/drm/i915/intel_drv.h |  1 +
 2 files changed, 11 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index da0c3d2..ad2c7d6 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -3777,7 +3777,6 @@ intel_dp_get_dpcd(struct intel_dp *intel_dp)
struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp);
struct drm_device *dev = dig_port->base.base.dev;
struct drm_i915_private *dev_priv = dev->dev_private;
-   uint8_t rev;
 
if (intel_dp_dpcd_read_wake(_dp->aux, 0x000, intel_dp->dpcd,
sizeof(intel_dp->dpcd)) < 0)
@@ -3834,6 +3833,15 @@ intel_dp_get_dpcd(struct intel_dp *intel_dp)
DRM_DEBUG_KMS("PSR2 %s on sink",
dev_priv->psr.psr2_support ? "supported" : "not 
supported");
}
+
+   /* Read the eDP Display control capabilities registers */
+   memset(intel_dp->edp_dpcd, 0, sizeof(intel_dp->edp_dpcd));
+   if ((intel_dp->dpcd[DP_EDP_CONFIGURATION_CAP] & 
DP_DPCD_DISPLAY_CONTROL_CAPABLE) &&
+   (intel_dp_dpcd_read_wake(_dp->aux, 
DP_EDP_DPCD_REV,
+   intel_dp->edp_dpcd, 
sizeof(intel_dp->edp_dpcd)) ==
+   
sizeof(intel_dp->edp_dpcd)))
+   DRM_DEBUG_KMS("EDP DPCD : %*ph\n", (int) 
sizeof(intel_dp->edp_dpcd),
+   intel_dp->edp_dpcd);
}
 
DRM_DEBUG_KMS("Display Port TPS3 support: source %s, sink %s\n",
@@ -3841,10 +3849,7 @@ intel_dp_get_dpcd(struct intel_dp *intel_dp)
  yesno(drm_dp_tps3_supported(intel_dp->dpcd)));
 
/* Intermediate frequency support */
-   if (is_edp(intel_dp) &&
-   (intel_dp->dpcd[DP_EDP_CONFIGURATION_CAP] & 
DP_DPCD_DISPLAY_CONTROL_CAPABLE) &&
-   (intel_dp_dpcd_read_wake(_dp->aux, DP_EDP_DPCD_REV, , 1) 
== 1) &&
-   (rev >= 0x03)) { /* eDp v1.4 or higher */
+   if (is_edp(intel_dp) && (intel_dp->edp_dpcd[0] >= 0x03)) { /* eDp v1.4 
or higher */
__le16 sink_rates[DP_MAX_SUPPORTED_RATES];
int i;
 
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 9255b56..b14e515 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -805,6 +805,7 @@ struct intel_dp {
uint8_t dpcd[DP_RECEIVER_CAP_SIZE];
uint8_t psr_dpcd[EDP_PSR_RECEIVER_CAP_SIZE];
uint8_t downstream_ports[DP_MAX_DOWNSTREAM_PORTS];
+   uint8_t edp_dpcd[EDP_DISPLAY_CTL_CAP_SIZE];
/* sink rates as reported by DP_SUPPORTED_LINK_RATES */
uint8_t num_sink_rates;
int sink_rates[DP_MAX_SUPPORTED_RATES];
-- 
1.9.3

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


Re: [Intel-gfx] [PATCH 045/190] drm/i915: Move releasing of the GEM request from free to retire/cancel

2016-04-05 Thread Tvrtko Ursulin


On 08/03/16 13:15, Tvrtko Ursulin wrote:


On 11/01/16 09:16, Chris Wilson wrote:

If we move the release of the GEM request (i.e. decoupling it from the
various lists used for client and context tracking) after it is complete
(either by the GPU retiring the request, or by the caller cancelling the
request), we can remove the requirement that the final unreference of
the GEM request need to be under the struct_mutex.

v2: Execlists as always is badly asymetric and year old patches still
haven't landed to fix it up.


Looks good and pretty standalone to me (depends on i915_gem_request code
movement only I think). Just one question below.


Signed-off-by: Chris Wilson 
---
  drivers/gpu/drm/i915/i915_gem.c  |  4 +--
  drivers/gpu/drm/i915/i915_gem_request.c  | 50
++--
  drivers/gpu/drm/i915/i915_gem_request.h  | 14 -
  drivers/gpu/drm/i915/intel_breadcrumbs.c |  2 +-
  drivers/gpu/drm/i915/intel_display.c |  2 +-
  drivers/gpu/drm/i915/intel_lrc.c |  6 ++--
  drivers/gpu/drm/i915/intel_pm.c  |  2 +-
  7 files changed, 30 insertions(+), 50 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem.c
b/drivers/gpu/drm/i915/i915_gem.c
index 68a25617ca7a..6d8d65304abf 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -2502,7 +2502,7 @@ i915_gem_wait_ioctl(struct drm_device *dev, void
*data, struct drm_file *file)
  ret = __i915_wait_request(req[i], true,
args->timeout_ns > 0 ? >timeout_ns :
NULL,
to_rps_client(file));
-i915_gem_request_unreference__unlocked(req[i]);
+i915_gem_request_unreference(req[i]);
  }
  return ret;

@@ -3505,7 +3505,7 @@ i915_gem_ring_throttle(struct drm_device *dev,
struct drm_file *file)
  return 0;

  ret = __i915_wait_request(target, true, NULL, NULL);
-i915_gem_request_unreference__unlocked(target);
+i915_gem_request_unreference(target);

  return ret;
  }
diff --git a/drivers/gpu/drm/i915/i915_gem_request.c
b/drivers/gpu/drm/i915/i915_gem_request.c
index b4ede6dd7b20..1c4f4d83a3c2 100644
--- a/drivers/gpu/drm/i915/i915_gem_request.c
+++ b/drivers/gpu/drm/i915/i915_gem_request.c
@@ -184,13 +184,6 @@ err:
  return ret;
  }

-void i915_gem_request_cancel(struct drm_i915_gem_request *req)
-{
-intel_ring_reserved_space_cancel(req->ringbuf);
-
-i915_gem_request_unreference(req);
-}
-
  int i915_gem_request_add_to_client(struct drm_i915_gem_request *req,
 struct drm_file *file)
  {
@@ -235,9 +228,28 @@ i915_gem_request_remove_from_client(struct
drm_i915_gem_request *request)
  request->pid = NULL;
  }

+static void __i915_gem_request_release(struct drm_i915_gem_request
*request)
+{
+i915_gem_request_remove_from_client(request);
+
+i915_gem_context_unreference(request->ctx);
+i915_gem_request_unreference(request);
+}
+
+void i915_gem_request_cancel(struct drm_i915_gem_request *req)
+{
+intel_ring_reserved_space_cancel(req->ringbuf);
+if (i915.enable_execlists) {
+if (req->ctx != req->ring->default_context)
+intel_lr_context_unpin(req);
+}
+__i915_gem_request_release(req);
+}
+
  static void i915_gem_request_retire(struct drm_i915_gem_request
*request)
  {
  trace_i915_gem_request_retire(request);
+list_del_init(>list);

  /* We know the GPU must have read the request to have
   * sent us the seqno + interrupt, so use the position
@@ -248,11 +260,7 @@ static void i915_gem_request_retire(struct
drm_i915_gem_request *request)
   * completion order.
   */
  request->ringbuf->last_retired_head = request->postfix;
-
-list_del_init(>list);
-i915_gem_request_remove_from_client(request);
-
-i915_gem_request_unreference(request);
+__i915_gem_request_release(request);
  }

  void
@@ -639,21 +647,7 @@ i915_wait_request(struct drm_i915_gem_request *req)

  void i915_gem_request_free(struct kref *req_ref)
  {
-struct drm_i915_gem_request *req = container_of(req_ref,
- typeof(*req), ref);
-struct intel_context *ctx = req->ctx;
-
-if (req->file_priv)
-i915_gem_request_remove_from_client(req);
-
-if (ctx) {
-if (i915.enable_execlists) {
-if (ctx != req->ring->default_context)
-intel_lr_context_unpin(req);
-}
-
-i915_gem_context_unreference(ctx);
-}
-
+struct drm_i915_gem_request *req =
+container_of(req_ref, typeof(*req), ref);
  kmem_cache_free(req->i915->requests, req);
  }
diff --git a/drivers/gpu/drm/i915/i915_gem_request.h
b/drivers/gpu/drm/i915/i915_gem_request.h
index d46f22f30b0a..af1b825fce50 100644
--- a/drivers/gpu/drm/i915/i915_gem_request.h
+++ b/drivers/gpu/drm/i915/i915_gem_request.h
@@ -154,23 +154,9 @@ i915_gem_request_reference(struct
drm_i915_gem_request *req)
  static inline void
  

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Add a way to test the modeset done during gpu reset.

2016-04-05 Thread Patchwork
== Series Details ==

Series: drm/i915: Add a way to test the modeset done during gpu reset.
URL   : https://patchwork.freedesktop.org/series/5314/
State : failure

== Summary ==

Series 5314v1 drm/i915: Add a way to test the modeset done during gpu reset.
http://patchwork.freedesktop.org/api/1.0/series/5314/revisions/1/mbox/

Test drv_getparams_basic:
Subgroup basic-subslice-total:
pass   -> DMESG-WARN (bsw-nuc-2)
Test drv_hangman:
Subgroup error-state-basic:
pass   -> SKIP   (bsw-nuc-2)
Test gem_cs_tlb:
Subgroup basic-default:
pass   -> SKIP   (bsw-nuc-2)
Test gem_ctx_basic:
pass   -> DMESG-WARN (bsw-nuc-2)
Test gem_exec_basic:
Subgroup gtt-bsd:
pass   -> SKIP   (bsw-nuc-2)
Subgroup readonly-default:
pass   -> SKIP   (bsw-nuc-2)
Subgroup readonly-vebox:
pass   -> SKIP   (bsw-nuc-2)
Test gem_exec_nop:
Subgroup basic:
pass   -> SKIP   (bsw-nuc-2)
Test gem_exec_store:
Subgroup basic-default:
pass   -> SKIP   (bsw-nuc-2)
Test gem_exec_suspend:
Subgroup basic-s3:
pass   -> SKIP   (bsw-nuc-2)
Test gem_exec_whisper:
Subgroup basic:
pass   -> INCOMPLETE (bsw-nuc-2)
Test gem_mmap_gtt:
Subgroup basic-read-write-distinct:
pass   -> DMESG-WARN (bsw-nuc-2)
Subgroup basic-write-gtt:
pass   -> DMESG-WARN (bsw-nuc-2)
Test gem_ringfill:
Subgroup basic-default:
pass   -> SKIP   (bsw-nuc-2)
Test gem_storedw_loop:
Subgroup basic-blt:
pass   -> DMESG-FAIL (bsw-nuc-2)
Subgroup basic-render:
pass   -> SKIP   (bsw-nuc-2)
Test kms_addfb_basic:
Subgroup addfb25-framebuffer-vs-set-tiling:
pass   -> DMESG-WARN (bsw-nuc-2)
Subgroup addfb25-x-tiled-mismatch:
pass   -> DMESG-WARN (bsw-nuc-2)
Subgroup addfb25-y-tiled:
pass   -> DMESG-WARN (bsw-nuc-2)
Subgroup bad-pitch-1024:
pass   -> DMESG-WARN (bsw-nuc-2)
Subgroup bad-pitch-63:
pass   -> DMESG-WARN (bsw-nuc-2)
Subgroup basic:
pass   -> DMESG-WARN (bsw-nuc-2)
Subgroup basic-x-tiled:
pass   -> DMESG-WARN (bsw-nuc-2)
Subgroup basic-y-tiled:
pass   -> DMESG-WARN (bsw-nuc-2)
Subgroup bo-too-small-due-to-tiling:
pass   -> DMESG-WARN (bsw-nuc-2)
Subgroup clobberred-modifier:
pass   -> DMESG-WARN (bsw-nuc-2)
Subgroup no-handle:
pass   -> DMESG-WARN (bsw-nuc-2)
Subgroup unused-modifier:
pass   -> DMESG-WARN (bsw-nuc-2)
Test kms_flip:
Subgroup basic-flip-vs-dpms:
pass   -> DMESG-WARN (ilk-hp8440p) UNSTABLE
Subgroup basic-flip-vs-wf_vblank:
fail   -> PASS   (snb-x220t)
pass   -> FAIL   (bsw-nuc-2)
Test kms_force_connector_basic:
Subgroup prune-stale-modes:
pass   -> SKIP   (ilk-hp8440p)
Test kms_frontbuffer_tracking:
Subgroup basic:
pass   -> DMESG-FAIL (bsw-nuc-2)
Test kms_pipe_crc_basic:
Subgroup hang-read-crc-pipe-c:
pass   -> SKIP   (bsw-nuc-2)
Subgroup nonblocking-crc-pipe-c-frame-sequence:
pass   -> DMESG-FAIL (bsw-nuc-2)
Subgroup read-crc-pipe-c-frame-sequence:
pass   -> DMESG-FAIL (bsw-nuc-2)
Test pm_rpm:
Subgroup basic-pci-d3-state:
pass   -> DMESG-WARN (bsw-nuc-2)
Subgroup basic-rte:
dmesg-warn -> PASS   (bsw-nuc-2)
Test prime_self_import:
Subgroup basic-llseek-bad:
pass   -> DMESG-WARN (bsw-nuc-2)
Subgroup basic-llseek-size:
pass   -> DMESG-WARN (bsw-nuc-2)
Subgroup basic-with_fd_dup:
pass   -> DMESG-WARN (bsw-nuc-2)

bdw-ultratotal:196  pass:175  dwarn:0   dfail:0   fail:0   skip:21 
bsw-nuc-2total:153  pass:88   dwarn:20  dfail:4   fail:1   skip:39 
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:130  dwarn:1   dfail:0   fail:0   skip:65 
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  

Re: [Intel-gfx] [PATCH i-g-t] lib: kms: move framebuffer scanout offset/size to plane

2016-04-05 Thread Ville Syrjälä
On Tue, Apr 05, 2016 at 02:12:43PM +0100, Lionel Landwerlin wrote:
> On 05/04/16 12:48, Ville Syrjälä wrote:
> > On Tue, Apr 05, 2016 at 12:11:19PM +0100, Lionel Landwerlin wrote:
> >> This fixes potential crashes when the framebuffer is unset from a
> >> given plane.
> >>
> >> Signed-off-by: Lionel Landwerlin 
> >> Cc: Maarten Lankhorst 
> >> Cc: Marius Vlad 
> >> Cc: Ville Syrjälä 
> >> ---
> >>   lib/igt_fb.h  |  4 
> >>   lib/igt_kms.c | 32 
> >>   lib/igt_kms.h |  8 
> >>   3 files changed, 24 insertions(+), 20 deletions(-)
> >>
> >> diff --git a/lib/igt_fb.h b/lib/igt_fb.h
> >> index e8fe3ac..0a06899 100644
> >> --- a/lib/igt_fb.h
> >> +++ b/lib/igt_fb.h
> >> @@ -55,10 +55,6 @@ struct igt_fb {
> >>unsigned size;
> >>cairo_surface_t *cairo_surface;
> >>unsigned domain;
> >> -  uint32_t src_x;
> >> -  uint32_t src_y;
> >> -  uint32_t src_w;
> >> -  uint32_t src_h;
> >>   };
> >>   
> >>   enum igt_text_align {
> >> diff --git a/lib/igt_kms.c b/lib/igt_kms.c
> >> index 82257a6..b63a59d 100644
> >> --- a/lib/igt_kms.c
> >> +++ b/lib/igt_kms.c
> >> @@ -1586,10 +1586,10 @@ igt_atomic_prepare_plane_commit(igt_plane_t 
> >> *plane, igt_output_t *output,
> >>}
> >>   
> >>if (plane->position_changed || plane->size_changed) {
> >> -  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 */
> >> -  uint32_t src_h = IGT_FIXED(plane->fb->src_h, 0); /* src_h */
> >> +  uint32_t src_x = IGT_FIXED(plane->src_x, 0); /* src_x */
> >> +  uint32_t src_y = IGT_FIXED(plane->src_y, 0); /* src_y */
> >> +  uint32_t src_w = IGT_FIXED(plane->src_w, 0); /* src_w */
> >> +  uint32_t src_h = IGT_FIXED(plane->src_h, 0); /* src_h */
> >>int32_t crtc_x = plane->crtc_x;
> >>int32_t crtc_y = plane->crtc_y;
> >>uint32_t crtc_w = plane->crtc_w;
> >> @@ -1677,10 +1677,10 @@ static int igt_drm_plane_commit(igt_plane_t *plane,
> >>CHECK_RETURN(ret, fail_on_error);
> >>} else if (plane->fb_changed || plane->position_changed ||
> >>plane->size_changed) {
> >> -  src_x = IGT_FIXED(plane->fb->src_x,0); /* src_x */
> >> -  src_y = IGT_FIXED(plane->fb->src_y,0); /* src_y */
> >> -  src_w = IGT_FIXED(plane->fb->src_w,0); /* src_w */
> >> -  src_h = IGT_FIXED(plane->fb->src_h,0); /* src_h */
> >> +  src_x = IGT_FIXED(plane->src_x,0); /* src_x */
> >> +  src_y = IGT_FIXED(plane->src_y,0); /* src_y */
> >> +  src_w = IGT_FIXED(plane->src_w,0); /* src_w */
> >> +  src_h = IGT_FIXED(plane->src_h,0); /* src_h */
> >>crtc_x = plane->crtc_x;
> >>crtc_y = plane->crtc_y;
> >>crtc_w = plane->crtc_w;
> >> @@ -2201,10 +2201,10 @@ void igt_plane_set_fb(igt_plane_t *plane, struct 
> >> igt_fb *fb)
> >>plane->crtc_h = fb->height;
> >>   
> >>/* set default src pos/size as fb size */
> >> -  fb->src_x = 0;
> >> -  fb->src_y = 0;
> >> -  fb->src_w = fb->width;
> >> -  fb->src_h = fb->height;
> >> +  plane->src_x = 0;
> >> +  plane->src_y = 0;
> >> +  plane->src_w = fb->width;
> >> +  plane->src_h = fb->height;
> >>} else {
> >>plane->crtc_w = 0;
> >>plane->crtc_h = 0;
> >> @@ -2271,8 +2271,8 @@ void igt_fb_set_position(struct igt_fb *fb, 
> >> igt_plane_t *plane,
> >>LOG(display, "%s.%d: fb_set_position(%d,%d)\n",
> >>kmstest_pipe_name(pipe->pipe), plane->index, x, y);
> >>   
> >> -  fb->src_x = x;
> >> -  fb->src_y = y;
> >> +  plane->src_x = x;
> >> +  plane->src_y = y;
> >>   
> >>plane->fb_changed = true;
> >>   }
> >> @@ -2297,8 +2297,8 @@ void igt_fb_set_size(struct igt_fb *fb, igt_plane_t 
> >> *plane,
> >>LOG(display, "%s.%d: fb_set_size(%dx%d)\n",
> >>kmstest_pipe_name(pipe->pipe), plane->index, w, h);
> >>   
> >> -  fb->src_w = w;
> >> -  fb->src_h = h;
> >> +  plane->src_w = w;
> >> +  plane->src_h = h;
> >>   
> >>plane->fb_changed = true;
> >>   }
> >> diff --git a/lib/igt_kms.h b/lib/igt_kms.h
> >> index 8ae1192..aabe244 100644
> >> --- a/lib/igt_kms.h
> >> +++ b/lib/igt_kms.h
> >> @@ -243,6 +243,14 @@ typedef struct {
> >>int crtc_x, crtc_y;
> >>/* size within pipe_src_w x pipe_src_h */
> >>int crtc_w, crtc_h;
> >> +
> >> +  /* position with the framebuffer */
> >> +  uint32_t src_x;
> >> +  uint32_t src_y;
> >> +  /* size within the framebuffer*/
> >> +  uint32_t src_w;
> >> +  uint32_t src_h;
> >
> > Perhaps add a small note that these are 16.16
> >
> > Patch looks good to me otherwise.
> 
> I think we convert them to 16.16 at commit time.
> 

Re: [Intel-gfx] [PATCH 1/2] drm/i915: Read eDP Display control capability registers

2016-04-05 Thread kbuild test robot
Hi Yetunde,

[auto build test ERROR on drm-intel/for-linux-next]
[also build test ERROR on v4.6-rc2 next-20160405]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improving the system]

url:
https://github.com/0day-ci/linux/commits/Yetunde-Adebisi/DPCD-Backlight-Control/20160405-204039
base:   git://anongit.freedesktop.org/drm-intel for-linux-next
config: x86_64-randconfig-x010-201614 (attached as .config)
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64 

All errors (new ones prefixed by >>):

   In file included from drivers/gpu/drm/i915/i915_trace.h:10:0,
from drivers/gpu/drm/i915/i915_drv.h:2719,
from drivers/gpu/drm/i915/i915_drv.c:34:
>> drivers/gpu/drm/i915/intel_drv.h:808:19: error: 'EDP_DISPLAY_CTL_CAP_SIZE' 
>> undeclared here (not in a function)
 uint8_t edp_dpcd[EDP_DISPLAY_CTL_CAP_SIZE];
  ^

vim +/EDP_DISPLAY_CTL_CAP_SIZE +808 drivers/gpu/drm/i915/intel_drv.h

   802  enum hdmi_force_audio force_audio;
   803  bool limited_color_range;
   804  bool color_range_auto;
   805  uint8_t dpcd[DP_RECEIVER_CAP_SIZE];
   806  uint8_t psr_dpcd[EDP_PSR_RECEIVER_CAP_SIZE];
   807  uint8_t downstream_ports[DP_MAX_DOWNSTREAM_PORTS];
 > 808  uint8_t edp_dpcd[EDP_DISPLAY_CTL_CAP_SIZE];
   809  /* sink rates as reported by DP_SUPPORTED_LINK_RATES */
   810  uint8_t num_sink_rates;
   811  int sink_rates[DP_MAX_SUPPORTED_RATES];

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: Binary data
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] [PATCH i-g-t] lib: kms: move framebuffer scanout offset/size to plane

2016-04-05 Thread Lionel Landwerlin
This fixes potential crashes when the framebuffer is unset from a
given plane.

v2: s/with/within/ typo in header

Signed-off-by: Lionel Landwerlin 
Cc: Maarten Lankhorst 
Cc: Marius Vlad 
Cc: Ville Syrjälä 
---
 lib/igt_fb.h  |  4 
 lib/igt_kms.c | 32 
 lib/igt_kms.h |  8 
 3 files changed, 24 insertions(+), 20 deletions(-)

diff --git a/lib/igt_fb.h b/lib/igt_fb.h
index e8fe3ac..0a06899 100644
--- a/lib/igt_fb.h
+++ b/lib/igt_fb.h
@@ -55,10 +55,6 @@ struct igt_fb {
unsigned size;
cairo_surface_t *cairo_surface;
unsigned domain;
-   uint32_t src_x;
-   uint32_t src_y;
-   uint32_t src_w;
-   uint32_t src_h;
 };
 
 enum igt_text_align {
diff --git a/lib/igt_kms.c b/lib/igt_kms.c
index 82257a6..b63a59d 100644
--- a/lib/igt_kms.c
+++ b/lib/igt_kms.c
@@ -1586,10 +1586,10 @@ igt_atomic_prepare_plane_commit(igt_plane_t *plane, 
igt_output_t *output,
}
 
if (plane->position_changed || plane->size_changed) {
-   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 */
-   uint32_t src_h = IGT_FIXED(plane->fb->src_h, 0); /* src_h */
+   uint32_t src_x = IGT_FIXED(plane->src_x, 0); /* src_x */
+   uint32_t src_y = IGT_FIXED(plane->src_y, 0); /* src_y */
+   uint32_t src_w = IGT_FIXED(plane->src_w, 0); /* src_w */
+   uint32_t src_h = IGT_FIXED(plane->src_h, 0); /* src_h */
int32_t crtc_x = plane->crtc_x;
int32_t crtc_y = plane->crtc_y;
uint32_t crtc_w = plane->crtc_w;
@@ -1677,10 +1677,10 @@ static int igt_drm_plane_commit(igt_plane_t *plane,
CHECK_RETURN(ret, fail_on_error);
} else if (plane->fb_changed || plane->position_changed ||
plane->size_changed) {
-   src_x = IGT_FIXED(plane->fb->src_x,0); /* src_x */
-   src_y = IGT_FIXED(plane->fb->src_y,0); /* src_y */
-   src_w = IGT_FIXED(plane->fb->src_w,0); /* src_w */
-   src_h = IGT_FIXED(plane->fb->src_h,0); /* src_h */
+   src_x = IGT_FIXED(plane->src_x,0); /* src_x */
+   src_y = IGT_FIXED(plane->src_y,0); /* src_y */
+   src_w = IGT_FIXED(plane->src_w,0); /* src_w */
+   src_h = IGT_FIXED(plane->src_h,0); /* src_h */
crtc_x = plane->crtc_x;
crtc_y = plane->crtc_y;
crtc_w = plane->crtc_w;
@@ -2201,10 +2201,10 @@ void igt_plane_set_fb(igt_plane_t *plane, struct igt_fb 
*fb)
plane->crtc_h = fb->height;
 
/* set default src pos/size as fb size */
-   fb->src_x = 0;
-   fb->src_y = 0;
-   fb->src_w = fb->width;
-   fb->src_h = fb->height;
+   plane->src_x = 0;
+   plane->src_y = 0;
+   plane->src_w = fb->width;
+   plane->src_h = fb->height;
} else {
plane->crtc_w = 0;
plane->crtc_h = 0;
@@ -2271,8 +2271,8 @@ void igt_fb_set_position(struct igt_fb *fb, igt_plane_t 
*plane,
LOG(display, "%s.%d: fb_set_position(%d,%d)\n",
kmstest_pipe_name(pipe->pipe), plane->index, x, y);
 
-   fb->src_x = x;
-   fb->src_y = y;
+   plane->src_x = x;
+   plane->src_y = y;
 
plane->fb_changed = true;
 }
@@ -2297,8 +2297,8 @@ void igt_fb_set_size(struct igt_fb *fb, igt_plane_t 
*plane,
LOG(display, "%s.%d: fb_set_size(%dx%d)\n",
kmstest_pipe_name(pipe->pipe), plane->index, w, h);
 
-   fb->src_w = w;
-   fb->src_h = h;
+   plane->src_w = w;
+   plane->src_h = h;
 
plane->fb_changed = true;
 }
diff --git a/lib/igt_kms.h b/lib/igt_kms.h
index 8ae1192..b763120 100644
--- a/lib/igt_kms.h
+++ b/lib/igt_kms.h
@@ -243,6 +243,14 @@ typedef struct {
int crtc_x, crtc_y;
/* size within pipe_src_w x pipe_src_h */
int crtc_w, crtc_h;
+
+   /* position within the framebuffer */
+   uint32_t src_x;
+   uint32_t src_y;
+   /* size within the framebuffer*/
+   uint32_t src_w;
+   uint32_t src_h;
+
/* panning offset within the fb */
unsigned int pan_x, pan_y;
igt_rotation_t rotation;
-- 
2.8.0.rc3

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


Re: [Intel-gfx] [PATCH 6/6] drm/i915: Avoid allocating a vmap arena for a single page

2016-04-05 Thread Matthew Auld
I use :autocmd FileType gitcommit setlocal spell
___
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: kms: move framebuffer scanout offset/size to plane

2016-04-05 Thread Lionel Landwerlin

On 05/04/16 12:48, Ville Syrjälä wrote:

On Tue, Apr 05, 2016 at 12:11:19PM +0100, Lionel Landwerlin wrote:

This fixes potential crashes when the framebuffer is unset from a
given plane.

Signed-off-by: Lionel Landwerlin 
Cc: Maarten Lankhorst 
Cc: Marius Vlad 
Cc: Ville Syrjälä 
---
  lib/igt_fb.h  |  4 
  lib/igt_kms.c | 32 
  lib/igt_kms.h |  8 
  3 files changed, 24 insertions(+), 20 deletions(-)

diff --git a/lib/igt_fb.h b/lib/igt_fb.h
index e8fe3ac..0a06899 100644
--- a/lib/igt_fb.h
+++ b/lib/igt_fb.h
@@ -55,10 +55,6 @@ struct igt_fb {
unsigned size;
cairo_surface_t *cairo_surface;
unsigned domain;
-   uint32_t src_x;
-   uint32_t src_y;
-   uint32_t src_w;
-   uint32_t src_h;
  };
  
  enum igt_text_align {

diff --git a/lib/igt_kms.c b/lib/igt_kms.c
index 82257a6..b63a59d 100644
--- a/lib/igt_kms.c
+++ b/lib/igt_kms.c
@@ -1586,10 +1586,10 @@ igt_atomic_prepare_plane_commit(igt_plane_t *plane, 
igt_output_t *output,
}
  
  	if (plane->position_changed || plane->size_changed) {

-   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 */
-   uint32_t src_h = IGT_FIXED(plane->fb->src_h, 0); /* src_h */
+   uint32_t src_x = IGT_FIXED(plane->src_x, 0); /* src_x */
+   uint32_t src_y = IGT_FIXED(plane->src_y, 0); /* src_y */
+   uint32_t src_w = IGT_FIXED(plane->src_w, 0); /* src_w */
+   uint32_t src_h = IGT_FIXED(plane->src_h, 0); /* src_h */
int32_t crtc_x = plane->crtc_x;
int32_t crtc_y = plane->crtc_y;
uint32_t crtc_w = plane->crtc_w;
@@ -1677,10 +1677,10 @@ static int igt_drm_plane_commit(igt_plane_t *plane,
CHECK_RETURN(ret, fail_on_error);
} else if (plane->fb_changed || plane->position_changed ||
plane->size_changed) {
-   src_x = IGT_FIXED(plane->fb->src_x,0); /* src_x */
-   src_y = IGT_FIXED(plane->fb->src_y,0); /* src_y */
-   src_w = IGT_FIXED(plane->fb->src_w,0); /* src_w */
-   src_h = IGT_FIXED(plane->fb->src_h,0); /* src_h */
+   src_x = IGT_FIXED(plane->src_x,0); /* src_x */
+   src_y = IGT_FIXED(plane->src_y,0); /* src_y */
+   src_w = IGT_FIXED(plane->src_w,0); /* src_w */
+   src_h = IGT_FIXED(plane->src_h,0); /* src_h */
crtc_x = plane->crtc_x;
crtc_y = plane->crtc_y;
crtc_w = plane->crtc_w;
@@ -2201,10 +2201,10 @@ void igt_plane_set_fb(igt_plane_t *plane, struct igt_fb 
*fb)
plane->crtc_h = fb->height;
  
  		/* set default src pos/size as fb size */

-   fb->src_x = 0;
-   fb->src_y = 0;
-   fb->src_w = fb->width;
-   fb->src_h = fb->height;
+   plane->src_x = 0;
+   plane->src_y = 0;
+   plane->src_w = fb->width;
+   plane->src_h = fb->height;
} else {
plane->crtc_w = 0;
plane->crtc_h = 0;
@@ -2271,8 +2271,8 @@ void igt_fb_set_position(struct igt_fb *fb, igt_plane_t 
*plane,
LOG(display, "%s.%d: fb_set_position(%d,%d)\n",
kmstest_pipe_name(pipe->pipe), plane->index, x, y);
  
-	fb->src_x = x;

-   fb->src_y = y;
+   plane->src_x = x;
+   plane->src_y = y;
  
  	plane->fb_changed = true;

  }
@@ -2297,8 +2297,8 @@ void igt_fb_set_size(struct igt_fb *fb, igt_plane_t 
*plane,
LOG(display, "%s.%d: fb_set_size(%dx%d)\n",
kmstest_pipe_name(pipe->pipe), plane->index, w, h);
  
-	fb->src_w = w;

-   fb->src_h = h;
+   plane->src_w = w;
+   plane->src_h = h;
  
  	plane->fb_changed = true;

  }
diff --git a/lib/igt_kms.h b/lib/igt_kms.h
index 8ae1192..aabe244 100644
--- a/lib/igt_kms.h
+++ b/lib/igt_kms.h
@@ -243,6 +243,14 @@ typedef struct {
int crtc_x, crtc_y;
/* size within pipe_src_w x pipe_src_h */
int crtc_w, crtc_h;
+
+   /* position with the framebuffer */
+   uint32_t src_x;
+   uint32_t src_y;
+   /* size within the framebuffer*/
+   uint32_t src_w;
+   uint32_t src_h;


Perhaps add a small note that these are 16.16

Patch looks good to me otherwise.


I think we convert them to 16.16 at commit time.
The values stored there should be normal integers.




+
/* panning offset within the fb */
unsigned int pan_x, pan_y;
igt_rotation_t rotation;
--
2.8.0.rc3


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


Re: [Intel-gfx] [PATCH 5/6] drm,i915: Introduce drm_malloc_gfp()

2016-04-05 Thread Chris Wilson
On Tue, Apr 05, 2016 at 01:57:36PM +0100, Chris Wilson wrote:
> I have instances where I want to use drm_malloc_ab() but with a custom
> gfp mask. And with those, where I want a temporary allocation, I want to
> try a high-order kmalloc() before using a vmalloc().
> 
> So refactor my usage into drm_malloc_gfp().
> 
> Signed-off-by: Chris Wilson 
> Cc: dri-de...@lists.freedesktop.org
> Cc: Ville Syrjälä 
> Reviewed-by: Ville Syrjälä 
> Acked-by: Dave Airlie 

> +static __inline__ void *drm_malloc_gfp(size_t nmemb, size_t size, gfp_t gfp)
> +{
> + if (size != 0 && nmemb > SIZE_MAX / size)
> + return NULL;

I know Dave G. has some fancy code to detect when the size parameter is
not constant, but one thing I noticed was that gcc would uninline this
function and we would lose the constant folding. Is there anything we
can do to convince gcc to avoid a div here (other than pure macro)?
-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] kms_atomic: Skip rather than fail on non-atomic drivers

2016-04-05 Thread Daniel Stone
Hi,

On 4 April 2016 at 22:17, Matt Roper  wrote:
> 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.

That was certainly the intention.

Reviewed-by: Daniel Stone 

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


Re: [Intel-gfx] [PATCH 6/6] drm/i915: Avoid allocating a vmap arena for a single page

2016-04-05 Thread Chris Wilson
On Tue, Apr 05, 2016 at 01:57:37PM +0100, Chris Wilson wrote:
> If we want a contiguous mapping of a single page sized object, we can
> forgo using vmap() and just use a regular kmap(). Note that this is only
> suitable if the desired pgprot_t is comptabitible.

One day, I will enable :set spell. Does anyone know if there is a .vim
rule to detect git? Or something to stuff in git config core.editor ?
-Chris

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


Re: [Intel-gfx] [PATCH] drm/i915: Add a way to test the modeset done during gpu reset.

2016-04-05 Thread Ville Syrjälä
On Tue, Apr 05, 2016 at 12:56:37PM +0200, Maarten Lankhorst wrote:
> Add force_reset_modeset_test as a parameter to force the modeset path during 
> gpu reset.
> This allows a IGT test to set the knob and trigger a hang to force the gpu 
> reset.
> 
> Signed-off-by: Maarten Lankhorst 
> Fixes: e2c8b8701e2d ("drm/i915: Use atomic helpers for suspend, v2.")
> Cc: drm-intel-fi...@lists.freedesktop.org

Seems like this should be two patches; One to fix the locking and
another to add the debug knob.

> ---
>  drivers/gpu/drm/i915/i915_params.c   |   6 ++
>  drivers/gpu/drm/i915/i915_params.h   |   1 +
>  drivers/gpu/drm/i915/intel_display.c | 161 
> ---
>  3 files changed, 116 insertions(+), 52 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_params.c 
> b/drivers/gpu/drm/i915/i915_params.c
> index 1779f02e6df8..80ce581793dc 100644
> --- a/drivers/gpu/drm/i915/i915_params.c
> +++ b/drivers/gpu/drm/i915/i915_params.c
> @@ -45,6 +45,7 @@ struct i915_params i915 __read_mostly = {
>   .fastboot = 0,
>   .prefault_disable = 0,
>   .load_detect_test = 0,
> + .force_reset_modeset_test = 0,
>   .reset = true,
>   .invert_brightness = 0,
>   .disable_display = 0,
> @@ -158,6 +159,11 @@ MODULE_PARM_DESC(load_detect_test,
>   "Force-enable the VGA load detect code for testing (default:false). "
>   "For developers only.");
>  
> +module_param_named_unsafe(force_reset_modeset_test, 
> i915.force_reset_modeset_test, bool, 0600);
> +MODULE_PARM_DESC(force_reset_modeset_test,
> + "Force a modeset during gpu reset for testing (default:false). "
> + "For developers only.");
> +
>  module_param_named_unsafe(invert_brightness, i915.invert_brightness, int, 
> 0600);
>  MODULE_PARM_DESC(invert_brightness,
>   "Invert backlight brightness "
> diff --git a/drivers/gpu/drm/i915/i915_params.h 
> b/drivers/gpu/drm/i915/i915_params.h
> index 02bc27804291..3934c4300427 100644
> --- a/drivers/gpu/drm/i915/i915_params.h
> +++ b/drivers/gpu/drm/i915/i915_params.h
> @@ -55,6 +55,7 @@ struct i915_params {
>   bool fastboot;
>   bool prefault_disable;
>   bool load_detect_test;
> + bool force_reset_modeset_test;
>   bool reset;
>   bool disable_display;
>   bool enable_guc_submission;
> diff --git a/drivers/gpu/drm/i915/intel_display.c 
> b/drivers/gpu/drm/i915/intel_display.c
> index af74cdba7081..acca08797123 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -3119,27 +3119,94 @@ static void intel_update_primary_planes(struct 
> drm_device *dev)
>   }
>  }
>  
> +static int
> +__intel_display_resume(struct drm_device *dev,
> +struct drm_atomic_state *state,
> +bool *setup)
> +{
> + struct drm_crtc_state *crtc_state;
> + struct drm_crtc *crtc;
> + int i;
> +
> + if (!setup || !*setup) {
> + if (setup)
> + *setup = true;
> +
> + intel_modeset_setup_hw_state(dev);
> + i915_redisable_vga(dev);
> + }
> +
> + if (!state)
> + return 0;
> +
> + for_each_crtc_in_state(state, crtc, crtc_state, i) {
> + /*
> +  * Force recalculation even if we restore
> +  * current state. With fast modeset this may not result
> +  * in a modeset when the state is compatible.
> +  */
> + crtc_state->mode_changed = true;
> + }
> +
> + return drm_atomic_commit(state);
> +}
> +
>  void intel_prepare_reset(struct drm_device *dev)
>  {
> + bool requires_display_reset = true;
> + struct drm_atomic_state *state;
> + struct drm_modeset_acquire_ctx *pctx;
> + int ret;
> +
>   /* no reset support for gen2 */
>   if (IS_GEN2(dev))
>   return;
>  
>   /* reset doesn't touch the display */
> - if (INTEL_INFO(dev)->gen >= 5 || IS_G4X(dev))
> - return;
> + if (INTEL_INFO(dev)->gen >= 5 || IS_G4X(dev)) {
> + if (!i915.force_reset_modeset_test)
> + return;
> +
> + requires_display_reset = false;

Can't we just run the full code on g4x+ anyway? Would leave the code
much simpler.

> + }
>  
>   drm_modeset_lock_all(dev);
> + pctx = dev->mode_config.acquire_ctx;

pctx makes me think of power context.

> +
>   /*
>* Disabling the crtcs gracefully seems nicer. Also the
>* g33 docs say we should at least disable all the planes.
>*/
> - intel_display_suspend(dev);
> +
> + state = drm_atomic_helper_duplicate_state(dev, pctx);
> + if (IS_ERR(state)) {
> + ret = PTR_ERR(state);
> + state = NULL;
> + DRM_ERROR("Duplicating state failed with %i\n", ret);
> + goto err;
> + }
> +
> + ret = drm_atomic_helper_disable_all(dev, pctx);
> + if (ret) {
> + 

Re: [Intel-gfx] [PATCH 1/2] drm/i915/skl: Fix rc6 based gpu/system hang

2016-04-05 Thread Timo Aaltonen
05.04.2016, 15:56, Mika Kuoppala kirjoitti:
> For all gt3 and gt4 skylake variants, extend the usage of
> WaRsDisableCoarsePowerGating for all revisions. Without this
> gt3 and gt4 skylakes up to atleast rev 0xa can gpu hang or
> system hang.
> 
> Cc: Abdiel Janulgue 
> Cc: Ben Widawsky 
> Cc: Timo Aaltonen 
> Cc: 
> Reported-by: Mikael Djurfeldt 
> References: https://bugs.freedesktop.org/show_bug.cgi?id=94161
> Signed-off-by: Mika Kuoppala 
> ---

thanks, with a big-n-loud

Tested-by: Timo Aaltonen 

to both


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


Re: [Intel-gfx] [PATCH 14/16] drm/i915/gen9: Calculate watermarks during atomic 'check'

2016-04-05 Thread Patrik Jakobsson
On Thu, Mar 31, 2016 at 06:46:36PM -0700, Matt Roper wrote:
> Moving watermark calculation into the check phase will allow us to to
> reject display configurations for which there are no valid watermark
> values before we start trying to program the hardware (although those
> tests will come in a subsequent patch).
> 
> Another advantage of moving this calculation to the check phase is that
> we can calculate the watermarks in a single shot as part of the atomic
> transaction.  The watermark interfaces we inherited from our legacy
> modesetting days are a bit broken in the atomic design because they use
> per-crtc entry points but actually re-calculate and re-program something
> that is really more of a global state.  That worked okay in the legacy
> modesetting world because operations only ever updated a single CRTC at
> a time.  However in the atomic world, a transaction can involve multiple
> CRTC's, which means we wind up computing and programming the watermarks
> NxN times (where N is the number of CRTC's involved).  With this patch
> we eliminate the redundant re-calculation of watermark data for atomic
> states (which was the cause of the WARN_ON(!wm_changed) problems that
> have plagued us for a while).

This one also fixes: https://bugs.freedesktop.org/show_bug.cgi?id=92181

> 
> We still need to work on the 'commit' side of watermark handling so that
> we aren't doing redundant NxN programming of watermarks, but that's
> content for future patches.
> 
> Signed-off-by: Matt Roper 
> ---
>  drivers/gpu/drm/i915/intel_display.c |   2 +-
>  drivers/gpu/drm/i915/intel_drv.h |   2 +-
>  drivers/gpu/drm/i915/intel_pm.c  | 141 
> +--
>  3 files changed, 55 insertions(+), 90 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_display.c 
> b/drivers/gpu/drm/i915/intel_display.c
> index c514549..f1bea9f 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -13523,7 +13523,7 @@ static int intel_atomic_commit(struct drm_device *dev,
>  
>   drm_atomic_helper_swap_state(dev, state);
>   dev_priv->wm.config = intel_state->wm_config;
> - dev_priv->wm.skl_results.ddb = intel_state->ddb;
> + dev_priv->wm.skl_results = intel_state->wm_results;
>   intel_shared_dpll_commit(state);
>  
>   if (intel_state->modeset) {
> diff --git a/drivers/gpu/drm/i915/intel_drv.h 
> b/drivers/gpu/drm/i915/intel_drv.h
> index 6471f69..3abd394 100644
> --- a/drivers/gpu/drm/i915/intel_drv.h
> +++ b/drivers/gpu/drm/i915/intel_drv.h
> @@ -303,7 +303,7 @@ struct intel_atomic_state {
>   bool skip_intermediate_wm;
>  
>   /* Gen9+ only */
> - struct skl_ddb_allocation ddb;
> + struct skl_wm_values wm_results;
>  };
>  
>  struct intel_plane_state {
> diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
> index 1bef89a..e4de5aa 100644
> --- a/drivers/gpu/drm/i915/intel_pm.c
> +++ b/drivers/gpu/drm/i915/intel_pm.c
> @@ -3187,23 +3187,6 @@ static uint32_t skl_wm_method2(uint32_t pixel_rate, 
> uint32_t pipe_htotal,
>   return ret;
>  }
>  
> -static bool skl_ddb_allocation_changed(const struct skl_ddb_allocation 
> *new_ddb,
> -const struct intel_crtc *intel_crtc)
> -{
> - struct drm_device *dev = intel_crtc->base.dev;
> - struct drm_i915_private *dev_priv = dev->dev_private;
> - const struct skl_ddb_allocation *cur_ddb = _priv->wm.skl_hw.ddb;
> -
> - /*
> -  * If ddb allocation of pipes changed, it may require recalculation of
> -  * watermarks
> -  */
> - if (memcmp(new_ddb->pipe, cur_ddb->pipe, sizeof(new_ddb->pipe)))
> - return true;
> -
> - return false;
> -}
> -
>  static int skl_compute_plane_wm(const struct drm_i915_private *dev_priv,
>   struct intel_crtc_state *cstate,
>   struct intel_plane_state *intel_pstate,
> @@ -3654,72 +3637,16 @@ static int skl_update_pipe_wm(struct drm_crtc_state 
> *cstate,
>   else
>   *changed = true;
>  
> - intel_crtc->wm.active.skl = *pipe_wm;
> -
>   return 0;
>  }
>  
> -static void skl_update_other_pipe_wm(struct drm_device *dev,
> -  struct drm_crtc *crtc,
> -  struct skl_wm_values *r)
> -{
> - struct intel_crtc *intel_crtc;
> - struct intel_crtc *this_crtc = to_intel_crtc(crtc);
> -
> - /*
> -  * If the WM update hasn't changed the allocation for this_crtc (the
> -  * crtc we are currently computing the new WM values for), other
> -  * enabled crtcs will keep the same allocation and we don't need to
> -  * recompute anything for them.
> -  */
> - if (!skl_ddb_allocation_changed(>ddb, this_crtc))
> - return;
> -
> - /*
> -  * Otherwise, because of this_crtc being freshly enabled/disabled, the
> -  * other active pipes need 

[Intel-gfx] [PATCH 3/6] drm/i915: Refactor duplicate object vmap functions

2016-04-05 Thread Chris Wilson
We now have two implementations for vmapping a whole object, one for
dma-buf and one for the ringbuffer. If we couple the vmapping into the
obj->pages lifetime, then we can reuse an obj->vmapping for both and at
the same time couple it into the shrinker.

v2: Mark the failable kmalloc() as __GFP_NOWARN (vsyrjala)
v3: Call unpin_vmap from the right dmabuf unmapper

Signed-off-by: Chris Wilson 
---
 drivers/gpu/drm/i915/i915_drv.h | 12 +---
 drivers/gpu/drm/i915/i915_gem.c | 45 ++
 drivers/gpu/drm/i915/i915_gem_dmabuf.c  | 49 -
 drivers/gpu/drm/i915/intel_ringbuffer.c | 26 ++---
 4 files changed, 60 insertions(+), 72 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 6443745d4182..5fedb1b7d8d3 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2167,10 +2167,7 @@ struct drm_i915_gem_object {
struct scatterlist *sg;
int last;
} get_page;
-
-   /* prime dma-buf support */
-   void *dma_buf_vmapping;
-   int vmapping_count;
+   void *vmapping;
 
/** Breadcrumb of last rendering to the buffer.
 * There can only be one writer, but we allow for multiple readers.
@@ -2985,12 +2982,19 @@ static inline void i915_gem_object_pin_pages(struct 
drm_i915_gem_object *obj)
BUG_ON(obj->pages == NULL);
obj->pages_pin_count++;
 }
+
 static inline void i915_gem_object_unpin_pages(struct drm_i915_gem_object *obj)
 {
BUG_ON(obj->pages_pin_count == 0);
obj->pages_pin_count--;
 }
 
+void *__must_check i915_gem_object_pin_vmap(struct drm_i915_gem_object *obj);
+static inline void i915_gem_object_unpin_vmap(struct drm_i915_gem_object *obj)
+{
+   i915_gem_object_unpin_pages(obj);
+}
+
 int __must_check i915_mutex_lock_interruptible(struct drm_device *dev);
 int i915_gem_object_sync(struct drm_i915_gem_object *obj,
 struct intel_engine_cs *to,
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 40f90c7e718a..be4cf13343d5 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -2232,6 +2232,11 @@ i915_gem_object_put_pages(struct drm_i915_gem_object 
*obj)
 * lists early. */
list_del(>global_list);
 
+   if (obj->vmapping) {
+   vunmap(obj->vmapping);
+   obj->vmapping = NULL;
+   }
+
ops->put_pages(obj);
obj->pages = NULL;
 
@@ -2400,6 +2405,46 @@ i915_gem_object_get_pages(struct drm_i915_gem_object 
*obj)
return 0;
 }
 
+void *i915_gem_object_pin_vmap(struct drm_i915_gem_object *obj)
+{
+   int ret;
+
+   ret = i915_gem_object_get_pages(obj);
+   if (ret)
+   return ERR_PTR(ret);
+
+   i915_gem_object_pin_pages(obj);
+
+   if (obj->vmapping == NULL) {
+   struct sg_page_iter sg_iter;
+   struct page **pages;
+   int n;
+
+   n = obj->base.size >> PAGE_SHIFT;
+   pages = kmalloc(n*sizeof(*pages), GFP_TEMPORARY | __GFP_NOWARN);
+   if (pages == NULL)
+   pages = drm_malloc_ab(n, sizeof(*pages));
+   if (pages != NULL) {
+   n = 0;
+   for_each_sg_page(obj->pages->sgl, _iter, 
obj->pages->nents, 0)
+   pages[n++] = sg_page_iter_page(_iter);
+
+   obj->vmapping = vmap(pages, n, 0, PAGE_KERNEL);
+   if (obj->vmapping == NULL) {
+   i915_gem_shrink_all(to_i915(obj->base.dev));
+   obj->vmapping = vmap(pages, n, 0, PAGE_KERNEL);
+   }
+   drm_free_large(pages);
+   }
+   if (obj->vmapping == NULL) {
+   i915_gem_object_unpin_pages(obj);
+   return ERR_PTR(-ENOMEM);
+   }
+   }
+
+   return obj->vmapping;
+}
+
 void i915_vma_move_to_active(struct i915_vma *vma,
 struct drm_i915_gem_request *req)
 {
diff --git a/drivers/gpu/drm/i915/i915_gem_dmabuf.c 
b/drivers/gpu/drm/i915/i915_gem_dmabuf.c
index b7d46800c49f..8d8feadee18c 100644
--- a/drivers/gpu/drm/i915/i915_gem_dmabuf.c
+++ b/drivers/gpu/drm/i915/i915_gem_dmabuf.c
@@ -108,51 +108,17 @@ static void *i915_gem_dmabuf_vmap(struct dma_buf *dma_buf)
 {
struct drm_i915_gem_object *obj = dma_buf_to_obj(dma_buf);
struct drm_device *dev = obj->base.dev;
-   struct sg_page_iter sg_iter;
-   struct page **pages;
-   int ret, i;
+   void *addr;
+   int ret;
 
ret = i915_mutex_lock_interruptible(dev);
if (ret)
return ERR_PTR(ret);
 
-   if (obj->dma_buf_vmapping) {
-   obj->vmapping_count++;
-   goto 

[Intel-gfx] vmap consolidation

2016-04-05 Thread Chris Wilson
We have a couple of pieces of code that wish to take further advantange
of prolonged vmappings: execlists (ringbuffers), the cmdparser and the GuC
(workqueues). This series refactors the whole-object vmapping code and
caches it on the drm_i915_gem_object until it is released along with the
object's pages (i.e. under memory pressure or at the end of the object's
lifetime). This was stalled until we had a notifier in place from the
mm/vmalloc for when we ran out of vmalloc arena (quite possible on 32bit
machines which only reserve ~128MiB globally).

This should unblock a couple of perf.orientated series, but doesn't offer
any new features for itself.
-Chris

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


[Intel-gfx] [PATCH 4/6] drm/i915/shrinker: Restrict vmap purge to objects with vmaps

2016-04-05 Thread Chris Wilson
When called because we have run out of vmap address space, we only need
to recover objects that have vmappings and not all.

Signed-off-by: Chris Wilson 
---
 drivers/gpu/drm/i915/i915_drv.h  |  1 +
 drivers/gpu/drm/i915/i915_gem_shrinker.c | 10 +-
 2 files changed, 10 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 5fedb1b7d8d3..99e2cd3bb290 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -3311,6 +3311,7 @@ unsigned long i915_gem_shrink(struct drm_i915_private 
*dev_priv,
 #define I915_SHRINK_UNBOUND 0x2
 #define I915_SHRINK_BOUND 0x4
 #define I915_SHRINK_ACTIVE 0x8
+#define I915_SHRINK_VMAPS 0x10
 unsigned long i915_gem_shrink_all(struct drm_i915_private *dev_priv);
 void i915_gem_shrinker_init(struct drm_i915_private *dev_priv);
 void i915_gem_shrinker_cleanup(struct drm_i915_private *dev_priv);
diff --git a/drivers/gpu/drm/i915/i915_gem_shrinker.c 
b/drivers/gpu/drm/i915/i915_gem_shrinker.c
index 39943793edcc..56b4ec31d798 100644
--- a/drivers/gpu/drm/i915/i915_gem_shrinker.c
+++ b/drivers/gpu/drm/i915/i915_gem_shrinker.c
@@ -167,6 +167,10 @@ i915_gem_shrink(struct drm_i915_private *dev_priv,
obj->madv != I915_MADV_DONTNEED)
continue;
 
+   if (flags & I915_SHRINK_VMAPS &&
+   obj->vmapping == NULL)
+   continue;
+
if ((flags & I915_SHRINK_ACTIVE) == 0 && obj->active)
continue;
 
@@ -388,7 +392,11 @@ i915_gem_shrinker_vmap(struct notifier_block *nb, unsigned 
long event, void *ptr
if (!i915_gem_shrinker_lock_uninterruptible(dev_priv, , 5000))
return NOTIFY_DONE;
 
-   freed_pages = i915_gem_shrink_all(dev_priv);
+   freed_pages = i915_gem_shrink(dev_priv, -1UL,
+ I915_SHRINK_BOUND |
+ I915_SHRINK_UNBOUND |
+ I915_SHRINK_ACTIVE |
+ I915_SHRINK_VMAPS);
 
i915_gem_shrinker_unlock_uninterruptible(dev_priv, );
 
-- 
2.8.0.rc3

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


[Intel-gfx] [PATCH 6/6] drm/i915: Avoid allocating a vmap arena for a single page

2016-04-05 Thread Chris Wilson
If we want a contiguous mapping of a single page sized object, we can
forgo using vmap() and just use a regular kmap(). Note that this is only
suitable if the desired pgprot_t is comptabitible.

Signed-off-by: Chris Wilson 
---
 drivers/gpu/drm/i915/i915_gem.c | 22 --
 1 file changed, 16 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 985f067c1f0e..dc8e1b76c896 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -2233,7 +2233,10 @@ i915_gem_object_put_pages(struct drm_i915_gem_object 
*obj)
list_del(>global_list);
 
if (obj->vmapping) {
-   vunmap(obj->vmapping);
+   if (obj->base.size == PAGE_SIZE)
+   kunmap(kmap_to_page(obj->vmapping));
+   else
+   vunmap(obj->vmapping);
obj->vmapping = NULL;
}
 
@@ -2416,15 +2419,22 @@ void *i915_gem_object_pin_vmap(struct 
drm_i915_gem_object *obj)
i915_gem_object_pin_pages(obj);
 
if (obj->vmapping == NULL) {
-   struct sg_page_iter sg_iter;
struct page **pages;
-   int n;
 
-   n = obj->base.size >> PAGE_SHIFT;
-   pages = drm_malloc_gfp(n, sizeof(*pages), GFP_TEMPORARY);
+   pages = NULL;
+   if (obj->base.size == PAGE_SIZE)
+   obj->vmapping = kmap(sg_page(obj->pages->sgl));
+   else
+   pages = drm_malloc_gfp(obj->base.size >> PAGE_SHIFT,
+  sizeof(*pages),
+  GFP_TEMPORARY);
if (pages != NULL) {
+   struct sg_page_iter sg_iter;
+   int n;
+
n = 0;
-   for_each_sg_page(obj->pages->sgl, _iter, 
obj->pages->nents, 0)
+   for_each_sg_page(obj->pages->sgl, _iter,
+obj->pages->nents, 0)
pages[n++] = sg_page_iter_page(_iter);
 
obj->vmapping = vmap(pages, n, 0, PAGE_KERNEL);
-- 
2.8.0.rc3

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


[Intel-gfx] [PATCH 5/6] drm,i915: Introduce drm_malloc_gfp()

2016-04-05 Thread Chris Wilson
I have instances where I want to use drm_malloc_ab() but with a custom
gfp mask. And with those, where I want a temporary allocation, I want to
try a high-order kmalloc() before using a vmalloc().

So refactor my usage into drm_malloc_gfp().

Signed-off-by: Chris Wilson 
Cc: dri-de...@lists.freedesktop.org
Cc: Ville Syrjälä 
Reviewed-by: Ville Syrjälä 
Acked-by: Dave Airlie 
---
 drivers/gpu/drm/i915/i915_gem.c|  4 +---
 drivers/gpu/drm/i915/i915_gem_execbuffer.c |  8 +++-
 drivers/gpu/drm/i915/i915_gem_gtt.c|  5 +++--
 drivers/gpu/drm/i915/i915_gem_userptr.c| 15 ---
 include/drm/drm_mem_util.h | 19 +++
 5 files changed, 30 insertions(+), 21 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index be4cf13343d5..985f067c1f0e 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -2421,9 +2421,7 @@ void *i915_gem_object_pin_vmap(struct drm_i915_gem_object 
*obj)
int n;
 
n = obj->base.size >> PAGE_SHIFT;
-   pages = kmalloc(n*sizeof(*pages), GFP_TEMPORARY | __GFP_NOWARN);
-   if (pages == NULL)
-   pages = drm_malloc_ab(n, sizeof(*pages));
+   pages = drm_malloc_gfp(n, sizeof(*pages), GFP_TEMPORARY);
if (pages != NULL) {
n = 0;
for_each_sg_page(obj->pages->sgl, _iter, 
obj->pages->nents, 0)
diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c 
b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
index 0ee61fd014df..6ee4f00f620c 100644
--- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
@@ -1783,11 +1783,9 @@ i915_gem_execbuffer2(struct drm_device *dev, void *data,
return -EINVAL;
}
 
-   exec2_list = kmalloc(sizeof(*exec2_list)*args->buffer_count,
-GFP_TEMPORARY | __GFP_NOWARN | __GFP_NORETRY);
-   if (exec2_list == NULL)
-   exec2_list = drm_malloc_ab(sizeof(*exec2_list),
-  args->buffer_count);
+   exec2_list = drm_malloc_gfp(args->buffer_count,
+   sizeof(*exec2_list),
+   GFP_TEMPORARY);
if (exec2_list == NULL) {
DRM_DEBUG("Failed to allocate exec list for %d buffers\n",
  args->buffer_count);
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c 
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index ae9cb2735767..18f2bd7caad5 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -3413,8 +3413,9 @@ intel_rotate_fb_obj_pages(struct intel_rotation_info 
*rot_info,
int ret = -ENOMEM;
 
/* Allocate a temporary list of source pages for random access. */
-   page_addr_list = drm_malloc_ab(obj->base.size / PAGE_SIZE,
-  sizeof(dma_addr_t));
+   page_addr_list = drm_malloc_gfp(obj->base.size / PAGE_SIZE,
+   sizeof(dma_addr_t),
+   GFP_TEMPORARY);
if (!page_addr_list)
return ERR_PTR(ret);
 
diff --git a/drivers/gpu/drm/i915/i915_gem_userptr.c 
b/drivers/gpu/drm/i915/i915_gem_userptr.c
index 291a9393493d..67883ebf9504 100644
--- a/drivers/gpu/drm/i915/i915_gem_userptr.c
+++ b/drivers/gpu/drm/i915/i915_gem_userptr.c
@@ -494,10 +494,7 @@ __i915_gem_userptr_get_pages_worker(struct work_struct 
*_work)
ret = -ENOMEM;
pinned = 0;
 
-   pvec = kmalloc(npages*sizeof(struct page *),
-  GFP_TEMPORARY | __GFP_NOWARN | __GFP_NORETRY);
-   if (pvec == NULL)
-   pvec = drm_malloc_ab(npages, sizeof(struct page *));
+   pvec = drm_malloc_gfp(npages, sizeof(struct page *), GFP_TEMPORARY);
if (pvec != NULL) {
struct mm_struct *mm = obj->userptr.mm->mm;
 
@@ -634,14 +631,10 @@ i915_gem_userptr_get_pages(struct drm_i915_gem_object 
*obj)
pvec = NULL;
pinned = 0;
if (obj->userptr.mm->mm == current->mm) {
-   pvec = kmalloc(num_pages*sizeof(struct page *),
-  GFP_TEMPORARY | __GFP_NOWARN | __GFP_NORETRY);
+   pvec = drm_malloc_gfp(num_pages, sizeof(struct page *), 
GFP_TEMPORARY);
if (pvec == NULL) {
-   pvec = drm_malloc_ab(num_pages, sizeof(struct page *));
-   if (pvec == NULL) {
-   __i915_gem_userptr_set_active(obj, false);
-   return -ENOMEM;
-   }
+   __i915_gem_userptr_set_active(obj, false);
+   return -ENOMEM;
}
 
pinned = 

[Intel-gfx] [PATCH 2/6] drm/i915: Consolidate common error handling in intel_pin_and_map_ringbuffer_obj

2016-04-05 Thread Chris Wilson
After we pin the ringbuffer into the GGTT, all error paths need to unpin
it again. Move this common step into one block, and make the unable to
iomap error code consistent (i.e. treat it as out of memory to avoid
confusing it with a invalid argument).

Signed-off-by: Chris Wilson 
---
 drivers/gpu/drm/i915/intel_ringbuffer.c | 25 -
 1 file changed, 12 insertions(+), 13 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c 
b/drivers/gpu/drm/i915/intel_ringbuffer.c
index 2e864b7a528b..c6ae92529fdc 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.c
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
@@ -2121,15 +2121,13 @@ int intel_pin_and_map_ringbuffer_obj(struct drm_device 
*dev,
return ret;
 
ret = i915_gem_object_set_to_cpu_domain(obj, true);
-   if (ret) {
-   i915_gem_object_ggtt_unpin(obj);
-   return ret;
-   }
+   if (ret)
+   goto err_unpin;
 
ringbuf->virtual_start = vmap_obj(obj);
if (ringbuf->virtual_start == NULL) {
-   i915_gem_object_ggtt_unpin(obj);
-   return -ENOMEM;
+   ret = -ENOMEM;
+   goto err_unpin;
}
} else {
ret = i915_gem_obj_ggtt_pin(obj, PAGE_SIZE, PIN_MAPPABLE);
@@ -2137,10 +2135,8 @@ int intel_pin_and_map_ringbuffer_obj(struct drm_device 
*dev,
return ret;
 
ret = i915_gem_object_set_to_gtt_domain(obj, true);
-   if (ret) {
-   i915_gem_object_ggtt_unpin(obj);
-   return ret;
-   }
+   if (ret)
+   goto err_unpin;
 
/* Access through the GTT requires the device to be awake. */
assert_rpm_wakelock_held(dev_priv);
@@ -2148,14 +2144,17 @@ int intel_pin_and_map_ringbuffer_obj(struct drm_device 
*dev,
ringbuf->virtual_start = ioremap_wc(ggtt->mappable_base +

i915_gem_obj_ggtt_offset(obj), ringbuf->size);
if (ringbuf->virtual_start == NULL) {
-   i915_gem_object_ggtt_unpin(obj);
-   return -EINVAL;
+   ret = -ENOMEM;
+   goto err_unpin;
}
}
 
ringbuf->vma = i915_gem_obj_to_ggtt(obj);
-
return 0;
+
+err_unpin:
+   i915_gem_object_ggtt_unpin(obj);
+   return ret;
 }
 
 static void intel_destroy_ringbuffer_obj(struct intel_ringbuffer *ringbuf)
-- 
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/6] drm/i915/dmabuf: Tighten struct_mutex for unmap_dma_buf

2016-04-05 Thread Chris Wilson
We only need the struct_mutex to manipulate the pages_pin_count on the
object, we do not need to hold our BKL when freeing the exported
scatterlist.

Signed-off-by: Chris Wilson 
---
 drivers/gpu/drm/i915/i915_gem_dmabuf.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem_dmabuf.c 
b/drivers/gpu/drm/i915/i915_gem_dmabuf.c
index 0506016e18e0..b7d46800c49f 100644
--- a/drivers/gpu/drm/i915/i915_gem_dmabuf.c
+++ b/drivers/gpu/drm/i915/i915_gem_dmabuf.c
@@ -95,14 +95,12 @@ static void i915_gem_unmap_dma_buf(struct 
dma_buf_attachment *attachment,
 {
struct drm_i915_gem_object *obj = dma_buf_to_obj(attachment->dmabuf);
 
-   mutex_lock(>base.dev->struct_mutex);
-
dma_unmap_sg(attachment->dev, sg->sgl, sg->nents, dir);
sg_free_table(sg);
kfree(sg);
 
+   mutex_lock(>base.dev->struct_mutex);
i915_gem_object_unpin_pages(obj);
-
mutex_unlock(>base.dev->struct_mutex);
 }
 
-- 
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/2] drm/i915/skl: Fix rc6 based gpu/system hang

2016-04-05 Thread Mika Kuoppala
For all gt3 and gt4 skylake variants, extend the usage of
WaRsDisableCoarsePowerGating for all revisions. Without this
gt3 and gt4 skylakes up to atleast rev 0xa can gpu hang or
system hang.

Cc: Abdiel Janulgue 
Cc: Ben Widawsky 
Cc: Timo Aaltonen 
Cc: 
Reported-by: Mikael Djurfeldt 
References: https://bugs.freedesktop.org/show_bug.cgi?id=94161
Signed-off-by: Mika Kuoppala 
---
 drivers/gpu/drm/i915/i915_drv.h | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 10480939159c..daba7ebb9699 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2634,8 +2634,9 @@ struct drm_i915_cmd_table {
 
 /* WaRsDisableCoarsePowerGating:skl,bxt */
 #define NEEDS_WaRsDisableCoarsePowerGating(dev) (IS_BXT_REVID(dev, 0, 
BXT_REVID_A1) || \
-((IS_SKL_GT3(dev) || 
IS_SKL_GT4(dev)) && \
- IS_SKL_REVID(dev, 0, 
SKL_REVID_F0)))
+IS_SKL_GT3(dev) || \
+IS_SKL_GT4(dev))
+
 /*
  * dp aux and gmbus irq on gen4 seems to be able to generate legacy interrupts
  * even when in MSI mode. This results in spurious interrupt warnings if the
-- 
2.5.0

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


[Intel-gfx] [PATCH 2/2] drm/i915/skl: Fix spurious gpu hang with gt3/gt4 revs

2016-04-05 Thread Mika Kuoppala
Experiments with heaven 4.0 benchmark and skylake gt3e (rev 0xa)
suggest that WaForceContextSaveRestoreNonCoherent is needed for all
revs. Extending this to all revs cures a gpu hang with rev 0xa when
running heaven4.0 gpu benchmark.

We have been here before, with problems enabling gt4e and extending
up to revision F0 instead of false claims of bspec of E0 only. See
commit  ("drm/i915/skl: Default to noncoherent access
up to F0"). In retrospect we should have covered this with this big
blanket back then already, as E0 vs F0 discrepancy was suspicious
enough.

Previously the WaForceEnableNonCoherent has been tied to
context non-coherence, atleast in relevant hsds. So keep this tie
and extended this alongside.

Cc: Abdiel Janulgue 
Cc: Ben Widawsky 
Cc: Timo Aaltonen 
Cc: sta...@vger.kernel.org
Reported-by: Mike Lothian 
References: https://bugs.freedesktop.org/show_bug.cgi?id=93491
Signed-off-by: Mika Kuoppala 
---
 drivers/gpu/drm/i915/intel_ringbuffer.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c 
b/drivers/gpu/drm/i915/intel_ringbuffer.c
index 45ce45a5e122..7fce1e6afcbc 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.c
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
@@ -968,7 +968,7 @@ static int gen9_init_workarounds(struct intel_engine_cs 
*ring)
 
/* WaForceContextSaveRestoreNonCoherent:skl,bxt */
tmp = HDC_FORCE_CONTEXT_SAVE_RESTORE_NON_COHERENT;
-   if (IS_SKL_REVID(dev, SKL_REVID_F0, SKL_REVID_F0) ||
+   if (IS_SKL_REVID(dev, SKL_REVID_F0, REVID_FOREVER) ||
IS_BXT_REVID(dev, BXT_REVID_B0, REVID_FOREVER))
tmp |= HDC_FORCE_CSR_NON_COHERENT_OVR_DISABLE;
WA_SET_BIT_MASKED(HDC_CHICKEN0, tmp);
@@ -1085,7 +1085,8 @@ static int skl_init_workarounds(struct intel_engine_cs 
*ring)
WA_SET_BIT_MASKED(HIZ_CHICKEN,
  BDW_HIZ_POWER_COMPILER_CLOCK_GATING_DISABLE);
 
-   if (IS_SKL_REVID(dev, 0, SKL_REVID_F0)) {
+   /* This is tied to WaForceContextSaveRestoreNonCoherent */
+   if (IS_SKL_REVID(dev, 0, REVID_FOREVER)) {
/*
 *Use Force Non-Coherent whenever executing a 3D context. This
 * is a workaround for a possible hang in the unlikely event
-- 
2.5.0

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


[Intel-gfx] [PATCH 2/2] drm/i915: Add Backlight Control using DPCD for eDP connectors (v9)

2016-04-05 Thread Yetunde Adebisi
This patch adds support for eDP backlight control using DPCD registers to
backlight hooks in intel_panel.

It checks for backlight control over AUX channel capability and sets up
function pointers to get and set the backlight brightness level if
supported.

v2: Moved backlight functions from intel_dp.c into a new file
intel_dp_aux_backlight.c. Also moved reading of eDP display control
registers to intel_dp_get_dpcd

v3: Correct some formatting mistakes

v4: Updated to use AUX backlight control if PWM control is not possible
(Jani)
v5: Moved call to initialize backlight registers to dp_aux_setup_backlight
v6: Check DP_EDP_BACKLIGHT_PIN_ENABLE_CAP is disabled before setting up AUX
backlight control. To fix BLM_PWM_ENABLE igt test warnings on bdw_ultra
v7: Add enable_dpcd_backlight module parameter.
v8: Rebase onto latest drm-intel-nightly branch
v9: Remove changes to intel_dp_dpcd_read_wake
Split addition edp_dpcd variable into a separate patch

Cc: Bob Paauwe 
Cc: Jani Nikula 
Signed-off-by: Yetunde Adebisi 
---
 drivers/gpu/drm/i915/Makefile |   1 +
 drivers/gpu/drm/i915/i915_params.c|   4 +
 drivers/gpu/drm/i915/i915_params.h|   1 +
 drivers/gpu/drm/i915/intel_dp_aux_backlight.c | 173 ++
 drivers/gpu/drm/i915/intel_drv.h  |   3 +
 drivers/gpu/drm/i915/intel_panel.c|   4 +
 6 files changed, 186 insertions(+)
 create mode 100644 drivers/gpu/drm/i915/intel_dp_aux_backlight.c

diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 7ffb51b..11cc3e6 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -79,6 +79,7 @@ i915-y += dvo_ch7017.o \
  dvo_tfp410.o \
  intel_crt.o \
  intel_ddi.o \
+ intel_dp_aux_backlight.o \
  intel_dp_link_training.o \
  intel_dp_mst.o \
  intel_dp.o \
diff --git a/drivers/gpu/drm/i915/i915_params.c 
b/drivers/gpu/drm/i915/i915_params.c
index 1779f02..383c076 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_dpcd_backlight = false,
 };
 
 module_param_named(modeset, i915.modeset, int, 0400);
@@ -210,3 +211,6 @@ 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(enable_dpcd_backlight, i915.enable_dpcd_backlight, bool, 
0600);
+MODULE_PARM_DESC(enable_dpcd_backlight,
+   "Enable support for DPCD backlight control (default:false)");
diff --git a/drivers/gpu/drm/i915/i915_params.h 
b/drivers/gpu/drm/i915/i915_params.h
index 02bc278..65e73dd 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_dpcd_backlight;
 };
 
 extern struct i915_params i915 __read_mostly;
diff --git a/drivers/gpu/drm/i915/intel_dp_aux_backlight.c 
b/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
new file mode 100644
index 000..984fb0d
--- /dev/null
+++ b/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
@@ -0,0 +1,173 @@
+/*
+ * Copyright © 2015 Intel Corporation
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
+ * IN THE SOFTWARE.
+ *
+ */
+
+#include "intel_drv.h"
+
+static void set_aux_backlight_enable(struct intel_dp *intel_dp, bool enable)
+{
+   uint8_t reg_val = 0;
+
+   if (drm_dp_dpcd_readb(_dp->aux, 

[Intel-gfx] [PATCH 0/2] DPCD Backlight Control

2016-04-05 Thread Yetunde Adebisi
These patches add support for Backlight Control using DPCD registers on eDP 
displays.

- Patch 1 Reads the eDP DPCD Display Control capability registers.

- Patch 2 Implements functionaly for DPCD Backlight Control 

Yetunde Adebisi (2):
  drm/i915: Add edp_dpcd variable
  drm/i915: Add Backlight Control using DPCD for eDP connectors (v9)

 drivers/gpu/drm/i915/Makefile |   1 +
 drivers/gpu/drm/i915/i915_params.c|   4 +
 drivers/gpu/drm/i915/i915_params.h|   1 +
 drivers/gpu/drm/i915/intel_dp.c   |  15 ++-
 drivers/gpu/drm/i915/intel_dp_aux_backlight.c | 173 ++
 drivers/gpu/drm/i915/intel_drv.h  |   4 +
 drivers/gpu/drm/i915/intel_panel.c|   4 +
 7 files changed, 197 insertions(+), 5 deletions(-)
 create mode 100644 drivers/gpu/drm/i915/intel_dp_aux_backlight.c

-- 
1.9.3

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


[Intel-gfx] [PATCH 1/2] drm/i915: Read eDP Display control capability registers

2016-04-05 Thread Yetunde Adebisi
Add new edp_dpcd variable to intel_dp.
Read and save eDP Display control capability registers to edp_dpcd.

Signed-off-by: Yetunde Adebisi 
---
 drivers/gpu/drm/i915/intel_dp.c  | 15 ++-
 drivers/gpu/drm/i915/intel_drv.h |  1 +
 2 files changed, 11 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index da0c3d2..ad2c7d6 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -3777,7 +3777,6 @@ intel_dp_get_dpcd(struct intel_dp *intel_dp)
struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp);
struct drm_device *dev = dig_port->base.base.dev;
struct drm_i915_private *dev_priv = dev->dev_private;
-   uint8_t rev;
 
if (intel_dp_dpcd_read_wake(_dp->aux, 0x000, intel_dp->dpcd,
sizeof(intel_dp->dpcd)) < 0)
@@ -3834,6 +3833,15 @@ intel_dp_get_dpcd(struct intel_dp *intel_dp)
DRM_DEBUG_KMS("PSR2 %s on sink",
dev_priv->psr.psr2_support ? "supported" : "not 
supported");
}
+
+   /* Read the eDP Display control capabilities registers */
+   memset(intel_dp->edp_dpcd, 0, sizeof(intel_dp->edp_dpcd));
+   if ((intel_dp->dpcd[DP_EDP_CONFIGURATION_CAP] & 
DP_DPCD_DISPLAY_CONTROL_CAPABLE) &&
+   (intel_dp_dpcd_read_wake(_dp->aux, 
DP_EDP_DPCD_REV,
+   intel_dp->edp_dpcd, 
sizeof(intel_dp->edp_dpcd)) ==
+   
sizeof(intel_dp->edp_dpcd)))
+   DRM_DEBUG_KMS("EDP DPCD : %*ph\n", (int) 
sizeof(intel_dp->edp_dpcd),
+   intel_dp->edp_dpcd);
}
 
DRM_DEBUG_KMS("Display Port TPS3 support: source %s, sink %s\n",
@@ -3841,10 +3849,7 @@ intel_dp_get_dpcd(struct intel_dp *intel_dp)
  yesno(drm_dp_tps3_supported(intel_dp->dpcd)));
 
/* Intermediate frequency support */
-   if (is_edp(intel_dp) &&
-   (intel_dp->dpcd[DP_EDP_CONFIGURATION_CAP] & 
DP_DPCD_DISPLAY_CONTROL_CAPABLE) &&
-   (intel_dp_dpcd_read_wake(_dp->aux, DP_EDP_DPCD_REV, , 1) 
== 1) &&
-   (rev >= 0x03)) { /* eDp v1.4 or higher */
+   if (is_edp(intel_dp) && (intel_dp->edp_dpcd[0] >= 0x03)) { /* eDp v1.4 
or higher */
__le16 sink_rates[DP_MAX_SUPPORTED_RATES];
int i;
 
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 9255b56..b14e515 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -805,6 +805,7 @@ struct intel_dp {
uint8_t dpcd[DP_RECEIVER_CAP_SIZE];
uint8_t psr_dpcd[EDP_PSR_RECEIVER_CAP_SIZE];
uint8_t downstream_ports[DP_MAX_DOWNSTREAM_PORTS];
+   uint8_t edp_dpcd[EDP_DISPLAY_CTL_CAP_SIZE];
/* sink rates as reported by DP_SUPPORTED_LINK_RATES */
uint8_t num_sink_rates;
int sink_rates[DP_MAX_SUPPORTED_RATES];
-- 
1.9.3

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


[Intel-gfx] [PATCH 4/6] drm/i915/bxt: Block D3 during suspend.

2016-04-05 Thread Animesh Manna
For BXT, display engine can not generate interrupt when in D3.
On the othen hand S0ix can be achieved without display in D3. So,
Display should not put into D3 for HPD to work and will not
have any power impact.

Signed-off-by: Animesh Manna 
---
 drivers/gpu/drm/i915/i915_drv.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 020a31c..6b8c906 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -1547,6 +1547,9 @@ static int intel_runtime_suspend(struct device *device)
 
assert_forcewakes_inactive(dev_priv);
 
+   if (dev_priv->vbt.hpd_wakeup_enabled)
+   pci_save_state(pdev);
+
DRM_DEBUG_KMS("Device suspended\n");
return 0;
 }
@@ -1563,6 +1566,9 @@ static int intel_runtime_resume(struct device *device)
 
DRM_DEBUG_KMS("Resuming device\n");
 
+   if (dev_priv->vbt.hpd_wakeup_enabled)
+   pci_restore_state(pdev);
+
WARN_ON_ONCE(atomic_read(_priv->pm.wakeref_count));
disable_rpm_wakeref_asserts(dev_priv);
 
-- 
2.0.2

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


[Intel-gfx] [PATCH 0/6] HPD support during suspend.

2016-04-05 Thread Animesh Manna
Along with below patches sharing some background details/design.
- On BXT, Display cannot generate an interrupt when in D3.
- Without display in D3, S0ix can be achieved, Power impact
will be zero if d3 is blocked. PMCSR for Graphics/Display
is irrelevant, as the power management for them is taken
care by the PUNIT using RC6/DC9 hints and *not* through
PMCSR write trigger.

So solution is based on below principles:
- Display should not be put into D3 for HPD to work.
- With D0+DC9 we can achieve S0ix and at the same time
helps to get the interrupt.
- Using pci_save_state() during suspend to take control
from OSPM and blocking D3, while resuming, giving back
to OSPM by pci_restore_state(). 
- _DSM method is used to program pmc hpd control register
to enable hpd during suspend.

Please have a look and send your comments/suggestions.

Animesh Manna (6):
  drm/i915/bxt: VBT changes for hpd as wakeup feature
  drm/i915/bxt: Added _DSM call to set HPD_CTL.
  drm/i915/bxt: Corrected the guid for bxt.
  drm/i915/bxt: Block D3 during suspend.
  drm/i915: Enable HPD interrupts with master ctl interrupt
  drm/i915/bxt: Enable HPD during suspend.

 drivers/gpu/drm/i915/i915_drv.c   |  6 
 drivers/gpu/drm/i915/i915_drv.h   |  8 +
 drivers/gpu/drm/i915/i915_irq.c   | 56 +--
 drivers/gpu/drm/i915/i915_reg.h   | 13 
 drivers/gpu/drm/i915/intel_acpi.c | 53 -
 drivers/gpu/drm/i915/intel_bios.c |  7 +
 drivers/gpu/drm/i915/intel_vbt_defs.h |  3 +-
 7 files changed, 134 insertions(+), 12 deletions(-)

-- 
2.0.2

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


[Intel-gfx] [PATCH 6/6] drm/i915/bxt: Enable HPD during suspend.

2016-04-05 Thread Animesh Manna
Based on vbt entry enabling i915 driver to act on
hpd support during suspend.

Signed-off-by: Animesh Manna 
---
 drivers/gpu/drm/i915/intel_bios.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_bios.c 
b/drivers/gpu/drm/i915/intel_bios.c
index 9c406b0..8ed084a 100644
--- a/drivers/gpu/drm/i915/intel_bios.c
+++ b/drivers/gpu/drm/i915/intel_bios.c
@@ -529,6 +529,13 @@ parse_driver_features(struct drm_i915_private *dev_priv,
if (driver->lvds_config == BDB_DRIVER_FEATURE_EDP)
dev_priv->vbt.edp.support = 1;
 
+   if (driver->hpd_wakeup_source) {
+   dev_priv->vbt.hpd_wakeup_enabled =
+   ENABLE_HOT_PLUG_AS_WAKE_EVENT;
+   DRM_DEBUG_KMS("HPD as wakeup feature is enabled\n");
+   } else
+   DRM_DEBUG_KMS("HPD wakeup source feature is disabled in VBT\n");
+
DRM_DEBUG_KMS("DRRS State Enabled:%d\n", driver->drrs_enabled);
/*
 * If DRRS is not supported, drrs_type has to be set to 0.
-- 
2.0.2

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


[Intel-gfx] [PATCH 3/6] drm/i915/bxt: Corrected the guid for bxt.

2016-04-05 Thread Animesh Manna
Guid is changed for bxt platform, so corrected the guid for bxt.

Signed-off-by: Ananth Krishna R 
Signed-off-by: Bharath K Veera 
Signed-off-by: Animesh Manna 
---
 drivers/gpu/drm/i915/intel_acpi.c | 8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_acpi.c 
b/drivers/gpu/drm/i915/intel_acpi.c
index 8f3d672..79b774b 100644
--- a/drivers/gpu/drm/i915/intel_acpi.c
+++ b/drivers/gpu/drm/i915/intel_acpi.c
@@ -17,7 +17,7 @@ static struct intel_dsm_priv {
acpi_handle dhandle;
 } intel_dsm_priv;
 
-static const u8 intel_dsm_guid[] = {
+static u8 intel_dsm_guid[] = {
0xd3, 0x73, 0xd8, 0x7e,
0xd0, 0xc2,
0x4f, 0x4e,
@@ -25,6 +25,9 @@ static const u8 intel_dsm_guid[] = {
0x0f, 0x13, 0x17, 0xb0, 0x1c, 0x2c
 };
 
+static u8 intel_bxt_dsm_guid[] __initdata =
+   "3E5B41C6-EB1D-4260-9D15-C71FBADAE414";
+
 static char *intel_dsm_port_name(u8 id)
 {
switch (id) {
@@ -143,6 +146,9 @@ static bool intel_dsm_pci_probe(struct pci_dev *pdev)
 
intel_dsm_priv.dhandle = dhandle;
 
+   if (IS_BROXTON(dev))
+   acpi_str_to_uuid(intel_bxt_dsm_guid, intel_dsm_guid);
+
if (acpi_check_dsm(dhandle, intel_dsm_guid, INTEL_DSM_REVISION_ID,
1 << INTEL_DSM_FN_PLATFORM_MUX_INFO))
intel_dsm_platform_mux_info();
-- 
2.0.2

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


[Intel-gfx] [PATCH 5/6] drm/i915: Enable HPD interrupts with master ctl interrupt

2016-04-05 Thread Animesh Manna
While suspending the device hpd related interrupts are enabled
to get the interrupt when device is in suspend state.

Though display is in DC9 but system can be in S0 or S0i3 state.
Hot plug during S0 state will generate de_port_interrupt but if
system is in S0i3 state then display driver will get hotplug
interrupt as pcu_hpd_interrupt which will come via pmc. So
added the interrupt handling for pcu hpd interrupt.

Signed-off-by: Animesh Manna 
Signed-off-by: A.Sunil Kamath 
---
 drivers/gpu/drm/i915/i915_irq.c | 56 ++---
 drivers/gpu/drm/i915/i915_reg.h | 12 +
 2 files changed, 65 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index c85eb8d..35d7423 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -110,9 +110,9 @@ static const u32 hpd_status_i915[HPD_NUM_PINS] = {
 
 /* BXT hpd list */
 static const u32 hpd_bxt[HPD_NUM_PINS] = {
-   [HPD_PORT_A] = BXT_DE_PORT_HP_DDIA,
-   [HPD_PORT_B] = BXT_DE_PORT_HP_DDIB,
-   [HPD_PORT_C] = BXT_DE_PORT_HP_DDIC
+   [HPD_PORT_A] = (BXT_DE_PORT_HP_DDIA | BXT_PCU_DC9_HP_DDIA),
+   [HPD_PORT_B] = (BXT_DE_PORT_HP_DDIB | BXT_PCU_DC9_HP_DDIB),
+   [HPD_PORT_C] = (BXT_DE_PORT_HP_DDIC | BXT_PCU_DC9_HP_DDIC)
 };
 
 /* IIR can theoretically queue up two events. Be paranoid. */
@@ -2337,6 +2337,22 @@ gen8_de_irq_handler(struct drm_i915_private *dev_priv, 
u32 master_ctl)
DRM_ERROR("The master control interrupt lied (DE 
PORT)!\n");
}
 
+   if (master_ctl & GEN8_PCU_IRQ) {
+   iir = I915_READ(GEN8_PCU_IIR);
+   if (iir) {
+   u32 tmp_mask;
+   I915_WRITE(GEN8_PCU_IIR, iir);
+   ret = IRQ_HANDLED;
+   if (IS_BROXTON(dev)) {
+   tmp_mask = iir & BXT_PCU_DC9_HOTPLUG_MASK;
+   if (tmp_mask)
+   bxt_hpd_irq_handler(dev, tmp_mask, 
hpd_bxt);
+   } else
+   DRM_ERROR("Unexpected PCU interrupt\n");
+   } else
+   DRM_ERROR("The master control interrupt lied (PCU)!\n");
+   }
+
for_each_pipe(dev_priv, pipe) {
u32 flip_done, fault_errors;
 
@@ -4681,6 +4697,19 @@ void intel_irq_uninstall(struct drm_i915_private 
*dev_priv)
dev_priv->pm.irqs_enabled = false;
 }
 
+static void bxt_enable_pcu_interrupt(struct drm_i915_private *dev_priv)
+{
+   u32 de_pcu_hpd_enable_mask, de_pcu_imr, de_pcu_ier;
+
+   de_pcu_hpd_enable_mask = GEN9_DE_PCU_PORTA_HOTPLUG |
+   GEN9_DE_PCU_PORTB_HOTPLUG |
+   GEN9_DE_PCU_PORTC_HOTPLUG;
+
+   de_pcu_imr = (I915_READ(GEN8_PCU_IMR) & 0x0);
+   de_pcu_ier = (I915_READ(GEN8_PCU_IER) | de_pcu_hpd_enable_mask);
+   GEN5_IRQ_INIT(GEN8_PCU_, de_pcu_imr, de_pcu_ier);
+}
+
 /**
  * intel_runtime_pm_disable_interrupts - runtime interrupt disabling
  * @dev_priv: i915 device instance
@@ -4690,8 +4719,29 @@ void intel_irq_uninstall(struct drm_i915_private 
*dev_priv)
  */
 void intel_runtime_pm_disable_interrupts(struct drm_i915_private *dev_priv)
 {
+   struct drm_device *dev = dev_priv->dev;
+   unsigned long flags = 0;
+
dev_priv->dev->driver->irq_uninstall(dev_priv->dev);
dev_priv->pm.irqs_enabled = false;
+
+   if (IS_BROXTON(dev) && dev_priv->vbt.hpd_wakeup_enabled) {
+
+   /* Enable HPD related interrupts during DC9 for HPD wakeup */
+
+   I915_WRITE(GEN8_MASTER_IRQ, GEN8_MASTER_IRQ_CONTROL);
+   POSTING_READ(GEN8_MASTER_IRQ);
+
+   spin_lock_irqsave(_priv->irq_lock, flags);
+   if (dev_priv->display.hpd_irq_setup)
+   dev_priv->display.hpd_irq_setup(dev_priv->dev);
+   spin_unlock_irqrestore(_priv->irq_lock, flags);
+
+   bxt_enable_pcu_interrupt(dev_priv);
+
+   dev_priv->pm.irqs_enabled = true;
+   }
+
synchronize_irq(dev_priv->dev->irq);
 }
 
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index cc42bd9..15f9021 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -5954,6 +5954,18 @@ enum skl_disp_power_wells {
 #define GEN8_PCU_IIR _MMIO(0x444e8)
 #define GEN8_PCU_IER _MMIO(0x444ec)
 
+/* BXT PCU DC9 hotplug control */
+#define BXT_PCU_DC9_HP_DDIA(1<<31)
+#define BXT_PCU_DC9_HP_DDIB(1<<30)
+#define BXT_PCU_DC9_HP_DDIC(1<<29)
+#define BXT_PCU_DC9_HOTPLUG_MASK   (BXT_PCU_DC9_HP_DDIA | \
+BXT_PCU_DC9_HP_DDIB | \
+BXT_PCU_DC9_HP_DDIC)
+
+#define GEN9_DE_PCU_PORTA_HOTPLUG  (1 << 31)
+#define 

[Intel-gfx] [PATCH 1/6] drm/i915/bxt: VBT changes for hpd as wakeup feature

2016-04-05 Thread Animesh Manna
To support hpd during sleep a new feature flag is
added in vbt and also in dev_priv for enabling/disabling
inside deiver. By default this feature will be
diabled and based on oem request this feature can
be enabled by changing vbt feature flag.

Signed-off-by: Animesh Manna 
Signed-off-by: A.Sunil Kamath 
---
 drivers/gpu/drm/i915/i915_drv.h   | 8 
 drivers/gpu/drm/i915/i915_reg.h   | 1 +
 drivers/gpu/drm/i915/intel_vbt_defs.h | 3 ++-
 3 files changed, 11 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index dd18772..445b80b 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1429,6 +1429,11 @@ enum psr_lines_to_wait {
PSR_8_LINES_TO_WAIT
 };
 
+enum hpd_wakeup_state {
+   DISABLE_HOT_PLUG_AS_WAKE_EVENT = 0,
+   ENABLE_HOT_PLUG_AS_WAKE_EVENT
+};
+
 struct intel_vbt_data {
struct drm_display_mode *lfp_lvds_vbt_mode; /* if any */
struct drm_display_mode *sdvo_lvds_vbt_mode; /* if any */
@@ -1485,6 +1490,9 @@ struct intel_vbt_data {
const u8 *sequence[MIPI_SEQ_MAX];
} dsi;
 
+   /* HPD as wakesoure for DC9 BXT */
+   enum hpd_wakeup_state hpd_wakeup_enabled;
+
int crt_ddc_pin;
 
int child_dev_num;
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 12f5103..cc42bd9 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -6119,6 +6119,7 @@ enum skl_disp_power_wells {
 SDE_PORTB_HOTPLUG |\
 SDE_PORTC_HOTPLUG |\
 SDE_PORTD_HOTPLUG)
+
 #define SDE_TRANSB_CRC_DONE(1 << 5)
 #define SDE_TRANSB_CRC_ERR (1 << 4)
 #define SDE_TRANSB_FIFO_UNDER  (1 << 3)
diff --git a/drivers/gpu/drm/i915/intel_vbt_defs.h 
b/drivers/gpu/drm/i915/intel_vbt_defs.h
index 749dcea..8e2b765 100644
--- a/drivers/gpu/drm/i915/intel_vbt_defs.h
+++ b/drivers/gpu/drm/i915/intel_vbt_defs.h
@@ -547,7 +547,8 @@ struct bdb_driver_features {
u16 tbt_enabled:1;
u16 psr_enabled:1;
u16 ips_enabled:1;
-   u16 reserved3:4;
+   u16 reserved3:3;
+   u16 hpd_wakeup_source:1;
u16 pc_feature_valid:1;
 } __packed;
 
-- 
2.0.2

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


Re: [Intel-gfx] Is Skylake graphics completely broken with multiple monitors?

2016-04-05 Thread Oskar Berggren
2016-04-02 15:08 GMT+01:00 Oskar Berggren :

> Hi,
>
> After trying two different machines I'm beginning to feel like Skylake is
> completely unusable with multiple monitors connected. Is this a known
> limitation? Am I the only one experiencing this?
>
> First I tested on laptop Dell XPS 15 9550 with QHD display. Seems to work
> fine with internal panel, though I haven't used it extensively. Immediately
> or sometimes within a minute or two when I connect an external monitor
> using HDMI the system freezes completely (ping reply stops). This is with
> updated Fedora 23 with kernel from drm-intel-nigthly tested several times
> during the last two months. I've reported this here:
> https://bugs.freedesktop.org/show_bug.cgi?id=94625 with more details.
>
>
> Now I've also got access to a Dell Precision Tower 3620. Being a tower,
> this of course has no internal panel. Connecting one external monitor seems
> to work, but again I've not used it extensively. The second I connect a
> second monitor it freezes completely. Booting with two monitors connected
> also doesn't work. This is with updated Fedora 23 and distribution kernel
> 4.4.6-300 (waiting for download/build of drm-intel-nigthly to finish). CPU
> is i7-6700 stepping 3 microcode 0x74.
>


More testing:

It turns out both systems are reasonably stable using Fedora's 4.4.6-300
kernel - on HDMI and DP _without _ MST. This is what caused the problem -
my DELL U2415 monitor with DP 1.2 enabled causes stability issues, system
freeezes, or is not detected at all, on 4.4.6 and drm-intel-nightly. HDMI
or DP 1.1 seems to work.

However, drm-intel-nightly from last night is still very unstable with HDMI
on the laptop, and also with DP 1.1 for external monitors on the tower
system.

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


[Intel-gfx] [PATCH 2/6] drm/i915/bxt: Added _DSM call to set HPD_CTL.

2016-04-05 Thread Animesh Manna
_DSM is added to program HPD_CTL(0x1094) register
of PMC from i915 driver which will be called
based on driver feature flag. PMC hpd control register
programming will enable PMC to get hpd interrupt
during dc9.

Signed-off-by: Animesh Manna 
---
 drivers/gpu/drm/i915/intel_acpi.c | 45 +--
 1 file changed, 38 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_acpi.c 
b/drivers/gpu/drm/i915/intel_acpi.c
index eb638a1..8f3d672 100644
--- a/drivers/gpu/drm/i915/intel_acpi.c
+++ b/drivers/gpu/drm/i915/intel_acpi.c
@@ -10,6 +10,8 @@
 
 #define INTEL_DSM_REVISION_ID 1 /* For Calpella anyway... */
 #define INTEL_DSM_FN_PLATFORM_MUX_INFO 1 /* No args */
+#define INTEL_DSM_SET_HPD_WAKEUP 17
+#define HPD_WAKEUP_EN_VAL 0xFCF0
 
 static struct intel_dsm_priv {
acpi_handle dhandle;
@@ -110,23 +112,52 @@ static void intel_dsm_platform_mux_info(void)
ACPI_FREE(pkg);
 }
 
+static void intel_dsm_set_hpd_wakeup(void)
+{
+   union acpi_object *obj;
+   union acpi_object argv4 = {
+   .integer.type = ACPI_TYPE_INTEGER,
+   .integer.value = HPD_WAKEUP_EN_VAL,
+   };
+
+   obj = acpi_evaluate_dsm_typed(intel_dsm_priv.dhandle, intel_dsm_guid,
+   INTEL_DSM_REVISION_ID, INTEL_DSM_SET_HPD_WAKEUP,
+   , ACPI_TYPE_INTEGER);
+
+   if (!obj)
+   DRM_DEBUG_DRIVER("failed to evaluate _DSM\n");
+
+   ACPI_FREE(obj);
+}
+
 static bool intel_dsm_pci_probe(struct pci_dev *pdev)
 {
acpi_handle dhandle;
+   struct drm_device *dev = pci_get_drvdata(pdev);
+   struct drm_i915_private *dev_priv = dev->dev_private;
 
dhandle = ACPI_HANDLE(>dev);
-   if (!dhandle)
-   return false;
 
-   if (!acpi_check_dsm(dhandle, intel_dsm_guid, INTEL_DSM_REVISION_ID,
-   1 << INTEL_DSM_FN_PLATFORM_MUX_INFO)) {
-   DRM_DEBUG_KMS("no _DSM method for intel device\n");
+   if (!dhandle)
return false;
-   }
 
intel_dsm_priv.dhandle = dhandle;
-   intel_dsm_platform_mux_info();
 
+   if (acpi_check_dsm(dhandle, intel_dsm_guid, INTEL_DSM_REVISION_ID,
+   1 << INTEL_DSM_FN_PLATFORM_MUX_INFO))
+   intel_dsm_platform_mux_info();
+   else
+   DRM_DEBUG_KMS("no _DSM method for mux-info\n");
+
+   /* Need to ensure vbt parsing is completed. */
+   if (dev_priv->vbt.hpd_wakeup_enabled &&
+   acpi_check_dsm(dhandle, intel_dsm_guid, INTEL_DSM_REVISION_ID,
+   1 << INTEL_DSM_SET_HPD_WAKEUP))
+   intel_dsm_set_hpd_wakeup();
+   else {
+   dev_priv->vbt.hpd_wakeup_enabled = false;
+   DRM_DEBUG_KMS("no _DSM method for hpd-enabling\n");
+   }
return true;
 }
 
-- 
2.0.2

___
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/userptr: Flush cancellations before mmu-notifier invalidate returns

2016-04-05 Thread Chris Wilson
On Tue, Apr 05, 2016 at 01:05:05PM +0100, Tvrtko Ursulin wrote:
> 
> On 03/04/16 18:14, Chris Wilson wrote:
> >In order to ensure that all invalidations are completed before the
> >operation returns to userspace (i.e. before the mmap() syscall returns)
> >we need to flush the outstanding operations. To this end, we submit all
> >the per-object invalidation work to a private workqueue and then flush
> >the workqueue at the end of the function. We are allowed to block inside
> >invalidate_range_start, and struct_mutex is the inner lock so the worker
> >is not hiding any lock inversions. The advantage of using the workqueue
> >over direct calling of cancel_userptr() is that it allows us to
> >parallelise the potential waits and unpinning of large objects.
> 
> There was no direct calling, but running it from a shared wq which
> is now private, per task->mm.

I meant keep using a wq as opposed to changing the invalidate_range_begin to
call cancel_userptr() directly.

> But it sounds so obvious now that the mmu notifier needs to wait for
> cancel_userptr workers to complete that I wonder how we missed that
> until now.
> 
> I would also spell out the two new bits explicitly in the commit:
> waiting for workers and waiting on rendering.

Ok, deleted a couple of attempts already. Will get a cup of tea and try
and write something eloquent.

> With some more description for the latter - why it is needed?
> i915_vma_unbind would be doing a flavour of waiting already.

It allows us to drop the lock whilst waiting for outstanding rendering,
to try and prevent contention between munmap in one process and execbuf
in another. Later on we can reduce the lock here further.
-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] ✗ Fi.CI.BAT: failure for GuC reset-and-retry patches (resend)

2016-04-05 Thread Tvrtko Ursulin


On 05/04/16 13:03, Dave Gordon wrote:

On 05/04/16 07:56, Patchwork wrote:

== Series Details ==

Series: GuC reset-and-retry patches (resend)
URL   : https://patchwork.freedesktop.org/series/5287/
State : failure

== Summary ==

Series 5287v1 GuC reset-and-retry patches (resend)
http://patchwork.freedesktop.org/api/1.0/series/5287/revisions/1/mbox/

Test gem_ctx_switch:
 Subgroup basic-default:
 pass   -> DMESG-WARN (skl-i7k-2)


https://bugs.freedesktop.org/show_bug.cgi?id=93847
GuC is calling a sleeping function in atomic context
Fix in progress (unrelated to the reset-and-retry patches)


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


https://bugs.freedesktop.org/show_bug.cgi?id=94307
[BAT ILK] gem_sync/basic-bsd fails / hangcheck timer elapsed
Unrelated; being investigated by Gabriel Feceoru


Test kms_flip:
 Subgroup basic-flip-vs-dpms:
 pass   -> DMESG-WARN (ilk-hp8440p) UNSTABLE


https://bugs.freedesktop.org/show_bug.cgi?id=93787
[BAT ILK] sporadic fifo underruns in igt@kms_flip@basic-flip-vs-* on
ilk-hp8440p (edit)
Unrelated


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)
Test pm_rpm:
 Subgroup basic-pci-d3-state:
 pass   -> DMESG-WARN (bsw-nuc-2)


https://bugs.freedesktop.org/show_bug.cgi?id=94164
[BAT BYT/BSW] Runtime PM: *ERROR* Unclaimed access detected prior to
suspending
Unrelated


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:130  dwarn:1   dfail:1   fail:0
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
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_1794/

aedfaaef290af9c8df7d9f4adf22cbe21704d091 drm-intel-nightly:
2016y-04m-04d-13h-09m-54s UTC integration manifest
c7e3e58bc5509154a98e7c2fa1e433538f67c97a DO NOT MERGE: add
enable_guc_loading parameter
87ce739817a1d65a3770c67d27560ea7377ad05e drm/i915/guc: always reset
GuC before loading firmware
4f0836e699a720d8429de99f8d374e3a732a16f5 drm/i915/guc: reset GuC and
retry on firmware load failure


1 and 2 merged, thanks for the patches and review!

Regards,

Tvrtko


___
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/userptr: Hold mmref whilst calling get-user-pages

2016-04-05 Thread Tvrtko Ursulin


On 03/04/16 18:14, Chris Wilson wrote:

Holding a reference to the containing task_struct is not sufficient to
prevent the mm_struct from being reaped under memory pressure. If this
happens whilst we are calling get_user_pages(), explosions errupt -
sometimes an immediate GPF, sometimes page flag corruption. To prevent
the target mm from being reaped as we are reading from it, acquire a
reference before we begin.

Testcase: igt/gem_shrink/*userptr
Signed-off-by: Chris Wilson 
Cc: Tvrtko Ursulin 
Cc: Michał Winiarski 
Cc: sta...@vger.kernel.org
---
  drivers/gpu/drm/i915/i915_gem_userptr.c | 29 +
  1 file changed, 17 insertions(+), 12 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem_userptr.c 
b/drivers/gpu/drm/i915/i915_gem_userptr.c
index 92b39186b05a..960bb37f458f 100644
--- a/drivers/gpu/drm/i915/i915_gem_userptr.c
+++ b/drivers/gpu/drm/i915/i915_gem_userptr.c
@@ -547,19 +547,24 @@ __i915_gem_userptr_get_pages_worker(struct work_struct 
*_work)
if (pvec != NULL) {
struct mm_struct *mm = obj->userptr.mm->mm;

-   down_read(>mmap_sem);
-   while (pinned < npages) {
-   ret = get_user_pages_remote(work->task, mm,
-   obj->userptr.ptr + pinned * PAGE_SIZE,
-   npages - pinned,
-   !obj->userptr.read_only, 0,
-   pvec + pinned, NULL);
-   if (ret < 0)
-   break;
-
-   pinned += ret;
+   ret = -EFAULT;
+   if (atomic_inc_not_zero(>mm_users)) {
+   down_read(>mmap_sem);
+   while (pinned < npages) {
+   ret = get_user_pages_remote
+   (work->task, mm,
+obj->userptr.ptr + pinned * PAGE_SIZE,
+npages - pinned,
+!obj->userptr.read_only, 0,
+pvec + pinned, NULL);
+   if (ret < 0)
+   break;
+
+   pinned += ret;
+   }
+   up_read(>mmap_sem);
+   mmput(mm);
}
-   up_read(>mmap_sem);
}

mutex_lock(>struct_mutex);



Strange, doesn't this mean that the atomic_inc(>mm->mm_count) 
is not doing what we thought it would?


Regards,

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


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

2016-04-05 Thread Patchwork
== Series Details ==

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

== Summary ==

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

Test core_auth:
Subgroup basic-auth:
incomplete -> PASS   (bdw-nuci7)
Test drv_getparams_basic:
Subgroup basic-eu-total:
incomplete -> PASS   (bdw-nuci7)
Test drv_module_reload_basic:
fail   -> PASS   (snb-dellxps)
skip   -> PASS   (skl-nuci5)
Test gem_basic:
Subgroup create-close:
incomplete -> PASS   (bdw-nuci7)
Test gem_ctx_create:
Subgroup basic:
incomplete -> PASS   (bdw-nuci7)
Test gem_ctx_param_basic:
Subgroup basic-default:
incomplete -> PASS   (bdw-nuci7)
Subgroup invalid-ctx-get:
incomplete -> PASS   (bdw-nuci7)
Subgroup invalid-ctx-set:
incomplete -> PASS   (bdw-nuci7)
Test gem_exec_basic:
Subgroup basic-blt:
incomplete -> PASS   (bdw-nuci7)
Subgroup gtt-bsd1:
incomplete -> PASS   (bdw-nuci7)
Subgroup readonly-bsd:
incomplete -> PASS   (bdw-nuci7)
Test gem_exec_parse:
Subgroup basic-rejected:
incomplete -> SKIP   (bdw-nuci7)
Test gem_exec_store:
Subgroup basic-render:
incomplete -> PASS   (bdw-nuci7)
Test gem_exec_suspend:
Subgroup basic-s4:
fail   -> SKIP   (snb-dellxps)
Test gem_mmap_gtt:
Subgroup basic-read-no-prefault:
incomplete -> PASS   (bdw-nuci7)
Subgroup basic-small-bo:
incomplete -> PASS   (bdw-nuci7)
Subgroup basic-small-copy-xy:
incomplete -> PASS   (bdw-nuci7)
Subgroup basic-write-gtt:
incomplete -> PASS   (bdw-nuci7)
Test gem_render_linear_blits:
Subgroup basic:
incomplete -> PASS   (bdw-nuci7)
Test gem_ringfill:
Subgroup basic-default-forked:
incomplete -> PASS   (bdw-nuci7)
Test gem_storedw_loop:
Subgroup basic-blt:
incomplete -> PASS   (bdw-nuci7)
Subgroup basic-bsd2:
incomplete -> PASS   (bdw-nuci7)
Subgroup basic-render:
incomplete -> PASS   (bdw-nuci7) UNSTABLE
Test gem_sync:
Subgroup basic-bsd1:
incomplete -> PASS   (bdw-nuci7)
Subgroup basic-render:
incomplete -> PASS   (bdw-nuci7) UNSTABLE
Subgroup basic-vebox:
incomplete -> PASS   (bdw-nuci7)
Test kms_addfb_basic:
Subgroup addfb25-x-tiled:
incomplete -> PASS   (bdw-nuci7)
Subgroup addfb25-x-tiled-mismatch:
incomplete -> PASS   (bdw-nuci7)
Subgroup bad-pitch-0:
incomplete -> PASS   (bdw-nuci7)
Subgroup bo-too-small-due-to-tiling:
incomplete -> PASS   (bdw-nuci7)
Subgroup unused-handle:
incomplete -> PASS   (bdw-nuci7)
Subgroup unused-modifier:
incomplete -> PASS   (bdw-nuci7)
Test kms_flip:
Subgroup basic-flip-vs-dpms:
pass   -> DMESG-WARN (ilk-hp8440p) UNSTABLE
Subgroup basic-flip-vs-wf_vblank:
fail   -> PASS   (byt-nuc)
Test kms_force_connector_basic:
Subgroup force-edid:
incomplete -> SKIP   (bdw-nuci7)
Subgroup force-load-detect:
incomplete -> SKIP   (bdw-nuci7)
Test kms_pipe_crc_basic:
Subgroup nonblocking-crc-pipe-a:
incomplete -> PASS   (bdw-nuci7)
Subgroup nonblocking-crc-pipe-b:
incomplete -> PASS   (bdw-nuci7)
Subgroup read-crc-pipe-c-frame-sequence:
incomplete -> PASS   (bdw-nuci7)
Test kms_setmode:
Subgroup basic-clone-single-crtc:
incomplete -> PASS   (bdw-nuci7)
Test kms_sink_crc_basic:
incomplete -> SKIP   (bdw-nuci7)
Test pm_rpm:
Subgroup basic-rte:
incomplete -> PASS   (bdw-nuci7)

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:131  dwarn:1   dfail:0   fail:0   skip:64 
ivb-t430stotal:196  pass:171  dwarn:0   dfail:0   fail:0   skip:25 

Re: [Intel-gfx] [PATCH i-g-t] tools/intel_reg: Fix builtin register spec for gen4

2016-04-05 Thread Matthew Auld
Reviewed-by: Matthew Auld 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] [PATCH i-g-t] tools/intel_reg: Fix builtin register spec for gen4

2016-04-05 Thread ville . syrjala
From: Ville Syrjälä 

Actually use the builtin register spec on gen4. Makes intel_reg dump
actually do something on gen4.

Signed-off-by: Ville Syrjälä 
---
 tools/intel_reg_decode.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/intel_reg_decode.c b/tools/intel_reg_decode.c
index bb8f5b30311f..470fecc165c6 100644
--- a/tools/intel_reg_decode.c
+++ b/tools/intel_reg_decode.c
@@ -2580,7 +2580,7 @@ static bool is_945gm(uint32_t devid, uint32_t pch)
 
 static bool is_gen234(uint32_t devid, uint32_t pch)
 {
-   return IS_GEN2(devid) || IS_GEN3(devid) || IS_GEN3(devid);
+   return IS_GEN2(devid) || IS_GEN3(devid) || IS_GEN4(devid);
 }
 
 #define DECLARE_REGS(d,r,m)\
-- 
2.7.4

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


  1   2   >