date:20151208

Re: [Intel-gfx] [PATCH 3/3] drm/tegra: Use __drm_atomic_helper_reset_connector for subclassing connector state.

2015-12-08 Thread Maarten Lankhorst

Op 07-12-15 om 11:02 schreef Thierry Reding:
> On Tue, Nov 24, 2015 at 02:35:34PM +0100, Maarten Lankhorst wrote:
>> Signed-off-by: Maarten Lankhorst 
>> ---
>>  drivers/gpu/drm/tegra/dsi.c | 9 +++--
>>  1 file changed, 3 insertions(+), 6 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/tegra/dsi.c b/drivers/gpu/drm/tegra/dsi.c
>> index f0a138ef68ce..33ad50487f2e 100644
>> --- a/drivers/gpu/drm/tegra/dsi.c
>> +++ b/drivers/gpu/drm/tegra/dsi.c
>> @@ -745,14 +745,11 @@ static void tegra_dsi_soft_reset(struct tegra_dsi *dsi)
>>  
>>  static void tegra_dsi_connector_reset(struct drm_connector *connector)
>>  {
>> -struct tegra_dsi_state *state;
>> +struct tegra_dsi_state *state =
>> +kzalloc(sizeof(*state), GFP_KERNEL);
> I think this could use a check just for safety. It's unlikely to ever
> happen, but just in case, better allow to fail gracefully than crash.

I didn't bother because drm_atomic_helper_connector_reset has the same kind of 
failure.

~Maarten

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

Re: [Intel-gfx] [PATCH 1/2] drm/i915/skl: Disable coarse power gating up until F0

2015-12-08 Thread Kamble, Sagar A


Reviewed-by: Sagar Arun Kamble 

On 12/7/2015 9:59 PM, Mika Kuoppala wrote:

There is conflicting info between E0 and F0 steppings
for this workarounds. Trust more authoritative source and
be conservative and extend also for F0.

This prevents numerous (>50) gpu hangs with SKL GT4e
during piglit run.

References: HSD: gen9lp/2134184
Cc: Sagar Arun Kamble 
Signed-off-by: Mika Kuoppala 
---
  drivers/gpu/drm/i915/intel_pm.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index ee05ce8..7096c06 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -4717,7 +4717,7 @@ static void gen9_enable_rc6(struct drm_device *dev)
 */
if (IS_BXT_REVID(dev, 0, BXT_REVID_A1) ||
((IS_SKL_GT3(dev) || IS_SKL_GT4(dev)) &&
-IS_SKL_REVID(dev, 0, SKL_REVID_E0)))
+IS_SKL_REVID(dev, 0, SKL_REVID_F0)))
I915_WRITE(GEN9_PG_ENABLE, 0);
else
I915_WRITE(GEN9_PG_ENABLE, (rc6_mask & GEN6_RC_CTL_RC6_ENABLE) ?


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

Re: [Intel-gfx] [PATCH 1/5] [RFC] drm: Documentation style guide

2015-12-08 Thread Pierre Moreau

Hello Daniel,

Just some typo comments below.

On 09:49 AM - Dec 08 2015, Daniel Vetter wrote:
> Every time I type or review docs this seems a bit different. Try to
> document the common style so we can try to unify at least new docs.
> 
> Signed-off-by: Daniel Vetter 
> ---
>  Documentation/DocBook/gpu.tmpl | 37 +
>  1 file changed, 37 insertions(+)
> 
> diff --git a/Documentation/DocBook/gpu.tmpl b/Documentation/DocBook/gpu.tmpl
> index 86e5b12a49ba..5698c93dae8b 100644
> --- a/Documentation/DocBook/gpu.tmpl
> +++ b/Documentation/DocBook/gpu.tmpl
> @@ -124,6 +124,43 @@
>  
>[Insert diagram of typical DRM stack here]
>  
> +  
> +Style Guidelines
> +
> +  For consistency these documentations use American English. 
> Abbreviations
> +  are written as all-uppercase, for example: DRM, KMS, IOCTL, CRTC, and 
> so
> +  on. To aid in reading documentations make full use of the markup
> +  characters kerneldoc provides: @parameter for function paramters, 
> @member

paramters -> parameters

> +  for structure members, structure to refernce structures and

refernce -> reference

> +  function() for functions. These all get automatically hyperlinked if
> +  kerneldoc for the referencec objects exists When referencing entries in

referencec -> referenced, missing '.' after exists

> +  function vtables please use -vfunc(). Note that with kerneldoc does

Isn't "with" too much here? "Note that kerneldoc does not […]"?

> +  not support referncing struct members directly, so please add a 
> reference

referncing -> referencing

> +  to the vtable struct somewhere in the same paragraph or at least 
> section.
> +
> +
> +  Except in special situations (to separate locked from unlocked 
> variants)
> +  locking requirements for functions aren't documented in the kerneldoc.
> +  Instead locking should be check at runtime using e.g.
> +  WARN_ON(!mutex_is_locked(...));. Since it's much easier to
> +  ignore documentation than runtime noise this provides more value. And 
> on
> +  top of that runtime checks do need to be updated when the locking rules
> +  change, increasing the changes that they're correct. Within the
> +  documentation the locking rules should be explained in the relevant
> +  structures: Either in the comment for the lock explaining what it
> +  protects, or data fields need a note about which lock protects them, or
> +  both.
> +
> +
> +  Functions which have a non-void return value should have a
> +  section called "Returns" explaining the expected return values in
> +  different cases an their meanings. Currently there's no consensus 
> whether
> +  that section name should be all upper-case or not, and whether it 
> should
> +  end in a colon or not. Go with the file-local style. Other common 
> section
> +  names are "Notes" with information for dangerous or tricky corner 
> cases,
> +  and "FIXME" where the interface could be cleaned up.

Why not define (and use) a single style for naming all sections? Old
documentation might not use it, but it should be doable to upgrade those old
documents.

Pierre


> +
> +  
>
>  
>
> -- 
> 2.5.1
> 
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: Restore waitboost credit to the synchronous waiter

2015-12-08 Thread Eero Tamminen


Hi,

On 12/07/2015 07:38 PM, Jesse Barnes wrote:
[...]

Still wishing we had a good way to benchmark these types of changes
across a range of workloads.  Eero, have you guys looked at turbo stuff
at all yet?


Except for this, not really:
https://jira01.devtools.intel.com/browse/LCK-2271

To make results comparable other platforms, I'm using sustained 
performance numbers by discarding results for first round(s) that were 
run with turbo.


For some of performance tracks, we've also planned to disable power 
management completely (e.g. by using fixed freqs for CPU & GPU) because 
it causes way too much variance to performance results (more between 
runs, than within single run).



- Eero


Also, is the boost logic only documented in misc commit messages?  Or do
we have a nice block of text somewhere describing the intent (which may
not match our implementation!) and how we try to achieve it?

Those are both new requests though, so no need to block this patch:
Reviewed-by: Jesse Barnes 


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

Re: [Intel-gfx] [PATCH 28/28] drm/atomic-helper: Reject legacy flips on a disabled pipe

2015-12-08 Thread Daniel Vetter

On Mon, Dec 07, 2015 at 03:33:00PM +, Daniel Stone wrote:
> Hi,
> 
> On 4 December 2015 at 08:46, Daniel Vetter  wrote:
> > +   /*
> > +* Reject event generation for when a CRTC is off and stays off. It
> > +* wouldn't be hard to implement this, but userspace has a track 
> > record
> > +* of happily burning through 100% cpu (or worse, crash) when the
> > +* display pipe is suspended. To avoid all that fun just reject 
> > updates
> > +* that ask for events since likely that indicates a bug in the
> > +* compositors drawing loop. This is consistent with the vblank 
> > ioctl
> > +* which also rejects service on a disabled pipe.
> > +*/
> 
> Sorry to keep whingeing, but this isn't actually related to event
> generation. To the best of my knowledge, this change does a few
> things. Firstly, comments the check above (enforcing that (flags &
> ALLOW_MODESET) == {crtcs}->allow_modeset), which is good. But the
> comment is incorrect, because whether or not an event is requested is
> wholly unrelated. Secondly, it disables allow_modeset on pageflip,
> which shouldn't be changing DPMS stage (good!). Thirdly, it enforces
> something like the above statement on pageflips, except again it has
> no regard to events: it just enforces the no-DPMS-on-flip rule, for
> which event generation is a subset.

Well the comment is completely misplace, I wanted to put it next to the
check for event generation, not here.

> If you fix the above comment to more accurately note that this just
> enforces that you need the ALLOW_MODESET flag to change active, mode
> or connector routing, and (as Thierry asked), add a comment below to
> note that we enforce existing no-DPMS-on-flip semantics in the helper,
> then you're welcome to my R-b. But please don't mention events in the
> new comment. :)

