[Bug 95911] Recursive error in radeon device driver module after resume from hibernation

[bugzilla-dae...@bugzilla.kernel.org]

https://bugzilla.kernel.org/show_bug.cgi?id=95911

--- Comment #18 from gitne at excite.co.jp ---
Just FYI:
I have just tested kernel version 4.0.8. Unfortunately, the problem still
persists. Additionally, since kernel version 3.15.7 the machine does not power
down after swapping the hibernation data to disk.

While trying to resolve this problem perhaps via a workaround, I have tried
forcing the kernel to use BIOS routines where possible, just to rule out the
possibility of any hardware bugs that may have been worked around in the BIOS.
This did not improve the situation either. So, I still assume that the radeon
device driver is or can be put into invalid state from user space.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 80419] XCOM: Enemy Unknown Causes lockup

[bugzilla-dae...@freedesktop.org]

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

--- Comment #54 from Daniel Exner <dex+fdobugzilla at dragonslave.de> ---
I'am sorry to inform you that I still see this bug.

Radeon R270X
Mesa 11.0.0-devel git-5f247a9
xf86-video-ati git-09c7cdb
llvm svn-243977

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150804/c6123a50/attachment.html>

[PATCH 11/11] drm/exynos: remove struct exynos_drm_encoder layer

[Inki Dae]

On 2015년 08월 04일 04:09, Gustavo Padovan wrote:
> From: Gustavo Padovan 
> 
> struct exynos_drm_encoder was justing wrapping struct drm_encoder, it had
> only a drm_encoder member and the internal exynos_drm_encoders ops that
> was directly mapped to the drm_encoder helper funcs.
> 
> So now exynos DRM uses struct drm_encoder directly, this removes
> completely the struct exynos_drm_encoder.
> 
> Signed-off-by: Gustavo Padovan 
> ---
>  drivers/gpu/drm/exynos/Makefile |   7 +-
>  drivers/gpu/drm/exynos/exynos7_drm_decon.c  |   2 +-
>  drivers/gpu/drm/exynos/exynos_dp_core.c |  68 --
>  drivers/gpu/drm/exynos/exynos_dp_core.h |   2 +-
>  drivers/gpu/drm/exynos/exynos_drm_core.c|   1 -
>  drivers/gpu/drm/exynos/exynos_drm_crtc.c|   1 -
>  drivers/gpu/drm/exynos/exynos_drm_dpi.c |  51 --
>  drivers/gpu/drm/exynos/exynos_drm_drv.c |   1 -
>  drivers/gpu/drm/exynos/exynos_drm_drv.h |  47 ++---
>  drivers/gpu/drm/exynos/exynos_drm_dsi.c |  80 +++--
>  drivers/gpu/drm/exynos/exynos_drm_encoder.c | 105 
> 
>  drivers/gpu/drm/exynos/exynos_drm_encoder.h |  22 --
>  drivers/gpu/drm/exynos/exynos_drm_fimd.c|   2 +-
>  drivers/gpu/drm/exynos/exynos_drm_vidi.c|  71 ++-
>  drivers/gpu/drm/exynos/exynos_hdmi.c|  85 +-
>  15 files changed, 236 insertions(+), 309 deletions(-)
>  delete mode 100644 drivers/gpu/drm/exynos/exynos_drm_encoder.c
>  delete mode 100644 drivers/gpu/drm/exynos/exynos_drm_encoder.h

[-- SNIP --]

> diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c 
> b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
> index d791ad4..a87d030 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
> @@ -30,7 +30,6 @@
>  #include 
>  
>  #include "exynos_drm_crtc.h"
> -#include "exynos_drm_encoder.h"
>  #include "exynos_drm_drv.h"
>  
>  /* returns true iff both arguments logically differs */
> @@ -260,7 +259,7 @@ struct exynos_dsi_driver_data {
>  };
>  
>  struct exynos_dsi {
> - struct exynos_drm_encoder encoder;
> + struct drm_encoder encoder;
>   struct mipi_dsi_host dsi_host;
>   struct drm_connector connector;
>   struct device_node *panel_node;
> @@ -296,7 +295,7 @@ struct exynos_dsi {
>  #define host_to_dsi(host) container_of(host, struct exynos_dsi, dsi_host)
>  #define connector_to_dsi(c) container_of(c, struct exynos_dsi, connector)
>  
> -static inline struct exynos_dsi *encoder_to_dsi(struct exynos_drm_encoder *e)
> +static inline struct exynos_dsi *encoder_to_dsi(struct drm_encoder *e)
>  {
>   return container_of(e, struct exynos_dsi, encoder);
>  }
> @@ -1273,7 +1272,7 @@ static irqreturn_t exynos_dsi_irq(int irq, void *dev_id)
>  static irqreturn_t exynos_dsi_te_irq_handler(int irq, void *dev_id)
>  {
>   struct exynos_dsi *dsi = (struct exynos_dsi *)dev_id;
> - struct drm_encoder *encoder = >encoder.base;
> + struct drm_encoder *encoder = >encoder;
>  
>   if (dsi->state & DSIM_STATE_VIDOUT_AVAILABLE)
>   exynos_drm_crtc_te_handler(encoder->crtc);
> @@ -1519,7 +1518,7 @@ static void exynos_dsi_poweroff(struct exynos_dsi *dsi)
>   dev_err(dsi->dev, "cannot disable regulators %d\n", ret);
>  }
>  
> -static void exynos_dsi_enable(struct exynos_drm_encoder *encoder)
> +static void exynos_dsi_enable(struct drm_encoder *encoder)
>  {
>   struct exynos_dsi *dsi = encoder_to_dsi(encoder);
>   int ret;
> @@ -1555,7 +1554,7 @@ static void exynos_dsi_enable(struct exynos_drm_encoder 
> *encoder)
>   dsi->state |= DSIM_STATE_VIDOUT_AVAILABLE;
>  }
>  
> -static void exynos_dsi_disable(struct exynos_drm_encoder *encoder)
> +static void exynos_dsi_disable(struct drm_encoder *encoder)
>  {
>   struct exynos_dsi *dsi = encoder_to_dsi(encoder);
>  
> @@ -1583,7 +1582,7 @@ exynos_dsi_detect(struct drm_connector *connector, bool 
> force)
>   if (dsi->panel)
>   drm_panel_attach(dsi->panel, >connector);
>   } else if (!dsi->panel_node) {
> - struct exynos_drm_encoder *encoder;
> + struct drm_encoder *encoder;
>  
>   encoder = platform_get_drvdata(to_platform_device(dsi->dev));
>   exynos_dsi_disable(encoder);
> @@ -1629,7 +1628,7 @@ exynos_dsi_best_encoder(struct drm_connector *connector)
>  {
>   struct exynos_dsi *dsi = connector_to_dsi(connector);
>  
> - return >encoder.base;
> + return >encoder;
>  }
>  
>  static struct drm_connector_helper_funcs exynos_dsi_connector_helper_funcs = 
> {
> @@ -1637,11 +1636,9 @@ static struct drm_connector_helper_funcs 
> exynos_dsi_connector_helper_funcs = {
>   .best_encoder = exynos_dsi_best_encoder,
>  };
>  
> -static int exynos_dsi_create_connector(
> - struct exynos_drm_encoder *exynos_encoder)
> +static int exynos_dsi_create_connector(struct 

[PATCH 09/11] drm/exynos: remove exynos_drm_create_enc_conn()

[Inki Dae]

On 2015년 08월 04일 04:09, Gustavo Padovan wrote:
> From: Gustavo Padovan 
> 
> This functions was just hiding the encoder and connector creation in
> a way that was less clean than if we get rid of it. For example,
> exynos_encoder ops had .create_connector() defined only because we were
> handing off the encoder and connector creation to
> exynos_drm_create_enc_conn(). Without this function we can directly call
> the create_connector function internally in the code, without the need of
> any vtable access.
> 
> It also does some refactoring in the code like creating a bind function
> for dpi devices.
> 
> Signed-off-by: Gustavo Padovan 
> ---
>  drivers/gpu/drm/exynos/exynos7_drm_decon.c  |  3 +--
>  drivers/gpu/drm/exynos/exynos_dp_core.c | 20 ---
>  drivers/gpu/drm/exynos/exynos_drm_core.c| 30 
> -
>  drivers/gpu/drm/exynos/exynos_drm_dpi.c | 26 +++--
>  drivers/gpu/drm/exynos/exynos_drm_drv.h | 12 ++--
>  drivers/gpu/drm/exynos/exynos_drm_dsi.c | 20 ---
>  drivers/gpu/drm/exynos/exynos_drm_encoder.c | 11 +++
>  drivers/gpu/drm/exynos/exynos_drm_encoder.h |  4 +++-
>  drivers/gpu/drm/exynos/exynos_drm_fimd.c|  3 +--
>  drivers/gpu/drm/exynos/exynos_drm_vidi.c| 20 ++-
>  drivers/gpu/drm/exynos/exynos_hdmi.c| 21 +---
>  11 files changed, 101 insertions(+), 69 deletions(-)
> 

[-- SNIP --]

> diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c 
> b/drivers/gpu/drm/exynos/exynos_hdmi.c
> index 11bac50..f72ceeb 100644
> --- a/drivers/gpu/drm/exynos/exynos_hdmi.c
> +++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
> @@ -44,6 +44,7 @@
>  
>  #include "exynos_drm_drv.h"
>  #include "exynos_drm_crtc.h"
> +#include "exynos_drm_encoder.h"
>  #include "exynos_mixer.h"
>  
>  #include 
> @@ -1783,7 +1784,6 @@ static void hdmi_disable(struct exynos_drm_encoder 
> *encoder)
>  }
>  
>  static struct exynos_drm_encoder_ops hdmi_encoder_ops = {
> - .create_connector = hdmi_create_connector,
>   .mode_fixup = hdmi_mode_fixup,
>   .mode_set   = hdmi_mode_set,
>   .enable = hdmi_enable,
> @@ -1917,11 +1917,26 @@ static int hdmi_bind(struct device *dev, struct 
> device *master, void *data)
>  {
>   struct drm_device *drm_dev = data;
>   struct hdmi_context *hdata = dev_get_drvdata(dev);
> + struct exynos_drm_encoder *exynos_encoder = >encoder;
> + int ret;
>  
>   hdata->drm_dev = drm_dev;
>  
> - return exynos_drm_create_enc_conn(drm_dev, >encoder,
> -   EXYNOS_DISPLAY_TYPE_HDMI);
> + ret = exynos_drm_encoder_create(drm_dev, exynos_encoder,
> + EXYNOS_DISPLAY_TYPE_HDMI);
> + if (ret) {
> + DRM_ERROR("failed to create encoder\n");
> + return ret;
> + }
> +
> + hdmi_create_connector(exynos_encoder);

ret = hdmi_create_connector(exynos_encoder);

> + if (ret) {
> + DRM_ERROR("failed to create connector ret = %d\n", ret);
> + drm_encoder_cleanup(_encoder->base);
> + return ret;
> + }
> +
> + return 0;
>  }
>  
>  static void hdmi_unbind(struct device *dev, struct device *master, void 
> *data)
> 

[Intel-gfx] [PATCH 1/2] drm/i915: Use CPU mapping for userspace dma-buf mmap()

[Tiago Vignatti]

On 07/31/2015 06:02 PM, Chris Wilson wrote:
>
> The first problem is that llc does not guarrantee that the buffer is
> cache coherent with all aspects of the GPU. For scanout and similar
> writes need to be WC.
>
> if (obj->has_framebuffer_references) would at least catch where the fb
> is made before the mmap.
>
> Equally this buffer could then be shared with other devices and exposing
> a CPU mmap to userspace (and no flush/set-domain protocol) will result in
> corruption.

I've built an igt test to catch this corruption but it's not really 
falling there in my IvyBridge. If what you described is right (and so 
what I coded) then this test should write in the mapped buffer but not 
update the screen.

Any idea what's going on?

https://github.com/tiagovignatti/intel-gpu-tools/commit/3e130ac2b274f1a3f6889c78cb72d0673ca2.patch


 From 3e130ac2b274f1a3f6889c78cb72d0673ca2 Mon Sep 17 00:00:00 2001
From: Tiago Vignatti 
Date: Tue, 4 Aug 2015 13:38:09 -0300
Subject: [PATCH] tests: Add prime_crc for cache coherency

This program can be used to detect when the writes don't land in 
scanout, due
cache incoherency.

Run it like ./prime_crc --interactive-debug=crc

Signed-off-by: Tiago Vignatti 
---
  tests/.gitignore   |   1 +
  tests/Makefile.sources |   1 +
  tests/prime_crc.c  | 201 
+
  3 files changed, 203 insertions(+)
  create mode 100644 tests/prime_crc.c

diff --git a/tests/.gitignore b/tests/.gitignore
index 5bc4a58..96dbf57 100644
--- a/tests/.gitignore
+++ b/tests/.gitignore
@@ -160,6 +160,7 @@ pm_rc6_residency
  pm_rpm
  pm_rps
  pm_sseu
+prime_crc
  prime_nv_api
  prime_nv_pcopy
  prime_nv_test
diff --git a/tests/Makefile.sources b/tests/Makefile.sources
index 5b2072e..c05b5a7 100644
--- a/tests/Makefile.sources
+++ b/tests/Makefile.sources
@@ -90,6 +90,7 @@ TESTS_progs_M = \
pm_rps \
pm_rc6_residency \
pm_sseu \
+   prime_crc \
prime_mmap \
prime_self_import \
template \
diff --git a/tests/prime_crc.c b/tests/prime_crc.c
new file mode 100644
index 000..3474cc9
--- /dev/null
+++ b/tests/prime_crc.c
@@ -0,0 +1,201 @@
+/*
+ * 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.
+ *
+ * Authors:
+ *Tiago Vignatti 
+ *
+ */
+
+/* This program can detect when the writes don't land in scanout, due cache
+ * incoherency. */
+
+#include "drmtest.h"
+#include "igt_debugfs.h"
+#include "igt_kms.h"
+
+#define MAX_CONNECTORS 32
+
+struct modeset_params {
+   uint32_t crtc_id;
+   uint32_t connector_id;
+   drmModeModeInfoPtr mode;
+};
+
+int drm_fd;
+drmModeResPtr drm_res;
+drmModeConnectorPtr drm_connectors[MAX_CONNECTORS];
+drm_intel_bufmgr *bufmgr;
+igt_pipe_crc_t *pipe_crc;
+
+struct modeset_params ms;
+
+static void find_modeset_params(void)
+{
+   int i;
+   uint32_t connector_id = 0, crtc_id;
+   drmModeModeInfoPtr mode = NULL;
+
+   for (i = 0; i < drm_res->count_connectors; i++) {
+   drmModeConnectorPtr c = drm_connectors[i];
+
+   if (c->count_modes) {
+   connector_id = c->connector_id;
+   mode = >modes[0];
+   break;
+   }
+   }
+   igt_require(connector_id);
+
+   crtc_id = drm_res->crtcs[0];
+   igt_assert(crtc_id);
+   igt_assert(mode);
+
+   ms.connector_id = connector_id;
+   ms.crtc_id = crtc_id;
+   ms.mode = mode;
+
+}
+
+#define BO_SIZE (16*1024)
+
+char pattern[] = {0xff, 0x00, 0x00, 0x00,
+   0x00, 0xff, 0x00, 0x00,
+   0x00, 0x00, 0xff, 0x00,
+   0x00, 0x00, 0x00, 0xff};
+
+static void mess_with_coherency(char *ptr)
+{
+   off_t i;
+
+   for (i = 0; i < BO_SIZE; i+=sizeof(pattern)) {
+   memcpy(ptr + i, pattern, sizeof(pattern));
+   }
+// 

[REGRESSION] Re: i915 driver crashes on T540p if docking station attached

[Daniel Vetter]

On Mon, Aug 03, 2015 at 12:25:11PM -0400, Theodore Ts'o wrote:
> On Mon, Aug 03, 2015 at 05:27:29PM +0200, Daniel Vetter wrote:
> > 
> > Ok I updated fixes-stuff with just 2 patches which seem to be enough to
> > fix it. Plus a patch to convert Linus' hack into something we can keep
> > plus a drive-by WARNING fix in mst that got in the way for me.
> > 
> > Seems to work here in getting rid of the Oops. If this tests out for you
> > too I'll send a pull to Linus.
> 
> I've just tried pulling in your updated fixes-stuff, and it avoids the
> oops and allows external the monitor to work correctly.  However, I'm
> still seeing a large number of drm/i915 related warning messages and
> other kernel kvetching.

Involved a bit of head-scratching since I'm not too familiar with the
watermark code and it gained a lot of complexity for atomic. But the below
patch should be able to fix this WARNING (and it looks like it was a
genuine one). If it works for you I'll bake it into a proper patch.

Thanks, Daniel

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 30e0f54ba19d..ae07fd0c395c 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -15121,6 +15121,11 @@ void intel_modeset_setup_hw_state(struct drm_device 
*dev,

intel_modeset_readout_hw_state(dev);

+   if (IS_GEN9(dev))
+   skl_wm_get_hw_state(dev);
+   else if (HAS_PCH_SPLIT(dev))
+   ilk_wm_get_hw_state(dev);
+
/*
 * Now that we have the config, copy it to each CRTC struct
 * Note that this could go away if we move to using crtc_config
@@ -15162,11 +15167,6 @@ void intel_modeset_setup_hw_state(struct drm_device 
*dev,
pll->on = false;
}

-   if (IS_GEN9(dev))
-   skl_wm_get_hw_state(dev);
-   else if (HAS_PCH_SPLIT(dev))
-   ilk_wm_get_hw_state(dev);
-
if (force_restore) {
i915_redisable_vga(dev);

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

[PULL] topic/mst-fixes

[Daniel Vetter]

Hi Linus,

Special pull request for mst fixes since most of the patches touch code
outside of i915 proper. DRM parts have also been reviewed by Thierry
(nvidia) since Dave's enjoying vacations.

Cheers, Daniel


The following changes since commit 74d33293e467df61de1b1d8b2fbe29e550dec33b:

  Linux 4.2-rc5 (2015-08-02 18:34:55 -0700)

are available in the git repository at:

  git://anongit.freedesktop.org/drm-intel tags/topic/mst-fixes-2015-08-04

for you to fetch changes up to 6ea76f3cade4734e73e3da842005820558b8b828:

  drm/atomic-helpers: Make encoder picking more robust (2015-08-04 11:10:41 
+0200)


Daniel Vetter (4):
  drm/atomic-helper: Add an atomice best_encoder callback
  drm/i915: Fixup dp mst encoder selection
  drm/dp-mst: Remove debug WARN_ON
  drm/atomic-helpers: Make encoder picking more robust

 drivers/gpu/drm/drm_atomic_helper.c   | 18 --
 drivers/gpu/drm/drm_dp_mst_topology.c |  1 -
 drivers/gpu/drm/i915/intel_dp_mst.c   | 11 +++
 include/drm/drm_crtc_helper.h |  3 +++
 4 files changed, 26 insertions(+), 7 deletions(-)

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

[PATCH 0/2] drm/fb-helper: Silence defined but not used warning

[Daniel Vetter]

On Tue, Aug 04, 2015 at 03:22:09PM +0200, Geert Uytterhoeven wrote:
> From: Geert Uytterhoeven 
> 
>   Hi,
> 
> If CONFIG_MAGIC_SYSRQ is not set:
> 
> drivers/gpu/drm/drm_fb_helper.c:390:13: warning: 
> 'drm_fb_helper_force_kernel_mode' defined but not used [-Wunused-function]
>  static bool drm_fb_helper_force_kernel_mode(void)
>^
> 
> As just silencing this warning would require moving two functions (one
> of them having obsolete documentation) inside the #ifdef, I fixed the
> documentation first.
> 
> This patch series is against next-20150803.
> 
> Geert Uytterhoeven (2):
>   drm/fb-helper: Clarify drm_fb_helper_restore_fbdev_mode*()
>   drm/fb-helper: Move drm_fb_helper_force_kernel_mode() inside #ifdef

Thanks, both applied to drm-misc.
-Daniel

> 
>  drivers/gpu/drm/drm_fb_helper.c | 71 
> -
>  1 file changed, 28 insertions(+), 43 deletions(-)
> 
> -- 
> 1.9.1
> 
> Gr{oetje,eeting}s,
> 
>   Geert
> 
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at 
> linux-m68k.org
> 
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like 
> that.
>   -- Linus Torvalds
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

[PATCH 2/2] drm/fb-helper: Move drm_fb_helper_force_kernel_mode() inside #ifdef

[Geert Uytterhoeven]

From: Geert Uytterhoeven 

If CONFIG_MAGIC_SYSRQ is not set:

drivers/gpu/drm/drm_fb_helper.c:390:13: warning: 
'drm_fb_helper_force_kernel_mode' defined but not used [-Wunused-function]
 static bool drm_fb_helper_force_kernel_mode(void)
 ^

Move drm_fb_helper_force_kernel_mode() inside the existing #ifdef to fix
this.

Signed-off-by: Geert Uytterhoeven 
---
 drivers/gpu/drm/drm_fb_helper.c | 50 -
 1 file changed, 25 insertions(+), 25 deletions(-)

diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index 7278c23ea98b9918..5875059a7625ed27 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -383,6 +383,31 @@ bool drm_fb_helper_restore_fbdev_mode_unlocked(struct 
drm_fb_helper *fb_helper)
 }
 EXPORT_SYMBOL(drm_fb_helper_restore_fbdev_mode_unlocked);

+static bool drm_fb_helper_is_bound(struct drm_fb_helper *fb_helper)
+{
+   struct drm_device *dev = fb_helper->dev;
+   struct drm_crtc *crtc;
+   int bound = 0, crtcs_bound = 0;
+
+   /* Sometimes user space wants everything disabled, so don't steal the
+* display if there's a master. */
+   if (dev->primary->master)
+   return false;
+
+   drm_for_each_crtc(crtc, dev) {
+   if (crtc->primary->fb)
+   crtcs_bound++;
+   if (crtc->primary->fb == fb_helper->fb)
+   bound++;
+   }
+
+   if (bound < crtcs_bound)
+   return false;
+
+   return true;
+}
+
+#ifdef CONFIG_MAGIC_SYSRQ
 /*
  * restore fbcon display for all kms driver's using this helper, used for sysrq
  * and panic handling.
@@ -410,31 +435,6 @@ static bool drm_fb_helper_force_kernel_mode(void)
return error;
 }

-static bool drm_fb_helper_is_bound(struct drm_fb_helper *fb_helper)
-{
-   struct drm_device *dev = fb_helper->dev;
-   struct drm_crtc *crtc;
-   int bound = 0, crtcs_bound = 0;
-
-   /* Sometimes user space wants everything disabled, so don't steal the
-* display if there's a master. */
-   if (dev->primary->master)
-   return false;
-
-   drm_for_each_crtc(crtc, dev) {
-   if (crtc->primary->fb)
-   crtcs_bound++;
-   if (crtc->primary->fb == fb_helper->fb)
-   bound++;
-   }
-
-   if (bound < crtcs_bound)
-   return false;
-
-   return true;
-}
-
-#ifdef CONFIG_MAGIC_SYSRQ
 static void drm_fb_helper_restore_work_fn(struct work_struct *ignored)
 {
bool ret;
-- 
1.9.1

[PATCH 1/2] drm/fb-helper: Clarify drm_fb_helper_restore_fbdev_mode*()

[Geert Uytterhoeven]

From: Geert Uytterhoeven 

As of commit 5ea1f752ae04be40 ("drm: add
drm_fb_helper_restore_fbdev_mode_unlocked()"),
drm_fb_helper_restore_fbdev_mode() is no longer public, and drivers
should call drm_fb_helper_restore_fbdev_mode_unlocked() from their
->lastclose callbacks instead.

Update the documentation to reflect this, and absorb the one liner
drm_fb_helper_restore_fbdev_mode() into its single caller.

Signed-off-by: Geert Uytterhoeven 
---
 drivers/gpu/drm/drm_fb_helper.c | 21 +++--
 1 file changed, 3 insertions(+), 18 deletions(-)

diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index e4bbb53096029718..7278c23ea98b9918 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -56,8 +56,8 @@ static LIST_HEAD(kernel_fb_helper_list);
  * Teardown is done with drm_fb_helper_fini().
  *
  * At runtime drivers should restore the fbdev console by calling
- * drm_fb_helper_restore_fbdev_mode() from their ->lastclose callback. They
- * should also notify the fb helper code from updates to the output
+ * drm_fb_helper_restore_fbdev_mode_unlocked() from their ->lastclose callback.
+ * They should also notify the fb helper code from updates to the output
  * configuration by calling drm_fb_helper_hotplug_event(). For easier
  * integration with the output polling code in drm_crtc_helper.c the modeset
  * code provides a ->output_poll_changed callback.
@@ -354,21 +354,6 @@ static bool restore_fbdev_mode(struct drm_fb_helper 
*fb_helper)
}
return error;
 }
-/**
- * drm_fb_helper_restore_fbdev_mode - restore fbdev configuration
- * @fb_helper: fbcon to restore
- *
- * This should be called from driver's drm ->lastclose callback
- * when implementing an fbcon on top of kms using this helper. This ensures 
that
- * the user isn't greeted with a black screen when e.g. X dies.
- *
- * Use this variant if you need to bypass locking (panic), or already
- * hold all modeset locks.  Otherwise use 
drm_fb_helper_restore_fbdev_mode_unlocked()
- */
-static bool drm_fb_helper_restore_fbdev_mode(struct drm_fb_helper *fb_helper)
-{
-   return restore_fbdev_mode(fb_helper);
-}

 /**
  * drm_fb_helper_restore_fbdev_mode_unlocked - restore fbdev configuration
@@ -417,7 +402,7 @@ static bool drm_fb_helper_force_kernel_mode(void)
continue;

drm_modeset_lock_all(dev);
-   ret = drm_fb_helper_restore_fbdev_mode(helper);
+   ret = restore_fbdev_mode(helper);
if (ret)
error = true;
drm_modeset_unlock_all(dev);
-- 
1.9.1

[PATCH 0/2] drm/fb-helper: Silence defined but not used warning

[Geert Uytterhoeven]

From: Geert Uytterhoeven 

Hi,

If CONFIG_MAGIC_SYSRQ is not set:

drivers/gpu/drm/drm_fb_helper.c:390:13: warning: 
'drm_fb_helper_force_kernel_mode' defined but not used [-Wunused-function]
 static bool drm_fb_helper_force_kernel_mode(void)
 ^

As just silencing this warning would require moving two functions (one
of them having obsolete documentation) inside the #ifdef, I fixed the
documentation first.

This patch series is against next-20150803.

Geert Uytterhoeven (2):
  drm/fb-helper: Clarify drm_fb_helper_restore_fbdev_mode*()
  drm/fb-helper: Move drm_fb_helper_force_kernel_mode() inside #ifdef

 drivers/gpu/drm/drm_fb_helper.c | 71 -
 1 file changed, 28 insertions(+), 43 deletions(-)

-- 
1.9.1

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at 
linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds

[Bug 91268] R6xx freezes with kernel 3.17 and up

[bugzilla-dae...@freedesktop.org]

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

--- Comment #23 from Kajzer  ---
Still working fine with disabled WC, not a single crash since.
Also, I wasn't able to notice any difference with disabled WC, I mean regarding
performance or something.
Disabling WC on RV6xx is definitely a good thing.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150804/0eb5d062/attachment.html>

[Bug 100351] System freezes for 2 seconds while opening apps

[bugzilla-dae...@bugzilla.kernel.org]

https://bugzilla.kernel.org/show_bug.cgi?id=100351

--- Comment #5 from yaroslav.sapozhnik at gmail.com ---
Still there with kernel 4.1.3-200.fc22.x86_64

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 91375] [radeonsi] [drm:si_dpm_set_power_state [radeon]] *ERROR* si_restrict_performance_levels_before_switch failed

[bugzilla-dae...@freedesktop.org]

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

--- Comment #3 from Alexandre Demers  ---
I've not encountered the error again... I wonder if it is related to a sleep /
wake-up cycle... I'll have a look at that option. If I catch the error again,
I'll post the info. Otherwise, I may just close the bug.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150804/b093b39c/attachment.html>

[PATCH] drm/atomic: Fix bookkeeping with TEST_ONLY.

[Maarten Lankhorst]

Commit ec9f932ed41622d120de52a5b525e4d77b9ef17e
"drm/atomic: Cleanup on error properly in the atomic ioctl."
cleaned up some error paths, but didn't fix the TEST_ONLY path.
In the check only case plane->fb shouldn't be updated, and
the vblank events should be cleared as on failure.

Signed-off-by: Maarten Lankhorst 
---
diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index d719ce0b10a0..03672a782e84 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -1507,7 +1507,8 @@ retry:
copied_props++;
}

-   if (obj->type == DRM_MODE_OBJECT_PLANE && count_props) {
+   if (obj->type == DRM_MODE_OBJECT_PLANE && count_props &&
+   !(arg->flags & DRM_MODE_ATOMIC_TEST_ONLY)) {
plane = obj_to_plane(obj);
plane_mask |= (1 << drm_plane_index(plane));
plane->old_fb = plane->fb;
@@ -1532,7 +1533,7 @@ retry:
ret = drm_atomic_check_only(state);
/* _check_only() does not free state, unlike _commit() */
if (!ret)
-   drm_atomic_state_free(state);
+   goto free;
} else if (arg->flags & DRM_MODE_ATOMIC_NONBLOCK) {
ret = drm_atomic_async_commit(state);
} else {
@@ -1566,6 +1567,7 @@ out:
}

if (ret) {
+free:
if (arg->flags & DRM_MODE_PAGE_FLIP_EVENT) {
for_each_crtc_in_state(state, crtc, crtc_state, i) {
if (!crtc_state->event)

[Intel-gfx] [PATCH 4/4] drm/atomic-helpers: Make encoder picking more robust

[Ander Conselvan De Oliveira]

For the series:

Reviewed-by: Ander Conselvan de Oliveira 


On Mon, 2015-08-03 at 17:24 +0200, Daniel Vetter wrote:
> We've had a few issues with atomic where subtle bugs in the encoder
> picking logic lead to accidental self-stealing of the encoder,
> resulting in a NULL connector_state->crtc in update_connector_routing
> and subsequent.
> 
> Linus applied some duct-tape for an mst regression in
> 
> commit 27667f4744fc5a0f3e50910e78740bac5670d18b
> Author: Linus Torvalds 
> Date:   Wed Jul 29 22:18:16 2015 -0700
> 
> i915: temporary fix for DP MST docking station NULL pointer dereference
> 
> But that was incomplete (the code will still oops when debuggin is
> enabled) and mangled the state even further. So instead WARN and bail
> out as the more future-proof option.
> 
> Cc: Theodore Ts'o 
> Cc: Linus Torvalds 
> Signed-off-by: Daniel Vetter 
> ---
>  drivers/gpu/drm/drm_atomic_helper.c | 11 ++-
>  1 file changed, 6 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
> b/drivers/gpu/drm/drm_atomic_helper.c
> index 8694ca9beee3..9dcc7280e572 100644
> --- a/drivers/gpu/drm/drm_atomic_helper.c
> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> @@ -234,13 +234,14 @@ update_connector_routing(struct drm_atomic_state 
> *state, int conn_idx)
>   }
>   }
>  
> + if (WARN_ON(!connector_state->crtc))
> + return -EINVAL;
> +
>   connector_state->best_encoder = new_encoder;
> - if (connector_state->crtc) {
> - idx = drm_crtc_index(connector_state->crtc);
> + idx = drm_crtc_index(connector_state->crtc);
>  
> - crtc_state = state->crtc_states[idx];
> - crtc_state->mode_changed = true;
> - }
> + crtc_state = state->crtc_states[idx];
> + crtc_state->mode_changed = true;
>  
>   DRM_DEBUG_ATOMIC("[CONNECTOR:%d:%s] using [ENCODER:%d:%s] on 
> [CRTC:%d]\n",
>connector->base.id,

[PATCH 11/11] drm/exynos: remove struct exynos_drm_encoder layer

[Gustavo Padovan]

Hi Inki,

2015-08-04 Inki Dae :

> On 2015년 08월 04일 04:09, Gustavo Padovan wrote:
> > From: Gustavo Padovan 
> > 
> > struct exynos_drm_encoder was justing wrapping struct drm_encoder, it had
> > only a drm_encoder member and the internal exynos_drm_encoders ops that
> > was directly mapped to the drm_encoder helper funcs.
> > 
> > So now exynos DRM uses struct drm_encoder directly, this removes
> > completely the struct exynos_drm_encoder.
> > 
> > Signed-off-by: Gustavo Padovan 
> > ---
> >  drivers/gpu/drm/exynos/Makefile |   7 +-
> >  drivers/gpu/drm/exynos/exynos7_drm_decon.c  |   2 +-
> >  drivers/gpu/drm/exynos/exynos_dp_core.c |  68 --
> >  drivers/gpu/drm/exynos/exynos_dp_core.h |   2 +-
> >  drivers/gpu/drm/exynos/exynos_drm_core.c|   1 -
> >  drivers/gpu/drm/exynos/exynos_drm_crtc.c|   1 -
> >  drivers/gpu/drm/exynos/exynos_drm_dpi.c |  51 --
> >  drivers/gpu/drm/exynos/exynos_drm_drv.c |   1 -
> >  drivers/gpu/drm/exynos/exynos_drm_drv.h |  47 ++---
> >  drivers/gpu/drm/exynos/exynos_drm_dsi.c |  80 +++--
> >  drivers/gpu/drm/exynos/exynos_drm_encoder.c | 105 
> > 
> >  drivers/gpu/drm/exynos/exynos_drm_encoder.h |  22 --
> >  drivers/gpu/drm/exynos/exynos_drm_fimd.c|   2 +-
> >  drivers/gpu/drm/exynos/exynos_drm_vidi.c|  71 ++-
> >  drivers/gpu/drm/exynos/exynos_hdmi.c|  85 +-
> >  15 files changed, 236 insertions(+), 309 deletions(-)
> >  delete mode 100644 drivers/gpu/drm/exynos/exynos_drm_encoder.c
> >  delete mode 100644 drivers/gpu/drm/exynos/exynos_drm_encoder.h
> 
> [-- SNIP --]
> 
> > diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c 
> > b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
> > index d791ad4..a87d030 100644
> > --- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
> > +++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
> > @@ -30,7 +30,6 @@
> >  #include 
> >  
> >  #include "exynos_drm_crtc.h"
> > -#include "exynos_drm_encoder.h"
> >  #include "exynos_drm_drv.h"
> >  
> >  /* returns true iff both arguments logically differs */
> > @@ -260,7 +259,7 @@ struct exynos_dsi_driver_data {
> >  };
> >  
> >  struct exynos_dsi {
> > -   struct exynos_drm_encoder encoder;
> > +   struct drm_encoder encoder;
> > struct mipi_dsi_host dsi_host;
> > struct drm_connector connector;
> > struct device_node *panel_node;
> > @@ -296,7 +295,7 @@ struct exynos_dsi {
> >  #define host_to_dsi(host) container_of(host, struct exynos_dsi, dsi_host)
> >  #define connector_to_dsi(c) container_of(c, struct exynos_dsi, connector)
> >  
> > -static inline struct exynos_dsi *encoder_to_dsi(struct exynos_drm_encoder 
> > *e)
> > +static inline struct exynos_dsi *encoder_to_dsi(struct drm_encoder *e)
> >  {
> > return container_of(e, struct exynos_dsi, encoder);
> >  }
> > @@ -1273,7 +1272,7 @@ static irqreturn_t exynos_dsi_irq(int irq, void 
> > *dev_id)
> >  static irqreturn_t exynos_dsi_te_irq_handler(int irq, void *dev_id)
> >  {
> > struct exynos_dsi *dsi = (struct exynos_dsi *)dev_id;
> > -   struct drm_encoder *encoder = >encoder.base;
> > +   struct drm_encoder *encoder = >encoder;
> >  
> > if (dsi->state & DSIM_STATE_VIDOUT_AVAILABLE)
> > exynos_drm_crtc_te_handler(encoder->crtc);
> > @@ -1519,7 +1518,7 @@ static void exynos_dsi_poweroff(struct exynos_dsi 
> > *dsi)
> > dev_err(dsi->dev, "cannot disable regulators %d\n", ret);
> >  }
> >  
> > -static void exynos_dsi_enable(struct exynos_drm_encoder *encoder)
> > +static void exynos_dsi_enable(struct drm_encoder *encoder)
> >  {
> > struct exynos_dsi *dsi = encoder_to_dsi(encoder);
> > int ret;
> > @@ -1555,7 +1554,7 @@ static void exynos_dsi_enable(struct 
> > exynos_drm_encoder *encoder)
> > dsi->state |= DSIM_STATE_VIDOUT_AVAILABLE;
> >  }
> >  
> > -static void exynos_dsi_disable(struct exynos_drm_encoder *encoder)
> > +static void exynos_dsi_disable(struct drm_encoder *encoder)
> >  {
> > struct exynos_dsi *dsi = encoder_to_dsi(encoder);
> >  
> > @@ -1583,7 +1582,7 @@ exynos_dsi_detect(struct drm_connector *connector, 
> > bool force)
> > if (dsi->panel)
> > drm_panel_attach(dsi->panel, >connector);
> > } else if (!dsi->panel_node) {
> > -   struct exynos_drm_encoder *encoder;
> > +   struct drm_encoder *encoder;
> >  
> > encoder = platform_get_drvdata(to_platform_device(dsi->dev));
> > exynos_dsi_disable(encoder);
> > @@ -1629,7 +1628,7 @@ exynos_dsi_best_encoder(struct drm_connector 
> > *connector)
> >  {
> > struct exynos_dsi *dsi = connector_to_dsi(connector);
> >  
> > -   return >encoder.base;
> > +   return >encoder;
> >  }
> >  
> >  static struct drm_connector_helper_funcs exynos_dsi_connector_helper_funcs 
> > = {
> > @@ -1637,11 +1636,9 @@ static struct drm_connector_helper_funcs 
> > exynos_dsi_connector_helper_funcs 

[Intel-gfx] [PATCH 4/4] drm/atomic-helpers: Make encoder picking more robust

[Daniel Vetter]

On Tue, Aug 04, 2015 at 11:56:08AM +0300, Ander Conselvan De Oliveira wrote:
> For the series:
> 
> Reviewed-by: Ander Conselvan de Oliveira 

Thanks for the review.
-Daniel
> 
> 
> On Mon, 2015-08-03 at 17:24 +0200, Daniel Vetter wrote:
> > We've had a few issues with atomic where subtle bugs in the encoder
> > picking logic lead to accidental self-stealing of the encoder,
> > resulting in a NULL connector_state->crtc in update_connector_routing
> > and subsequent.
> > 
> > Linus applied some duct-tape for an mst regression in
> > 
> > commit 27667f4744fc5a0f3e50910e78740bac5670d18b
> > Author: Linus Torvalds 
> > Date:   Wed Jul 29 22:18:16 2015 -0700
> > 
> > i915: temporary fix for DP MST docking station NULL pointer dereference
> > 
> > But that was incomplete (the code will still oops when debuggin is
> > enabled) and mangled the state even further. So instead WARN and bail
> > out as the more future-proof option.
> > 
> > Cc: Theodore Ts'o 
> > Cc: Linus Torvalds 
> > Signed-off-by: Daniel Vetter 
> > ---
> >  drivers/gpu/drm/drm_atomic_helper.c | 11 ++-
> >  1 file changed, 6 insertions(+), 5 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
> > b/drivers/gpu/drm/drm_atomic_helper.c
> > index 8694ca9beee3..9dcc7280e572 100644
> > --- a/drivers/gpu/drm/drm_atomic_helper.c
> > +++ b/drivers/gpu/drm/drm_atomic_helper.c
> > @@ -234,13 +234,14 @@ update_connector_routing(struct drm_atomic_state 
> > *state, int conn_idx)
> > }
> > }
> >  
> > +   if (WARN_ON(!connector_state->crtc))
> > +   return -EINVAL;
> > +
> > connector_state->best_encoder = new_encoder;
> > -   if (connector_state->crtc) {
> > -   idx = drm_crtc_index(connector_state->crtc);
> > +   idx = drm_crtc_index(connector_state->crtc);
> >  
> > -   crtc_state = state->crtc_states[idx];
> > -   crtc_state->mode_changed = true;
> > -   }
> > +   crtc_state = state->crtc_states[idx];
> > +   crtc_state->mode_changed = true;
> >  
> > DRM_DEBUG_ATOMIC("[CONNECTOR:%d:%s] using [ENCODER:%d:%s] on 
> > [CRTC:%d]\n",
> >  connector->base.id,

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

[PATCH] scripts/kernel-doc Allow struct arguments documentation in struct body

[Daniel Vetter]

On Fri, Jul 31, 2015 at 06:06:45PM -0300, Danilo Cesar Lemes de Paula wrote:
> Describing arguments at top of a struct definition works fine
> for small/medium size structs, but it definitely doesn't work well
> for struct with a huge list of elements.
> 
> Keeping the arguments list inside the struct body makes it easier
> to maintain the documentation.
> ie:
> /**
>  * struct my_struct - short description
>  * @a: first member
>  * @b: second member
>  *
>  * Longer description
>  */
> struct my_struct {
> int a;
> int b;
> /**
>  * @c: This is longer description of C
>  *
>  * You can use paragraphs to describe arguments
>  * using this method.
>  */
> int c;
> };
> 
> This patch allows the use of this kind of syntax. Only one argument
> per comment and user can use how many paragraphs he needs. It should
> start with /**, which is already being used by kernel-doc. If those
> comment doesn't follow those rules, it will be ignored.
> 
> Signed-off-by: Danilo Cesar Lemes de Paula 
> Cc: Randy Dunlap 
> Cc: Daniel Vetter 
> Cc: Laurent Pinchart 
> Cc: Jonathan Corbet 
> Cc: Herbert Xu 
> Cc: Stephan Mueller 
> Cc: Michal Marek 
> Cc: linux-kernel at vger.kernel.org
> Cc: linux-doc at vger.kernel.org
> Cc: intel-gfx 
> Cc: dri-devel 
> ---
>  scripts/kernel-doc | 80 
> --
>  1 file changed, 78 insertions(+), 2 deletions(-)
> 
> diff --git a/scripts/kernel-doc b/scripts/kernel-doc
> index 9922e66..9bfa8b9 100755
> --- a/scripts/kernel-doc
> +++ b/scripts/kernel-doc
> @@ -133,6 +133,30 @@ use strict;
>  #
>  # All descriptions can be multiline, except the short function description.
>  #
> +# For really longs structs, you can also describe arguments inside the
> +# body of the struct.
> +# eg.
> +# /**
> +#  * struct my_struct - short description
> +#  * @a: first member
> +#  * @b: second member
> +#  *
> +#  * Longer description
> +#  */
> +# struct my_struct {
> +# int a;
> +# int b;
> +# /**
> +#  * @c: This is longer description of C
> +#  *
> +#  * You can use paragraphs to describe arguments
> +#  * using this method.
> +#  */
> +# int c;
> +# };
> +#
> +# This should be use for arguments only.
> +#
>  # You can also add additional sections. When documenting kernel functions you
>  # should document the "Context:" of the function, e.g. whether the functions
>  # can be called form interrupts. Unlike other sections you can end it with an
> @@ -287,9 +311,19 @@ my $lineprefix="";
>  # 2 - scanning field start.
>  # 3 - scanning prototype.
>  # 4 - documentation block
> +# 5 - gathering documentation outside main block
>  my $state;
>  my $in_doc_sect;
>  
> +# Split Doc State
> +# 0 - Invalid (Before start or after finish)
> +# 1 - Is started (the /** was found inside a struct)
> +# 2 - The @parameter header was found, start accepting multi paragraph text.
> +# 3 - Finished (the */ was found)
> +# 4 - Error - Comment without header was found. Spit a warning as it's not
> +# proper kernel-doc and ignore the rest.
> +my $split_doc_state;
> +
>  #declaration types: can be
>  # 'function', 'struct', 'union', 'enum', 'typedef'
>  my $decl_type;
> @@ -304,6 +338,9 @@ my $doc_decl = $doc_com . '(\w+)';
>  my $doc_sect = $doc_com . '([' . $doc_special . ']?[\w\s]+):(.*)';
>  my $doc_content = $doc_com_body . '(.*)';
>  my $doc_block = $doc_com . 'DOC:\s*(.*)?';
> +my $doc_split_start = '^\s*/\*\*\s*$';
> +my $doc_split_sect = '\s*\*\s*(@[\w\s]+):(.*)';
> +my $doc_split_end = '^\s*\*/\s*$';
>  
>  my %constants;
>  my %parameterdescs;
> @@ -2181,6 +2218,7 @@ sub reset_state {
>  $prototype = "";
>  
>  $state = 0;
> +$split_doc_state = 0;
>  }
>  
>  sub tracepoint_munge($) {
> @@ -2453,7 +2491,6 @@ sub process_file($) {
>   }
>   $section = $newsection;
>   } elsif (/$doc_end/) {
> -
>   if (($contents ne "") && ($contents ne "\n")) {
>   dump_section($file, $section, xml_escape($contents));
>   $section = $section_default;
> @@ -2494,8 +2531,47 @@ sub process_file($) {
>   print STDERR "Warning(${file}:$.): bad line: $_";
>   ++$warnings;
>   }
> + } elsif ($state == 5) { # scanning for split parameters
> +
> + # First line (state 1) needs to be a @parameter
> + if ($split_doc_state == 1 && /$doc_split_sect/o) {
> + $section = $1;
> + $contents = $2;

You're using a mix of tabs and spaces here to indent. Ofc we need 4 spaces
for odd indent levels, but for others it shouldn't be required.
-Daniel

> + if ($contents ne "") {
> + while ((substr($contents, 0, 1) eq " ") ||
> + substr($contents, 0, 1) eq "\t") {
> + $contents = substr($contents, 1);
> + }
> + $contents .= "\n";
> + }
> + 

[PATCH 4/4] drm/atomic-helpers: Make encoder picking more robust

[Thierry Reding]

On Mon, Aug 03, 2015 at 05:24:11PM +0200, Daniel Vetter wrote:
> We've had a few issues with atomic where subtle bugs in the encoder
> picking logic lead to accidental self-stealing of the encoder,
> resulting in a NULL connector_state->crtc in update_connector_routing
> and subsequent.
> 
> Linus applied some duct-tape for an mst regression in
> 
> commit 27667f4744fc5a0f3e50910e78740bac5670d18b
> Author: Linus Torvalds 
> Date:   Wed Jul 29 22:18:16 2015 -0700
> 
> i915: temporary fix for DP MST docking station NULL pointer dereference
> 
> But that was incomplete (the code will still oops when debuggin is
> enabled) and mangled the state even further. So instead WARN and bail
> out as the more future-proof option.
> 
> Cc: Theodore Ts'o 
> Cc: Linus Torvalds 
> Signed-off-by: Daniel Vetter 
> ---
>  drivers/gpu/drm/drm_atomic_helper.c | 11 ++-
>  1 file changed, 6 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
> b/drivers/gpu/drm/drm_atomic_helper.c
> index 8694ca9beee3..9dcc7280e572 100644
> --- a/drivers/gpu/drm/drm_atomic_helper.c
> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> @@ -234,13 +234,14 @@ update_connector_routing(struct drm_atomic_state 
> *state, int conn_idx)
>   }
>   }
>  
> + if (WARN_ON(!connector_state->crtc))
> + return -EINVAL;
> +
>   connector_state->best_encoder = new_encoder;
> - if (connector_state->crtc) {
> - idx = drm_crtc_index(connector_state->crtc);
> + idx = drm_crtc_index(connector_state->crtc);
>  
> - crtc_state = state->crtc_states[idx];
> - crtc_state->mode_changed = true;
> - }
> + crtc_state = state->crtc_states[idx];
> + crtc_state->mode_changed = true;
>  
>   DRM_DEBUG_ATOMIC("[CONNECTOR:%d:%s] using [ENCODER:%d:%s] on 
> [CRTC:%d]\n",
>connector->base.id,

Reviewed-by: Thierry Reding 
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150804/ebba5338/attachment.sig>

[PATCH 3/4] drm/dp-mst: Remove debug WARN_ON

[Thierry Reding]

On Mon, Aug 03, 2015 at 05:24:10PM +0200, Daniel Vetter wrote:
> Apparently been in there since forever and fairly easy to hit when
> hotplugging really fast. I can do that since my mst hub has a manual
> button to flick the hpd line for reprobing. The resulting WARNING spam
> isn't pretty.
> 
> Cc: Dave Airlie 
> Cc: stable at vger.kernel.org
> Signed-off-by: Daniel Vetter 
> ---
>  drivers/gpu/drm/drm_dp_mst_topology.c | 1 -
>  1 file changed, 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c 
> b/drivers/gpu/drm/drm_dp_mst_topology.c
> index 778bbb6425b8..b0487c9f018c 100644
> --- a/drivers/gpu/drm/drm_dp_mst_topology.c
> +++ b/drivers/gpu/drm/drm_dp_mst_topology.c
> @@ -1294,7 +1294,6 @@ retry:
>   goto retry;
>   }
>   DRM_DEBUG_KMS("failed to dpcd write %d %d\n", tosend, 
> ret);
> - WARN(1, "fail\n");
>  
>   return -EIO;
>   }

Reviewed-by: Thierry Reding 
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150804/bd6e44bd/attachment.sig>

[PATCH 1/4] drm/atomic-helper: Add an atomice best_encoder callback

[Thierry Reding]

On Mon, Aug 03, 2015 at 05:24:08PM +0200, Daniel Vetter wrote:
> With legacy helpers all the routing was already set up when calling
> best_encoder and so could be inspected. But with atomic it's staged,
> hence we need a new atomic compliant callback for drivers which need
> to inspect the requested state and can't just decided the best encoder
> statically.
> 
> This is needed to fix up i915 dp mst where we need to pick the right
> encoder depending upon the requested CRTC for the connector.
> 
> v2: Don't forget to amend the kerneldoc
> 
> Cc: Chris Wilson 
> Cc: Linus Torvalds 
> Cc: Theodore Ts'o 
> Signed-off-by: Daniel Vetter 
> ---
>  drivers/gpu/drm/drm_atomic_helper.c | 7 ++-
>  include/drm/drm_crtc_helper.h   | 3 +++
>  2 files changed, 9 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
> b/drivers/gpu/drm/drm_atomic_helper.c
> index aac212297b49..8694ca9beee3 100644
> --- a/drivers/gpu/drm/drm_atomic_helper.c
> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> @@ -196,7 +196,12 @@ update_connector_routing(struct drm_atomic_state *state, 
> int conn_idx)
>   }
>  
>   funcs = connector->helper_private;
> - new_encoder = funcs->best_encoder(connector);
> +
> + if (funcs->atomic_best_encoder)
> + new_encoder = funcs->atomic_best_encoder(connector,
> +  connector_state);
> + else
> + new_encoder = funcs->best_encoder(connector);
>  
>   if (!new_encoder) {
>   DRM_DEBUG_ATOMIC("No suitable encoder found for 
> [CONNECTOR:%d:%s]\n",
> diff --git a/include/drm/drm_crtc_helper.h b/include/drm/drm_crtc_helper.h
> index c8fc187061de..918aa68b5199 100644
> --- a/include/drm/drm_crtc_helper.h
> +++ b/include/drm/drm_crtc_helper.h
> @@ -168,6 +168,7 @@ struct drm_encoder_helper_funcs {
>   * @get_modes: get mode list for this connector
>   * @mode_valid: is this mode valid on the given connector? (optional)
>   * @best_encoder: return the preferred encoder for this connector
> + * @atomic_best_encoder: atomic version of @best_encoder

This could arguably be more verbose, but the limits of kerneldoc don't
make that easy. Perhaps a more verbose description could be provided in
done in the DRM DocBook, along with other documentation about atomic
mode-setting.

Irrespective of that, this makes sense, so:

Acked-by: Thierry Reding 
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150804/49015961/attachment.sig>

[Bug 91268] R6xx freezes with kernel 3.17 and up

[bugzilla-dae...@freedesktop.org]

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

--- Comment #22 from Michel Dänzer  ---
Seeing as both Kajzer and Fedja Beader are using RV6xx GPUs, maybe we could
just disable WC for those for now?

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150804/218023a5/attachment-0001.html>

[Bug 86781] enabling glamor causes jumpy VDPAU playback with 2x framerate DI

[bugzilla-dae...@freedesktop.org]

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

--- Comment #2 from warpme at o2.pl ---
Marek,
I just checked with Mesa10.6.3/xorg1.17.2 and issue with too slow decode
(manifested by "Video is 3.40015 frames behind audio") gone. 
Unfortunately interlaced video playback with any 2x framerate DI is not smooth
as expected. Issue is seen on movements where I see v.short (50mSec like)
picture freezes regularly every 0.5sec or so. 
Exactly the same software but with Nvidia HW and their closed source drivers
plays perfectly. I didn't see anything in log's.
I would love to provide You more details if needed.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150804/c77d07d4/attachment.html>

[PATCH v2] scripts/kernel-doc Allow struct arguments documentation in struct body

[Danilo Cesar Lemes de Paula]

Describing arguments at top of a struct definition works fine
for small/medium size structs, but it definitely doesn't work well
for struct with a huge list of elements.

Keeping the arguments list inside the struct body makes it easier
to maintain the documentation.
ie:
/**
 * struct my_struct - short description
 * @a: first member
 * @b: second member
 *
 * Longer description
 */
struct my_struct {
int a;
int b;
/**
 * @c: This is longer description of C
 *
 * You can use paragraphs to describe arguments
 * using this method.
 */
int c;
};

This patch allows the use of this kind of syntax. Only one argument
per comment and user can use how many paragraphs he needs. It should
start with /**, which is already being used by kernel-doc. If those
comment doesn't follow those rules, it will be ignored.

Signed-off-by: Danilo Cesar Lemes de Paula 
Cc: Randy Dunlap 
Cc: Daniel Vetter 
Cc: Laurent Pinchart 
Cc: Jonathan Corbet 
Cc: Herbert Xu 
Cc: Stephan Mueller 
Cc: Michal Marek 
Cc: linux-kernel at vger.kernel.org
Cc: linux-doc at vger.kernel.org
Cc: intel-gfx 
Cc: dri-devel 
---
 Changelog:
  v2:
 - Fixed comment typo
 - Fixed identantion by following the rest of the kernel-doc script pattern.
 - Improved usage comment.

 scripts/kernel-doc | 77 --
 1 file changed, 75 insertions(+), 2 deletions(-)

diff --git a/scripts/kernel-doc b/scripts/kernel-doc
index 9922e66..5adc7ee 100755
--- a/scripts/kernel-doc
+++ b/scripts/kernel-doc
@@ -133,6 +133,30 @@ use strict;
 #
 # All descriptions can be multiline, except the short function description.
 #
+# For really longs structs, you can also describe arguments inside the
+# body of the struct.
+# eg.
+# /**
+#  * struct my_struct - short description
+#  * @a: first member
+#  * @b: second member
+#  *
+#  * Longer description
+#  */
+# struct my_struct {
+# int a;
+# int b;
+# /**
+#  * @c: This is longer description of C
+#  *
+#  * You can use paragraphs to describe arguments
+#  * using this method.
+#  */
+# int c;
+# };
+#
+# This should be use only for struct/enum members.
+#
 # You can also add additional sections. When documenting kernel functions you
 # should document the "Context:" of the function, e.g. whether the functions
 # can be called form interrupts. Unlike other sections you can end it with an
@@ -287,9 +311,19 @@ my $lineprefix="";
 # 2 - scanning field start.
 # 3 - scanning prototype.
 # 4 - documentation block
+# 5 - gathering documentation outside main block
 my $state;
 my $in_doc_sect;

+# Split Doc State
+# 0 - Invalid (Before start or after finish)
+# 1 - Is started (the /** was found inside a struct)
+# 2 - The @parameter header was found, start accepting multi paragraph text.
+# 3 - Finished (the */ was found)
+# 4 - Error - Comment without header was found. Spit a warning as it's not
+# proper kernel-doc and ignore the rest.
+my $split_doc_state;
+
 #declaration types: can be
 # 'function', 'struct', 'union', 'enum', 'typedef'
 my $decl_type;
@@ -304,6 +338,9 @@ my $doc_decl = $doc_com . '(\w+)';
 my $doc_sect = $doc_com . '([' . $doc_special . ']?[\w\s]+):(.*)';
 my $doc_content = $doc_com_body . '(.*)';
 my $doc_block = $doc_com . 'DOC:\s*(.*)?';
+my $doc_split_start = '^\s*/\*\*\s*$';
+my $doc_split_sect = '\s*\*\s*(@[\w\s]+):(.*)';
+my $doc_split_end = '^\s*\*/\s*$';

 my %constants;
 my %parameterdescs;
@@ -2181,6 +2218,7 @@ sub reset_state {
 $prototype = "";

 $state = 0;
+$split_doc_state = 0;
 }

 sub tracepoint_munge($) {
@@ -2453,7 +2491,6 @@ sub process_file($) {
}
$section = $newsection;
} elsif (/$doc_end/) {
-
if (($contents ne "") && ($contents ne "\n")) {
dump_section($file, $section, xml_escape($contents));
$section = $section_default;
@@ -2494,8 +2531,44 @@ sub process_file($) {
print STDERR "Warning(${file}:$.): bad line: $_";
++$warnings;
}
+   } elsif ($state == 5) { # scanning for split parameters
+   # First line (state 1) needs to be a @parameter
+   if ($split_doc_state == 1 && /$doc_split_sect/o) {
+   $section = $1;
+   $contents = $2;
+   if ($contents ne "") {
+   while ((substr($contents, 0, 1) eq " ") ||
+  substr($contents, 0, 1) eq "\t") {
+   $contents = substr($contents, 1);
+   }
+   $contents .= "\n";
+   }
+   $split_doc_state = 2;
+   # Documentation block end */
+   } elsif (/$doc_split_end/) {
+   if (($contents ne "") && ($contents ne "\n")) {
+   dump_section($file, $section, xml_escape($contents));
+   $section = $section_default;
+   $contents = "";
+ 

[PATCH 3/5] drm/i2c: adv7511: Refactor encoder slave functions

[Rob Clark]

On Tue, Aug 4, 2015 at 1:16 AM, Andrzej Hajda  wrote:
> On 08/03/2015 04:04 PM, Rob Clark wrote:
>> On Mon, Aug 3, 2015 at 8:03 AM, Andrzej Hajda  wrote:
>>> Hi,
>>>
>>> On 07/31/2015 04:48 PM, Rob Clark wrote:
 On Fri, Jul 31, 2015 at 8:58 AM, Boris Brezillon
  wrote:
> Hi Rob,
>
> On Fri, 31 Jul 2015 08:13:59 -0400
> Rob Clark  wrote:
>
>>> (...)
>>>
> Another problem I've seen with some drm bridge drivers is that they
> directly create their own connector, which, as Archit stated, is wrong
> if you decide to chain this bridge with another bridge. The other
 I agree with Archit on this.  He took this approach w/ msm support for
 external bridges, and it seems sensible that the last bridge
 constructs the connector.  (Plus presumably that is where hpd, ddc
 probing, etc, is happing)
>>> With this approach many bridges should construct connector conditionally,
>>> depending if there is something behind them in pipeline (the same is true 
>>> for
>>> encoders and even crtcs). It works, but for me there is lot of unnecessary 
>>> code
>>> and all those conditional paths make things less friendly for development.
>>> Wouldn't be better to move creation of the connector to the main drm driver,
>>> it would require probably adding some opses/fields to drm_bridges but the
>>> drivers would be simpler, I guess.
>> six of one, half dozen of the other..   you'd still need to implement
>> the hpd and ddc probe bits, and that sort of thing *somewhere*.
>> Whether it is directly by implementing drm_connector in the bridge, or
>> indirectly via some extra drm_bridge op's called by a shim connector
>> in the main drm driver, doesn't really seem to change things..
>
> The difference is that instead of duplicating connector related code in every
> driver you will call one helper from the main drm driver/core.

Which isn't more than a few lines of code.. I mean, looking at a
couple connectors, the bulk of the code is hpd and ddc related.  That
doesn't magically go away.  There isn't that many lines of
boilerplate, so meh.

BR,
-R

> Regards
> Andrzej
>
>>
>> BR,
>> -R
>>
>>> Regards
>>> Andrzej
>>>
> reason why the bridge should not create the connector by its own is
> that in some case the encoder supports different types of connectors (a
> TDMS encoder can be used to output HDMI or DVI), and thus, selecting
> the connector type should be left to the part responsible for creating
> the display pipelines.
 did you mean "should" instead of "should not"?  Otherwise I don't
 think I understand..

 BR,
 -R

> This being said, I'm definitely not an expert in this area, so don't
> hesitate to show me where I'm wrong.
>
> Best Regards,
>
> Boris
>
> --
> Boris Brezillon, Free Electrons
> Embedded Linux and Kernel engineering
> http://free-electrons.com
>

[PATCH v2] drm/i2c: tda998x: Fix bad checksum of the HDMI AVI infoframe

[Jean-Francois Moine]

On Tue, 28 Jul 2015 15:59:17 +0200
Jean-Francois Moine  wrote:

> Using hdmi_avi_infoframe_pack() to create the AVI infoframe calculates
> the checksum of the frame and breaks the second calculation which is
> done in tda998x_write_if(). Then the HDMI AVI frame is wrong and
> the display device does not handle correctly the video frames.
> 
> Fixes: 8c7a075da9f7980c ("use drm_hdmi_avi_infoframe_from_display_mode()")
> Signed-off-by: Jean-Francois Moine 
> ---
> v2: add the Fixes: tag
> ---
>  drivers/gpu/drm/i2c/tda998x_drv.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i2c/tda998x_drv.c 
> b/drivers/gpu/drm/i2c/tda998x_drv.c
> index fe1599d..424228b 100644
> --- a/drivers/gpu/drm/i2c/tda998x_drv.c
> +++ b/drivers/gpu/drm/i2c/tda998x_drv.c
> @@ -606,8 +606,6 @@ static void
>  tda998x_write_if(struct tda998x_priv *priv, uint8_t bit, uint16_t addr,
>uint8_t *buf, size_t size)
>  {
> - buf[PB(0)] = tda998x_cksum(buf, size);
> -
>   reg_clear(priv, REG_DIP_IF_FLAGS, bit);
>   reg_write_range(priv, addr, buf, size);
>   reg_set(priv, REG_DIP_IF_FLAGS, bit);
> @@ -627,6 +625,8 @@ tda998x_write_aif(struct tda998x_priv *priv, struct 
> tda998x_encoder_params *p)
>   buf[PB(4)] = p->audio_frame[4];
>   buf[PB(5)] = p->audio_frame[5] & 0xf8; /* DM_INH + LSV */
>  
> + buf[PB(0)] = tda998x_cksum(buf, sizeof(buf));
> +
>   tda998x_write_if(priv, DIP_IF_FLAGS_IF4, REG_IF4_HB0, buf,
>sizeof(buf));
>  }

Ping!

-- 
Ken ar c'hentañ| ** Breizh ha Linux atav! **
Jef |   http://moinejf.free.fr/

[PATCH 3/5] drm/i2c: adv7511: Refactor encoder slave functions

[Andrzej Hajda]

On 08/03/2015 04:04 PM, Rob Clark wrote:
> On Mon, Aug 3, 2015 at 8:03 AM, Andrzej Hajda  wrote:
>> Hi,
>>
>> On 07/31/2015 04:48 PM, Rob Clark wrote:
>>> On Fri, Jul 31, 2015 at 8:58 AM, Boris Brezillon
>>>  wrote:
 Hi Rob,

 On Fri, 31 Jul 2015 08:13:59 -0400
 Rob Clark  wrote:

>> (...)
>>
 Another problem I've seen with some drm bridge drivers is that they
 directly create their own connector, which, as Archit stated, is wrong
 if you decide to chain this bridge with another bridge. The other
>>> I agree with Archit on this.  He took this approach w/ msm support for
>>> external bridges, and it seems sensible that the last bridge
>>> constructs the connector.  (Plus presumably that is where hpd, ddc
>>> probing, etc, is happing)
>> With this approach many bridges should construct connector conditionally,
>> depending if there is something behind them in pipeline (the same is true for
>> encoders and even crtcs). It works, but for me there is lot of unnecessary 
>> code
>> and all those conditional paths make things less friendly for development.
>> Wouldn't be better to move creation of the connector to the main drm driver,
>> it would require probably adding some opses/fields to drm_bridges but the
>> drivers would be simpler, I guess.
> six of one, half dozen of the other..   you'd still need to implement
> the hpd and ddc probe bits, and that sort of thing *somewhere*.
> Whether it is directly by implementing drm_connector in the bridge, or
> indirectly via some extra drm_bridge op's called by a shim connector
> in the main drm driver, doesn't really seem to change things..

The difference is that instead of duplicating connector related code in every
driver you will call one helper from the main drm driver/core.

Regards
Andrzej

>
> BR,
> -R
>
>> Regards
>> Andrzej
>>
 reason why the bridge should not create the connector by its own is
 that in some case the encoder supports different types of connectors (a
 TDMS encoder can be used to output HDMI or DVI), and thus, selecting
 the connector type should be left to the part responsible for creating
 the display pipelines.
>>> did you mean "should" instead of "should not"?  Otherwise I don't
>>> think I understand..
>>>
>>> BR,
>>> -R
>>>
 This being said, I'm definitely not an expert in this area, so don't
 hesitate to show me where I'm wrong.

 Best Regards,

 Boris

 --
 Boris Brezillon, Free Electrons
 Embedded Linux and Kernel engineering
 http://free-electrons.com

[REGRESSION] Re: i915 driver crashes on T540p if docking station attached

[Rafael J. Wysocki]

On Tuesday, August 04, 2015 12:05:14 AM Daniel Vetter wrote:
> On Mon, Aug 3, 2015 at 7:24 PM, Linus Torvalds
>  wrote:
> >>  However, I'm
> >> still seeing a large number of drm/i915 related warning messages and
> >> other kernel kvetching.
> >
> > I suspect I can live with that for now. The lockdep one looks like
> > it's mainly an initialization issue, so you'd never get the actual
> > deadlock in practice, but it's obviously annoying.  The intel_pm.c one
> > I'll have to defer to the i915 people for..
> 
> The lockdep splat is just acpi being inconsistent with init_mutex vs.
> backlight notifier_chain (which has it's own lock) calls. init_mutex
> is new in 4.2 and has been added in
> 
> commit 87521e16a7abbf3fa337f56cb4d1e18247f15e8a
> Author: Hans de Goede 
> Date:   Tue Jun 16 16:27:48 2015 +0200
> 
> acpi-video-detect: Rewrite backlight interface selection logic
> 
> 
> Not mine ;-) But adding relevant people.

Hans, can you have a look at this, please?

Rafael

[Bug 90217] Counter Strike Global Offensive: GPU fault after a while

[bugzilla-dae...@freedesktop.org]

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

--- Comment #7 from Paul  ---
Created attachment 117500
  --> https://bugs.freedesktop.org/attachment.cgi?id=117500=edit
dmesg csgo tahiti

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150804/682beefe/attachment.html>

[Bug 90217] Counter Strike Global Offensive: GPU fault after a while

[bugzilla-dae...@freedesktop.org]

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

Paul  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|FIXED   |---

--- Comment #6 from Paul  ---
Unfortunately I'm hit by this as well. Although I can't tell if it's fixed in
the latest git.
Happened after a few minutes (First try 2 minutes, second try ~30 minutes) of
gameplay on my HD 7970 - Tahiti XT. 
Mesa 10.6.3
Kernel 4.1.2
Arch, up-to-date

Game Settings: 
Global Shadow Quality - High
Model / Texture Detail -High 
Effect Detail - High
Shader Detail - Very High
Multicore Rendering - Enabled
MSAA - 8x
FSAA - Enabled
Texture Filter - Anisotropic 16x
Vsync - Disabled
Motion Blur - Enabled

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150804/33a02ac2/attachment.html>

[Bug 91545] [BONAIRE][ARK: Survival Evolved] Regression: radeonsi: flush if the memory usage for an IB is too high

[bugzilla-dae...@freedesktop.org]

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

Bug ID: 91545
   Summary: [BONAIRE][ARK: Survival Evolved] Regression: radeonsi:
flush if the memory usage for an IB is too high
   Product: Mesa
   Version: git
  Hardware: Other
OS: All
Status: NEW
  Severity: normal
  Priority: medium
 Component: Drivers/Gallium/radeonsi
  Assignee: dri-devel at lists.freedesktop.org
  Reporter: shawn.starr at rogers.com
QA Contact: dri-devel at lists.freedesktop.org

While playing ARK: Survival Evolved this patch caused some corruption in rain
falling and other textures.

See video: https://www.youtube.com/watch?v=2rbvF2CzwgE

Reverting this patch fixes issue.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150804/7e27e84a/attachment.html>

[REGRESSION] Re: i915 driver crashes on T540p if docking station attached

[Daniel Vetter]

On Mon, Aug 3, 2015 at 7:24 PM, Linus Torvalds
 wrote:
>>  However, I'm
>> still seeing a large number of drm/i915 related warning messages and
>> other kernel kvetching.
>
> I suspect I can live with that for now. The lockdep one looks like
> it's mainly an initialization issue, so you'd never get the actual
> deadlock in practice, but it's obviously annoying.  The intel_pm.c one
> I'll have to defer to the i915 people for..

The lockdep splat is just acpi being inconsistent with init_mutex vs.
backlight notifier_chain (which has it's own lock) calls. init_mutex
is new in 4.2 and has been added in

commit 87521e16a7abbf3fa337f56cb4d1e18247f15e8a
Author: Hans de Goede 
Date:   Tue Jun 16 16:27:48 2015 +0200

acpi-video-detect: Rewrite backlight interface selection logic


Not mine ;-) But adding relevant people.

I'll send you a pull for the mst one tomorrow and look into the
watermark fail in intel_pm.c too.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

[Bug 91543] [BONAIRE] ARK: Survival Evolved: corruption with certain textures inside cave (spider web)

[bugzilla-dae...@freedesktop.org]

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

--- Comment #1 from Shawn Starr  ---
Here is youtube video of a scene with this happening:
https://www.youtube.com/watch?v=4fJLyyVXSrQ

Sometimes it will turn the whole screen white/pink/black if the spider
successfully captures the player.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 

[Bug 91136] [tahiti xt] portal2/dota2 glitchy without R600_DEBUG=switch_on_eop

[bugzilla-dae...@freedesktop.org]

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

Sylvain BERTRAND  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #7 from Sylvain BERTRAND  ---
Checked portal2 and dota2, they both seem fine.
fixed.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 

[Bug 91527] 7870 radeon crashes after kernel msg drm:radeon_mn_invalidate_range_start

[bugzilla-dae...@freedesktop.org]

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

--- Comment #3 from JATothrim  ---
Created attachment 117498
  --> https://bugs.freedesktop.org/attachment.cgi?id=117498=edit
Xorg.0.log

It was hard to catch the dmesg and Xorg log because soon as I close the Dolphin
emu the system hard freezes --> no data synced.
Note that after the kernel prints those last lines the the bug is just
triggered - after I close the Dolphin main window does the crash occurs.

If some one is interested I have kdump data of the system. Thanks to my kexec
dump kernel. :)

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: