[Bug 97879] [amdgpu] Rocket League: long hangs (several seconds) when loading assets (models/textures/shaders?)

2016-09-24 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=97879

--- Comment #15 from Tobias Droste  ---
Created attachment 126771
  --> https://bugs.freedesktop.org/attachment.cgi?id=126771&action=edit
Profile of the the first few seconds of a game (only radeonsi)

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160924/5068f0c6/attachment.html>


[Bug 97879] [amdgpu] Rocket League: long hangs (several seconds) when loading assets (models/textures/shaders?)

2016-09-24 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=97879

--- Comment #14 from Tobias Droste  ---
Created attachment 126770
  --> https://bugs.freedesktop.org/attachment.cgi?id=126770&action=edit
Profile of the the first few seconds of a game (all components)

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160924/9f1b6559/attachment.html>


[PATCH v2 2/2] drm: zte: add initial vou drm driver

2016-09-24 Thread Shawn Guo
It adds the initial ZTE VOU display controller DRM driver.  There are
still some features to be added, like overlay plane, scaling, and more
output devices support.  But it's already useful with dual CRTCs and
HDMI monitor working.

It's been tested on Debian Jessie LXDE desktop with modesetting driver.

Signed-off-by: Shawn Guo 
---
 drivers/gpu/drm/Kconfig  |   2 +
 drivers/gpu/drm/Makefile |   1 +
 drivers/gpu/drm/zte/Kconfig  |   8 +
 drivers/gpu/drm/zte/Makefile |   8 +
 drivers/gpu/drm/zte/zx_crtc.c| 691 +++
 drivers/gpu/drm/zte/zx_crtc.h|  47 +++
 drivers/gpu/drm/zte/zx_drm_drv.c | 258 +++
 drivers/gpu/drm/zte/zx_drm_drv.h |  22 ++
 drivers/gpu/drm/zte/zx_hdmi.c| 540 ++
 drivers/gpu/drm/zte/zx_plane.c   | 362 
 drivers/gpu/drm/zte/zx_plane.h   |  26 ++
 11 files changed, 1965 insertions(+)
 create mode 100644 drivers/gpu/drm/zte/Kconfig
 create mode 100644 drivers/gpu/drm/zte/Makefile
 create mode 100644 drivers/gpu/drm/zte/zx_crtc.c
 create mode 100644 drivers/gpu/drm/zte/zx_crtc.h
 create mode 100644 drivers/gpu/drm/zte/zx_drm_drv.c
 create mode 100644 drivers/gpu/drm/zte/zx_drm_drv.h
 create mode 100644 drivers/gpu/drm/zte/zx_hdmi.c
 create mode 100644 drivers/gpu/drm/zte/zx_plane.c
 create mode 100644 drivers/gpu/drm/zte/zx_plane.h

diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index 483059a22b1b..a91f8cecbe0f 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -223,6 +223,8 @@ source "drivers/gpu/drm/hisilicon/Kconfig"

 source "drivers/gpu/drm/mediatek/Kconfig"

+source "drivers/gpu/drm/zte/Kconfig"
+
 # Keep legacy drivers last

 menuconfig DRM_LEGACY
diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index 439d89b25ae0..fe461c94d266 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -85,3 +85,4 @@ obj-$(CONFIG_DRM_FSL_DCU) += fsl-dcu/
 obj-$(CONFIG_DRM_ETNAVIV) += etnaviv/
 obj-$(CONFIG_DRM_ARCPGU)+= arc/
 obj-y  += hisilicon/