Hm, I didn't really want to type a comment for ALLOW_MODESET - imo it's
pretty clear what it does and why it's useful. I'll try again at making
something coheren here ;-)
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 5/5] drm/tda998x: Remove dummy save/restore funcs

2015-12-08 Thread Emil Velikov

On 8 December 2015 at 08:49, Daniel Vetter  wrote:
> In my quest to remove all the drm_encoder_helper_funcs->save/restore
> hooks I somehow missed that this driver has a dummy set too - I
> thought all the i2c drivers only set up the slave_encoder save/restore
> hooks, which I've left. Remove them.
>
There was an identical patch from Rodrigo a couple of days ago

http://lists.freedesktop.org/archives/dri-devel/2015-December/096492.html

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

Re: [Intel-gfx] [PATCH] Revert "drm/i915: skip modeset if compatible for everyone."

2015-12-08 Thread Maarten Lankhorst

Op 19-11-15 om 10:05 schreef Jani Nikula:
> On Thu, 19 Nov 2015, Jani Nikula  wrote:
>> This reverts
>>
>> commit 6764e9f8724f1231b4deac53b9a82286ac0830e7
>> Author: Maarten Lankhorst 
>> Date:   Thu Aug 27 15:44:06 2015 +0200
>>
>> drm/i915: skip modeset if compatible for everyone.
>>
>> Bring back the i915.fastboot module parameter, disabled by default, due
>> to backlight regression on Chromebook Pixel 2015.
>>
>> Apparently the firmware of the Chromebook in question enables the panel
>> but disables backlight to avoid a brief garbage scanout upon loading the
>> kernel/module. With fastboot, we leave the backlight untouched, in this
>> case disabled. The user would have to do a modeset (i.e. not just crank
>> up the brightness) to enable the backlight.
>>
>> There is no clean fix readily available, so get back to the drawing
>> board by reverting.
>>
>> [N.B. The reference below is for when the thread was included on public
>> lists, and some of the context had already been dropped by then.]
>>
>> Reported-and-tested-by: Olof Johansson 
>> Cc: Maarten Lankhorst 
>> Cc: Daniel Vetter 
>> References: 
>> http://marc.info/?i=CAKMK7uES7xk05ki92oeX6gmvZWAh9f2vL7yz=6t+fgk9j3x...@mail.gmail.com
>> Fixes: 6764e9f8724f ("drm/i915: skip modeset if compatible for everyone.")
>> Signed-off-by: Jani Nikula 
> Pushed to drm-intel-fixes with IRC acks from Daniel and Maarten (*). I
> took the liberty of adding Tested-by from Olof, as he reported reverting
> the bad commit fixes the issue for him, and it's a clean revert.
>
I want to enable fast modeset again in the future, but that depends on 
chromebook pixel being fixed.
How do you want to handle fixing up the backlight on this machine?
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH i-g-t] lib/pm_workarounds: Lib for PM workarounds