+obj-$(CONFIG_DRM_ZTE)  += zte/
diff --git a/drivers/gpu/drm/zte/Kconfig b/drivers/gpu/drm/zte/Kconfig
new file mode 100644
index ..4065b2840f1c
--- /dev/null
+++ b/drivers/gpu/drm/zte/Kconfig
@@ -0,0 +1,8 @@
+config DRM_ZTE
+   tristate "DRM Support for ZTE SoCs"
+   depends on DRM && ARCH_ZX
+   select DRM_KMS_CMA_HELPER
+   select DRM_KMS_FB_HELPER
+   select DRM_KMS_HELPER
+   help
+ Choose this option to enable DRM on ZTE ZX SoCs.
diff --git a/drivers/gpu/drm/zte/Makefile b/drivers/gpu/drm/zte/Makefile
new file mode 100644
index ..b40968dc749f
--- /dev/null
+++ b/drivers/gpu/drm/zte/Makefile
@@ -0,0 +1,8 @@
+zxdrm-y := \
+   zx_drm_drv.o \
+   zx_crtc.o \
+   zx_plane.o \
+   zx_hdmi.o
+
+obj-$(CONFIG_DRM_ZTE) += zxdrm.o
+
diff --git a/drivers/gpu/drm/zte/zx_crtc.c b/drivers/gpu/drm/zte/zx_crtc.c
new file mode 100644
index ..818bf9072573
--- /dev/null
+++ b/drivers/gpu/drm/zte/zx_crtc.c
@@ -0,0 +1,691 @@
+/*
+ * Copyright 2016 Linaro Ltd.
+ * Copyright 2016 ZTE Corporation.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "zx_drm_drv.h"
+#include "zx_crtc.h"
+#include "zx_plane.h"
+
+/* OSD (GPC_GLOBAL) registers */
+#define OSD_INT_STA0x04
+#define OSD_INT_CLRSTA 0x08
+#define OSD_INT_MSK0x0c
+#define OSD_INT_AUX_UPTBIT(14)
+#define OSD_INT_MAIN_UPT   BIT(13)
+#define OSD_INT_GL1_LBWBIT(10)
+#define OSD_INT_GL0_LBWBIT(9)
+#define OSD_INT_VL2_LBWBIT(8)
+#define OSD_INT_VL1_LBWBIT(7)
+#define OSD_INT_VL0_LBWBIT(6)
+#define OSD_INT_BUS_ERRBIT(3)
+#define OSD_INT_CFG_ERRBIT(2)
+#define OSD_INT_ERROR (\
+   OSD_INT_GL1_LBW | OSD_INT_GL0_LBW | \
+   OSD_INT_VL2_LBW | OSD_INT_VL1_LBW | OSD_INT_VL0_LBW | \
+   OSD_INT_BUS_ERR | OSD_INT_CFG_ERR \
+)
+#define OSD_INT_ENABLE (OSD_INT_ERROR | OSD_INT_AUX_UPT | OSD_INT_MAIN_UPT)
+#define OSD_CTRL0  0x10
+#define OSD_CTRL0_GL0_EN   BIT(7)
+#define OSD_CTRL0_GL0_SEL  BIT(6)
+#define OSD_CTRL0_GL1_EN   BIT(5)
+#define OSD_CTRL0_GL1_SEL  BIT(4)
+#define OSD_RST_CLR0x1c
+#define RST_PER_FRAME  BIT(19)
+
+/* Main/Aux channel registers */
+#define OSD_MAIN_CHN   0x470
+#define OSD_AUX_CHN0x4d0
+#define CHN_CTRL0

[PATCH v2 1/2] dt-bindings: add bindings doc for ZTE VOU display controller

2016-09-24 Thread Shawn Guo
It adds initial bindings doc for ZTE VOU display controller.  HDMI is
the only supported output device right now.

Signed-off-by: Shawn Guo 
---
 .../devicetree/bindings/display/zte,vou.txt| 86 ++
 1 file changed, 86 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/display/zte,vou.txt

diff --git a/Documentation/devicetree/bindings/display/zte,vou.txt 
b/Documentation/devicetree/bindings/display/zte,vou.txt
new file mode 100644
index ..d03ba4c4810c
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/zte,vou.txt
@@ -0,0 +1,86 @@
+ZTE VOU Display Controller
+
+This is a display controller found on ZTE ZX296718 SoC.  It includes multiple
+Graphic Layer (GL) and Video Layer (VL), two Mixers/Channels, and a few blocks
+handling scaling, color space conversion etc.  VOU also integrates the support
+for typical output devices, like HDMI, TV Encoder, VGA, and RGB LCD.
+
+* Master VOU node
+
+It must be the parent node of all the sub-device nodes.
+
+Required properties:
+ - compatible: should be "zte,zx296718-vou"
+ - #address-cells: should be <1>
+ - #size-cells: should be <1>
+ - reg: Physical base address and length of the whole VOU IO region
+ - ranges: to allow probing of sub-devices
+
+* VOU DPC device
+
+Required properties:
+ - compatible: should be "zte,zx296718-dpc"
+ - reg: Physical base address and length of DPC register regions, one for each
+   entry in 'reg-names'
+ - reg-names: The names of register regions. The following regions are 
required:
+   "osd"
+   "timing_ctrl"
+   "dtrc"
+   "vou_ctrl"
+   "otfppu"
+ - interrupts: VOU DPC interrupt number to CPU
+ - clocks: A list of phandle + clock-specifier pairs, one for each entry
+   in 'clock-names'
+ - clock-names: A list of clock names.  The following clocks are required:
+   "aclk"
+   "ppu_wclk"
+   "main_wclk"
+   "aux_wclk"
+
+* HDMI output device
+
+Required properties:
+ - compatible: should be "zte,zx296718-hdmi"
+ - reg: Physical base address and length of the HDMI device IO region
+ - interrupts : HDMI interrupt number to CPU
+ - clocks: A list of phandle + clock-specifier pairs, one for each entry
+   in 'clock-names'
+ - clock-names: A list of clock names.  The following clocks are required:
+   "osc_cec"
+   "osc_clk"
+   "xclk"
+
+Example:
+
+vou: vou at 144 {
+   compatible = "zte,zx296718-vou";
+   #address-cells = <1>;
+   #size-cells = <1>;
+   reg = <0x144 0x1>;
+   ranges;
+
+   dpc: dpc at 144 {
+   compatible = "zte,zx296718-dpc";
+   reg = <0x144 0x1000>, <0x1441000 0x1000>,
+ <0x1445000 0x1000>, <0x1446000 0x1000>,
+ <0x144a000 0x1000>;
+   reg-names = "osd", "timing_ctrl",
+   "dtrc", "vou_ctrl",
+   "otfppu";
+   interrupts = ;
+   clocks = <&topcrm VOU_ACLK>, <&topcrm VOU_PPU_WCLK>,
+<&topcrm VOU_MAIN_WCLK>, <&topcrm VOU_AUX_WCLK>;
+   clock-names = "aclk", "ppu_wclk",
+ "main_wclk", "aux_wclk";
+   };
+
+   hdmi: hdmi at 144c000 {
+   compatible = "zte,zx296718-hdmi";
+   reg = <0x144c000 0x4000>;
+   interrupts = ;
+   clocks = <&topcrm HDMI_OSC_CEC>,
+<&topcrm HDMI_OSC_CLK>,
+<&topcrm HDMI_XCLK>;
+   clock-names = "osc_cec", "osc_clk", "xclk";
+   };
+};
-- 
1.9.1



[PATCH v2 0/2] Add initial ZTE VOU DRM/KMS driver

2016-09-24 Thread Shawn Guo
The series adds the initial ZTE VOU display controller DRM/KMS driver.
There are still some features to be added, like overlay plane, scaling,
and more output devices support.  But it's already useful with dual
CRTCs and HDMI monitor working.

Changes for v2:
 - Change device tree bindings to kill the virtual display-subsystem
   node make VOU the parent node.

Shawn Guo (2):
  dt-bindings: add bindings doc for ZTE VOU display controller
  drm: zte: add initial vou drm driver

 .../devicetree/bindings/display/zte,vou.txt|  86 +++
 drivers/gpu/drm/Kconfig|   2 +
 drivers/gpu/drm/Makefile   |   1 +
 drivers/gpu/drm/zte/Kconfig|   8 +
 drivers/gpu/drm/zte/Makefile   |   8 +
 drivers/gpu/drm/zte/zx_crtc.c  | 691 +
 drivers/gpu/drm/zte/zx_crtc.h  |  47 ++
 drivers/gpu/drm/zte/zx_drm_drv.c   | 258 
 drivers/gpu/drm/zte/zx_drm_drv.h   |  22 +
 drivers/gpu/drm/zte/zx_hdmi.c  | 540 
 drivers/gpu/drm/zte/zx_plane.c | 362 +++
 drivers/gpu/drm/zte/zx_plane.h |  26 +
 12 files changed, 2051 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/display/zte,vou.txt
 create mode 100644 drivers/gpu/drm/zte/Kconfig
 create mode 100644 drivers/gpu/drm/zte/Makefile
 create mode 100644 drivers/gpu/drm/zte/zx_crtc.c
 create mode 100644 drivers/gpu/drm/zte/zx_crtc.h
 create mode 100644 drivers/gpu/drm/zte/zx_drm_drv.c
 create mode 100644 drivers/gpu/drm/zte/zx_drm_drv.h
 create mode 100644 drivers/gpu/drm/zte/zx_hdmi.c
 create mode 100644 drivers/gpu/drm/zte/zx_plane.c
 create mode 100644 drivers/gpu/drm/zte/zx_plane.h

-- 
1.9.1



[PATCH] drm/sun4i: rgb: Enable panel after controller

2016-09-24 Thread Maxime Ripard
is is done in
>  * the .disable() function. Analogously to .enable() this typically involves
>  * turning off the backlight and waiting for some time to make sure no image
>  * is visible on the panel. It is then safe for the display controller to
>  * cease transmission of video data.
>  *
>  * To save power when no video data is transmitted, a driver can power down
>  * the panel. This is the job of the .unprepare() function.
>  */

It kind of make my point. When drm_panel_enable is called, the content
is visible, and there's no extra delay needed.

If what you want to fix is that the panel is enabled before the
controller, hence resulting in garbage on the screen while the
controller is setup, then your commit log is seriously misleading.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160924/15933e61/attachment.sig>


[PATCH] drm/tegra: sor: No need to free devm_ allocated memory

2016-09-24 Thread Christophe JAILLET
'brick' has been allocated by 'devm_kzalloc', so there is no need here to
free it explicitly.
There is only one caller of 'tegra_clk_sor_brick_register()'. This function
is a probe function which correctly checks and handles the return value of
'tegra_clk_sor_brick_register()'.

Signed-off-by: Christophe JAILLET 
---
 drivers/gpu/drm/tegra/sor.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/gpu/drm/tegra/sor.c b/drivers/gpu/drm/tegra/sor.c
index 74d0540b8d4c..a8f528925009 100644
--- a/drivers/gpu/drm/tegra/sor.c
+++ b/drivers/gpu/drm/tegra/sor.c
@@ -349,8 +349,6 @@ static struct clk *tegra_clk_sor_brick_register(struct 
tegra_sor *sor,
brick->hw.init = &init;

clk = devm_clk_register(sor->dev, &brick->hw);
-   if (IS_ERR(clk))
-   kfree(brick);

return clk;
 }
-- 
2.7.4



[Bug 97500] Cannot unbind GPU from AMDGPU

2016-09-24 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=97500

--- Comment #5 from Grazvydas Ignotas  ---
Created attachment 126769
  --> https://bugs.freedesktop.org/attachment.cgi?id=126769&action=edit
modprobe then X then rmmod

dmasg if X session was used before rmmod

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


[Bug 97500] Cannot unbind GPU from AMDGPU

2016-09-24 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=97500

--- Comment #4 from Grazvydas Ignotas  ---
Created attachment 126768
  --> https://bugs.freedesktop.org/attachment.cgi?id=126768&action=edit
modprobe then rmmod