2015-12-08 Thread David Weinehall

Move workarounds for power management related issues in external
components into a separate library, and modify the users of such
workarounds accordingly.  This currently involves HD audio and
SATA link power management.  For SATA link PM there's also code to
save the previous settings, to allow for resetting the values after
we've finished testing.

Signed-off-by: David Weinehall 
---
 lib/Makefile.sources |   2 +
 lib/igt.h|   1 +
 lib/igt_aux.c|  15 +---
 lib/pm_workarounds.c | 233 +++
 lib/pm_workarounds.h |  31 +++
 tests/pm_lpsp.c  |  25 +-
 tests/pm_rpm.c   |  29 ++-
 7 files changed, 279 insertions(+), 57 deletions(-)
 create mode 100644 lib/pm_workarounds.c
 create mode 100644 lib/pm_workarounds.h

diff --git a/lib/Makefile.sources b/lib/Makefile.sources
index cb20f030cbec..25f67edbd19a 100644
--- a/lib/Makefile.sources
+++ b/lib/Makefile.sources
@@ -59,6 +59,8 @@ libintel_tools_la_SOURCES =   \
igt_core.h  \
igt_draw.c  \
igt_draw.h  \
+   pm_workarounds.c\
+   pm_workarounds.h\
$(NULL)
 
 .PHONY: version.h.tmp