I've been trying today's drm-next-4.9-wip (merged with 4.8.0-rc7) and the
situation has improved somewhat, doing rmmod just after modprobe succeeds with
a WARN from TTM, but attempts to modprobe it again are failing. If X session is
started/stopped before rmmod, the consequences are more severe, looks like some
sort of corruption.

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


[RFC v3] drm/exynos: g2d: fix runtime PM

2016-09-24 Thread Tobias Jakobi
The commit b05984e21a7e000bf5074ace00d7a574944b2c16 broke
operation of the G2D. After this commit the following
happens.
- exynos_g2d_exec_ioctl() prepares a runqueue node and
  calls g2d_exec_runqueue()
- g2d_exec_runqueue() calls g2d_dma_start() which gets
  runtime PM sync
- runtime PM calls g2d_runtime_resume()
- g2d_runtime_resume() calls g2d_exec_runqueue()

Luckily for us this doesn't really loop, but creates a
mutex lockup, which the kernel even predicts.

Anyway, we fix this by reintroducing dedicated sleep
operations again, and only letting runtime PM control
the gate clock.

This is not enough to fix the issue though.
- We switch runtime PM to autosuspend. Currently clocks get
  disabled, and then re-enabled again in the runqueue worker
  when a node is completed and the next is started.
  With the upcoming introduction of IOMMU runtime PM this
  situations gets worse, since now also the IOMMU goes
  through a disable/enable cycle before the next node is
  started.
- We consolidate all runtime PM management to the runqueue
  worker.
- We introduce g2d_wait_finish() which waits until the currently
  processed runqueue node is finished.
  If this takes too long, the engine is forcibly reset. This
  is necessary to properly close the driver in case the engine
  should hang with read/write access to some area of memory.
  In this situation we can't properly unmap GEM/userptr
  objects, since this might create a pagefault.
- Sleep suspend issues a suspend of the runqueue and then calls
  g2d_wait_finish(), which returns the engine in the idle state.
  The current runqueue node gets completed, all other queued
  nodes stay in the queue. There is no hardware state that
  needs to be retained.
- Sleep resume just pokes the runqueue worker, which, should
  something be in queue, continues its work, or just exits.

Changes in v2:
- disable autosuspend mode again in g2d_remove()
- only get sync in g2d_runqueue_worker() if there is node
  in the queue left

Changes in v3:
- actually delete node in g2d_remove_runqueue_nodes()

Signed-off-by: Tobias Jakobi 
---
 drivers/gpu/drm/exynos/exynos_drm_g2d.c | 238 +---
 1 file changed, 189 insertions(+), 49 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_g2d.c 
b/drivers/gpu/drm/exynos/exynos_drm_g2d.c
index 6eca8bb..ef546ec 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_g2d.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_g2d.c
@@ -138,6 +138,18 @@ enum g2d_reg_type {
MAX_REG_TYPE_NR
 };