diff --git a/lib/igt.h b/lib/igt.h
index 3be25511bb77..bb1c199bbbec 100644
--- a/lib/igt.h
+++ b/lib/igt.h
@@ -44,5 +44,6 @@
 #include "media_fill.h"
 #include "media_spin.h"
 #include "rendercopy.h"
+#include "pm_workarounds.h"
 
 #endif /* IGT_H */
diff --git a/lib/igt_aux.c b/lib/igt_aux.c
index 4d08d68bb932..da9770ec88ea 100644
--- a/lib/igt_aux.c
+++ b/lib/igt_aux.c
@@ -59,6 +59,7 @@
 #include "intel_reg.h"
 #include "ioctl_wrappers.h"
 #include "igt_kms.h"
+#include "pm_workarounds.h"
 
 /**
  * SECTION:igt_aux
@@ -531,19 +532,7 @@ bool igt_setup_runtime_pm(void)
if (pm_status_fd >= 0)
return true;
 
-   /* The Audio driver can get runtime PM references, so we need to make
-* sure its runtime PM is enabled, so it can release the refs and
-* actually enable us to runtime suspend. */
-   fd = open("/sys/module/snd_hda_intel/parameters/power_save", O_WRONLY);
-   if (fd >= 0) {
-   igt_assert(write(fd, "1\n", 2) == 2);
-   close(fd);
-   }
-   fd = open("/sys/bus/pci/devices/:00:03.0/power/control", O_WRONLY);
-   if (fd >= 0) {
-   igt_assert(write(fd, "auto\n", 5) == 5);
-   close(fd);
-   }
+   enable_audio_runtime_pm();
 
/* Our implementation uses autosuspend. Try to set it to 0ms so the test
 * suite goes faster and we have a higher probability of triggering race
diff --git a/lib/pm_workarounds.c b/lib/pm_workarounds.c
new file mode 100644
index ..ae9da4fad910
--- /dev/null
+++ b/lib/pm_workarounds.c
@@ -0,0 +1,233 @@
+/*
+ * Copyright © 2013, 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.
+ *
+ * Authors:
+ *Paulo Zanoni 
+ *David Weinehall 
+ *
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "drmtest.h"
+#include "pm_workarounds.h"
+
+enum {
+   POLICY_UNKNOWN = -1,
+   POLICY_MAX_PERFORMANCE = 0,
+   POLICY_MEDIUM_POWER = 1,
+   POLICY_MIN_POWER = 2
+};
+
+#define MAX_PERFORMANCE_STR"max_performance\n"
+#define MEDIUM_POWER_STR   "medium_power\n"
+#define MIN_POWER_STR  "min_power\n"
+/* Remember to fix this if adding longer strings */
+#define MAX_POLICY_STRLEN  strlen(MAX_PERFORMANCE_STR)
+
+/**
+ * SECTION:pm_workarounds
+ * @short_description: Workarounds for PM issues in external components
+ * @title: PM Workarounds
+ * @include: igt.h
+ *
+ * This library provides various helpers that will workaround,
+ * and in some cases subsequently allow restoring of the old behaviour of,
+ *

Re: [Intel-gfx] [PATCH V4 2/2] drm/i915: start adding dp mst audio

2015-12-08 Thread Libin Yang


Hi all,

Any comments on the patches?

Best Regards,
Libin

On 12/02/2015 02:09 PM, libin.y...@linux.intel.com wrote:

From: Libin Yang 

This patch adds support for DP MST audio in i915.

Enable audio codec when DP MST is enabled if has_audio flag is set.
Disable audio codec when DP MST is disabled if has_audio flag is set.

Another separated patches to support DP MST audio will be implemented
in audio driver.

Reviewed-by: Ander Conselvan de Oliveira 
Signed-off-by: Libin Yang 
Signed-off-by: Dave Airlie 
---
  drivers/gpu/drm/i915/i915_debugfs.c | 16 
  drivers/gpu/drm/i915/intel_audio.c  |  9 ++---
  drivers/gpu/drm/i915/intel_ddi.c| 20 +++-
  drivers/gpu/drm/i915/intel_dp_mst.c | 22 ++
  drivers/gpu/drm/i915/intel_drv.h|  2 ++
  5 files changed, 61 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index bfd57fb..8387638 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -2850,6 +2850,20 @@ static void intel_dp_info(struct seq_file *m,
intel_panel_info(m, _connector->panel);
  }

+static void intel_dp_mst_info(struct seq_file *m,
+ struct intel_connector *intel_connector)
+{
+   struct intel_encoder *intel_encoder = intel_connector->encoder;
+   struct intel_dp_mst_encoder *intel_mst =
+   enc_to_mst(_encoder->base);
+   struct intel_digital_port *intel_dig_port = intel_mst->primary;
+   struct intel_dp *intel_dp = _dig_port->dp;
+   bool has_audio = drm_dp_mst_port_has_audio(_dp->mst_mgr,
+   intel_connector->port);
+
+   seq_printf(m, "\taudio support: %s\n", yesno(has_audio));
+}
+
  static void intel_hdmi_info(struct seq_file *m,
struct intel_connector *intel_connector)
  {
@@ -2893,6 +2907,8 @@ static void intel_connector_info(struct seq_file *m,
intel_hdmi_info(m, intel_connector);
else if (intel_encoder->type == INTEL_OUTPUT_LVDS)
intel_lvds_info(m, intel_connector);
+   else if (intel_encoder->type == INTEL_OUTPUT_DP_MST)
+   intel_dp_mst_info(m, intel_connector);
}

seq_printf(m, "\tmodes:\n");
diff --git a/drivers/gpu/drm/i915/intel_audio.c 
b/drivers/gpu/drm/i915/intel_audio.c
index 9aa83e7..5ad2e66 100644
--- a/drivers/gpu/drm/i915/intel_audio.c
+++ b/drivers/gpu/drm/i915/intel_audio.c
@@ -262,7 +262,8 @@ static void hsw_audio_codec_disable(struct intel_encoder 
*encoder)
tmp |= AUD_CONFIG_N_PROG_ENABLE;
tmp &= ~AUD_CONFIG_UPPER_N_MASK;
tmp &= ~AUD_CONFIG_LOWER_N_MASK;
-   if (intel_pipe_has_type(intel_crtc, INTEL_OUTPUT_DISPLAYPORT))
+   if (intel_pipe_has_type(intel_crtc, INTEL_OUTPUT_DISPLAYPORT) ||
+   intel_pipe_has_type(intel_crtc, INTEL_OUTPUT_DP_MST))
tmp |= AUD_CONFIG_N_VALUE_INDEX;
I915_WRITE(HSW_AUD_CFG(pipe), tmp);

@@ -474,7 +475,8 @@ static void ilk_audio_codec_enable(struct drm_connector 
*connector,
tmp &= ~AUD_CONFIG_N_VALUE_INDEX;
tmp &= ~AUD_CONFIG_N_PROG_ENABLE;
tmp &= ~AUD_CONFIG_PIXEL_CLOCK_HDMI_MASK;
-   if (intel_pipe_has_type(intel_crtc, INTEL_OUTPUT_DISPLAYPORT))
+   if (intel_pipe_has_type(intel_crtc, INTEL_OUTPUT_DISPLAYPORT) ||
+   intel_pipe_has_type(intel_crtc, INTEL_OUTPUT_DP_MST))
tmp |= AUD_CONFIG_N_VALUE_INDEX;
else
tmp |= audio_config_hdmi_pixel_clock(adjusted_mode);
@@ -512,7 +514,8 @@ void intel_audio_codec_enable(struct intel_encoder 
*intel_encoder)

/* ELD Conn_Type */
connector->eld[5] &= ~(3 << 2);
-   if (intel_pipe_has_type(crtc, INTEL_OUTPUT_DISPLAYPORT))
+   if (intel_pipe_has_type(crtc, INTEL_OUTPUT_DISPLAYPORT) ||
+   intel_pipe_has_type(crtc, INTEL_OUTPUT_DP_MST))
connector->eld[5] |= (1 << 2);