+enum g2d_flag_bits {
+   /*
+* If set, suspends the runqueue worker after the currently
+* processed node is finished.
+*/
+   G2D_BIT_SUSPEND_RUNQUEUE,
+   /*
+* If set, indicates that the engine is currently busy.
+*/
+   G2D_BIT_ENGINE_BUSY,
+};
+
 /* cmdlist data structure */
 struct g2d_cmdlist {
u32 head;
@@ -226,7 +238,7 @@ struct g2d_data {
struct workqueue_struct *g2d_workq;
struct work_struct  runqueue_work;
struct exynos_drm_subdrvsubdrv;
-   boolsuspended;
+   unsigned long   flags;

/* cmdlist */
struct g2d_cmdlist_node *cmdlist_node;
@@ -246,6 +258,12 @@ struct g2d_data {
unsigned long   max_pool;
 };

+static inline void g2d_hw_reset(struct g2d_data *g2d)
+{
+   writel(G2D_R | G2D_SFRCLEAR, g2d->regs + G2D_SOFT_RESET);
+   clear_bit(G2D_BIT_ENGINE_BUSY, &g2d->flags);
+}
+
 static int g2d_init_cmdlist(struct g2d_data *g2d)
 {
struct device *dev = g2d->dev;
@@ -803,12 +821,8 @@ static void g2d_dma_start(struct g2d_data *g2d,
struct g2d_cmdlist_node *node =
list_first_entry(&runqueue_node->run_cmdlist,
struct g2d_cmdlist_node, list);
-   int ret;
-
-   ret = pm_runtime_get_sync(g2d->dev);
-   if (ret < 0)
-   return;

+   set_bit(G2D_BIT_ENGINE_BUSY, &g2d->flags);
writel_relaxed(node->dma_addr, g2d->regs + G2D_DMA_SFR_BASE_ADDR);
writel_relaxed(G2D_DMA_START, g2d->regs + G2D_DMA_COMMAND);
 }
@@ -831,9 +845,6 @@ static void g2d_free_runqueue_node(struct g2d_data *g2d,
 {
struct g2d_cmdlist_node *node;

-   if (!runqueue_node)
-   return;
-
mutex_lock(&g2d->cmdlist_mutex);
/*
 * commands in run_cmdlist have been completed so unmap all gem
@@ -847,29 +858,65 @@ static void g2d_free_runqueue_node(struct g2d_data *g2d,
kmem_cache_free(g2d->runqueue_slab, runqueue_node);
 }

-static void g2d_exec_runqueue(struct g2d_data *g2d)
+/**
+ * g2d_remove_runqueue_nodes - remove items from the list of runqueue nodes
+ * @g2d: G2D state object
+ * @file: if not zero, only remove items with this DRM file
+ *
+ * Has to be called under runqueue lock.
+ */
+static void g2d_remove_runqueue_nodes(struct g2d_data *g2d, struc

[Bug 97917] Talos Principle gives Assertion `!NodePtr->isKnownSentinel()' failed

2016-09-24 Thread bugzilla-dae...@freedesktop.org
t;
0001:004C500B
DBG:  7FC75A3DF114 0001 $adr: "/usr/local/lib64/dri/radeonsi_dri.so"
0001:003A2114
DBG:  7FC75A3DEF07 0001 $adr: "/usr/local/lib64/dri/radeonsi_dri.so"
0001:003A1F07
DBG:  7FC7690F46CA 0001 $adr: "/lib64/libpthread.so.0"
0001:76CA
DBG:  7FC768914F6F 0001 $adr: "/lib64/libc.so.6" 0001:00107F6F
DBG:  7FC7690F46CA 0001 $adr: "/lib64/libpthread.so.0"
0001:76CA
DBG:  
DBG:  //=
DBG:  
DBG:

Will bisect.

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


[Bug 93649] [radeonsi] Graphics lockup while playing tf2

2016-09-24 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=93649

--- Comment #39 from hofmann.zachary at gmail.com ---
I'm also having this problem with Radeon R7 250 (radeonsi), Mesa 12.0.2, LLVM
3.8.1 and kernel version 4.6.0.

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


[Bug 172421] radeon: allow to set the TMDS frequency by a special kernel parameter

2016-09-24 Thread bugzilla-dae...@bugzilla.kernel.org
https://bugzilla.kernel.org/show_bug.cgi?id=172421

--- Comment #17 from Elmar Stellnberger  ---
  The patch does not only allow overclocking; it can also be used to disable
the duallink feature. In certain cases this may be necessary to get a picture
at all (see comment 12).

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


[Bug 97879] [amdgpu] Rocket League: long hangs (several seconds) when loading assets (models/textures/shaders?)

2016-09-24 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=97879

--- Comment #13 from hofmann.zachary at gmail.com ---
I can also confirm this problem with Radeon R7 250 (radeonsi), Mesa 12.0.2,
LLVM 3.8.1 and kernel version 4.6.0.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160924/af5a4a5f/attachment.html>


[PATCH] dma-buf/sw_sync: mark sync_timeline_create() static

2016-09-24 Thread Baoyou Xie
We get 1 warning when building kernel with W=1:
drivers/dma-buf/sw_sync.c:87:23: warning: no previous prototype for 
'sync_timeline_create' [-Wmissing-prototypes]

In fact, this function is only used in the file in which it is
declared and don't need a declaration, but can be made static.
So this patch marks it 'static'.

Signed-off-by: Baoyou Xie 
---
 drivers/dma-buf/sw_sync.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/dma-buf/sw_sync.c b/drivers/dma-buf/sw_sync.c
index 62e8e6d..6f16c85 100644
--- a/drivers/dma-buf/sw_sync.c
+++ b/drivers/dma-buf/sw_sync.c
@@ -84,7 +84,7 @@ static inline struct sync_pt *fence_to_sync_pt(struct fence 
*fence)
  * Creates a new sync_timeline. Returns the sync_timeline object or NULL in
  * case of error.
  */
-struct sync_timeline *sync_timeline_create(const char *name)
+static struct sync_timeline *sync_timeline_create(const char *name)
 {
struct sync_timeline *obj;

-- 
2.7.4



[Bug 97806] GPU lockup with mesa-git and llvm-svn with rx 470 on Unigine Heaven and TombRaider 2013

2016-09-24 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=97806

Laurent carlier  changed:

   What|Removed |Added

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

--- Comment #13 from Laurent carlier  ---
Fixed with llvm commit:
Author: vpykhtin
Date: Fri Sep 23 16:21:21 2016
New Revision: 282296

URL: http://llvm.org/viewvc/llvm-project?rev=282296&view=rev
Log:
[AMDGPU] Fix for bz30427: wrong MTBUF encoding on VI

Differential revision: https://reviews.llvm.org/D24875

--
llvm bug report https://llvm.org/bugs/show_bug.cgi?id=30427

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


[PATCH] dma-buf/sw_sync: mark sync_timeline_create() static

2016-09-24 Thread Arnd Bergmann
On Saturday, September 24, 2016 12:33:46 PM CEST Baoyou Xie wrote:
> We get 1 warning when building kernel with W=1:
> drivers/dma-buf/sw_sync.c:87:23: warning: no previous prototype for 
> 'sync_timeline_create' [-Wmissing-prototypes]
> 
> In fact, this function is only used in the file in which it is
> declared and don't need a declaration, but can be made static.
> So this patch marks it 'static'.
> 
> Signed-off-by: Baoyou Xie 
> 

Acked-by: Arnd Bergmann 


[RFC v2] drm/exynos: g2d: fix runtime PM

2016-09-24 Thread Tobias Jakobi
The commit b05984e21a7e000bf5074ace00d7a574944b2c16 broke
operation of the G2D. After this commit the following
happens.
- exynos_g2d_exec_ioctl() prepares a runqueue node and
  calls g2d_exec_runqueue()
- g2d_exec_runqueue() calls g2d_dma_start() which gets
  runtime PM sync
- runtime PM calls g2d_runtime_resume()
- g2d_runtime_resume() calls g2d_exec_runqueue()

Luckily for us this doesn't really loop, but creates a
mutex lockup, which the kernel even predicts.

Anyway, we fix this by reintroducing dedicated sleep
operations again, and only letting runtime PM control
the gate clock.

This is not enough to fix the issue though.
- We switch runtime PM to autosuspend. Currently clocks get
  disabled, and then re-enabled again in the runqueue worker
  when a node is completed and the next is started.
  With the upcoming introduction of IOMMU runtime PM this
  situations gets worse, since now also the IOMMU goes
  through a disable/enable cycle before the next node is
  started.
- We consolidate all runtime PM management to the runqueue
  worker.
- We introduce g2d_wait_finish() which waits until the currently
  processed runqueue node is finished.
  If this takes too long, the engine is forcibly reset. This
  is necessary to properly close the driver in case the engine
  should hang with read/write access to some area of memory.
  In this situation we can't properly unmap GEM/userptr
  objects, since this might create a pagefault.
- Sleep suspend issues a suspend of the runqueue and then calls
  g2d_wait_finish(), which returns the engine in the idle state.
  The current runqueue node gets completed, all other queued
  nodes stay in the queue. There is no hardware state that
  needs to be retained.
- Sleep resume just pokes the runqueue worker, which, should
  something be in queue, continues its work, or just exits.

Changes in v2:
- disable autosuspend mode again in g2d_remove()
- only get sync in g2d_runqueue_worker() if there is node
  in the queue left

Signed-off-by: Tobias Jakobi 
---
 drivers/gpu/drm/exynos/exynos_drm_g2d.c | 237 +---
 1 file changed, 188 insertions(+), 49 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_g2d.c 
b/drivers/gpu/drm/exynos/exynos_drm_g2d.c
index 6eca8bb..c3f839c 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_g2d.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_g2d.c
@@ -138,6 +138,18 @@ enum g2d_reg_type {
MAX_REG_TYPE_NR
 };

+enum g2d_flag_bits {
+   /*
+* If set, suspends the runqueue worker after the currently
+* processed node is finished.
+*/
+   G2D_BIT_SUSPEND_RUNQUEUE,
+   /*
+* If set, indicates that the engine is currently busy.
+*/
+   G2D_BIT_ENGINE_BUSY,
+};
+
 /* cmdlist data structure */
 struct g2d_cmdlist {
u32 head;
@@ -226,7 +238,7 @@ struct g2d_data {
struct workqueue_struct *g2d_workq;
struct work_struct  runqueue_work;
struct exynos_drm_subdrvsubdrv;
-   boolsuspended;
+   unsigned long   flags;

/* cmdlist */
struct g2d_cmdlist_node *cmdlist_node;
@@ -246,6 +258,12 @@ struct g2d_data {
unsigned long   max_pool;
 };

+static inline void g2d_hw_reset(struct g2d_data *g2d)
+{
+   writel(G2D_R | G2D_SFRCLEAR, g2d->regs + G2D_SOFT_RESET);
+   clear_bit(G2D_BIT_ENGINE_BUSY, &g2d->flags);
+}
+
 static int g2d_init_cmdlist(struct g2d_data *g2d)
 {
struct device *dev = g2d->dev;
@@ -803,12 +821,8 @@ static void g2d_dma_start(struct g2d_data *g2d,
struct g2d_cmdlist_node *node =
list_first_entry(&runqueue_node->run_cmdlist,
struct g2d_cmdlist_node, list);
-   int ret;
-
-   ret = pm_runtime_get_sync(g2d->dev);
-   if (ret < 0)
-   return;

+   set_bit(G2D_BIT_ENGINE_BUSY, &g2d->flags);
writel_relaxed(node->dma_addr, g2d->regs + G2D_DMA_SFR_BASE_ADDR);
writel_relaxed(G2D_DMA_START, g2d->regs + G2D_DMA_COMMAND);
 }
@@ -831,9 +845,6 @@ static void g2d_free_runqueue_node(struct g2d_data *g2d,
 {
struct g2d_cmdlist_node *node;

-   if (!runqueue_node)
-   return;
-
mutex_lock(&g2d->cmdlist_mutex);
/*
 * commands in run_cmdlist have been completed so unmap all gem
@@ -847,29 +858,64 @@ static void g2d_free_runqueue_node(struct g2d_data *g2d,
kmem_cache_free(g2d->runqueue_slab, runqueue_node);
 }

-static void g2d_exec_runqueue(struct g2d_data *g2d)
+/**
+ * g2d_remove_runqueue_nodes - remove items from the list of runqueue nodes
+ * @g2d: G2D state object
+ * @file: if not zero, only remove items with this DRM file
+ *
+ * Has to be called under runqueue lock.
+ */
+static void g2d_remove_runqueue_nodes(struct g2d_data *g2d, struct drm_file* 
file)
 {
-   g2d->runqueue_node = g2d_get_runqueue_no