connector->eld[6] = drm_av_sync_delay(connector, adjusted_mode) / 2;
diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index 76ce7c2..bc7fffb 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -3108,6 +3108,19 @@ void intel_ddi_fdi_disable(struct drm_crtc *crtc)
I915_WRITE(FDI_RX_CTL(PIPE_A), val);
  }

+bool intel_ddi_is_audio_enabled(struct drm_i915_private *dev_priv,
+struct intel_crtc *intel_crtc)
+{
+   u32 temp;
+
+   if (intel_display_power_is_enabled(dev_priv, POWER_DOMAIN_AUDIO)) {
+   temp = I915_READ(HSW_AUD_PIN_ELD_CP_VLD);
+   if (temp & AUDIO_OUTPUT_ENABLE(intel_crtc->pipe))
+   return true;
+   }
+   return false;
+}
+
  void intel_ddi_get_config(struct

[Intel-gfx] [maintainer-tools PATCH] drm-intel: embed wavedrom engine and skin into the web page

2015-12-08 Thread Jani Nikula

The wavedrom timeline will be missing from html pages served over https
due to "mixed active content" blocking [1], because the wavedrom engine
and skin are only available over http. Embed the engine and skin into
the resulting html to avoid the problem.

The rst :url: will fetch and include the scripts at html build time.

[1] https://developer.mozilla.org/en-US/docs/Security/MixedContent

Signed-off-by: Jani Nikula 
---
 drm-intel-timeline.rst | 21 +
 drm-intel.rst  |  1 -
 2 files changed, 17 insertions(+), 5 deletions(-)

diff --git a/drm-intel-timeline.rst b/drm-intel-timeline.rst
index 0d78046736b2..e1766a5df98b 100644
--- a/drm-intel-timeline.rst
+++ b/drm-intel-timeline.rst
@@ -1,10 +1,23 @@
-.. This is a wrapper intended to both keep the master document clean of the raw
-.. html script stuff and to keep the wavedrom source pure json.
+.. raw:: html
+
+   
+   /* Embedded WaveDrom skin from http://wavedrom.com/skins/default.js */
+
+.. raw:: html
+   :url: http://wavedrom.com/skins/default.js
 
 .. raw:: html
 
-