[Bug 58042] Garbled UI in Team Fortress 2 Beta

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

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

--- Comment #3 from dev at stuffit.at ---
Only tried it with mesa from git but i can give 9.0 a shot. Though as far as I
know the native client is not officially released yet, so I don't know if
bisecting will help.

-- 
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/20121210/2d50c01a/attachment.html>

[RFC v2 5/5] drm/exynos: add gsc ipp driver

[Eunchul Kim]

GSC is stand for General SCaler and supports supports
image scaler/rotator/crop/flip/csc and input/output DMA operations.
input DMA reads image data from the memory.
output DMA writes image data to memory.
GSC supports image rotation and imag effect functions.
also supports writeback and display output operations.

Signed-off-by: Eunchul Kim 
Signed-off-by: Jinyoung Jeon 
---
 drivers/gpu/drm/exynos/Kconfig  |5 +
 drivers/gpu/drm/exynos/Makefile |1 +
 drivers/gpu/drm/exynos/exynos_drm_drv.c |   15 +
 drivers/gpu/drm/exynos/exynos_drm_drv.h |1 +
 drivers/gpu/drm/exynos/exynos_drm_gsc.c | 1476 +++
 drivers/gpu/drm/exynos/exynos_drm_gsc.h |   35 +
 drivers/gpu/drm/exynos/regs-gsc.h   |  295 ++
 include/drm/exynos_drm.h|   15 +
 8 files changed, 1843 insertions(+), 0 deletions(-)
 create mode 100644 drivers/gpu/drm/exynos/exynos_drm_gsc.c
 create mode 100644 drivers/gpu/drm/exynos/exynos_drm_gsc.h
 create mode 100644 drivers/gpu/drm/exynos/regs-gsc.h

diff --git a/drivers/gpu/drm/exynos/Kconfig b/drivers/gpu/drm/exynos/Kconfig
index 4860835..c93d776 100644
--- a/drivers/gpu/drm/exynos/Kconfig
+++ b/drivers/gpu/drm/exynos/Kconfig
@@ -64,3 +64,8 @@ config DRM_EXYNOS_ROTATOR
help
  Choose this option if you want to use Exynos Rotator for DRM.

+config DRM_EXYNOS_GSC
+   bool "Exynos DRM GSC"
+   depends on DRM_EXYNOS_IPP && ARCH_EXYNOS5
+   help
+ Choose this option if you want to use Exynos GSC for DRM.
diff --git a/drivers/gpu/drm/exynos/Makefile b/drivers/gpu/drm/exynos/Makefile
index 3b70668..639b49e 100644
--- a/drivers/gpu/drm/exynos/Makefile
+++ b/drivers/gpu/drm/exynos/Makefile
@@ -19,5 +19,6 @@ exynosdrm-$(CONFIG_DRM_EXYNOS_G2D)+= exynos_drm_g2d.o
 exynosdrm-$(CONFIG_DRM_EXYNOS_IPP) += exynos_drm_ipp.o
 exynosdrm-$(CONFIG_DRM_EXYNOS_FIMC)+= exynos_drm_fimc.o
 exynosdrm-$(CONFIG_DRM_EXYNOS_ROTATOR) += exynos_drm_rotator.o
+exynosdrm-$(CONFIG_DRM_EXYNOS_GSC) += exynos_drm_gsc.o

 obj-$(CONFIG_DRM_EXYNOS)   += exynosdrm.o
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c 
b/drivers/gpu/drm/exynos/exynos_drm_drv.c
index 09d884b..e0a8e80 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
@@ -384,6 +384,12 @@ static int __init exynos_drm_init(void)
goto out_rotator;
 #endif

+#ifdef CONFIG_DRM_EXYNOS_GSC
+   ret = platform_driver_register(_driver);
+   if (ret < 0)
+   goto out_gsc;
+#endif
+
 #ifdef CONFIG_DRM_EXYNOS_IPP
ret = platform_driver_register(_driver);
if (ret < 0)
@@ -412,6 +418,11 @@ out_drm:
 out_ipp:
 #endif

+#ifdef CONFIG_DRM_EXYNOS_GSC
+   platform_driver_unregister(_driver);
+out_gsc:
+#endif
+
 #ifdef CONFIG_DRM_EXYNOS_ROTATOR
platform_driver_unregister(_driver);
 out_rotator:
@@ -462,6 +473,10 @@ static void __exit exynos_drm_exit(void)
platform_driver_unregister(_driver);
 #endif

+#ifdef CONFIG_DRM_EXYNOS_GSC
+   platform_driver_unregister(_driver);
+#endif
+
 #ifdef CONFIG_DRM_EXYNOS_ROTATOR
platform_driver_unregister(_driver);
 #endif
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.h 
b/drivers/gpu/drm/exynos/exynos_drm_drv.h
index a74e37c..afe556c 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.h
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.h
@@ -354,5 +354,6 @@ extern struct platform_driver vidi_driver;
 extern struct platform_driver g2d_driver;
 extern struct platform_driver fimc_driver;
 extern struct platform_driver rotator_driver;
+extern struct platform_driver gsc_driver;
 extern struct platform_driver ipp_driver;
 #endif
diff --git a/drivers/gpu/drm/exynos/exynos_drm_gsc.c 
b/drivers/gpu/drm/exynos/exynos_drm_gsc.c
new file mode 100644
index 000..614365e
--- /dev/null
+++ b/drivers/gpu/drm/exynos/exynos_drm_gsc.c
@@ -0,0 +1,1476 @@
+/*
+ * Copyright (C) 2012 Samsung Electronics Co.Ltd
+ * Authors:
+ * Eunchul Kim 
+ * Jinyoung Jeon 
+ * Sangmin Lee 
+ *
+ * This program is free software; you can redistribute  it and/or modify it
+ * under  the terms of  the GNU General  Public License as published by the
+ * Free Software Foundation;  either version 2 of the  License, or (at your
+ * option) any later version.
+ *
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include "regs-gsc.h"
+#include "exynos_drm_drv.h"
+#include "exynos_drm_gem.h"
+#include "exynos_drm_ipp.h"
+#include "exynos_drm_gsc.h"
+
+/*
+ * GSC is stand for General SCaler and
+ * supports image scaler/rotator and input/output DMA operations.
+ * input DMA reads image data from the memory.
+ * output DMA writes image data to memory.
+ * GSC supports image rotation and image effect functions.
+ */
+
+#define GSC_MAX_DEVS   4
+#define GSC_MAX_SRC8
+#define GSC_MAX_DST32
+#define GSC_RESET_TIMEOUT  50
+#define GSC_CLK_RATE   16675
+#define 

[RFC v2 4/5] drm/exynos: add rotator ipp driver

[Eunchul Kim]

Rotator supports rotation/crop/flip and input/output DMA operations
Rotator ipp driver supports 90,180,270 degree rotaion and vertical, horizontal 
flip.
and has some limitations(source and destination format have to be same, no 
scaler)

Signed-off-by: Eunchul Kim 
Signed-off-by: Youngjun Cho 
---
 drivers/gpu/drm/exynos/Kconfig  |7 +
 drivers/gpu/drm/exynos/Makefile |1 +
 drivers/gpu/drm/exynos/exynos_drm_drv.c |   15 +
 drivers/gpu/drm/exynos/exynos_drm_drv.h |1 +
 drivers/gpu/drm/exynos/exynos_drm_rotator.c |  801 +++
 drivers/gpu/drm/exynos/exynos_drm_rotator.h |   13 +
 drivers/gpu/drm/exynos/regs-rotator.h   |   73 +++
 7 files changed, 911 insertions(+), 0 deletions(-)
 create mode 100644 drivers/gpu/drm/exynos/exynos_drm_rotator.c
 create mode 100644 drivers/gpu/drm/exynos/exynos_drm_rotator.h
 create mode 100644 drivers/gpu/drm/exynos/regs-rotator.h

diff --git a/drivers/gpu/drm/exynos/Kconfig b/drivers/gpu/drm/exynos/Kconfig
index 4915ab6..4860835 100644
--- a/drivers/gpu/drm/exynos/Kconfig
+++ b/drivers/gpu/drm/exynos/Kconfig
@@ -57,3 +57,10 @@ config DRM_EXYNOS_FIMC
depends on DRM_EXYNOS_IPP
help
  Choose this option if you want to use Exynos FIMC for DRM.
+
+config DRM_EXYNOS_ROTATOR
+   bool "Exynos DRM Rotator"
+   depends on DRM_EXYNOS_IPP
+   help
+ Choose this option if you want to use Exynos Rotator for DRM.
+
diff --git a/drivers/gpu/drm/exynos/Makefile b/drivers/gpu/drm/exynos/Makefile
index 9710024..3b70668 100644
--- a/drivers/gpu/drm/exynos/Makefile
+++ b/drivers/gpu/drm/exynos/Makefile
@@ -18,5 +18,6 @@ exynosdrm-$(CONFIG_DRM_EXYNOS_VIDI)   += exynos_drm_vidi.o
 exynosdrm-$(CONFIG_DRM_EXYNOS_G2D) += exynos_drm_g2d.o
 exynosdrm-$(CONFIG_DRM_EXYNOS_IPP) += exynos_drm_ipp.o
 exynosdrm-$(CONFIG_DRM_EXYNOS_FIMC)+= exynos_drm_fimc.o
+exynosdrm-$(CONFIG_DRM_EXYNOS_ROTATOR) += exynos_drm_rotator.o

 obj-$(CONFIG_DRM_EXYNOS)   += exynosdrm.o
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c 
b/drivers/gpu/drm/exynos/exynos_drm_drv.c
index 73f02ac..09d884b 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
@@ -378,6 +378,12 @@ static int __init exynos_drm_init(void)
goto out_fimc;
 #endif

+#ifdef CONFIG_DRM_EXYNOS_ROTATOR
+   ret = platform_driver_register(_driver);
+   if (ret < 0)
+   goto out_rotator;
+#endif
+
 #ifdef CONFIG_DRM_EXYNOS_IPP
ret = platform_driver_register(_driver);
if (ret < 0)
@@ -406,6 +412,11 @@ out_drm:
 out_ipp:
 #endif

+#ifdef CONFIG_DRM_EXYNOS_ROTATOR
+   platform_driver_unregister(_driver);
+out_rotator:
+#endif
+
 #ifdef CONFIG_DRM_EXYNOS_FIMC
platform_driver_unregister(_driver);
 out_fimc:
@@ -451,6 +462,10 @@ static void __exit exynos_drm_exit(void)
platform_driver_unregister(_driver);
 #endif

+#ifdef CONFIG_DRM_EXYNOS_ROTATOR
+   platform_driver_unregister(_driver);
+#endif
+
 #ifdef CONFIG_DRM_EXYNOS_FIMC
platform_driver_unregister(_driver);
 #endif
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.h 
b/drivers/gpu/drm/exynos/exynos_drm_drv.h
index 14f9490..a74e37c 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.h
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.h
@@ -353,5 +353,6 @@ extern struct platform_driver exynos_drm_common_hdmi_driver;
 extern struct platform_driver vidi_driver;
 extern struct platform_driver g2d_driver;
 extern struct platform_driver fimc_driver;
+extern struct platform_driver rotator_driver;
 extern struct platform_driver ipp_driver;
 #endif
diff --git a/drivers/gpu/drm/exynos/exynos_drm_rotator.c 
b/drivers/gpu/drm/exynos/exynos_drm_rotator.c
new file mode 100644
index 000..347de99
--- /dev/null
+++ b/drivers/gpu/drm/exynos/exynos_drm_rotator.c
@@ -0,0 +1,801 @@
+/*
+ * Copyright (C) 2012 Samsung Electronics Co.Ltd
+ * Authors:
+ * YoungJun Cho 
+ * Eunchul Kim 
+ *
+ * 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 Foundationr
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include "regs-rotator.h"
+#include "exynos_drm.h"
+#include "exynos_drm_drv.h"
+#include "exynos_drm_ipp.h"
+
+enum rot_irq_status {
+   ROT_IRQ_STATUS_COMPLETE = 8,
+   ROT_IRQ_STATUS_ILLEGAL  = 9,
+};
+
+struct rot_limit {
+   u32 min_w;
+   u32 min_h;
+   u32 max_w;
+   u32 max_h;
+   u32 align;
+};
+
+struct rot_limit_table {
+   struct rot_limitycbcr420_2p;
+   struct rot_limitrgb888;
+};
+
+struct rot_context {
+   struct rot_limit_table  *limit_tbl;
+   struct clk  *clock;
+   struct resource *regs_res;
+   void __iomem*regs;
+   int irq;
+   struct exynos_drm_ippdrv  

[RFC v2 3/5] drm/exynos: add fimc ipp driver

[Eunchul Kim]

FIMC is stand for Fully Interfactive Mobile Camera and
supports image scaler/rotator/crop/flip/csc and input/output DMA operations.
input DMA reads image data from the memory.
output DMA writes image data to memory.
FIMC supports image rotation and image effect functions.
also supports writeback and display output operations.

Signed-off-by: Eunchul Kim 
Signed-off-by: Jinyoung Jeon 
---
 drivers/gpu/drm/exynos/Kconfig   |6 +
 drivers/gpu/drm/exynos/Makefile  |1 +
 drivers/gpu/drm/exynos/exynos_drm_drv.c  |   15 +
 drivers/gpu/drm/exynos/exynos_drm_drv.h  |1 +
 drivers/gpu/drm/exynos/exynos_drm_fimc.c | 2041 ++
 drivers/gpu/drm/exynos/exynos_drm_fimc.h |   35 +
 drivers/gpu/drm/exynos/regs-fimc.h   |  669 ++
 include/drm/exynos_drm.h |   34 +
 8 files changed, 2802 insertions(+), 0 deletions(-)
 create mode 100644 drivers/gpu/drm/exynos/exynos_drm_fimc.c
 create mode 100644 drivers/gpu/drm/exynos/exynos_drm_fimc.h
 create mode 100644 drivers/gpu/drm/exynos/regs-fimc.h

diff --git a/drivers/gpu/drm/exynos/Kconfig b/drivers/gpu/drm/exynos/Kconfig
index bcf1c9d..4915ab6 100644
--- a/drivers/gpu/drm/exynos/Kconfig
+++ b/drivers/gpu/drm/exynos/Kconfig
@@ -51,3 +51,9 @@ config DRM_EXYNOS_IPP
depends on DRM_EXYNOS
help
  Choose this option if you want to use IPP feature for DRM.
+
+config DRM_EXYNOS_FIMC
+   bool "Exynos DRM FIMC"
+   depends on DRM_EXYNOS_IPP
+   help
+ Choose this option if you want to use Exynos FIMC for DRM.
diff --git a/drivers/gpu/drm/exynos/Makefile b/drivers/gpu/drm/exynos/Makefile
index 6c536ce..9710024 100644
--- a/drivers/gpu/drm/exynos/Makefile
+++ b/drivers/gpu/drm/exynos/Makefile
@@ -17,5 +17,6 @@ exynosdrm-$(CONFIG_DRM_EXYNOS_HDMI)   += exynos_hdmi.o 
exynos_mixer.o \
 exynosdrm-$(CONFIG_DRM_EXYNOS_VIDI)+= exynos_drm_vidi.o
 exynosdrm-$(CONFIG_DRM_EXYNOS_G2D) += exynos_drm_g2d.o
 exynosdrm-$(CONFIG_DRM_EXYNOS_IPP) += exynos_drm_ipp.o
+exynosdrm-$(CONFIG_DRM_EXYNOS_FIMC)+= exynos_drm_fimc.o

 obj-$(CONFIG_DRM_EXYNOS)   += exynosdrm.o
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c 
b/drivers/gpu/drm/exynos/exynos_drm_drv.c
index 0eb8a97..73f02ac 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
@@ -372,6 +372,12 @@ static int __init exynos_drm_init(void)
goto out_g2d;
 #endif

+#ifdef CONFIG_DRM_EXYNOS_FIMC
+   ret = platform_driver_register(_driver);
+   if (ret < 0)
+   goto out_fimc;
+#endif
+
 #ifdef CONFIG_DRM_EXYNOS_IPP
ret = platform_driver_register(_driver);
if (ret < 0)
@@ -400,6 +406,11 @@ out_drm:
 out_ipp:
 #endif

+#ifdef CONFIG_DRM_EXYNOS_FIMC
+   platform_driver_unregister(_driver);
+out_fimc:
+#endif
+
 #ifdef CONFIG_DRM_EXYNOS_G2D
platform_driver_unregister(_driver);
 out_g2d:
@@ -440,6 +451,10 @@ static void __exit exynos_drm_exit(void)
platform_driver_unregister(_driver);
 #endif

+#ifdef CONFIG_DRM_EXYNOS_FIMC
+   platform_driver_unregister(_driver);
+#endif
+
 #ifdef CONFIG_DRM_EXYNOS_G2D
platform_driver_unregister(_driver);
 #endif
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.h 
b/drivers/gpu/drm/exynos/exynos_drm_drv.h
index a365788..14f9490 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.h
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.h
@@ -352,5 +352,6 @@ extern struct platform_driver mixer_driver;
 extern struct platform_driver exynos_drm_common_hdmi_driver;
 extern struct platform_driver vidi_driver;
 extern struct platform_driver g2d_driver;
+extern struct platform_driver fimc_driver;
 extern struct platform_driver ipp_driver;
 #endif
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimc.c 
b/drivers/gpu/drm/exynos/exynos_drm_fimc.c
new file mode 100644
index 000..3adb452
--- /dev/null
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimc.c
@@ -0,0 +1,2041 @@
+/*
+ * Copyright (C) 2012 Samsung Electronics Co.Ltd
+ * Authors:
+ * Eunchul Kim 
+ * Jinyoung Jeon 
+ * Sangmin Lee 
+ *
+ * This program is free software; you can redistribute  it and/or modify it
+ * under  the terms of  the GNU General  Public License as published by the
+ * Free Software Foundation;  either version 2 of the  License, or (at your
+ * option) any later version.
+ *
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include "regs-fimc.h"
+#include "exynos_drm_drv.h"
+#include "exynos_drm_gem.h"
+#include "exynos_drm_ipp.h"
+#include "exynos_drm_fimc.h"
+
+/*
+ * FIMC is stand for Fully Interactive Mobile Camera and
+ * supports image scaler/rotator and input/output DMA operations.
+ * input DMA reads image data from the memory.
+ * output DMA writes image data to memory.
+ * FIMC supports image rotation and image effect functions.
+ */
+
+#define FIMC_MAX_DEVS  4
+#define FIMC_MAX_SRC   2
+#define FIMC_MAX_DST   32
+#define 

[RFC v2 2/5] drm/exynos: add iommu support for ipp

[Eunchul Kim]

This patch adds iommu support for ipp. For this, it
adds subdrv_probe/remove callback to enable or disable ipp iommu.
we can get or put device address to a gem handle from user
through exynos_drm_gem_get/put_dma_addr().

Signed-off-by: Eunchul Kim 
Signed-off-by: Jinyoung Jeon 
---
 drivers/gpu/drm/exynos/exynos_drm_ipp.c |   18 ++
 1 files changed, 18 insertions(+), 0 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_ipp.c 
b/drivers/gpu/drm/exynos/exynos_drm_ipp.c
index 2d84477..c582300 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_ipp.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_ipp.c
@@ -23,6 +23,7 @@
 #include "exynos_drm_drv.h"
 #include "exynos_drm_gem.h"
 #include "exynos_drm_ipp.h"
+#include "exynos_drm_iommu.h"

 /*
  * IPP is stand for Image Post Processing and
@@ -1668,10 +1669,24 @@ static int ipp_subdrv_probe(struct drm_device *drm_dev, 
struct device *dev)
ippdrv->event_workq = ctx->event_workq;
ippdrv->sched_event = ipp_sched_event;
INIT_LIST_HEAD(>cmd_list);
+
+   if (is_drm_iommu_supported(drm_dev)) {
+   ret = drm_iommu_attach_device(drm_dev, ippdrv->dev);
+   if (ret) {
+   DRM_ERROR("failed to activate iommu\n");
+   goto err_iommu;
+   }
+   }
}

return 0;

+err_iommu:
+   /* get ipp driver entry */
+   list_for_each_entry_reverse(ippdrv, _drm_ippdrv_list, drv_list)
+   if (is_drm_iommu_supported(drm_dev))
+   drm_iommu_detach_device(drm_dev, ippdrv->dev);
+
 err_idr:
idr_remove_all(>ipp_idr);
idr_remove_all(>prop_idr);
@@ -1689,6 +1704,9 @@ static void ipp_subdrv_remove(struct drm_device *drm_dev, 
struct device *dev)

/* get ipp driver entry */
list_for_each_entry(ippdrv, _drm_ippdrv_list, drv_list) {
+   if (is_drm_iommu_supported(drm_dev))
+   drm_iommu_detach_device(drm_dev, ippdrv->dev);
+
ippdrv->drm_dev = NULL;
exynos_drm_ippdrv_unregister(ippdrv);
}
-- 
1.7.0.4

[RFC v2 1/5] drm/exynos: add ipp subsystem

[Eunchul Kim]

IPP stand for Image Post Processing and supports image scaler/rotator
/crop/flip/csc(color space conversion) and input/output DMA operations using 
ipp drivers.
also supports writeback and display output operations.
ipp driver include FIMC, Rotator, GSC, SC, so on.
and ipp is integration device driver for each hardware.

Signed-off-by: Eunchul Kim 
Signed-off-by: Jinyoung Jeon 
---
 drivers/gpu/drm/exynos/Kconfig  |6 +
 drivers/gpu/drm/exynos/Makefile |1 +
 drivers/gpu/drm/exynos/exynos_drm_drv.c |   24 +
 drivers/gpu/drm/exynos/exynos_drm_drv.h |7 +
 drivers/gpu/drm/exynos/exynos_drm_ipp.c | 1944 +++
 drivers/gpu/drm/exynos/exynos_drm_ipp.h |  266 +
 include/uapi/drm/exynos_drm.h   |  189 +++
 7 files changed, 2437 insertions(+), 0 deletions(-)
 create mode 100644 drivers/gpu/drm/exynos/exynos_drm_ipp.c
 create mode 100644 drivers/gpu/drm/exynos/exynos_drm_ipp.h

diff --git a/drivers/gpu/drm/exynos/Kconfig b/drivers/gpu/drm/exynos/Kconfig
index 4ea8cdc..bcf1c9d 100644
--- a/drivers/gpu/drm/exynos/Kconfig
+++ b/drivers/gpu/drm/exynos/Kconfig
@@ -45,3 +45,9 @@ config DRM_EXYNOS_G2D
depends on DRM_EXYNOS && !VIDEO_SAMSUNG_S5P_G2D
help
  Choose this option if you want to use Exynos G2D for DRM.
+
+config DRM_EXYNOS_IPP
+   bool "Exynos DRM IPP"
+   depends on DRM_EXYNOS
+   help
+ Choose this option if you want to use IPP feature for DRM.
diff --git a/drivers/gpu/drm/exynos/Makefile b/drivers/gpu/drm/exynos/Makefile
index 26813b8..6c536ce 100644
--- a/drivers/gpu/drm/exynos/Makefile
+++ b/drivers/gpu/drm/exynos/Makefile
@@ -16,5 +16,6 @@ exynosdrm-$(CONFIG_DRM_EXYNOS_HDMI)   += exynos_hdmi.o 
exynos_mixer.o \
   exynos_drm_hdmi.o
 exynosdrm-$(CONFIG_DRM_EXYNOS_VIDI)+= exynos_drm_vidi.o
 exynosdrm-$(CONFIG_DRM_EXYNOS_G2D) += exynos_drm_g2d.o
+exynosdrm-$(CONFIG_DRM_EXYNOS_IPP) += exynos_drm_ipp.o

 obj-$(CONFIG_DRM_EXYNOS)   += exynosdrm.o
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c 
b/drivers/gpu/drm/exynos/exynos_drm_drv.c
index 4a1168d..0eb8a97 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
@@ -40,6 +40,7 @@
 #include "exynos_drm_vidi.h"
 #include "exynos_drm_dmabuf.h"
 #include "exynos_drm_g2d.h"
+#include "exynos_drm_ipp.h"
 #include "exynos_drm_iommu.h"

 #define DRIVER_NAME"exynos"
@@ -249,6 +250,14 @@ static struct drm_ioctl_desc exynos_ioctls[] = {
exynos_g2d_set_cmdlist_ioctl, DRM_UNLOCKED | DRM_AUTH),
DRM_IOCTL_DEF_DRV(EXYNOS_G2D_EXEC,
exynos_g2d_exec_ioctl, DRM_UNLOCKED | DRM_AUTH),
+   DRM_IOCTL_DEF_DRV(EXYNOS_IPP_GET_PROPERTY,
+   exynos_drm_ipp_get_property, DRM_UNLOCKED | DRM_AUTH),
+   DRM_IOCTL_DEF_DRV(EXYNOS_IPP_SET_PROPERTY,
+   exynos_drm_ipp_set_property, DRM_UNLOCKED | DRM_AUTH),
+   DRM_IOCTL_DEF_DRV(EXYNOS_IPP_QUEUE_BUF,
+   exynos_drm_ipp_queue_buf, DRM_UNLOCKED | DRM_AUTH),
+   DRM_IOCTL_DEF_DRV(EXYNOS_IPP_CMD_CTRL,
+   exynos_drm_ipp_cmd_ctrl, DRM_UNLOCKED | DRM_AUTH),
 };

 static const struct file_operations exynos_drm_driver_fops = {
@@ -363,6 +372,12 @@ static int __init exynos_drm_init(void)
goto out_g2d;
 #endif

+#ifdef CONFIG_DRM_EXYNOS_IPP
+   ret = platform_driver_register(_driver);
+   if (ret < 0)
+   goto out_ipp;
+#endif
+
ret = platform_driver_register(_drm_platform_driver);
if (ret < 0)
goto out_drm;
@@ -380,6 +395,11 @@ out:
platform_driver_unregister(_drm_platform_driver);

 out_drm:
+#ifdef CONFIG_DRM_EXYNOS_IPP
+   platform_driver_unregister(_driver);
+out_ipp:
+#endif
+
 #ifdef CONFIG_DRM_EXYNOS_G2D
platform_driver_unregister(_driver);
 out_g2d:
@@ -416,6 +436,10 @@ static void __exit exynos_drm_exit(void)

platform_driver_unregister(_drm_platform_driver);

+#ifdef CONFIG_DRM_EXYNOS_IPP
+   platform_driver_unregister(_driver);
+#endif
+
 #ifdef CONFIG_DRM_EXYNOS_G2D
platform_driver_unregister(_driver);
 #endif
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.h 
b/drivers/gpu/drm/exynos/exynos_drm_drv.h
index a9db025..a365788 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.h
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.h
@@ -235,8 +235,14 @@ struct exynos_drm_g2d_private {
unsigned intgem_nr;
 };

+struct exynos_drm_ipp_private {
+   struct device   *dev;
+   struct list_headevent_list;
+};
+
 struct drm_exynos_file_private {
struct exynos_drm_g2d_private   *g2d_priv;
+   struct exynos_drm_ipp_private   *ipp_priv;
 };

 /*
@@ -346,4 +352,5 @@ extern struct platform_driver mixer_driver;
 extern struct platform_driver exynos_drm_common_hdmi_driver;
 extern struct platform_driver vidi_driver;
 extern struct platform_driver 

[RFC v2 0/5] drm/exynos: add ipp subsystem and each ipp drivers

[Eunchul Kim]

Changelog v2:
Hi All.

This RFC v2 supports iommu in ipp. and Added/Removed comment from Inki.Dae.
Fixed GSC part bugs and next time I will send our local git commit.
and We finished implementation of SC for post-processing.
SC driver not fully tested yet. so, I didn't add SC feature in this patch.

Thank's

Changelog v1:

Hi All.

I am responsible for a display part from Samsung Electronics Telecommunication 
Division.
and I am going to add post-processing features in exynos drm.
If you have some opinions of this patch,
please give some comments about my patch.

This patch is post-processing(IPP) support for exynos drm driver.

IPP is stands for Image Post Processing and supports image scaler/rotator
and input/output DMA operations using IPP drivers(FIMC, Rotator, GSC, SC, so 
on.)
IPP is integration device driver of same attibute hardware.

Exynos4 SoC support FIMC, Rotator for post-processing.
and Exynos5 SoC support GSC, Rotator, SC for post-processing.
SC driver not tested yet. so, I didn't add SC feature in this patch.
and IPP subsystem works on Exynos SoC version independently.

IPP drivers supports Memory to Memory operations with various converting.
and some drivers supports Writeback and Display output operations using local 
path.
User can make converted image using this driver.
and also supports streaming concept for multimedia data processing.

And supports various operations
1. Scale operation generates various sizes of image.
2. CSC(Color Space Conversion) operation supports format converting.
3. Crop operation supports cutting the image.
4. Rotate operation supports to 90, 180, 270 degree.
5. Flip operation supports to vertical, horizontal, and both.
6. Writeback operation genertates cloned image from display controller(FIMD).
7. Display output operation support various format display to display 
controller(FIMD).
8. Input DMA reads image data from the memory.
9. Output DMA writes image data to memory.
10. Supports image effect functions.

Descriptions)
User should make property informations and set this property to registers.
and IPP subsystem manages property id using command node and make queue list 
using memory node.
IPP subsystem supports register function of IPP drivers.
IPP driver manages input/output DMA with various operations. and some driver 
supports
optional operations(writeback, output).
IPP driver needs various informations, so User set property information to IPP 
driver.
and also IPP driver needs memory base address of image for various operations.
User doesn't know its address, so fills the gem handle of that memory than 
address of image base.
and than IPP driver start operation.

Ioctls)
We adds four ioctls and one event for IPP subsystem.

- ioctls
DRM_EXYNOS_IPP_GET_PROPERTY : get ipp driver capabilitis and id.
DRM_EXYNOS_IPP_SET_PROPERTY : set format, position, rotation, flip about 
source/destination.
DRM_EXYNOS_IPP_QUEUE_BUF : enqueue/dequeue buffer and make event list.
DRM_EXYNOS_IPP_CMD_CTRL : play/stop/pause/resume control.

- event
DRM_EXYNOS_IPP_EVENT : event to give notification completion of buffer DMA with 
buffer list

Basic control flow and Sample pseudo application)
1. Basic control flow is same as below
Open -> Get properties -> User choose IPP driver and set property information 
-> Set Property -> Create gem handle ->
Queue buffer(Enqueue) of source/destination -> Command control(Play) -> Event 
occured to User
-> User handle converted image -> (Queue buffer(Enqueue) of source/destination 
-> Event occured to User)*N ->
Queue buffer(Dequeue) of source/destination -> Command control(Stop) -> Free 
gem handle -> Close

2. Sample pseudo application
#include "exynos_drm.h"
static int exynos_drm_ipp_set_property(int fd ...)
{
struct drm_exynos_pos crop_pos = {0, 0, hsize, vsize};
struct drm_exynos_pos scale_pos = {0, 0, hsize, vsize};
struct drm_exynos_sz src_sz = {hsize, vsize};
struct drm_exynos_sz dst_sz = {hsize, vsize};
int ret = 0;

memset(property, 0x00, sizeof(struct drm_exynos_ipp_property));
property->cmd = cmd;

property->config[EXYNOS_DRM_OPS_SRC].ops_id = EXYNOS_DRM_OPS_SRC;
property->config[EXYNOS_DRM_OPS_SRC].flip = EXYNOS_DRM_FLIP_NONE;
property->config[EXYNOS_DRM_OPS_SRC].degree = EXYNOS_DRM_DEGREE_0;
property->config[EXYNOS_DRM_OPS_SRC].fmt = DRM_FORMAT_XRGB;
property->config[EXYNOS_DRM_OPS_SRC].pos = crop_pos;
property->config[EXYNOS_DRM_OPS_SRC].sz = src_sz;

property->config[EXYNOS_DRM_OPS_DST].ops_id = EXYNOS_DRM_OPS_DST;
property->config[EXYNOS_DRM_OPS_DST].flip = EXYNOS_DRM_FLIP_NONE;
property->config[EXYNOS_DRM_OPS_DST].degree = degree;
property->config[EXYNOS_DRM_OPS_DST].fmt = DRM_FORMAT_XRGB;
property->config[EXYNOS_DRM_OPS_DST].pos = scale_pos;
property->config[EXYNOS_DRM_OPS_DST].sz = dst_sz;

ret = ioctl(fd, DRM_IOCTL_EXYNOS_IPP_SET_PROPERTY, 

[Bug 50655] ATI RV670 [Radeon HD 3870] Ioquake games causes GPU lockup (waiting for 0x00003039 last fence id 0x00003030)

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

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

--- Comment #21 from Bryan Quigley  ---
Nope, but the patch didn't work as is, so I changed it to:
rctx->framebuffer.atom.dirty = true;

Which may not be what the patch was actually trying to do...

-- 
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/20121210/732b6c17/attachment-0001.html>

[Bug 32131] small corruption around opengl window while using compize cube effect.

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

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

--- Comment #8 from Roman Elshin  ---
It is difficult to say definitely as report was about rv515 which I can not
test right now, but I do not see this any more with rv740 and relatively fresh
distributive (Linux Mint 14), so I think this bug may be closed as resolved.

-- 
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/20121210/d078b758/attachment.html>

[PATCH] drm: Make the HPD status updates debug logs more readable

[Damien Lespiau]

On Tue, Dec 4, 2012 at 5:39 PM, Daniel Vetter  wrote:
> On Tue, Dec 04, 2012 at 04:00:17PM +, Damien Lespiau wrote:
>> From: Damien Lespiau 
>>
>> Instead of just printing "status updated from 1 to 2", make those enum
>> numbers immediately readable.
>>
>> Signed-off-by: Damien Lespiau 
>
> I like, stupid me can never remember the magic values. For the patch
> itself, can you please also patch the connector updates in
> drm_helper_probe_single_connector_modes (which is required to avoid losing
> hpd events when doing a manual probe cycle) and output_poll_execute. For
> completeness maybe also throw in a debug output in
> drm_helper_disable_unused_functions, but that's only relevant for drivers
> that use the modeset helpers (i.e. not for drm/i915).

v2 sent. I think that the current log messages around ->detect in
drm_helper_probe_single_connector_modes() serves as nice guards around
the detection code and went to "fix" a bigger offender, namely logging
all the previously valid modes when detecting a disconnection.

For the last one, leaving the decision of adding yet another log
message to the users of that helper sounds better to me.

-- 
Damien

[PATCH 2/2] drm: Don't prune modes loudly when a connector is disconnected

[Damien Lespiau]

From: Damien Lespiau 

drm_helper_probe_single_connector_modes() is responsible for pruning the
previously detected modes on a disconnected connector. We don't really
need to log, again, the full list of modes that used to be valid when
connected.

Signed-off-by: Damien Lespiau 
---
 drivers/gpu/drm/drm_crtc_helper.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/drm_crtc_helper.c 
b/drivers/gpu/drm/drm_crtc_helper.c
index 524f0d3..865b0f7 100644
--- a/drivers/gpu/drm/drm_crtc_helper.c
+++ b/drivers/gpu/drm/drm_crtc_helper.c
@@ -111,6 +111,7 @@ int drm_helper_probe_single_connector_modes(struct 
drm_connector *connector,
connector->helper_private;
int count = 0;
int mode_flags = 0;
+   bool verbose_prune = true;

DRM_DEBUG_KMS("[CONNECTOR:%d:%s]\n", connector->base.id,
drm_get_connector_name(connector));
@@ -139,6 +140,7 @@ int drm_helper_probe_single_connector_modes(struct 
drm_connector *connector,
DRM_DEBUG_KMS("[CONNECTOR:%d:%s] disconnected\n",
connector->base.id, drm_get_connector_name(connector));
drm_mode_connector_update_edid_property(connector, NULL);
+   verbose_prune = false;
goto prune;
}

@@ -172,7 +174,7 @@ int drm_helper_probe_single_connector_modes(struct 
drm_connector *connector,
}

 prune:
-   drm_mode_prune_invalid(dev, >modes, true);
+   drm_mode_prune_invalid(dev, >modes, verbose_prune);

if (list_empty(>modes))
return 0;
-- 
1.7.11.7

[PATCH 1/2] drm: Make the HPD status updates debug logs more readable

[Damien Lespiau]

From: Damien Lespiau 

Instead of just printing "status updated from 1 to 2", make those enum
numbers immediately readable.

v2: Also patch output_poll_execute() (Daniel Vetter)

Signed-off-by: Damien Lespiau 
---
 drivers/gpu/drm/drm_crtc_helper.c | 22 ++
 1 file changed, 18 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/drm_crtc_helper.c 
b/drivers/gpu/drm/drm_crtc_helper.c
index 1fe719f..524f0d3 100644
--- a/drivers/gpu/drm/drm_crtc_helper.c
+++ b/drivers/gpu/drm/drm_crtc_helper.c
@@ -950,6 +950,18 @@ void drm_kms_helper_hotplug_event(struct drm_device *dev)
 }
 EXPORT_SYMBOL(drm_kms_helper_hotplug_event);

+static const char *connector_status_str(enum drm_connector_status status)
+{
+   switch (status) {
+   case connector_status_connected:
+   return "connected";
+   case connector_status_disconnected:
+   return "disconnected";
+   default:
+   return "unknown";
+   }
+}
+
 #define DRM_OUTPUT_POLL_PERIOD (10*HZ)
 static void output_poll_execute(struct work_struct *work)
 {
@@ -984,10 +996,11 @@ static void output_poll_execute(struct work_struct *work)
continue;

connector->status = connector->funcs->detect(connector, false);
-   DRM_DEBUG_KMS("[CONNECTOR:%d:%s] status updated from %d to 
%d\n",
+   DRM_DEBUG_KMS("[CONNECTOR:%d:%s] status updated from %s to 
%s\n",
  connector->base.id,
  drm_get_connector_name(connector),
- old_status, connector->status);
+ connector_status_str(old_status),
+ connector_status_str(connector->status));
if (old_status != connector->status)
changed = true;
}
@@ -1062,10 +1075,11 @@ void drm_helper_hpd_irq_event(struct drm_device *dev)
old_status = connector->status;

connector->status = connector->funcs->detect(connector, false);
-   DRM_DEBUG_KMS("[CONNECTOR:%d:%s] status updated from %d to 
%d\n",
+   DRM_DEBUG_KMS("[CONNECTOR:%d:%s] status updated from %s to 
%s\n",
  connector->base.id,
  drm_get_connector_name(connector),
- old_status, connector->status);
+ connector_status_str(old_status),
+ connector_status_str(connector->status));
if (old_status != connector->status)
changed = true;
}
-- 
1.7.11.7

[Bug 56405] Distorted graphics on Radeon HD 6620G

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

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

--- Comment #44 from Alex Deucher  ---
(In reply to comment #43)
> (In reply to comment #42)
> > case CHIP_SUMO2:
> > -   rdev->config.evergreen.num_ses = 1;
> > +   rdev->config.evergreen.num_ses = 2;
> > 
> > None of the APUs have multiple SEs.
> 
> So it waste of time, to try that patch?

Please try it.  Your card is not a SUMO2.

-- 
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/20121210/9f66bc0c/attachment-0001.html>

[Nouveau] [PATCH] drm/nouveau: fix takedown in move_notify

[Maarten Lankhorst]

Op 10-12-12 17:39, Emil Velikov schreef:
> On 21/11/12 13:15, Maarten Lankhorst wrote:
>> move_notify is called by ttm after the the object is idle and about
>> to be destroyed. Clean up the vm list properly in that case.
>>
>> This is not a problem right now, since the list should already be
>> empty, but if it wasn't empty, vm_put was not called which leads to
>> random corruption later.
>>
>> With this fix, nouveau_gem_object_close can be safely changed to a noop,
>> forcing the vm bindings to be removed when the original object is. This
>> is not done in this patch since it may lead to the object staying mapped
>> in the vm space until the gem object refcount drops to 0. This shouldn't
>> be a big issue however.
>>
>> If we choose to do so does allow us to use ttm's delayed destruction
>> mechanism to unmap vm after object is idle, resulting in ioread32 no
>> longer taking up 30% of cpu in Team Fortress 2 if I don't do the vma
>> unmap in nouveau_gem_object_close.
>>
>> Signed-off-by: Maarten Lankhorst 
>>
> Hi Maarten
>
> I've noticed ioread32 of up-to 40% on of cpu my system. With your patch
> if goes down to ~3% with no side effects. Frame-rate appears to be
> slightly improved, although it's hard to say.
>
> Is there any reason for holding this patch ?
> For what it's worth you can add
>
> Tested-by: Emil Velikov 
Well 2 reasons..

1) In the current form, you're guaranteed to cause memory corruption on forced 
client takedown. Locking needs more thought.
The warns you get are very real errors. ;-)

>> ---
>> diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c 
>> b/drivers/gpu/drm/nouveau/nouveau_bo.c
>> index 35ac57f..e8a47f0 100644
>> --- a/drivers/gpu/drm/nouveau/nouveau_bo.c
>> +++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
>> @@ -1139,12 +1139,22 @@ nouveau_bo_move_ntfy(struct ttm_buffer_object *bo, 
>> struct ttm_mem_reg *new_mem)
>>  if (bo->destroy != nouveau_bo_del_ttm)
>>  return;
>>  
>> +if (!new_mem) {
>> +while (!list_empty(>vma_list)) {
>> +vma = list_first_entry(>vma_list, struct 
>> nouveau_vma, head);
>> +
>> +nouveau_vm_unmap(vma);
>> +nouveau_vm_put(vma);
>> +list_del(>head);
2. I missed a kfree here ;-)

~Maarten

[Bug 56405] Distorted graphics on Radeon HD 6620G

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

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

--- Comment #43 from klausenbusk at hotmail.com ---
(In reply to comment #42)
>   case CHIP_SUMO2:
> - rdev->config.evergreen.num_ses = 1;
> + rdev->config.evergreen.num_ses = 2;
> 
> None of the APUs have multiple SEs.

So it waste of time, to try that patch?

-- 
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/20121210/d061d184/attachment.html>

[PATCH 0/3] add mie driver for exynos

[Inki Dae]

2012/12/10 St?phane Marchesin 

> On Sun, Dec 9, 2012 at 10:26 PM, Inki Dae  wrote:
> >
> >
> > 2012/12/6 R. Chandrasekar 
> >
> >> From: "R. Chandrasekar" 
> >>
> >> this patch set adds the driver support for the dithering functionality
> of
> >> the
> >> mobile image enhancement (mie) module.
> >>
> >> device tree support is added for mie.
> >>
> >> fimd adds the mie module as plugin and calls the dithering function.
> >> dithere is
> >> required when the panels bpp is less then fimd output.
> >>
> >> though mie mie has other functionalities, current system uses only
> >> dithereing.
> >>
> >
> > Please, move mie module into drivers/video/exynos. The mie is a interface
> > between fimd and lcd panel(or mipi-dsi, eDP) to enhance image to be
> > displayed. And it seems like that this doesn't need drm
> framework-relevant
> > interfaces, such as gem.
>
> Well, if you want to support it from the DRM, it should live in
> drivers/gpu/drm, and I don't think you should add another platform
> driver in the first place. The profusion of platform drivers in exynos
> makes it really difficult to support suspend/resume and initialization
> properly as many devices which operate separately need to sync through
> global variables.
>
>
MIE could be used by linux framebuffer-based specific driver(s3c-fb) also.
If linux framebuffer-based driver want to use this mie module, should the
mie module be placed in drivers/video coping it? I think it's not good so
it's better way to use this mie module commonly without duplicated codes.
And mipi-dsi and eDP drivers also have their own platform device/driver and
are being used by exynos drm driver or s3c-fb driver. Of course, for some
IPs such as mie between display controller and lcd panel, It seems like
that there should be proper framework or interfaces in drivers/video/exynos
or somewhere so that other frameworks can use it commonly. And drm and
linux framebuffer drivers should call the interfaces.

Thanks,
Inki Dae

St?phane
>
>
> >
> > And also, please refer to the below link, Common Display Framework, for
> more
> > generic way.
> >
> >
> http://lists.freedesktop.org/archives/dri-devel/2012-November/030888.html
> >
> > Thanks,
> > Inki Dae
> >
> >>
> >> R. Chandrasekar (3):
> >>   DTS: exynos: add device tree support for exynos mie
> >>   drm: fimd: add mie plugin support for dithering
> >>   drm: mie: add mie driver for exynos
> >>
> >>  arch/arm/boot/dts/exynos5250.dtsi   |7 +-
> >>  drivers/gpu/drm/exynos/Kconfig  |7 +
> >>  drivers/gpu/drm/exynos/Makefile |1 +
> >>  drivers/gpu/drm/exynos/exynos_drm_fimd.c|   58 +-
> >>  drivers/gpu/drm/exynos/exynos_drm_fimd_common.h |   20 ++
> >>  drivers/gpu/drm/exynos/exynos_drm_mie.c |  250
> >> +++
> >>  drivers/gpu/drm/exynos/exynos_drm_mie.h |   50 +
> >>  drivers/gpu/drm/exynos/exynos_regs-mie.h|   75 +++
> >>  8 files changed, 465 insertions(+), 3 deletions(-)
> >>  create mode 100644 drivers/gpu/drm/exynos/exynos_drm_fimd_common.h
> >>  create mode 100644 drivers/gpu/drm/exynos/exynos_drm_mie.c
> >>  create mode 100644 drivers/gpu/drm/exynos/exynos_drm_mie.h
> >>  create mode 100644 drivers/gpu/drm/exynos/exynos_regs-mie.h
> >>
> >> --
> >> 1.7.9.5
> >>
> >> ___
> >> dri-devel mailing list
> >> dri-devel at lists.freedesktop.org
> >> http://lists.freedesktop.org/mailman/listinfo/dri-devel
> >
> >
> >
> > ___
> > dri-devel mailing list
> > dri-devel at lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/dri-devel
> >
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121210/d7e22b15/attachment-0001.html>

[Bug 56405] Distorted graphics on Radeon HD 6620G

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

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

--- Comment #42 from Alex Deucher  ---
 case CHIP_SUMO2:
-rdev->config.evergreen.num_ses = 1;
+rdev->config.evergreen.num_ses = 2;

None of the APUs have multiple SEs.

-- 
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/20121210/3c372c68/attachment.html>

[Bug 56405] Distorted graphics on Radeon HD 6620G

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

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

--- Comment #41 from Jerome Glisse  ---
Created attachment 71284
  --> https://bugs.freedesktop.org/attachment.cgi?id=71284=edit
Patch gpu pipe

Does this kernel patch fix the 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/20121210/89f63d8a/attachment.html>

[pull] radeon drm-next-3.8 (v2)

[alexdeuc...@gmail.com]

From: Alex Deucher 

Hi Dave,

  I've added a new set of patches that adds support for the
asynchronous DMA engines on r6xx-SI.  These engines are used
for ttm bo moves and VM page table updates currently.  They
could also be exposed via the CS ioctl for userspace use,
but I haven't had a chance to add proper CS checker patches
for them yet.  These patches have been tested extensively
internally for months, so they should be pretty solid.

Alex

The following changes since commit e548a83c34806b8bc2c55f52d3bc481a13a3829e:

  Merge branch 'drm-fixes-3.7' of git://people.freedesktop.org/~agd5f/linux 
(2012-11-28 16:51:10 +1000)

are available in the git repository at:

  git://people.freedesktop.org/~agd5f/linux drm-next-3.8

Alex Deucher (16):
  drm/radeon/dce3.2: add registers for ELD handling
  drm/radeon/dce4/5: add registers for ELD handling
  drm/radeon/dce32+: use fractional fb dividers for high clocks
  drm/radeon: add new INFO ioctl requests
  drm/radeon: fix eDP clk and lane setup for scaled modes
  drm/radeon: bump driver version for new info ioctl requests
  drm/radeon/kms: Add initial support for async DMA on r6xx/r7xx
  drm/radeon/kms: Add initial support for async DMA on evergreen
  drm/radeon/kms: Add initial support for async DMA on cayman/TN
  drm/radeon/kms: Add initial support for async DMA on SI
  drm/radeon/kms: add support for dma rings to radeon_test_moves()
  drm/radeon: use async dma for ttm buffer moves on 6xx-SI
  drm/radeon: add dma engine support for vm pt updates on ni (v5)
  drm/radeon: use DMA engine for VM page table updates on cayman/TN
  drm/radeon: add dma engine support for vm pt updates on si (v2)
  drm/radeon: use DMA engine for VM page table updates on SI

Christian K?nig (1):
  drm/radeon: stop page faults from hanging the system (v2)

Jerome Glisse (1):
  drm/radeon: use cached memory when evicting for vram on non agp

Marek Ol??k (1):
  drm/radeon: add a CS flag END_OF_FRAME

 drivers/gpu/drm/radeon/atombios_crtc.c |2 +
 drivers/gpu/drm/radeon/atombios_encoders.c |2 +-
 drivers/gpu/drm/radeon/evergreen.c |  210 -
 drivers/gpu/drm/radeon/evergreend.h|   82 +
 drivers/gpu/drm/radeon/ni.c|  357 --
 drivers/gpu/drm/radeon/nid.h   |   86 +
 drivers/gpu/drm/radeon/r600.c  |  471 +++-
 drivers/gpu/drm/radeon/r600d.h |   54 +++-
 drivers/gpu/drm/radeon/radeon.h|   18 +-
 drivers/gpu/drm/radeon/radeon_asic.c   |  192 +---
 drivers/gpu/drm/radeon/radeon_asic.h   |   30 ++
 drivers/gpu/drm/radeon/radeon_drv.c|3 +-
 drivers/gpu/drm/radeon/radeon_kms.c|   16 +
 drivers/gpu/drm/radeon/radeon_object.c |   18 +-
 drivers/gpu/drm/radeon/radeon_test.c   |   37 ++-
 drivers/gpu/drm/radeon/rv770.c |   31 ++-
 drivers/gpu/drm/radeon/rv770d.h|   71 +
 drivers/gpu/drm/radeon/si.c|  308 --
 drivers/gpu/drm/radeon/sid.h   |   71 +
 include/uapi/drm/radeon_drm.h  |5 +
 20 files changed, 1952 insertions(+), 112 deletions(-)

[Bug 56405] Distorted graphics on Radeon HD 6620G

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

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

--- Comment #40 from klausenbusk at hotmail.com ---
Any update?

-- 
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/20121210/a0495a76/attachment.html>

[Nouveau] [PATCH] drm/nouveau: fix takedown in move_notify

[Emil Velikov]

On 21/11/12 13:15, Maarten Lankhorst wrote:
> move_notify is called by ttm after the the object is idle and about
> to be destroyed. Clean up the vm list properly in that case.
> 
> This is not a problem right now, since the list should already be
> empty, but if it wasn't empty, vm_put was not called which leads to
> random corruption later.
> 
> With this fix, nouveau_gem_object_close can be safely changed to a noop,
> forcing the vm bindings to be removed when the original object is. This
> is not done in this patch since it may lead to the object staying mapped
> in the vm space until the gem object refcount drops to 0. This shouldn't
> be a big issue however.
> 
> If we choose to do so does allow us to use ttm's delayed destruction
> mechanism to unmap vm after object is idle, resulting in ioread32 no
> longer taking up 30% of cpu in Team Fortress 2 if I don't do the vma
> unmap in nouveau_gem_object_close.
> 
> Signed-off-by: Maarten Lankhorst 
> 
Hi Maarten

I've noticed ioread32 of up-to 40% on of cpu my system. With your patch
if goes down to ~3% with no side effects. Frame-rate appears to be
slightly improved, although it's hard to say.

Is there any reason for holding this patch ?
For what it's worth you can add

Tested-by: Emil Velikov 

> ---
> diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c 
> b/drivers/gpu/drm/nouveau/nouveau_bo.c
> index 35ac57f..e8a47f0 100644
> --- a/drivers/gpu/drm/nouveau/nouveau_bo.c
> +++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
> @@ -1139,12 +1139,22 @@ nouveau_bo_move_ntfy(struct ttm_buffer_object *bo, 
> struct ttm_mem_reg *new_mem)
>   if (bo->destroy != nouveau_bo_del_ttm)
>   return;
>  
> + if (!new_mem) {
> + while (!list_empty(>vma_list)) {
> + vma = list_first_entry(>vma_list, struct 
> nouveau_vma, head);
> +
> + nouveau_vm_unmap(vma);
> + nouveau_vm_put(vma);
> + list_del(>head);
> + }
> + return;
> + }
> +
>   list_for_each_entry(vma, >vma_list, head) {
> - if (new_mem && new_mem->mem_type == TTM_PL_VRAM) {
> + if (new_mem->mem_type == TTM_PL_VRAM) {
>   nouveau_vm_map(vma, new_mem->mm_node);
> - } else
> - if (new_mem && new_mem->mem_type == TTM_PL_TT &&
> - nvbo->page_shift == vma->vm->vmm->spg_shift) {
> + } else if (new_mem->mem_type == TTM_PL_TT &&
> +nvbo->page_shift == vma->vm->vmm->spg_shift) {
>   if (((struct nouveau_mem *)new_mem->mm_node)->sg)
>   nouveau_vm_map_sg_table(vma, 0, new_mem->
> num_pages << PAGE_SHIFT,
> @@ -1153,8 +1163,6 @@ nouveau_bo_move_ntfy(struct ttm_buffer_object *bo, 
> struct ttm_mem_reg *new_mem)
>   nouveau_vm_map_sg(vma, 0, new_mem->
> num_pages << PAGE_SHIFT,
> new_mem->mm_node);
> - } else {
> - nouveau_vm_unmap(vma);
>   }
>   }
>  }
> 
> ___
> Nouveau mailing list
> Nouveau at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/nouveau
> 

[Bug 26809] KMS/R200: Bad shading in NWN since Mesa rewrite

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

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

Roland Scheidegger  changed:

   What|Removed |Added

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

--- Comment #2 from Roland Scheidegger  ---
Ought to be fixed by 320d531373e7b0873f5de42f6173b986290f593f.

-- 
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/20121210/cca1b139/attachment.html>

[Bug 22576] [KMS] mesa demo spectex broken on rv280

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

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

Roland Scheidegger  changed:

   What|Removed |Added

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

--- Comment #21 from Roland Scheidegger  ---
(In reply to comment #18)
>  I think i've found source of these lighting problems on r200 in this and
> other bugs. It is just a typo it seems in r200_state_init.c lit_emit()
> 
>  OUT_VEC(atom->cmd[LIT_CMD_1], atom->cmd+LIT_CMD_1+1);
> 
>  instead of OUT_VEC it needs to be OUT_SCL:
> 
>  OUT_SCL(atom->cmd[LIT_CMD_1], atom->cmd+LIT_CMD_1+1);

Should be fixed by 320d531373e7b0873f5de42f6173b986290f593f, thanks!
FWIW the command emit mechanism looks a bit too complicated it could profit
from some refactoring. For instance it is still based on the fake
drm_radeon_cmd_header_t structure, the scl vs. scl2 and vec vs. veclinear emits
are nothing but crude hacks around limitations in that structure, even though
since ums is gone there is absolutely no point in using that struct...
Section size calcs are also somewhat confusing, the sanity code (which was
really great back then) is totally unused etc.
Maybe another day...

-- 
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/20121210/9d34e4e5/attachment-0001.html>

[Bug 58042] Garbled UI in Team Fortress 2 Beta

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

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

--- Comment #2 from Alex Deucher  ---
Is this a regression or has it always had rendering problems?  Does it render
ok with mesa 9.0.x or 8.0.x?  If so, can you bisect?

-- 
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/20121210/757c7d44/attachment.html>

[PATCH] drm/exynos: remove unused vaddr member

[Inki Dae]

From: YoungJun Cho 

This patch removes vaddr member from exynos_drm_overlay structure
and also relevant codes for code cleanup.

Signed-off-by: YoungJun Cho 
Signed-off-by: Inki Dae 
Signed-off-by: Kyungmin Park 
---
 drivers/gpu/drm/exynos/exynos_drm_drv.h   |2 --
 drivers/gpu/drm/exynos/exynos_drm_fimd.c  |6 +-
 drivers/gpu/drm/exynos/exynos_drm_plane.c |6 ++
 drivers/gpu/drm/exynos/exynos_drm_vidi.c  |6 +-
 drivers/gpu/drm/exynos/exynos_mixer.c |4 
 5 files changed, 4 insertions(+), 20 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.h 
b/drivers/gpu/drm/exynos/exynos_drm_drv.h
index 5a8c1f2..e4ea74d 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.h
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.h
@@ -107,7 +107,6 @@ struct exynos_drm_overlay_ops {
  * @pixel_format: fourcc pixel format of this overlay
  * @dma_addr: array of bus(accessed by dma) address to the memory region
  *   allocated for a overlay.
- * @vaddr: array of virtual memory addresss to this overlay.
  * @zpos: order of overlay layer(z position).
  * @default_win: a window to be enabled.
  * @color_key: color key on or off.
@@ -139,7 +138,6 @@ struct exynos_drm_overlay {
unsigned int pitch;
uint32_t pixel_format;
dma_addr_t dma_addr[MAX_FB_BUFFER];
-   void __iomem *vaddr[MAX_FB_BUFFER];
int zpos;

bool default_win;
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c 
b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
index 7e66032..90ca4b2 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
@@ -79,7 +79,6 @@ struct fimd_win_data {
unsigned intfb_height;
unsigned intbpp;
dma_addr_t  dma_addr;
-   void __iomem*vaddr;
unsigned intbuf_offsize;
unsigned intline_size;  /* bytes */
boolenabled;
@@ -375,7 +374,6 @@ static void fimd_win_mode_set(struct device *dev,
win_data->fb_width = overlay->fb_width;
win_data->fb_height = overlay->fb_height;
win_data->dma_addr = overlay->dma_addr[0] + offset;
-   win_data->vaddr = overlay->vaddr[0] + offset;
win_data->bpp = overlay->bpp;
win_data->buf_offsize = (overlay->fb_width - overlay->crtc_width) *
(overlay->bpp >> 3);
@@ -385,9 +383,7 @@ static void fimd_win_mode_set(struct device *dev,
win_data->offset_x, win_data->offset_y);
DRM_DEBUG_KMS("ovl_width = %d, ovl_height = %d\n",
win_data->ovl_width, win_data->ovl_height);
-   DRM_DEBUG_KMS("paddr = 0x%lx, vaddr = 0x%lx\n",
-   (unsigned long)win_data->dma_addr,
-   (unsigned long)win_data->vaddr);
+   DRM_DEBUG_KMS("paddr = 0x%lx\n", (unsigned long)win_data->dma_addr);
DRM_DEBUG_KMS("fb_width = %d, crtc_width = %d\n",
overlay->fb_width, overlay->crtc_width);
 }
diff --git a/drivers/gpu/drm/exynos/exynos_drm_plane.c 
b/drivers/gpu/drm/exynos/exynos_drm_plane.c
index 862ca1e..399b026 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_plane.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_plane.c
@@ -93,11 +93,9 @@ int exynos_plane_mode_set(struct drm_plane *plane, struct 
drm_crtc *crtc,
}

overlay->dma_addr[i] = buffer->dma_addr;
-   overlay->vaddr[i] = buffer->kvaddr;

-   DRM_DEBUG_KMS("buffer: %d, vaddr = 0x%lx, dma_addr = 0x%lx\n",
-   i, (unsigned long)overlay->vaddr[i],
-   (unsigned long)overlay->dma_addr[i]);
+   DRM_DEBUG_KMS("buffer: %d, dma_addr = 0x%lx\n",
+   i, (unsigned long)overlay->dma_addr[i]);
}

actual_w = exynos_plane_get_size(crtc_x, crtc_w, crtc->mode.hdisplay);
diff --git a/drivers/gpu/drm/exynos/exynos_drm_vidi.c 
b/drivers/gpu/drm/exynos/exynos_drm_vidi.c
index 4b0c16b..99bfc38 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_vidi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_vidi.c
@@ -39,7 +39,6 @@ struct vidi_win_data {
unsigned intfb_height;
unsigned intbpp;
dma_addr_t  dma_addr;
-   void __iomem*vaddr;
unsigned intbuf_offsize;
unsigned intline_size;  /* bytes */
boolenabled;
@@ -294,7 +293,6 @@ static void vidi_win_mode_set(struct device *dev,
win_data->fb_width = overlay->fb_width;
win_data->fb_height = overlay->fb_height;
win_data->dma_addr = overlay->dma_addr[0] + offset;
-   win_data->vaddr = overlay->vaddr[0] + offset;
win_data->bpp = overlay->bpp;
win_data->buf_offsize = (overlay->fb_width - overlay->crtc_width) *

[Bug 58033] [r300g] Black gap artifacts when playing WoW

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

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

--- Comment #4 from Alex Deucher  ---
Can you bisect?

-- 
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/20121210/f34f2607/attachment.html>

[Bug 50655] ATI RV670 [Radeon HD 3870] Ioquake games causes GPU lockup (waiting for 0x00003039 last fence id 0x00003030)

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

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

--- Comment #20 from Alex Deucher  ---
Created attachment 71271
  --> https://bugs.freedesktop.org/attachment.cgi?id=71271=edit
possible fix

Does this patch help?

-- 
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/20121210/c2f3df2c/attachment.html>

[PATCH v3] drm/exynos: use DMA_ATTR_NO_KERNEL_MAPPING attribute

[Inki Dae]

Changelog v3:
just code cleanup.

Changelog v2:
fix argument to dma_mmap_attr function.
- use pages instead of kvaddr because kvaddr is 0 with
  DMA_ATTR_NO_KERNEL_MAPPING.

Changelog v1:
When gem allocation is requested, kernel space mapping isn't needed.
But if need, such as console framebuffer, the physical pages would be
mapped with kernel space though vmap function.

Signed-off-by: Inki Dae 
Signed-off-by: Kyungmin Park 
---
 drivers/gpu/drm/exynos/exynos_drm_buf.c   |   31 ++--
 drivers/gpu/drm/exynos/exynos_drm_fb.c|4 +--
 drivers/gpu/drm/exynos/exynos_drm_fbdev.c |   18 +++-
 drivers/gpu/drm/exynos/exynos_drm_gem.c   |2 +-
 drivers/gpu/drm/exynos/exynos_drm_gem.h   |2 +
 5 files changed, 32 insertions(+), 25 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_buf.c 
b/drivers/gpu/drm/exynos/exynos_drm_buf.c
index 72bf97b..9732043 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_buf.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_buf.c
@@ -35,6 +35,7 @@ static int lowlevel_buffer_allocate(struct drm_device *dev,
 {
int ret = 0;
enum dma_attr attr = DMA_ATTR_FORCE_CONTIGUOUS;
+   unsigned int nr_pages;

DRM_DEBUG_KMS("%s\n", __FILE__);

@@ -49,40 +50,31 @@ static int lowlevel_buffer_allocate(struct drm_device *dev,
attr = DMA_ATTR_WRITE_COMBINE;

dma_set_attr(attr, >dma_attrs);
+   dma_set_attr(DMA_ATTR_NO_KERNEL_MAPPING, >dma_attrs);

-   buf->kvaddr = dma_alloc_attrs(dev->dev, buf->size,
+   buf->pages = dma_alloc_attrs(dev->dev, buf->size,
>dma_addr, GFP_KERNEL, >dma_attrs);
-   if (!buf->kvaddr) {
+   if (!buf->pages) {
DRM_ERROR("failed to allocate buffer.\n");
return -ENOMEM;
}

-   buf->sgt = kzalloc(sizeof(struct sg_table), GFP_KERNEL);
+   nr_pages = buf->size >> PAGE_SHIFT;
+   buf->sgt = drm_prime_pages_to_sg(buf->pages, nr_pages);
if (!buf->sgt) {
-   DRM_ERROR("failed to allocate sg table.\n");
+   DRM_ERROR("failed to get sg table.\n");
ret = -ENOMEM;
goto err_free_attrs;
}

-   ret = dma_get_sgtable(dev->dev, buf->sgt, buf->kvaddr, buf->dma_addr,
-   buf->size);
-   if (ret < 0) {
-   DRM_ERROR("failed to get sgtable.\n");
-   goto err_free_sgt;
-   }
-
-   DRM_DEBUG_KMS("vaddr(0x%lx), dma_addr(0x%lx), size(0x%lx)\n",
-   (unsigned long)buf->kvaddr,
+   DRM_DEBUG_KMS("dma_addr(0x%lx), size(0x%lx)\n",
(unsigned long)buf->dma_addr,
buf->size);

return ret;

-err_free_sgt:
-   kfree(buf->sgt);
-   buf->sgt = NULL;
 err_free_attrs:
-   dma_free_attrs(dev->dev, buf->size, buf->kvaddr,
+   dma_free_attrs(dev->dev, buf->size, buf->pages,
(dma_addr_t)buf->dma_addr, >dma_attrs);
buf->dma_addr = (dma_addr_t)NULL;

@@ -99,8 +91,7 @@ static void lowlevel_buffer_deallocate(struct drm_device *dev,
return;
}

-   DRM_DEBUG_KMS("vaddr(0x%lx), dma_addr(0x%lx), size(0x%lx)\n",
-   (unsigned long)buf->kvaddr,
+   DRM_DEBUG_KMS("dma_addr(0x%lx), size(0x%lx)\n",
(unsigned long)buf->dma_addr,
buf->size);

@@ -109,7 +100,7 @@ static void lowlevel_buffer_deallocate(struct drm_device 
*dev,
kfree(buf->sgt);
buf->sgt = NULL;

-   dma_free_attrs(dev->dev, buf->size, buf->kvaddr,
+   dma_free_attrs(dev->dev, buf->size, buf->pages,
(dma_addr_t)buf->dma_addr, >dma_attrs);
buf->dma_addr = (dma_addr_t)NULL;
 }
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fb.c 
b/drivers/gpu/drm/exynos/exynos_drm_fb.c
index 7413f4b..764571c 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fb.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fb.c
@@ -297,9 +297,7 @@ struct exynos_drm_gem_buf *exynos_drm_fb_buffer(struct 
drm_framebuffer *fb,
if (!buffer)
return NULL;

-   DRM_DEBUG_KMS("vaddr = 0x%lx, dma_addr = 0x%lx\n",
-   (unsigned long)buffer->kvaddr,
-   (unsigned long)buffer->dma_addr);
+   DRM_DEBUG_KMS("dma_addr = 0x%lx\n", (unsigned long)buffer->dma_addr);

return buffer;
 }
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fbdev.c 
b/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
index 885ef23..f433eb7 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
@@ -65,7 +65,7 @@ static int exynos_drm_fb_mmap(struct fb_info *info,
if (vm_size > buffer->size)
return -EINVAL;

-   ret = dma_mmap_attrs(helper->dev->dev, vma, buffer->kvaddr,
+   ret = dma_mmap_attrs(helper->dev->dev, vma, buffer->pages,
buffer->dma_addr, buffer->size, >dma_attrs);
if (ret 

[PATCH -next] drm/exynos/iommu: fix return value check in drm_create_iommu_mapping()

[Inki Dae]

> -Original Message-
> From: ??? [mailto:sw0312.kim at samsung.com]
> Sent: Monday, December 10, 2012 3:14 PM
> To: Wei Yongjun
> Cc: inki.dae at samsung.com; jy0922.shim at samsung.com;
> kyungmin.park at samsung.com; airlied at linux.ie; yongjun_wei at 
> trendmicro.com.cn;
> linux-kernel at vger.kernel.org; dri-devel at lists.freedesktop.org;
> sw0312.kim at samsung.com
> Subject: Re: [PATCH -next] drm/exynos/iommu: fix return value check in
> drm_create_iommu_mapping()
> 
> 
> 
> On 2012? 12? 07? 21:50, Wei Yongjun wrote:
> > From: Wei Yongjun 
> >
> > In case of error, function arm_iommu_create_mapping() returns
> > ERR_PTR() and never returns NULL. The NULL test in the return
> > value check should be replaced with IS_ERR().
> >
> > Signed-off-by: Wei Yongjun 
> > ---
> >  drivers/gpu/drm/exynos/exynos_drm_iommu.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/exynos/exynos_drm_iommu.c
> b/drivers/gpu/drm/exynos/exynos_drm_iommu.c
> > index 09db198..3b3d3a6 100644
> > --- a/drivers/gpu/drm/exynos/exynos_drm_iommu.c
> > +++ b/drivers/gpu/drm/exynos/exynos_drm_iommu.c
> > @@ -56,7 +56,7 @@ int drm_create_iommu_mapping(struct drm_device
> *drm_dev)
> > mapping = arm_iommu_create_mapping(_bus_type, priv-
> >da_start,
> > priv->da_space_size,
> > priv->da_space_order);
> > -   if (!mapping)
> > +   if (IS_ERR(mapping))
> > return -ENOMEM;
> 
> One more fix is needed here.
> - return -ENOMEM;
> + return PTR_ERR(mapping);

Oh, good point, I missed. Please re-send it.

Thanks,
Inki Dae

> 
> >
> > dev->dma_parms = devm_kzalloc(dev, sizeof(*dev->dma_parms),
> >
> >
> > ___
> > dri-devel mailing list
> > dri-devel at lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/dri-devel
> >
> 
> --
> Seung-Woo Kim
> Samsung Software R Center
> --

[Bug 22576] [KMS] mesa demo spectex broken on rv280

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

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

--- Comment #20 from smoki  ---
 Yeah, i just see that, assume that it must be scl there then compared it with
radeon state, there is setup just like that, but with correct vec/scl as i
assume, so i changed it like that and that is it - tcl lighting works. Three
year old typo - i deserve a medal ;).

 Someone could pushed it in git.

-- 
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/20121210/5c2ba816/attachment.html>

[PATCH 0/3] add mie driver for exynos

[Inki Dae]

2012/12/6 R. Chandrasekar 

> From: "R. Chandrasekar" 
>
> this patch set adds the driver support for the dithering functionality of
> the
> mobile image enhancement (mie) module.
>
> device tree support is added for mie.
>
> fimd adds the mie module as plugin and calls the dithering function.
> dithere is
> required when the panels bpp is less then fimd output.
>
> though mie mie has other functionalities, current system uses only
> dithereing.
>
>
Please, move mie module into drivers/video/exynos. The mie is a interface
between fimd and lcd panel(or mipi-dsi, eDP) to enhance image to be
displayed. And it seems like that this doesn't need drm framework-relevant
interfaces, such as gem.

And also, please refer to the below link, Common Display Framework, for
more generic way.

http://lists.freedesktop.org/archives/dri-devel/2012-November/030888.html

Thanks,
Inki Dae


> R. Chandrasekar (3):
>   DTS: exynos: add device tree support for exynos mie
>   drm: fimd: add mie plugin support for dithering
>   drm: mie: add mie driver for exynos
>
>  arch/arm/boot/dts/exynos5250.dtsi   |7 +-
>  drivers/gpu/drm/exynos/Kconfig  |7 +
>  drivers/gpu/drm/exynos/Makefile |1 +
>  drivers/gpu/drm/exynos/exynos_drm_fimd.c|   58 +-
>  drivers/gpu/drm/exynos/exynos_drm_fimd_common.h |   20 ++
>  drivers/gpu/drm/exynos/exynos_drm_mie.c |  250
> +++
>  drivers/gpu/drm/exynos/exynos_drm_mie.h |   50 +
>  drivers/gpu/drm/exynos/exynos_regs-mie.h|   75 +++
>  8 files changed, 465 insertions(+), 3 deletions(-)
>  create mode 100644 drivers/gpu/drm/exynos/exynos_drm_fimd_common.h
>  create mode 100644 drivers/gpu/drm/exynos/exynos_drm_mie.c
>  create mode 100644 drivers/gpu/drm/exynos/exynos_drm_mie.h
>  create mode 100644 drivers/gpu/drm/exynos/exynos_regs-mie.h
>
> --
> 1.7.9.5
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121210/20988bf7/attachment.html>

[Bug 57875] Second Life viewer bad rendering with git-ec83535

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

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

--- Comment #16 from Henri Verbeet  ---
(In reply to comment #15)
> I've written an extension proposal for a new mesa extension that exposes the
> CLIP_DISABLE bit. The proposal is attached, please review and comment. There
> are some TODOs I'm not quite sure how to deal with, see the list in "Status".
> 
  - It probably makes sense to mention "depth" in the extension name somewhere,
we really only care about the near and far clipping planes. E.g.
MESA_depth_clip.
  - Perhaps it makes more sense to write the extension in terms of
ARB_depth_clamp. I.e., provide a subset of ARB_depth_clamp, that only disables
depth clipping, and generates undefined results in the depth test, except for
perhaps GL_ALWAYS / GL_NEVER. (Also, note that you can't really make fragment
depth values undefined before / in the fragment shader, because you have
interactions with e.g. texture filtering as well.) It would avoid the perhaps
somewhat questionable "ARB_depth_clamp must not be supported", and you can just
defer to ARB_depth_clamp for most of the issues etc. The interaction between
the two extensions just becomes that if ARB_depth_clamp is also supported you
get defined depth test results.

-- 
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/20121210/cf8f5109/attachment.html>

[PATCH 1/2] drm/radeon: do not move bo to different placement at each cs

[Jerome Glisse]

On Thu, Nov 29, 2012 at 10:35 AM,   wrote:
> From: Jerome Glisse 
>
> The bo creation placement is where the bo will be. Instead of trying
> to move bo at each command stream let this work to another worker
> thread that will use more advance heuristic.
>
> Signed-off-by: Jerome Glisse 

What about including this for 3.8 it will mostly fix all regression
performance and is a first valid step for proper bo placement.

Cheers,
Jerome

> ---
>  drivers/gpu/drm/radeon/radeon.h|  1 +
>  drivers/gpu/drm/radeon/radeon_object.c | 17 -
>  2 files changed, 9 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
> index 8c42d54..0a2664c 100644
> --- a/drivers/gpu/drm/radeon/radeon.h
> +++ b/drivers/gpu/drm/radeon/radeon.h
> @@ -313,6 +313,7 @@ struct radeon_bo {
> struct list_headlist;
> /* Protected by tbo.reserved */
> u32 placements[3];
> +   u32 busy_placements[3];
> struct ttm_placementplacement;
> struct ttm_buffer_objecttbo;
> struct ttm_bo_kmap_obj  kmap;
> diff --git a/drivers/gpu/drm/radeon/radeon_object.c 
> b/drivers/gpu/drm/radeon/radeon_object.c
> index 3f9f3bb..e25ae20 100644
> --- a/drivers/gpu/drm/radeon/radeon_object.c
> +++ b/drivers/gpu/drm/radeon/radeon_object.c
> @@ -84,7 +84,6 @@ void radeon_ttm_placement_from_domain(struct radeon_bo 
> *rbo, u32 domain)
> rbo->placement.fpfn = 0;
> rbo->placement.lpfn = 0;
> rbo->placement.placement = rbo->placements;
> -   rbo->placement.busy_placement = rbo->placements;
> if (domain & RADEON_GEM_DOMAIN_VRAM)
> rbo->placements[c++] = TTM_PL_FLAG_WC | TTM_PL_FLAG_UNCACHED |
> TTM_PL_FLAG_VRAM;
> @@ -105,6 +104,14 @@ void radeon_ttm_placement_from_domain(struct radeon_bo 
> *rbo, u32 domain)
> if (!c)
> rbo->placements[c++] = TTM_PL_MASK_CACHING | 
> TTM_PL_FLAG_SYSTEM;
> rbo->placement.num_placement = c;
> +
> +   c = 0;
> +   rbo->placement.busy_placement = rbo->busy_placements;
> +   if (rbo->rdev->flags & RADEON_IS_AGP) {
> +   rbo->busy_placements[c++] = TTM_PL_FLAG_WC | TTM_PL_FLAG_TT;
> +   } else {
> +   rbo->busy_placements[c++] = TTM_PL_FLAG_CACHED | 
> TTM_PL_FLAG_TT;
> +   }
> rbo->placement.num_busy_placement = c;
>  }
>
> @@ -360,17 +367,9 @@ int radeon_bo_list_validate(struct list_head *head)
> list_for_each_entry(lobj, head, tv.head) {
> bo = lobj->bo;
> if (!bo->pin_count) {
> -   domain = lobj->wdomain ? lobj->wdomain : 
> lobj->rdomain;
> -
> -   retry:
> -   radeon_ttm_placement_from_domain(bo, domain);
> r = ttm_bo_validate(>tbo, >placement,
> true, false, false);
> if (unlikely(r)) {
> -   if (r != -ERESTARTSYS && domain == 
> RADEON_GEM_DOMAIN_VRAM) {
> -   domain |= RADEON_GEM_DOMAIN_GTT;
> -   goto retry;
> -   }
> return r;
> }
> }
> --
> 1.7.11.7
>

[PATCH -next] drm/exynos/iommu: fix return value check in drm_create_iommu_mapping()

[김승우]

On 2012? 12? 07? 21:50, Wei Yongjun wrote:
> From: Wei Yongjun 
> 
> In case of error, function arm_iommu_create_mapping() returns
> ERR_PTR() and never returns NULL. The NULL test in the return
> value check should be replaced with IS_ERR().
> 
> Signed-off-by: Wei Yongjun 
> ---
>  drivers/gpu/drm/exynos/exynos_drm_iommu.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_iommu.c 
> b/drivers/gpu/drm/exynos/exynos_drm_iommu.c
> index 09db198..3b3d3a6 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_iommu.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_iommu.c
> @@ -56,7 +56,7 @@ int drm_create_iommu_mapping(struct drm_device *drm_dev)
>   mapping = arm_iommu_create_mapping(_bus_type, priv->da_start,
>   priv->da_space_size,
>   priv->da_space_order);
> - if (!mapping)
> + if (IS_ERR(mapping))
>   return -ENOMEM;

One more fix is needed here.
-   return -ENOMEM;
+   return PTR_ERR(mapping);

>  
>   dev->dma_parms = devm_kzalloc(dev, sizeof(*dev->dma_parms),
> 
> 
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
> 

-- 
Seung-Woo Kim
Samsung Software R Center
--

[Bug 22576] [KMS] mesa demo spectex broken on rv280

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

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

--- Comment #19 from Alan Swanson  ---
This fixes lighting bug 26809 with NWN on my rv250, but R200 untested as yet.
To correct the section size mismatch, add the following before the
BEGIN_BATCH_NO_AUTOSTATE() line;

  dwords += 2;

Thank you very much for finding this three year old radeon rewrite bug. I
assume you discerned this from cmdscl used for LIT_CMD_1 versus cmdvec used for
LIT_CMD_0?

-- 
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/20121210/13db7162/attachment.html>

[PATCH] drm/omap: use omapdss low level API

[Sumit Semwal]

On Friday 07 December 2012 04:15 PM, Archit Taneja wrote:
> On Wednesday 05 December 2012 01:29 AM, Rob Clark wrote:
>> This patch changes the omapdrm KMS to bypass the omapdss "compat"
>> layer and use the core omapdss API directly.  This solves some layering
>> issues that would cause unpin confusion vs GO bit status, because we
>> would not know whether a particular pageflip or overlay update has hit
>> the screen or not.  Now instead we explicitly manage the GO bits in
>> dispc and handle the vblank/framedone interrupts ourself so that we
>> always know which buffers are being scanned out at any given time, and
>> so on.
>>
>> As an added bonus, we no longer leave the last overlay buffer pinned
>> when the display is disabled, and have been able to add the previously
>> missing vblank event handling.
Very welcome patch; looks good to me.

Please feel free to add:
Reviewed-by: Sumit Semwal 
>
> Looks good to me.
>
> Reviewed-by: Archit Taneja 
>
>>
>> v1: original
>> v2: rebased on latest staging-next and omapdss patches from Tomi and
>>  review comments from Archit Taneja
>>
>> Signed-off-by: Rob Clark 
>> ---
>>   drivers/staging/omapdrm/Makefile |   1 +
>>   drivers/staging/omapdrm/TODO |   3 -
>>   drivers/staging/omapdrm/omap_connector.c | 111 +--
>>   drivers/staging/omapdrm/omap_crtc.c  | 507
>> +++
>>   drivers/staging/omapdrm/omap_drv.c   | 439
>> +-
>>   drivers/staging/omapdrm/omap_drv.h   | 140 +++--
>>   drivers/staging/omapdrm/omap_encoder.c   | 132 
>>   drivers/staging/omapdrm/omap_irq.c   | 322 
>>   drivers/staging/omapdrm/omap_plane.c | 452
>> +++
>>   9 files changed, 1214 insertions(+), 893 deletions(-)
>>   create mode 100644 drivers/staging/omapdrm/omap_irq.c
>>
>> diff --git a/drivers/staging/omapdrm/Makefile
>> b/drivers/staging/omapdrm/Makefile
>> index 1ca0e00..d85e058 100644
>> --- a/drivers/staging/omapdrm/Makefile
>> +++ b/drivers/staging/omapdrm/Makefile
>> @@ -5,6 +5,7 @@
>>
>>   ccflags-y := -Iinclude/drm -Werror
>>   omapdrm-y := omap_drv.o \
>> +omap_irq.o \
>>   omap_debugfs.o \
>>   omap_crtc.o \
>>   omap_plane.o \
>> diff --git a/drivers/staging/omapdrm/TODO b/drivers/staging/omapdrm/TODO
>> index 938c788..abeeb00 100644
>> --- a/drivers/staging/omapdrm/TODO
>> +++ b/drivers/staging/omapdrm/TODO
>> @@ -17,9 +17,6 @@ TODO
>>   . Revisit GEM sync object infrastructure.. TTM has some framework
>> for this
>> already.  Possibly this could be refactored out and made more common?
>> There should be some way to do this with less wheel-reinvention.
>> -. Review DSS vs KMS mismatches.  The omap_dss_device is sort of part
>> encoder,
>> -  part connector.  Which results in a bit of duct tape to fwd calls from
>> -  encoder to connector.  Possibly this could be done a bit better.
>>   . Solve PM sequencing on resume.  DMM/TILER must be reloaded before any
>> access is made from any component in the system.  Which means on
>> suspend
>> CRTC's should be disabled, and on resume the LUT should be
>> reprogrammed
>> diff --git a/drivers/staging/omapdrm/omap_connector.c
>> b/drivers/staging/omapdrm/omap_connector.c
>> index 91edb3f..4cc9ee7 100644
>> --- a/drivers/staging/omapdrm/omap_connector.c
>> +++ b/drivers/staging/omapdrm/omap_connector.c
>> @@ -31,9 +31,10 @@
>>   struct omap_connector {
>>   struct drm_connector base;
>>   struct omap_dss_device *dssdev;
>> +struct drm_encoder *encoder;
>>   };
>>
>> -static inline void copy_timings_omap_to_drm(struct drm_display_mode
>> *mode,
>> +void copy_timings_omap_to_drm(struct drm_display_mode *mode,
>>   struct omap_video_timings *timings)
>>   {
>>   mode->clock = timings->pixel_clock;
>> @@ -64,7 +65,7 @@ static inline void copy_timings_omap_to_drm(struct
>> drm_display_mode *mode,
>>   mode->flags |= DRM_MODE_FLAG_NVSYNC;
>>   }
>>
>> -static inline void copy_timings_drm_to_omap(struct omap_video_timings
>> *timings,
>> +void copy_timings_drm_to_omap(struct omap_video_timings *timings,
>>   struct drm_display_mode *mode)
>>   {
>>   timings->pixel_clock = mode->clock;
>> @@ -96,48 +97,7 @@ static inline void copy_timings_drm_to_omap(struct
>> omap_video_timings *timings,
>>   timings->sync_pclk_edge = OMAPDSS_DRIVE_SIG_OPPOSITE_EDGES;
>>   }
>>
>> -static void omap_connector_dpms(struct drm_connector *connector, int
>> mode)
>> -{
>> -struct omap_connector *omap_connector =
>> to_omap_connector(connector);
>> -struct omap_dss_device *dssdev = omap_connector->dssdev;
>> -int old_dpms;
>> -
>> -DBG("%s: %d", dssdev->name, mode);
>> -
>> -old_dpms = connector->dpms;
>> -
>> -/* from off to on, do from crtc to connector */
>> -if (mode < old_dpms)
>> -drm_helper_connector_dpms(connector, mode);
>> -
>> -if (mode == DRM_MODE_DPMS_ON) {
>> -/* store 

[RFC v2 6/8] gpu: drm: tegra: Remove redundant host1x

[Terje Bergström]

On 05.12.2012 14:04, Thierry Reding wrote:
> On Wed, Dec 05, 2012 at 01:47:38PM +0200, Terje Bergstr?m wrote:
>> You're right in that binding to a sub-device is not a nice way. DRM
>> framework just needs a "struct device" to bind to. exynos seems to solve
>> this by introducing a virtual device and bind to that. I'm not sure if
>> this is the best way, but worth considering?
> 
> That was discussed a few months back already and nobody seemed to like
> the idea. In fact it was as a result of that discussion that Stephen
> brought up the idea to register the DRM driver from a central host1x
> driver (it may also have been part of a discussion on IRC, I don't
> remember exactly).
> 
> At the time I spent some time on a patch that introduced drm_soc_init()
> to solve this by creating a dummy struct device and registering the
> driver on top of that. But I abandoned it in favour of fixing the DRM
> platform support code. The approach also didn't provide for the proper
> encapsulation.

I've managed to go through all the other feedback and implement a
solution to most of them, so now I have some slack to actually think
about the initialization. Sorry about this, but you (meaning all the
reviewers) did give us a _lot_ to do. :-) Fortunately, the driver
actually became a lot better, too.

Back to the topic of tegradrm init. The root cause of the problem is
that DRM framework needs some device to assign itself to. The problem is
that this device doesn't have any physical counterpart, as it's only for
storing a pointer in DRM framework. Please correct me if this is wrong.

Moving the client registration to ping pong between DRM and host1x has
its problems. host1x driver itself has no use for a list of client
devices. It can just iterate its children in case it needs them. In
tegradrm, you need a list of devices under tegradrm control, which might
or might not be the same as list of devices under host1x hardware.

The solutions that many other DRM drivers seem to employ are the virtual
devices. Exynos and OMAP drivers do this, as does SH Mobile DRM driver.
So I think I'd still go this way, as it's the path of minimum
resistance, least amount of code and most localized change. I know it's
not ideal, but I'd also not like to get stuck in this.

Terje

[PATCH v2] drm/exynos: use prime helpers

[Inki Dae]

2012/12/8 Aaron Plattner 

> On 12/06/2012 10:36 PM, Inki Dae wrote:
>
>>
>> Hi,
>>
>> CCing media guys.
>>
>> I agree with you but we should consider one issue released to v4l2.
>>
>> As you may know, V4L2-based driver uses vb2 as buffer manager and the
>> vb2 includes dmabuf feature>(import and export) And v4l2 uses streaming
>> concept>(qbuf and dqbuf)
>> With dmabuf and iommu, generally qbuf imports a fd into its own buffer
>> and maps it with its own iommu table calling dma_buf_map_attachment().
>> And dqbuf calls dma_buf_unmap_attachment() to unmap that buffer from its
>> own iommu table.
>> But now vb2's unmap_dma_buf callback is nothing to do. I think that the
>> reason is the below issue,
>>
>> If qbuf maps buffer with iomm table and dqbuf unmaps it from iommu table
>> then it has performance deterioration because qbuf and dqbuf are called
>> repeatedly.
>> And this means map/unmap are repeated also. So I think media guys moved
>> dma_unmap_sg call from its own unmap_dma_buf callback to detach callback
>> instead.
>> For this, you can refer to vb2_dc_dmabuf_ops_unmap and
>> vb2_dc_dmabuf_ops_detach function.
>>
>> So I added the below patch to avoid that performance deterioration and
>> am testing it now.(this patch is derived from videobuf2-dma-contig.c)
>> http://git.kernel.org/?p=**linux/kernel/git/daeinki/drm-**
>> exynos.git;a=commit;h=**576b1c3de8b90cf1570b8418b60afd**1edaae4e30<http://git.kernel.org/?p=linux/kernel/git/daeinki/drm-exynos.git;a=commit;h=576b1c3de8b90cf1570b8418b60afd1edaae4e30>
>>
>> Thus, I'm not sure that your common set could cover all the cases
>> including other frameworks. Please give me any opinions.
>>
>
> It seems like this adjustment would make perfect sense to add to the
> helper layer I suggested.  E.g., instead of having an exynos_attach
> structure that caches the sgt, there'd be a struct drm_gem_prime_attach
> that would do the same thing, and save the sgt it gets from
> driver->gem_prime_get_sg.  Then it would benefit nouveau and radeon, too.
>

If this change is applied to common helper and also that could be accepted
by other maintainers then I think it's better to use this common helper
instead of specific one.


>
> Alternatively, patch #4 could be dropped and Exynos can continue to
> reimplement all of this core functionality, since the helpers are optional,
> but I don't see anything about this change that should make it
> Exynos-specific,


I agree with you. I also think this change isn't specific to Exynos. But
you need to check if this is a reasonable change for other drivers also.

Thanks,
Inki Dae


> unless I'm missing something.
>
>
--
> Aaron
>
> __**_
> dri-devel mailing list
> dri-devel at lists.freedesktop.**org 
> http://lists.freedesktop.org/**mailman/listinfo/dri-devel<http://lists.freedesktop.org/mailman/listinfo/dri-devel>
>
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121210/a5487809/attachment.html>

glxgears frame rate when DPMS is in "off" state

[Ilija Hadzic]

Hi everyone,

With relatively recent versions of AMD/ATI DDX (xf86-video-ati library), I 
have noticed a behavior related to DPMS that looks incorrect to me.

Namely, if I run glxgears, the reported frame rate is equal to that of the 
monitor refresh rate, which is correct. Now if I enter DPMS "off" state, 
wait a while, and then exit it (back to DPMS "on"), I see that while in 
"off" mode the frame rate was up in the thousands. Consequently, the CPU 
utilization went up to 100% (split about 50%/50% between X and and 
glxgears process).

I have traced the problem to DDX and here are some findings. Now, thinking 
about how to fix it (elaborated later), I realize that I am not sure what 
would be the conceptually correct thing to do to fix this.

Here is how the problem happens:

* Screen is put into DPMS "off" mode.

* The application requests the buffer-swap and X eventually ends up in 
radeon_dri2_schedule_swap.

* radeon_dri2_schedule_swap tries to determine the CRTC by calling 
radeon_dri2_drawable_crtc which further leads into radeon_pick_best_crtc

* In radeon_pick_best_crtc, no CRTC is found because CRTCs are either 
unused by the affected drawable or the only right candidate CRTC is 
skipped by this check (radeon_crtc_is_enabled looks explicitly at DPMS 
state):

if (!radeon_crtc_is_enabled(crtc))
continue;

* Consequently, radeon_pick_best_crtc returns -1 to 
radeon_dri2_schedule_swap, which decides that it can't do the vblank
wait and jumps to blit_fallback label.

* blit_fallback does its thing, achieving the effect of swap, but now 
there is no pacing. It returns immediatelly and application proceeds with 
rendering the next frame without any pause.

* As a consequence, we get a glxgears and X to run at maximum speed 
allowed by the CPU and GPU combined.

Now, the reason DPMS exists is to conserve power, but it doesn't make much 
sense to conserve power through monitor shutoff if we will eat up much 
more power by thrashing the processor and the GPU.

One quick fix that came into my mind is to replace the 'if' in 
radeon_pick_best_crtc with something like this:

if (!crtc->enabled)
continue;

(whether by design or by accident, crtc in DPMS "off" state is still 
enabled as far as that flag is concerned). However, that will introduce 
the regression with regard to this bug:

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

(which is the reason the above check was originally added).

Another possibility would be to enforce some maximum rate per-drawable 
(using sleep for example) when radeon_dri2_schedule_swap decides to take 
the blit_fallback path. However, I don't personally like it and I have a 
gut feeling that sleeping in shedule_swap would probably do harm somewhere 
else. Also, there may be applications that would want to render an 
animated scene off-screen at maximum speed (e.g., off-line rendering) and
radeon_dri2_schedule_swap has no way of telling whether crtc is -1 because
the application wants it that way or because the associated crtc is in
power-savings mode.

Clearly, the behavior that we have now is wrong from the power-savings 
perspective (i.e., it completely defeats the purpose of DPMS), but before 
I try to hack up the fix, I would like to hear some suggestions on what 
the "right" thing to do would be.

thanks,

Ilija

[PATCH 1/2] drm: Make the HPD status updates debug logs more readable

[Jesse Barnes]

On Mon, 10 Dec 2012 20:24:23 +
Damien Lespiau  wrote:

> From: Damien Lespiau 
> 
> Instead of just printing "status updated from 1 to 2", make those enum
> numbers immediately readable.
> 
> v2: Also patch output_poll_execute() (Daniel Vetter)
> 
> Signed-off-by: Damien Lespiau 
> ---
>  drivers/gpu/drm/drm_crtc_helper.c | 22 ++
>  1 file changed, 18 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_crtc_helper.c 
> b/drivers/gpu/drm/drm_crtc_helper.c
> index 1fe719f..524f0d3 100644
> --- a/drivers/gpu/drm/drm_crtc_helper.c
> +++ b/drivers/gpu/drm/drm_crtc_helper.c
> @@ -950,6 +950,18 @@ void drm_kms_helper_hotplug_event(struct drm_device *dev)
>  }
>  EXPORT_SYMBOL(drm_kms_helper_hotplug_event);
>  
> +static const char *connector_status_str(enum drm_connector_status status)
> +{
> + switch (status) {
> + case connector_status_connected:
> + return "connected";
> + case connector_status_disconnected:
> + return "disconnected";
> + default:
> + return "unknown";
> + }
> +}
> +
>  #define DRM_OUTPUT_POLL_PERIOD (10*HZ)
>  static void output_poll_execute(struct work_struct *work)
>  {
> @@ -984,10 +996,11 @@ static void output_poll_execute(struct work_struct 
> *work)
>   continue;
>  
>   connector->status = connector->funcs->detect(connector, false);
> - DRM_DEBUG_KMS("[CONNECTOR:%d:%s] status updated from %d to 
> %d\n",
> + DRM_DEBUG_KMS("[CONNECTOR:%d:%s] status updated from %s to 
> %s\n",
> connector->base.id,
> drm_get_connector_name(connector),
> -   old_status, connector->status);
> +   connector_status_str(old_status),
> +   connector_status_str(connector->status));
>   if (old_status != connector->status)
>   changed = true;
>   }
> @@ -1062,10 +1075,11 @@ void drm_helper_hpd_irq_event(struct drm_device *dev)
>   old_status = connector->status;
>  
>   connector->status = connector->funcs->detect(connector, false);
> - DRM_DEBUG_KMS("[CONNECTOR:%d:%s] status updated from %d to 
> %d\n",
> + DRM_DEBUG_KMS("[CONNECTOR:%d:%s] status updated from %s to 
> %s\n",
> connector->base.id,
> drm_get_connector_name(connector),
> -   old_status, connector->status);
> +   connector_status_str(old_status),
> +   connector_status_str(connector->status));
>   if (old_status != connector->status)
>   changed = true;
>   }

Yeah, thanks.

Reviewed-by: Jesse Barnes 

-- 
Jesse Barnes, Intel Open Source Technology Center

[RFC,v2,1/8] video: tegra: Add nvhost driver

[Terje Bergström]

On 29.11.2012 11:10, Mark Zhang wrote:
>> +
>> +/**
>> + * Write a cpu syncpoint increment to the hardware, without touching
>> + * the cache. Caller is responsible for host being powered.
>> + */
>> +static void host1x_syncpt_cpu_incr(struct nvhost_syncpt *sp, u32 id)
>> +{
>> + struct nvhost_master *dev = syncpt_to_dev(sp);
>> + u32 reg_offset = id / 32;
>> +
>> + if (!nvhost_module_powered(dev->dev)) {
>> + dev_err(_to_dev(sp)->dev->dev,
>> + "Trying to access host1x when it's off");
>> + return;
>> + }
>> +
>> + if (!nvhost_syncpt_client_managed(sp, id)
>> + && nvhost_syncpt_min_eq_max(sp, id)) {
>> + dev_err(_to_dev(sp)->dev->dev,
>> + "Trying to increment syncpoint id %d beyond max\n",
>> + id);
>> + return;
>> + }
>> + writel(BIT_MASK(id), dev->sync_aperture +
>> + host1x_sync_syncpt_cpu_incr_r() + reg_offset * 4);
> 
> I have a stupid question: According to the name and the context of this
> function, seems it increases the syncpt value which specified by param
> "id". So how does this "writel" increase the value? I don't know much
> about host1x/syncpt reg operations, so could you explain a little bit or
> I just completely have a wrong understanding?

I believe I've implemented most of the requests in this mail, but I seem
to have missed answering this question.

writel() to that register invokes a method in host1x, which increments
the sync point indicated by the value of the register by one.

Best regards,
Terje

[PATCH] drm/ttm: move ttm_lock.c to drm/vmwgfx

[Daniel Vetter]

... it's the only user. Also move the header fil there.

 but seriously, ttm_lock is best left undocumented since
nobody should use that unholy thing..
 agreed ;-)
 imo we should shovel that under drm/vmwgfx ...
 amen
 that thing scares me
 out of sight, out of mind ...

Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/ttm/Makefile|2 +-
 drivers/gpu/drm/ttm/ttm_lock.c  |  310 ---
 drivers/gpu/drm/vmwgfx/Makefile |2 +-
 drivers/gpu/drm/vmwgfx/ttm_lock.c   |  310 +++
 drivers/gpu/drm/vmwgfx/ttm_lock.h   |  247 
 drivers/gpu/drm/vmwgfx/vmwgfx_drv.h |2 +-
 include/drm/ttm/ttm_lock.h  |  247 
 7 files changed, 560 insertions(+), 560 deletions(-)
 delete mode 100644 drivers/gpu/drm/ttm/ttm_lock.c
 create mode 100644 drivers/gpu/drm/vmwgfx/ttm_lock.c
 create mode 100644 drivers/gpu/drm/vmwgfx/ttm_lock.h
 delete mode 100644 include/drm/ttm/ttm_lock.h

diff --git a/drivers/gpu/drm/ttm/Makefile b/drivers/gpu/drm/ttm/Makefile
index b2b33dd..607a0b6 100644
--- a/drivers/gpu/drm/ttm/Makefile
+++ b/drivers/gpu/drm/ttm/Makefile
@@ -4,7 +4,7 @@
 ccflags-y := -Iinclude/drm
 ttm-y := ttm_agp_backend.o ttm_memory.o ttm_tt.o ttm_bo.o \
ttm_bo_util.o ttm_bo_vm.o ttm_module.o \
-   ttm_object.o ttm_lock.o ttm_execbuf_util.o ttm_page_alloc.o \
+   ttm_object.o ttm_execbuf_util.o ttm_page_alloc.o \
ttm_bo_manager.o

 ifeq ($(CONFIG_SWIOTLB),y)
diff --git a/drivers/gpu/drm/ttm/ttm_lock.c b/drivers/gpu/drm/ttm/ttm_lock.c
deleted file mode 100644
index 3daa9a3..000
--- a/drivers/gpu/drm/ttm/ttm_lock.c
+++ /dev/null
@@ -1,310 +0,0 @@
-/**
- *
- * Copyright (c) 2007-2009 VMware, Inc., Palo Alto, CA., USA
- * All Rights Reserved.
- *
- * 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, sub license, 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 NON-INFRINGEMENT. IN NO EVENT SHALL
- * THE COPYRIGHT HOLDERS, AUTHORS AND/OR ITS SUPPLIERS 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: Thomas Hellstrom 
- */
-
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-
-#define TTM_WRITE_LOCK_PENDING(1 << 0)
-#define TTM_VT_LOCK_PENDING   (1 << 1)
-#define TTM_SUSPEND_LOCK_PENDING  (1 << 2)
-#define TTM_VT_LOCK   (1 << 3)
-#define TTM_SUSPEND_LOCK  (1 << 4)
-
-void ttm_lock_init(struct ttm_lock *lock)
-{
-   spin_lock_init(>lock);
-   init_waitqueue_head(>queue);
-   lock->rw = 0;
-   lock->flags = 0;
-   lock->kill_takers = false;
-   lock->signal = SIGKILL;
-}
-EXPORT_SYMBOL(ttm_lock_init);
-
-void ttm_read_unlock(struct ttm_lock *lock)
-{
-   spin_lock(>lock);
-   if (--lock->rw == 0)
-   wake_up_all(>queue);
-   spin_unlock(>lock);
-}
-EXPORT_SYMBOL(ttm_read_unlock);
-
-static bool __ttm_read_lock(struct ttm_lock *lock)
-{
-   bool locked = false;
-
-   spin_lock(>lock);
-   if (unlikely(lock->kill_takers)) {
-   send_sig(lock->signal, current, 0);
-   spin_unlock(>lock);
-   return false;
-   }
-   if (lock->rw >= 0 && lock->flags == 0) {
-   ++lock->rw;
-   locked = true;
-   }
-   spin_unlock(>lock);
-   return locked;
-}
-
-int ttm_read_lock(struct ttm_lock *lock, bool interruptible)
-{
-   int ret = 0;
-
-   if (interruptible)
-   ret = wait_event_interruptible(lock->queue,
-  __ttm_read_lock(lock));
-   else
-   wait_event(lock->queue, __ttm_read_lock(lock));
-   return ret;
-}
-EXPORT_SYMBOL(ttm_read_lock);
-
-static bool __ttm_read_trylock(struct ttm_lock *lock, bool *locked)
-{
-   bool block = true;
-
-   *locked = false;
-
-   spin_lock(>lock);
-   if (unlikely(lock->kill_takers)) {
-   

[PATCH v2] drm/exynos: use DMA_ATTR_NO_KERNEL_MAPPING attribute

[Inki Dae]

Changelog v2:
fix argument to dma_mmap_attr function.
- use pages instead of kvaddr because kvaddr is 0 with
  DMA_ATTR_NO_KERNEL_MAPPING.

Changelog v1:
When gem allocation is requested, kernel space mapping isn't needed.
But if need, such as console framebuffer, the physical pages would be
mapped with kernel space though vmap function.

Signed-off-by: Inki Dae 
Signed-off-by: Kyungmin Park 
---
 drivers/gpu/drm/exynos/exynos_drm_buf.c   |   28 ++--
 drivers/gpu/drm/exynos/exynos_drm_fbdev.c |   18 +-
 drivers/gpu/drm/exynos/exynos_drm_gem.c   |2 +-
 drivers/gpu/drm/exynos/exynos_drm_gem.h   |2 ++
 4 files changed, 30 insertions(+), 20 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_buf.c 
b/drivers/gpu/drm/exynos/exynos_drm_buf.c
index 72bf97b..2774e9b 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_buf.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_buf.c
@@ -35,6 +35,7 @@ static int lowlevel_buffer_allocate(struct drm_device *dev,
 {
int ret = 0;
enum dma_attr attr = DMA_ATTR_FORCE_CONTIGUOUS;
+   unsigned int nr_pages;

DRM_DEBUG_KMS("%s\n", __FILE__);

@@ -49,40 +50,31 @@ static int lowlevel_buffer_allocate(struct drm_device *dev,
attr = DMA_ATTR_WRITE_COMBINE;

dma_set_attr(attr, >dma_attrs);
+   dma_set_attr(DMA_ATTR_NO_KERNEL_MAPPING, >dma_attrs);

-   buf->kvaddr = dma_alloc_attrs(dev->dev, buf->size,
+   buf->pages = dma_alloc_attrs(dev->dev, buf->size,
>dma_addr, GFP_KERNEL, >dma_attrs);
-   if (!buf->kvaddr) {
+   if (!buf->pages) {
DRM_ERROR("failed to allocate buffer.\n");
return -ENOMEM;
}

-   buf->sgt = kzalloc(sizeof(struct sg_table), GFP_KERNEL);
+   nr_pages = buf->size >> PAGE_SHIFT;
+   buf->sgt = drm_prime_pages_to_sg(buf->pages, nr_pages);
if (!buf->sgt) {
-   DRM_ERROR("failed to allocate sg table.\n");
+   DRM_ERROR("failed to get sg table.\n");
ret = -ENOMEM;
goto err_free_attrs;
}

-   ret = dma_get_sgtable(dev->dev, buf->sgt, buf->kvaddr, buf->dma_addr,
-   buf->size);
-   if (ret < 0) {
-   DRM_ERROR("failed to get sgtable.\n");
-   goto err_free_sgt;
-   }
-
-   DRM_DEBUG_KMS("vaddr(0x%lx), dma_addr(0x%lx), size(0x%lx)\n",
-   (unsigned long)buf->kvaddr,
+   DRM_DEBUG_KMS("dma_addr(0x%lx), size(0x%lx)\n",
(unsigned long)buf->dma_addr,
buf->size);

return ret;

-err_free_sgt:
-   kfree(buf->sgt);
-   buf->sgt = NULL;
 err_free_attrs:
-   dma_free_attrs(dev->dev, buf->size, buf->kvaddr,
+   dma_free_attrs(dev->dev, buf->size, buf->pages,
(dma_addr_t)buf->dma_addr, >dma_attrs);
buf->dma_addr = (dma_addr_t)NULL;

@@ -109,7 +101,7 @@ static void lowlevel_buffer_deallocate(struct drm_device 
*dev,
kfree(buf->sgt);
buf->sgt = NULL;

-   dma_free_attrs(dev->dev, buf->size, buf->kvaddr,
+   dma_free_attrs(dev->dev, buf->size, buf->pages,
(dma_addr_t)buf->dma_addr, >dma_attrs);
buf->dma_addr = (dma_addr_t)NULL;
 }
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fbdev.c 
b/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
index 885ef23..f433eb7 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
@@ -65,7 +65,7 @@ static int exynos_drm_fb_mmap(struct fb_info *info,
if (vm_size > buffer->size)
return -EINVAL;

-   ret = dma_mmap_attrs(helper->dev->dev, vma, buffer->kvaddr,
+   ret = dma_mmap_attrs(helper->dev->dev, vma, buffer->pages,
buffer->dma_addr, buffer->size, >dma_attrs);
if (ret < 0) {
DRM_ERROR("failed to mmap.\n");
@@ -109,6 +109,17 @@ static int exynos_drm_fbdev_update(struct drm_fb_helper 
*helper,
return -EFAULT;
}

+   /* map pages with kernel virtual space. */
+   if (!buffer->kvaddr) {
+   unsigned int nr_pages = buffer->size >> PAGE_SHIFT;
+   buffer->kvaddr = vmap(buffer->pages, nr_pages, VM_MAP,
+   pgprot_writecombine(PAGE_KERNEL));
+   if (!buffer->kvaddr) {
+   DRM_ERROR("failed to map pages to kernel space.\n");
+   return -EIO;
+   }
+   }
+
/* buffer count to framebuffer always is 1 at booting time. */
exynos_drm_fb_set_buf_cnt(fb, 1);

@@ -305,8 +316,13 @@ err_init:
 static void exynos_drm_fbdev_destroy(struct drm_device *dev,
  struct drm_fb_helper *fb_helper)
 {
+   struct exynos_drm_fbdev *exynos_fbd = to_exynos_fbdev(fb_helper);
+   struct exynos_drm_gem_obj *exynos_gem_obj = exynos_fbd->exynos_gem_obj;

[PATCHv15 3/7] video: add of helper for display timings/videomode

[Tomi Valkeinen]

On 2012-12-07 16:12, Philipp Zabel wrote:
> Hi,
> 
> Am Montag, den 26.11.2012, 18:56 +0200 schrieb Tomi Valkeinen:

>> So what does the pixelclk-inverted mean? Normally the SoC drives pixel
>> data on rising edge, and the panel samples it at falling edge? And
>> vice-versa for inverted? Or the other way around?
>>
>> When is hsync/vsync set? On rising or falling edge of pclk?
>>
>> My point here is that the pixelclk-inverted is not crystal clear thing,
>> like the hsync/vsync/de-active values are.
>>
>> And while thinking about this, I realized that the meaning of
>> pixelclk-inverted depends on what component is it applied to. Presuming
>> normal pixclk means "pixel data on rising edge", the meaning of that
>> depends on do we consider the SoC or the panel. The panel needs to
>> sample the data on the other edge from the one the SoC uses to drive the
>> data.
>>
>> Does the videomode describe the panel, or does it describe the settings
>> programmed to the SoC?
> 
> How about calling this property pixelclk-active, active high meaning
> driving pixel data on rising edges and sampling on falling edges (the
> pixel clock is high between driving and sampling the data), and active
> low meaning driving on falling edges and sampling on rising edges?
> It is the same from the SoC perspective and from the panel perspective,
> and it mirrors the usage of the other *-active properties.

This sounds good to me. It's not quite correct, as neither pixelclock or
pixel data are not really "active" when the clock is high/low, but it
still makes sense and is clear (at least with a short description).

 Tomi


-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 899 bytes
Desc: OpenPGP digital signature
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121210/d9a988de/attachment.pgp>

[PATCH -next] drm/exynos/iommu: fix return value check in drm_create_iommu_mapping()

[Inki Dae]

Applied.

Thanks,
Inki Dae

2012/12/7 Wei Yongjun 

> From: Wei Yongjun 
>
> In case of error, function arm_iommu_create_mapping() returns
> ERR_PTR() and never returns NULL. The NULL test in the return
> value check should be replaced with IS_ERR().
>
> Signed-off-by: Wei Yongjun 
> ---
>  drivers/gpu/drm/exynos/exynos_drm_iommu.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_iommu.c
> b/drivers/gpu/drm/exynos/exynos_drm_iommu.c
> index 09db198..3b3d3a6 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_iommu.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_iommu.c
> @@ -56,7 +56,7 @@ int drm_create_iommu_mapping(struct drm_device *drm_dev)
> mapping = arm_iommu_create_mapping(_bus_type,
> priv->da_start,
> priv->da_space_size,
> priv->da_space_order);
> -   if (!mapping)
> +   if (IS_ERR(mapping))
> return -ENOMEM;
>
> dev->dma_parms = devm_kzalloc(dev, sizeof(*dev->dma_parms),
>
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>
-- next part ------
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121210/39c255a0/attachment.html>

[PATCH 7/7] drm/ttm: unexport ttm_bo_wait_unreserved

[Maarten Lankhorst]

All legitimate users of this function outside ttm_bo.c are gone, now
it's only an implementation detail.

Signed-off-by: Maarten Lankhorst 
Reviewed-by: Jerome Glisse 
---
 drivers/gpu/drm/ttm/ttm_bo.c|  4 ++--
 include/drm/ttm/ttm_bo_driver.h | 12 
 2 files changed, 2 insertions(+), 14 deletions(-)

diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index 174b325..fd78104 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -158,7 +158,8 @@ static void ttm_bo_release_list(struct kref *list_kref)
ttm_mem_global_free(bdev->glob->mem_glob, acc_size);
 }

-int ttm_bo_wait_unreserved(struct ttm_buffer_object *bo, bool interruptible)
+static int ttm_bo_wait_unreserved(struct ttm_buffer_object *bo,
+ bool interruptible)
 {
if (interruptible) {
return wait_event_interruptible(bo->event_queue,
@@ -168,7 +169,6 @@ int ttm_bo_wait_unreserved(struct ttm_buffer_object *bo, 
bool interruptible)
return 0;
}
 }
-EXPORT_SYMBOL(ttm_bo_wait_unreserved);

 void ttm_bo_add_to_lru(struct ttm_buffer_object *bo)
 {
diff --git a/include/drm/ttm/ttm_bo_driver.h b/include/drm/ttm/ttm_bo_driver.h
index 5af71af..0fbd046 100644
--- a/include/drm/ttm/ttm_bo_driver.h
+++ b/include/drm/ttm/ttm_bo_driver.h
@@ -898,18 +898,6 @@ extern void ttm_bo_unreserve(struct ttm_buffer_object *bo);
  */
 extern void ttm_bo_unreserve_locked(struct ttm_buffer_object *bo);

-/**
- * ttm_bo_wait_unreserved
- *
- * @bo: A pointer to a struct ttm_buffer_object.
- *
- * Wait for a struct ttm_buffer_object to become unreserved.
- * This is typically used in the execbuf code to relax cpu-usage when
- * a potential deadlock condition backoff.
- */
-extern int ttm_bo_wait_unreserved(struct ttm_buffer_object *bo,
- bool interruptible);
-
 /*
  * ttm_bo_util.c
  */
-- 
1.8.0

[PATCH 6/7] drm/nouveau: use ttm_bo_reserve_slowpath in validate_init, v2

[Maarten Lankhorst]

Similar rationale to the identical commit in drm/ttm.
Instead of only waiting for unreservation, we make sure we actually
own the reservation, then retry to get the rest.

Changes since v1:
 - Increase the seqno before calling ttm_bo_reserve_slowpath

Signed-off-by: Maarten Lankhorst 
---
 drivers/gpu/drm/nouveau/nouveau_gem.c | 22 +-
 1 file changed, 17 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/nouveau_gem.c 
b/drivers/gpu/drm/nouveau/nouveau_gem.c
index f2bd59e..afcba1a 100644
--- a/drivers/gpu/drm/nouveau/nouveau_gem.c
+++ b/drivers/gpu/drm/nouveau/nouveau_gem.c
@@ -321,9 +321,10 @@ validate_init(struct nouveau_channel *chan, struct 
drm_file *file_priv,
uint32_t sequence;
int trycnt = 0;
int ret, i;
+   struct nouveau_bo *res_bo = NULL;

-retry:
sequence = atomic_add_return(1, >ttm.validate_sequence);
+retry:
if (++trycnt > 10) {
NV_ERROR(drm, "%s failed and gave up.\n", __func__);
return -EINVAL;
@@ -341,6 +342,11 @@ retry:
return -ENOENT;
}
nvbo = gem->driver_private;
+   if (nvbo == res_bo) {
+   res_bo = NULL;
+   drm_gem_object_unreference_unlocked(gem);
+   continue;
+   }

if (nvbo->reserved_by && nvbo->reserved_by == file_priv) {
NV_ERROR(drm, "multiple instances of buffer %d on "
@@ -353,15 +359,19 @@ retry:
ret = ttm_bo_reserve(>bo, true, false, true, sequence);
if (ret) {
validate_fini(op, NULL);
-   if (unlikely(ret == -EAGAIN))
-   ret = ttm_bo_wait_unreserved(>bo, true);
-   drm_gem_object_unreference_unlocked(gem);
+   if (unlikely(ret == -EAGAIN)) {
+   sequence = atomic_add_return(1, 
>ttm.validate_sequence);
+   ret = ttm_bo_reserve_slowpath(>bo, true,
+ sequence);
+   if (!ret)
+   res_bo = nvbo;
+   }
if (unlikely(ret)) {
+   drm_gem_object_unreference_unlocked(gem);
if (ret != -ERESTARTSYS)
NV_ERROR(drm, "fail reserve\n");
return ret;
}
-   goto retry;
}

b->user_priv = (uint64_t)(unsigned long)nvbo;
@@ -383,6 +393,8 @@ retry:
validate_fini(op, NULL);
return -EINVAL;
}
+   if (nvbo == res_bo)
+   goto retry;
}

return 0;
-- 
1.8.0

[PATCH 5/7] drm/ttm: use ttm_bo_reserve_slowpath_nolru in ttm_eu_reserve_buffers, v2

[Maarten Lankhorst]

This requires re-use of the seqno, which increases fairness slightly.
Instead of spinning with a new seqno every time we keep the current one,
but still drop all other reservations we hold. Only when we succeed,
we try to get back our other reservations again.

This should increase fairness slightly as well.

Changes since v1:
 - Increase val_seq before calling ttm_bo_reserve_slowpath_nolru and
   retrying to take all entries to prevent a race.

Signed-off-by: Maarten Lankhorst 
---
 drivers/gpu/drm/ttm/ttm_execbuf_util.c | 23 +--
 1 file changed, 21 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/ttm/ttm_execbuf_util.c 
b/drivers/gpu/drm/ttm/ttm_execbuf_util.c
index c7d3236..7b90def 100644
--- a/drivers/gpu/drm/ttm/ttm_execbuf_util.c
+++ b/drivers/gpu/drm/ttm/ttm_execbuf_util.c
@@ -129,13 +129,17 @@ int ttm_eu_reserve_buffers(struct list_head *list)
entry = list_first_entry(list, struct ttm_validate_buffer, head);
glob = entry->bo->glob;

-retry:
spin_lock(>lru_lock);
val_seq = entry->bo->bdev->val_seq++;

+retry:
list_for_each_entry(entry, list, head) {
struct ttm_buffer_object *bo = entry->bo;

+   /* already slowpath reserved? */
+   if (entry->reserved)
+   continue;
+
ret = ttm_bo_reserve_nolru(bo, true, true, true, val_seq);
switch (ret) {
case 0:
@@ -155,11 +159,26 @@ retry:
/* fallthrough */
case -EAGAIN:
ttm_eu_backoff_reservation_locked(list);
+
+   /*
+* temporarily increase sequence number every retry,
+* to prevent us from seeing our old reservation
+* sequence when someone else reserved the buffer,
+* but hasn't updated the seq_valid/seqno members yet.
+*/
+   val_seq = entry->bo->bdev->val_seq++;
+
spin_unlock(>lru_lock);
ttm_eu_list_ref_sub(list);
-   ret = ttm_bo_wait_unreserved(bo, true);
+   ret = ttm_bo_reserve_slowpath_nolru(bo, true, val_seq);
if (unlikely(ret != 0))
return ret;
+   spin_lock(>lru_lock);
+   entry->reserved = true;
+   if (unlikely(atomic_read(>cpu_writers) > 0)) {
+   ret = -EBUSY;
+   goto err;
+   }
goto retry;
default:
goto err;
-- 
1.8.0

[PATCH 4/7] drm/ttm: add ttm_bo_reserve_slowpath

[Maarten Lankhorst]

Instead of dropping everything, waiting for the bo to be unreserved
and trying over, a better strategy would be to do a blocking wait.

This can be mapped a lot better to a mutex_lock-like call.

Signed-off-by: Maarten Lankhorst 
Reviewed-by: Jerome Glisse 
---
 drivers/gpu/drm/ttm/ttm_bo.c| 47 +
 include/drm/ttm/ttm_bo_driver.h | 30 ++
 2 files changed, 77 insertions(+)

diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index 61b5cd0..174b325 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -310,6 +310,53 @@ int ttm_bo_reserve(struct ttm_buffer_object *bo,
return ret;
 }

+int ttm_bo_reserve_slowpath_nolru(struct ttm_buffer_object *bo,
+ bool interruptible, uint32_t sequence)
+{
+   bool wake_up = false;
+   int ret;
+
+   while (unlikely(atomic_xchg(>reserved, 1) != 0)) {
+   WARN_ON(bo->seq_valid && sequence == bo->val_seq);
+
+   ret = ttm_bo_wait_unreserved(bo, interruptible);
+
+   if (unlikely(ret))
+   return ret;
+   }
+
+   if ((bo->val_seq - sequence < (1 << 31)) || !bo->seq_valid)
+   wake_up = true;
+
+   /**
+* Wake up waiters that may need to recheck for deadlock,
+* if we decreased the sequence number.
+*/
+   bo->val_seq = sequence;
+   bo->seq_valid = true;
+   if (wake_up)
+   wake_up_all(>event_queue);
+
+   return 0;
+}
+
+int ttm_bo_reserve_slowpath(struct ttm_buffer_object *bo,
+   bool interruptible, uint32_t sequence)
+{
+   struct ttm_bo_global *glob = bo->glob;
+   int put_count, ret;
+
+   ret = ttm_bo_reserve_slowpath_nolru(bo, interruptible, sequence);
+   if (likely(!ret)) {
+   spin_lock(>lru_lock);
+   put_count = ttm_bo_del_from_lru(bo);
+   spin_unlock(>lru_lock);
+   ttm_bo_list_ref_sub(bo, put_count, true);
+   }
+   return ret;
+}
+EXPORT_SYMBOL(ttm_bo_reserve_slowpath);
+
 void ttm_bo_unreserve_locked(struct ttm_buffer_object *bo)
 {
ttm_bo_add_to_lru(bo);
diff --git a/include/drm/ttm/ttm_bo_driver.h b/include/drm/ttm/ttm_bo_driver.h
index 6fff432..5af71af 100644
--- a/include/drm/ttm/ttm_bo_driver.h
+++ b/include/drm/ttm/ttm_bo_driver.h
@@ -821,6 +821,36 @@ extern int ttm_bo_reserve(struct ttm_buffer_object *bo,
  bool interruptible,
  bool no_wait, bool use_sequence, uint32_t sequence);

+/**
+ * ttm_bo_reserve_slowpath_nolru:
+ * @bo: A pointer to a struct ttm_buffer_object.
+ * @interruptible: Sleep interruptible if waiting.
+ * @sequence: Set (@bo)->sequence to this value after lock
+ *
+ * This is called after ttm_bo_reserve returns -EAGAIN and we backed off
+ * from all our other reservations. Because there are no other reservations
+ * held by us, this function cannot deadlock any more.
+ *
+ * Will not remove reserved buffers from the lru lists.
+ * Otherwise identical to ttm_bo_reserve_slowpath.
+ */
+extern int ttm_bo_reserve_slowpath_nolru(struct ttm_buffer_object *bo,
+bool interruptible,
+uint32_t sequence);
+
+
+/**
+ * ttm_bo_reserve_slowpath:
+ * @bo: A pointer to a struct ttm_buffer_object.
+ * @interruptible: Sleep interruptible if waiting.
+ * @sequence: Set (@bo)->sequence to this value after lock
+ *
+ * This is called after ttm_bo_reserve returns -EAGAIN and we backed off
+ * from all our other reservations. Because there are no other reservations
+ * held by us, this function cannot deadlock any more.
+ */
+extern int ttm_bo_reserve_slowpath(struct ttm_buffer_object *bo,
+  bool interruptible, uint32_t sequence);

 /**
  * ttm_bo_reserve_nolru:
-- 
1.8.0

[PATCH 3/7] drm/ttm: cleanup ttm_eu_reserve_buffers handling

[Maarten Lankhorst]

With the lru lock no longer required for protecting reservations we
can just do a ttm_bo_reserve_nolru on -EBUSY, and handle all errors
in a single path.

Signed-off-by: Maarten Lankhorst 
Reviewed-by: Jerome Glisse 
---
 drivers/gpu/drm/ttm/ttm_execbuf_util.c | 53 ++
 1 file changed, 21 insertions(+), 32 deletions(-)

diff --git a/drivers/gpu/drm/ttm/ttm_execbuf_util.c 
b/drivers/gpu/drm/ttm/ttm_execbuf_util.c
index bd37b5c..c7d3236 100644
--- a/drivers/gpu/drm/ttm/ttm_execbuf_util.c
+++ b/drivers/gpu/drm/ttm/ttm_execbuf_util.c
@@ -82,22 +82,6 @@ static void ttm_eu_list_ref_sub(struct list_head *list)
}
 }

-static int ttm_eu_wait_unreserved_locked(struct list_head *list,
-struct ttm_buffer_object *bo)
-{
-   struct ttm_bo_global *glob = bo->glob;
-   int ret;
-
-   ttm_eu_del_from_lru_locked(list);
-   spin_unlock(>lru_lock);
-   ret = ttm_bo_wait_unreserved(bo, true);
-   spin_lock(>lru_lock);
-   if (unlikely(ret != 0))
-   ttm_eu_backoff_reservation_locked(list);
-   return ret;
-}
-
-
 void ttm_eu_backoff_reservation(struct list_head *list)
 {
struct ttm_validate_buffer *entry;
@@ -152,19 +136,23 @@ retry:
list_for_each_entry(entry, list, head) {
struct ttm_buffer_object *bo = entry->bo;

-retry_this_bo:
ret = ttm_bo_reserve_nolru(bo, true, true, true, val_seq);
switch (ret) {
case 0:
break;
case -EBUSY:
-   ret = ttm_eu_wait_unreserved_locked(list, bo);
-   if (unlikely(ret != 0)) {
-   spin_unlock(>lru_lock);
-   ttm_eu_list_ref_sub(list);
-   return ret;
-   }
-   goto retry_this_bo;
+   ttm_eu_del_from_lru_locked(list);
+   spin_unlock(>lru_lock);
+   ret = ttm_bo_reserve_nolru(bo, true, false,
+  true, val_seq);
+   spin_lock(>lru_lock);
+   if (!ret)
+   break;
+
+   if (unlikely(ret != -EAGAIN))
+   goto err;
+
+   /* fallthrough */
case -EAGAIN:
ttm_eu_backoff_reservation_locked(list);
spin_unlock(>lru_lock);
@@ -174,18 +162,13 @@ retry_this_bo:
return ret;
goto retry;
default:
-   ttm_eu_backoff_reservation_locked(list);
-   spin_unlock(>lru_lock);
-   ttm_eu_list_ref_sub(list);
-   return ret;
+   goto err;
}

entry->reserved = true;
if (unlikely(atomic_read(>cpu_writers) > 0)) {
-   ttm_eu_backoff_reservation_locked(list);
-   spin_unlock(>lru_lock);
-   ttm_eu_list_ref_sub(list);
-   return -EBUSY;
+   ret = -EBUSY;
+   goto err;
}
}

@@ -194,6 +177,12 @@ retry_this_bo:
ttm_eu_list_ref_sub(list);

return 0;
+
+err:
+   ttm_eu_backoff_reservation_locked(list);
+   spin_unlock(>lru_lock);
+   ttm_eu_list_ref_sub(list);
+   return ret;
 }
 EXPORT_SYMBOL(ttm_eu_reserve_buffers);

-- 
1.8.0

[PATCH 2/7] drm/ttm: remove lru_lock around ttm_bo_reserve

[Maarten Lankhorst]

There should no longer be assumptions that reserve will always succeed
with the lru lock held, so we can safely break the whole atomic
reserve/lru thing. As a bonus this fixes most lockdep annotations for
reservations.

Signed-off-by: Maarten Lankhorst 
Reviewed-by: Jerome Glisse 
---
 drivers/gpu/drm/ttm/ttm_bo.c   | 54 ++
 drivers/gpu/drm/ttm/ttm_execbuf_util.c |  2 +-
 include/drm/ttm/ttm_bo_driver.h| 19 +++-
 3 files changed, 40 insertions(+), 35 deletions(-)

diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index 9028327..61b5cd0 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -213,14 +213,13 @@ int ttm_bo_del_from_lru(struct ttm_buffer_object *bo)
return put_count;
 }

-int ttm_bo_reserve_locked(struct ttm_buffer_object *bo,
+int ttm_bo_reserve_nolru(struct ttm_buffer_object *bo,
  bool interruptible,
  bool no_wait, bool use_sequence, uint32_t sequence)
 {
-   struct ttm_bo_global *glob = bo->glob;
int ret;

-   while (unlikely(atomic_read(>reserved) != 0)) {
+   while (unlikely(atomic_xchg(>reserved, 1) != 0)) {
/**
 * Deadlock avoidance for multi-bo reserving.
 */
@@ -241,26 +240,36 @@ int ttm_bo_reserve_locked(struct ttm_buffer_object *bo,
if (no_wait)
return -EBUSY;

-   spin_unlock(>lru_lock);
ret = ttm_bo_wait_unreserved(bo, interruptible);
-   spin_lock(>lru_lock);

if (unlikely(ret))
return ret;
}

-   atomic_set(>reserved, 1);
if (use_sequence) {
+   bool wake_up = false;
/**
 * Wake up waiters that may need to recheck for deadlock,
 * if we decreased the sequence number.
 */
if (unlikely((bo->val_seq - sequence < (1 << 31))
 || !bo->seq_valid))
-   wake_up_all(>event_queue);
+   wake_up = true;

+   /*
+* In the worst case with memory ordering these values can be
+* seen in the wrong order. However since we call wake_up_all
+* in that case, this will hopefully not pose a problem,
+* and the worst case would only cause someone to accidentally
+* hit -EAGAIN in ttm_bo_reserve when they see old value of
+* val_seq. However this would only happen if seq_valid was
+* written before val_seq was, and just means some slightly
+* increased cpu usage
+*/
bo->val_seq = sequence;
bo->seq_valid = true;
+   if (wake_up)
+   wake_up_all(>event_queue);
} else {
bo->seq_valid = false;
}
@@ -289,14 +298,14 @@ int ttm_bo_reserve(struct ttm_buffer_object *bo,
int put_count = 0;
int ret;

-   spin_lock(>lru_lock);
-   ret = ttm_bo_reserve_locked(bo, interruptible, no_wait, use_sequence,
-   sequence);
-   if (likely(ret == 0))
+   ret = ttm_bo_reserve_nolru(bo, interruptible, no_wait, use_sequence,
+  sequence);
+   if (likely(ret == 0)) {
+   spin_lock(>lru_lock);
put_count = ttm_bo_del_from_lru(bo);
-   spin_unlock(>lru_lock);
-
-   ttm_bo_list_ref_sub(bo, put_count, true);
+   spin_unlock(>lru_lock);
+   ttm_bo_list_ref_sub(bo, put_count, true);
+   }

return ret;
 }
@@ -510,7 +519,7 @@ static void ttm_bo_cleanup_refs_or_queue(struct 
ttm_buffer_object *bo)
int ret;

spin_lock(>lru_lock);
-   ret = ttm_bo_reserve_locked(bo, false, true, false, 0);
+   ret = ttm_bo_reserve_nolru(bo, false, true, false, 0);

spin_lock(>fence_lock);
(void) ttm_bo_wait(bo, false, false, true);
@@ -603,7 +612,7 @@ static int ttm_bo_cleanup_refs_and_unlock(struct 
ttm_buffer_object *bo,
return ret;

spin_lock(>lru_lock);
-   ret = ttm_bo_reserve_locked(bo, false, true, false, 0);
+   ret = ttm_bo_reserve_nolru(bo, false, true, false, 0);

/*
 * We raced, and lost, someone else holds the reservation now,
@@ -667,7 +676,14 @@ static int ttm_bo_delayed_delete(struct ttm_bo_device 
*bdev, bool remove_all)
kref_get(>list_kref);
}

-   ret = ttm_bo_reserve_locked(entry, false, !remove_all, false, 
0);
+   ret = ttm_bo_reserve_nolru(entry, false, true, false, 0);
+   if (remove_all && ret) {
+   spin_unlock(>lru_lock);
+   ret = 

[PATCH 1/7] drm/nouveau: increase reservation sequence every retry

[Maarten Lankhorst]

This is temporary until the fence framework can be used. With the
lru/reservation atomicity removal it is possible to see your old
sequence number and the buffer being reserved, leading to erroneously
reporting -EDEADLK.

Workaround it by bumping the sequence number every retry.

Signed-off-by: Maarten Lankhorst 
---
 drivers/gpu/drm/nouveau/nouveau_gem.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/nouveau/nouveau_gem.c 
b/drivers/gpu/drm/nouveau/nouveau_gem.c
index 7b9364b..f2bd59e 100644
--- a/drivers/gpu/drm/nouveau/nouveau_gem.c
+++ b/drivers/gpu/drm/nouveau/nouveau_gem.c
@@ -322,8 +322,8 @@ validate_init(struct nouveau_channel *chan, struct drm_file 
*file_priv,
int trycnt = 0;
int ret, i;

-   sequence = atomic_add_return(1, >ttm.validate_sequence);
 retry:
+   sequence = atomic_add_return(1, >ttm.validate_sequence);
if (++trycnt > 10) {
NV_ERROR(drm, "%s failed and gave up.\n", __func__);
return -EINVAL;
-- 
1.8.0

[PATCH v2 linux-next] i915: intel_set_mode: Reduce stack allocation from 500 bytes to 2 pointers

[Daniel Vetter]

On Mon, Dec 10, 2012 at 09:29:17AM +0200, Jani Nikula wrote:
> On Fri, 07 Dec 2012, Tim Gardner  wrote:
> > smatch warning:
> >
> > drivers/gpu/drm/i915/intel_display.c:7019 intel_set_mode() warn: function 
> > puts
> > 500 bytes on stack
> >
> > Refactor so that saved_mode and saved_hwmode are dynamically allocated as 
> > opposed
> > to being automatic variables. 500 bytes seems like it could run the 
> > potential for blowing
> > the kernel stack.
> 
> Reviewed-by: Jani Nikula 
Queued for -next, thanks for the patch.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

[PATCH 1/1] drm/i915: Remove duplicate inclusion of drm/drm_edid.h

[Daniel Vetter]

On Mon, Dec 10, 2012 at 09:50:51AM +0200, Jani Nikula wrote:
> On Fri, 07 Dec 2012, Sachin Kamat  wrote:
> > drm/drm_edid.h was included twice.
> 
> Reviewed-by: Jani Nikula 
Queued for -next, thanks for the patch.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

[PATCH 1/1] drm/i915: Remove duplicate inclusion of drm/drm_edid.h

[Jani Nikula]

On Fri, 07 Dec 2012, Sachin Kamat  wrote:
> drm/drm_edid.h was included twice.

Reviewed-by: Jani Nikula 

>
> Signed-off-by: Sachin Kamat 
> ---
>  drivers/gpu/drm/i915/intel_modes.c |1 -
>  1 files changed, 0 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_modes.c 
> b/drivers/gpu/drm/i915/intel_modes.c
> index b00f1c8..49249bb 100644
> --- a/drivers/gpu/drm/i915/intel_modes.c
> +++ b/drivers/gpu/drm/i915/intel_modes.c
> @@ -28,7 +28,6 @@
>  #include 
>  #include 
>  #include 
> -#include 
>  #include "intel_drv.h"
>  #include "i915_drv.h"
>  
> -- 
> 1.7.4.1
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v2 linux-next] i915: intel_set_mode: Reduce stack allocation from 500 bytes to 2 pointers

[Jani Nikula]

On Fri, 07 Dec 2012, Tim Gardner  wrote:
> smatch warning:
>
> drivers/gpu/drm/i915/intel_display.c:7019 intel_set_mode() warn: function puts
> 500 bytes on stack
>
> Refactor so that saved_mode and saved_hwmode are dynamically allocated as 
> opposed
> to being automatic variables. 500 bytes seems like it could run the potential 
> for blowing
> the kernel stack.

Reviewed-by: Jani Nikula 


>
> Cc: Daniel Vetter 
> Cc: David Airlie 
> Cc: dri-devel at lists.freedesktop.org
> Signed-off-by: Tim Gardner 
> ---
>
> V2 - spaces around '*', use kmalloc instead of kzalloc(). Missed
> error return that would have orphaned memory.
>
>  drivers/gpu/drm/i915/intel_display.c |   22 --
>  1 file changed, 16 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_display.c 
> b/drivers/gpu/drm/i915/intel_display.c
> index de51489..c15b21b 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -7739,11 +7739,18 @@ bool intel_set_mode(struct drm_crtc *crtc,
>  {
>   struct drm_device *dev = crtc->dev;
>   drm_i915_private_t *dev_priv = dev->dev_private;
> - struct drm_display_mode *adjusted_mode, saved_mode, saved_hwmode;
> + struct drm_display_mode *adjusted_mode, *saved_mode, *saved_hwmode;
>   struct intel_crtc *intel_crtc;
>   unsigned disable_pipes, prepare_pipes, modeset_pipes;
>   bool ret = true;
>  
> + saved_mode = kmalloc(2 * sizeof(*saved_mode), GFP_KERNEL);
> + if (!saved_mode) {
> + DRM_ERROR("i915: Could not allocate saved display mode.\n");
> + return false;
> + }
> + saved_hwmode = saved_mode + 1;
> +
>   intel_modeset_affected_pipes(crtc, _pipes,
>_pipes, _pipes);
>  
> @@ -7753,8 +7760,8 @@ bool intel_set_mode(struct drm_crtc *crtc,
>   for_each_intel_crtc_masked(dev, disable_pipes, intel_crtc)
>   intel_crtc_disable(_crtc->base);
>  
> - saved_hwmode = crtc->hwmode;
> - saved_mode = crtc->mode;
> + *saved_hwmode = crtc->hwmode;
> + *saved_mode = crtc->mode;
>  
>   /* Hack: Because we don't (yet) support global modeset on multiple
>* crtcs, we don't keep track of the new mode for more than one crtc.
> @@ -7765,7 +7772,8 @@ bool intel_set_mode(struct drm_crtc *crtc,
>   if (modeset_pipes) {
>   adjusted_mode = intel_modeset_adjusted_mode(crtc, mode);
>   if (IS_ERR(adjusted_mode)) {
> - return false;
> + ret = false;
> + goto out;
>   }
>   }
>  
> @@ -7817,12 +7825,14 @@ bool intel_set_mode(struct drm_crtc *crtc,
>  done:
>   drm_mode_destroy(dev, adjusted_mode);
>   if (!ret && crtc->enabled) {
> - crtc->hwmode = saved_hwmode;
> - crtc->mode = saved_mode;
> + crtc->hwmode = *saved_hwmode;
> + crtc->mode = *saved_mode;
>   } else {
>   intel_modeset_check_state(dev);
>   }
>  
> +out:
> + kfree(saved_mode);
>   return ret;
>  }
>  
> -- 
> 1.7.9.5

[PATCHv15 3/7] video: add of helper for display timings/videomode

[Steffen Trumtrar]

Hi,

On Fri, Dec 07, 2012 at 03:12:48PM +0100, Philipp Zabel wrote:
> Hi,
> 
> Am Montag, den 26.11.2012, 18:56 +0200 schrieb Tomi Valkeinen:
> > On 2012-11-26 18:10, Steffen Trumtrar wrote:
> > > Hi,
> > > 
> > > On Mon, Nov 26, 2012 at 04:38:36PM +0200, Tomi Valkeinen wrote:
> > 
> > >>> +optional properties:
> > >>> + - hsync-active: hsync pulse is active low/high/ignored
> > >>> + - vsync-active: vsync pulse is active low/high/ignored
> > >>> + - de-active: data-enable pulse is active low/high/ignored
> > >>> + - pixelclk-inverted: pixelclock is inverted (active on falling edge)/
> > >>> +   non-inverted (active on rising edge)/
> > >>> +ignored (ignore property)
> > >>
> > >> I think hsync-active and vsync-active are clear, and commonly used, and
> > >> they are used for both drm and fb mode conversions in later patches.
> > >>
> > >> de-active is not used in drm and fb mode conversions, but I think it's
> > >> also clear.
> > >>
> > >> pixelclk-inverted is not used in the mode conversions. It's also a bit
> > >> unclear to me. What does it mean that pix clock is "active on rising
> > >> edge"? The pixel data is driven on rising edge? How about the sync
> > >> signals and DE, when are they driven? Does your HW have any settings
> > >> related to those?
> > >>
> > > 
> > > Those are properties commonly found in display specs. That is why they 
> > > are here.
> > > If the GPU does not support the property it can be omitted.
> > 
> > So what does the pixelclk-inverted mean? Normally the SoC drives pixel
> > data on rising edge, and the panel samples it at falling edge? And
> > vice-versa for inverted? Or the other way around?
> >
> > When is hsync/vsync set? On rising or falling edge of pclk?
> >
> > My point here is that the pixelclk-inverted is not crystal clear thing,
> > like the hsync/vsync/de-active values are.
> >
> > And while thinking about this, I realized that the meaning of
> > pixelclk-inverted depends on what component is it applied to. Presuming
> > normal pixclk means "pixel data on rising edge", the meaning of that
> > depends on do we consider the SoC or the panel. The panel needs to
> > sample the data on the other edge from the one the SoC uses to drive the
> > data.
> > 
> > Does the videomode describe the panel, or does it describe the settings
> > programmed to the SoC?
> 
> How about calling this property pixelclk-active, active high meaning
> driving pixel data on rising edges and sampling on falling edges (the
> pixel clock is high between driving and sampling the data), and active
> low meaning driving on falling edges and sampling on rising edges?
> It is the same from the SoC perspective and from the panel perspective,
> and it mirrors the usage of the other *-active properties.
> 

I think, this would not be a bad idea. I would include Philipps description in 
the
display-timing.txt, as it makes the meaning pretty clear; at least to me.

What do the others think about this?

Regards,
Steffen

-- 
Pengutronix e.K.   | |
Industrial Linux Solutions | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686   | Fax:   +49-5121-206917- |

[Bug 50655] ATI RV670 [Radeon HD 3870] Ioquake games causes GPU lockup (waiting for 0x00003039 last fence id 0x00003030)

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

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

--- Comment #19 from Bryan Quigley  ---
Would any other output help debug this?  Register dumps using avivotool?

-- 
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/20121210/60857d0d/attachment.html>

[Bug 50655] ATI RV670 [Radeon HD 3870] Ioquake games causes GPU lockup (waiting for 0x00003039 last fence id 0x00003030)

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

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

Bryan Quigley  changed:

   What|Removed |Added

  Attachment #66047|application/octet-stream|text/plain
  mime type||

-- 
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/20121210/a66ca1e6/attachment.html>

[Bug 50655] ATI RV670 [Radeon HD 3870] Ioquake games causes GPU lockup (waiting for 0x00003039 last fence id 0x00003030)

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

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

Bryan Quigley  changed:

   What|Removed |Added

  Attachment #62474|application/octet-stream|text/plain
  mime type||

-- 
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/20121210/50c3f966/attachment.html>

[Bug 50655] ATI RV670 [Radeon HD 3870] Ioquake games causes GPU lockup (waiting for 0x00003039 last fence id 0x00003030)

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

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

Bryan Quigley  changed:

   What|Removed |Added

  Attachment #62475|application/octet-stream|text/plain
  mime type||

-- 
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/20121210/08df1a4a/attachment.html>

[Bug 50655] ATI RV670 [Radeon HD 3870] Ioquake games causes GPU lockup (waiting for 0x00003039 last fence id 0x00003030)

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

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

Bryan Quigley  changed:

   What|Removed |Added

  Attachment #62689|application/octet-stream|text/plain
  mime type||

-- 
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/20121210/25e25396/attachment.html>

[PATCH -next v2] drm/exynos/iommu: fix return value check in drm_create_iommu_mapping()

[Wei Yongjun]

From: Wei Yongjun 

In case of error, function arm_iommu_create_mapping() returns
ERR_PTR() and never returns NULL. The NULL test in the return
value check should be replaced with IS_ERR().

Signed-off-by: Wei Yongjun 
---
 drivers/gpu/drm/exynos/exynos_drm_iommu.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_iommu.c 
b/drivers/gpu/drm/exynos/exynos_drm_iommu.c
index 09db198..2482b7f 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_iommu.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_iommu.c
@@ -56,8 +56,8 @@ int drm_create_iommu_mapping(struct drm_device *drm_dev)
mapping = arm_iommu_create_mapping(_bus_type, priv->da_start,
priv->da_space_size,
priv->da_space_order);
-   if (!mapping)
-   return -ENOMEM;
+   if (IS_ERR(mapping))
+   return PTR_ERR(mapping);

dev->dma_parms = devm_kzalloc(dev, sizeof(*dev->dma_parms),
GFP_KERNEL);

Re: [PATCHv15 3/7] video: add of helper for display timings/videomode

[Steffen Trumtrar]

Hi,

On Fri, Dec 07, 2012 at 03:12:48PM +0100, Philipp Zabel wrote:
 Hi,
 
 Am Montag, den 26.11.2012, 18:56 +0200 schrieb Tomi Valkeinen:
  On 2012-11-26 18:10, Steffen Trumtrar wrote:
   Hi,
   
   On Mon, Nov 26, 2012 at 04:38:36PM +0200, Tomi Valkeinen wrote:
  
   +optional properties:
   + - hsync-active: hsync pulse is active low/high/ignored
   + - vsync-active: vsync pulse is active low/high/ignored
   + - de-active: data-enable pulse is active low/high/ignored
   + - pixelclk-inverted: pixelclock is inverted (active on falling edge)/
   +   non-inverted (active on rising edge)/
   +ignored (ignore property)
  
   I think hsync-active and vsync-active are clear, and commonly used, and
   they are used for both drm and fb mode conversions in later patches.
  
   de-active is not used in drm and fb mode conversions, but I think it's
   also clear.
  
   pixelclk-inverted is not used in the mode conversions. It's also a bit
   unclear to me. What does it mean that pix clock is active on rising
   edge? The pixel data is driven on rising edge? How about the sync
   signals and DE, when are they driven? Does your HW have any settings
   related to those?
  
   
   Those are properties commonly found in display specs. That is why they 
   are here.
   If the GPU does not support the property it can be omitted.
  
  So what does the pixelclk-inverted mean? Normally the SoC drives pixel
  data on rising edge, and the panel samples it at falling edge? And
  vice-versa for inverted? Or the other way around?
 
  When is hsync/vsync set? On rising or falling edge of pclk?
 
  My point here is that the pixelclk-inverted is not crystal clear thing,
  like the hsync/vsync/de-active values are.
 
  And while thinking about this, I realized that the meaning of
  pixelclk-inverted depends on what component is it applied to. Presuming
  normal pixclk means pixel data on rising edge, the meaning of that
  depends on do we consider the SoC or the panel. The panel needs to
  sample the data on the other edge from the one the SoC uses to drive the
  data.
  
  Does the videomode describe the panel, or does it describe the settings
  programmed to the SoC?
 
 How about calling this property pixelclk-active, active high meaning
 driving pixel data on rising edges and sampling on falling edges (the
 pixel clock is high between driving and sampling the data), and active
 low meaning driving on falling edges and sampling on rising edges?
 It is the same from the SoC perspective and from the panel perspective,
 and it mirrors the usage of the other *-active properties.
 

I think, this would not be a bad idea. I would include Philipps description in 
the
display-timing.txt, as it makes the meaning pretty clear; at least to me.

What do the others think about this?

Regards,
Steffen

-- 
Pengutronix e.K.   | |
Industrial Linux Solutions | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686   | Fax:   +49-5121-206917- |
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH -next v2] drm/exynos/iommu: fix return value check in drm_create_iommu_mapping()

[Wei Yongjun]

From: Wei Yongjun yongjun_...@trendmicro.com.cn

In case of error, function arm_iommu_create_mapping() returns
ERR_PTR() and never returns NULL. The NULL test in the return
value check should be replaced with IS_ERR().

Signed-off-by: Wei Yongjun yongjun_...@trendmicro.com.cn
---
 drivers/gpu/drm/exynos/exynos_drm_iommu.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_iommu.c 
b/drivers/gpu/drm/exynos/exynos_drm_iommu.c
index 09db198..2482b7f 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_iommu.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_iommu.c
@@ -56,8 +56,8 @@ int drm_create_iommu_mapping(struct drm_device *drm_dev)
mapping = arm_iommu_create_mapping(platform_bus_type, priv-da_start,
priv-da_space_size,
priv-da_space_order);
-   if (!mapping)
-   return -ENOMEM;
+   if (IS_ERR(mapping))
+   return PTR_ERR(mapping);
 
dev-dma_parms = devm_kzalloc(dev, sizeof(*dev-dma_parms),
GFP_KERNEL);


___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCHv15 3/7] video: add of helper for display timings/videomode

[Tomi Valkeinen]

On 2012-12-07 16:12, Philipp Zabel wrote:
 Hi,
 
 Am Montag, den 26.11.2012, 18:56 +0200 schrieb Tomi Valkeinen:

 So what does the pixelclk-inverted mean? Normally the SoC drives pixel
 data on rising edge, and the panel samples it at falling edge? And
 vice-versa for inverted? Or the other way around?

 When is hsync/vsync set? On rising or falling edge of pclk?

 My point here is that the pixelclk-inverted is not crystal clear thing,
 like the hsync/vsync/de-active values are.

 And while thinking about this, I realized that the meaning of
 pixelclk-inverted depends on what component is it applied to. Presuming
 normal pixclk means pixel data on rising edge, the meaning of that
 depends on do we consider the SoC or the panel. The panel needs to
 sample the data on the other edge from the one the SoC uses to drive the
 data.

 Does the videomode describe the panel, or does it describe the settings
 programmed to the SoC?
 
 How about calling this property pixelclk-active, active high meaning
 driving pixel data on rising edges and sampling on falling edges (the
 pixel clock is high between driving and sampling the data), and active
 low meaning driving on falling edges and sampling on rising edges?
 It is the same from the SoC perspective and from the panel perspective,
 and it mirrors the usage of the other *-active properties.

This sounds good to me. It's not quite correct, as neither pixelclock or
pixel data are not really active when the clock is high/low, but it
still makes sense and is clear (at least with a short description).

 Tomi




signature.asc
Description: OpenPGP digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 1/1] drm/i915: Remove duplicate inclusion of drm/drm_edid.h

[Daniel Vetter]

On Mon, Dec 10, 2012 at 09:50:51AM +0200, Jani Nikula wrote:
 On Fri, 07 Dec 2012, Sachin Kamat sachin.ka...@linaro.org wrote:
  drm/drm_edid.h was included twice.
 
 Reviewed-by: Jani Nikula jani.nik...@intel.com
Queued for -next, thanks for the patch.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2 linux-next] i915: intel_set_mode: Reduce stack allocation from 500 bytes to 2 pointers

[Daniel Vetter]

On Mon, Dec 10, 2012 at 09:29:17AM +0200, Jani Nikula wrote:
 On Fri, 07 Dec 2012, Tim Gardner tim.gard...@canonical.com wrote:
  smatch warning:
 
  drivers/gpu/drm/i915/intel_display.c:7019 intel_set_mode() warn: function 
  puts
  500 bytes on stack
 
  Refactor so that saved_mode and saved_hwmode are dynamically allocated as 
  opposed
  to being automatic variables. 500 bytes seems like it could run the 
  potential for blowing
  the kernel stack.
 
 Reviewed-by: Jani Nikula jani.nik...@intel.com
Queued for -next, thanks for the patch.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 1/7] drm/nouveau: increase reservation sequence every retry

[Maarten Lankhorst]

This is temporary until the fence framework can be used. With the
lru/reservation atomicity removal it is possible to see your old
sequence number and the buffer being reserved, leading to erroneously
reporting -EDEADLK.

Workaround it by bumping the sequence number every retry.

Signed-off-by: Maarten Lankhorst maarten.lankho...@canonical.com
---
 drivers/gpu/drm/nouveau/nouveau_gem.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/nouveau/nouveau_gem.c 
b/drivers/gpu/drm/nouveau/nouveau_gem.c
index 7b9364b..f2bd59e 100644
--- a/drivers/gpu/drm/nouveau/nouveau_gem.c
+++ b/drivers/gpu/drm/nouveau/nouveau_gem.c
@@ -322,8 +322,8 @@ validate_init(struct nouveau_channel *chan, struct drm_file 
*file_priv,
int trycnt = 0;
int ret, i;
 
-   sequence = atomic_add_return(1, drm-ttm.validate_sequence);
 retry:
+   sequence = atomic_add_return(1, drm-ttm.validate_sequence);
if (++trycnt  10) {
NV_ERROR(drm, %s failed and gave up.\n, __func__);
return -EINVAL;
-- 
1.8.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 2/7] drm/ttm: remove lru_lock around ttm_bo_reserve

[Maarten Lankhorst]

There should no longer be assumptions that reserve will always succeed
with the lru lock held, so we can safely break the whole atomic
reserve/lru thing. As a bonus this fixes most lockdep annotations for
reservations.

Signed-off-by: Maarten Lankhorst maarten.lankho...@canonical.com
Reviewed-by: Jerome Glisse jgli...@redhat.com
---
 drivers/gpu/drm/ttm/ttm_bo.c   | 54 ++
 drivers/gpu/drm/ttm/ttm_execbuf_util.c |  2 +-
 include/drm/ttm/ttm_bo_driver.h| 19 +++-
 3 files changed, 40 insertions(+), 35 deletions(-)

diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index 9028327..61b5cd0 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -213,14 +213,13 @@ int ttm_bo_del_from_lru(struct ttm_buffer_object *bo)
return put_count;
 }
 
-int ttm_bo_reserve_locked(struct ttm_buffer_object *bo,
+int ttm_bo_reserve_nolru(struct ttm_buffer_object *bo,
  bool interruptible,
  bool no_wait, bool use_sequence, uint32_t sequence)
 {
-   struct ttm_bo_global *glob = bo-glob;
int ret;
 
-   while (unlikely(atomic_read(bo-reserved) != 0)) {
+   while (unlikely(atomic_xchg(bo-reserved, 1) != 0)) {
/**
 * Deadlock avoidance for multi-bo reserving.
 */
@@ -241,26 +240,36 @@ int ttm_bo_reserve_locked(struct ttm_buffer_object *bo,
if (no_wait)
return -EBUSY;
 
-   spin_unlock(glob-lru_lock);
ret = ttm_bo_wait_unreserved(bo, interruptible);
-   spin_lock(glob-lru_lock);
 
if (unlikely(ret))
return ret;
}
 
-   atomic_set(bo-reserved, 1);
if (use_sequence) {
+   bool wake_up = false;
/**
 * Wake up waiters that may need to recheck for deadlock,
 * if we decreased the sequence number.
 */
if (unlikely((bo-val_seq - sequence  (1  31))
 || !bo-seq_valid))
-   wake_up_all(bo-event_queue);
+   wake_up = true;
 
+   /*
+* In the worst case with memory ordering these values can be
+* seen in the wrong order. However since we call wake_up_all
+* in that case, this will hopefully not pose a problem,
+* and the worst case would only cause someone to accidentally
+* hit -EAGAIN in ttm_bo_reserve when they see old value of
+* val_seq. However this would only happen if seq_valid was
+* written before val_seq was, and just means some slightly
+* increased cpu usage
+*/
bo-val_seq = sequence;
bo-seq_valid = true;
+   if (wake_up)
+   wake_up_all(bo-event_queue);
} else {
bo-seq_valid = false;
}
@@ -289,14 +298,14 @@ int ttm_bo_reserve(struct ttm_buffer_object *bo,
int put_count = 0;
int ret;
 
-   spin_lock(glob-lru_lock);
-   ret = ttm_bo_reserve_locked(bo, interruptible, no_wait, use_sequence,
-   sequence);
-   if (likely(ret == 0))
+   ret = ttm_bo_reserve_nolru(bo, interruptible, no_wait, use_sequence,
+  sequence);
+   if (likely(ret == 0)) {
+   spin_lock(glob-lru_lock);
put_count = ttm_bo_del_from_lru(bo);
-   spin_unlock(glob-lru_lock);
-
-   ttm_bo_list_ref_sub(bo, put_count, true);
+   spin_unlock(glob-lru_lock);
+   ttm_bo_list_ref_sub(bo, put_count, true);
+   }
 
return ret;
 }
@@ -510,7 +519,7 @@ static void ttm_bo_cleanup_refs_or_queue(struct 
ttm_buffer_object *bo)
int ret;
 
spin_lock(glob-lru_lock);
-   ret = ttm_bo_reserve_locked(bo, false, true, false, 0);
+   ret = ttm_bo_reserve_nolru(bo, false, true, false, 0);
 
spin_lock(bdev-fence_lock);
(void) ttm_bo_wait(bo, false, false, true);
@@ -603,7 +612,7 @@ static int ttm_bo_cleanup_refs_and_unlock(struct 
ttm_buffer_object *bo,
return ret;
 
spin_lock(glob-lru_lock);
-   ret = ttm_bo_reserve_locked(bo, false, true, false, 0);
+   ret = ttm_bo_reserve_nolru(bo, false, true, false, 0);
 
/*
 * We raced, and lost, someone else holds the reservation now,
@@ -667,7 +676,14 @@ static int ttm_bo_delayed_delete(struct ttm_bo_device 
*bdev, bool remove_all)
kref_get(nentry-list_kref);
}
 
-   ret = ttm_bo_reserve_locked(entry, false, !remove_all, false, 
0);
+   ret = ttm_bo_reserve_nolru(entry, false, true, false, 0);
+   if (remove_all  

[PATCH 3/7] drm/ttm: cleanup ttm_eu_reserve_buffers handling

[Maarten Lankhorst]

With the lru lock no longer required for protecting reservations we
can just do a ttm_bo_reserve_nolru on -EBUSY, and handle all errors
in a single path.

Signed-off-by: Maarten Lankhorst maarten.lankho...@canonical.com
Reviewed-by: Jerome Glisse jgli...@redhat.com
---
 drivers/gpu/drm/ttm/ttm_execbuf_util.c | 53 ++
 1 file changed, 21 insertions(+), 32 deletions(-)

diff --git a/drivers/gpu/drm/ttm/ttm_execbuf_util.c 
b/drivers/gpu/drm/ttm/ttm_execbuf_util.c
index bd37b5c..c7d3236 100644
--- a/drivers/gpu/drm/ttm/ttm_execbuf_util.c
+++ b/drivers/gpu/drm/ttm/ttm_execbuf_util.c
@@ -82,22 +82,6 @@ static void ttm_eu_list_ref_sub(struct list_head *list)
}
 }
 
-static int ttm_eu_wait_unreserved_locked(struct list_head *list,
-struct ttm_buffer_object *bo)
-{
-   struct ttm_bo_global *glob = bo-glob;
-   int ret;
-
-   ttm_eu_del_from_lru_locked(list);
-   spin_unlock(glob-lru_lock);
-   ret = ttm_bo_wait_unreserved(bo, true);
-   spin_lock(glob-lru_lock);
-   if (unlikely(ret != 0))
-   ttm_eu_backoff_reservation_locked(list);
-   return ret;
-}
-
-
 void ttm_eu_backoff_reservation(struct list_head *list)
 {
struct ttm_validate_buffer *entry;
@@ -152,19 +136,23 @@ retry:
list_for_each_entry(entry, list, head) {
struct ttm_buffer_object *bo = entry-bo;
 
-retry_this_bo:
ret = ttm_bo_reserve_nolru(bo, true, true, true, val_seq);
switch (ret) {
case 0:
break;
case -EBUSY:
-   ret = ttm_eu_wait_unreserved_locked(list, bo);
-   if (unlikely(ret != 0)) {
-   spin_unlock(glob-lru_lock);
-   ttm_eu_list_ref_sub(list);
-   return ret;
-   }
-   goto retry_this_bo;
+   ttm_eu_del_from_lru_locked(list);
+   spin_unlock(glob-lru_lock);
+   ret = ttm_bo_reserve_nolru(bo, true, false,
+  true, val_seq);
+   spin_lock(glob-lru_lock);
+   if (!ret)
+   break;
+
+   if (unlikely(ret != -EAGAIN))
+   goto err;
+
+   /* fallthrough */
case -EAGAIN:
ttm_eu_backoff_reservation_locked(list);
spin_unlock(glob-lru_lock);
@@ -174,18 +162,13 @@ retry_this_bo:
return ret;
goto retry;
default:
-   ttm_eu_backoff_reservation_locked(list);
-   spin_unlock(glob-lru_lock);
-   ttm_eu_list_ref_sub(list);
-   return ret;
+   goto err;
}
 
entry-reserved = true;
if (unlikely(atomic_read(bo-cpu_writers)  0)) {
-   ttm_eu_backoff_reservation_locked(list);
-   spin_unlock(glob-lru_lock);
-   ttm_eu_list_ref_sub(list);
-   return -EBUSY;
+   ret = -EBUSY;
+   goto err;
}
}
 
@@ -194,6 +177,12 @@ retry_this_bo:
ttm_eu_list_ref_sub(list);
 
return 0;
+
+err:
+   ttm_eu_backoff_reservation_locked(list);
+   spin_unlock(glob-lru_lock);
+   ttm_eu_list_ref_sub(list);
+   return ret;
 }
 EXPORT_SYMBOL(ttm_eu_reserve_buffers);
 
-- 
1.8.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 4/7] drm/ttm: add ttm_bo_reserve_slowpath

[Maarten Lankhorst]

Instead of dropping everything, waiting for the bo to be unreserved
and trying over, a better strategy would be to do a blocking wait.

This can be mapped a lot better to a mutex_lock-like call.

Signed-off-by: Maarten Lankhorst maarten.lankho...@canonical.com
Reviewed-by: Jerome Glisse jgli...@redhat.com
---
 drivers/gpu/drm/ttm/ttm_bo.c| 47 +
 include/drm/ttm/ttm_bo_driver.h | 30 ++
 2 files changed, 77 insertions(+)

diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index 61b5cd0..174b325 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -310,6 +310,53 @@ int ttm_bo_reserve(struct ttm_buffer_object *bo,
return ret;
 }
 
+int ttm_bo_reserve_slowpath_nolru(struct ttm_buffer_object *bo,
+ bool interruptible, uint32_t sequence)
+{
+   bool wake_up = false;
+   int ret;
+
+   while (unlikely(atomic_xchg(bo-reserved, 1) != 0)) {
+   WARN_ON(bo-seq_valid  sequence == bo-val_seq);
+
+   ret = ttm_bo_wait_unreserved(bo, interruptible);
+
+   if (unlikely(ret))
+   return ret;
+   }
+
+   if ((bo-val_seq - sequence  (1  31)) || !bo-seq_valid)
+   wake_up = true;
+
+   /**
+* Wake up waiters that may need to recheck for deadlock,
+* if we decreased the sequence number.
+*/
+   bo-val_seq = sequence;
+   bo-seq_valid = true;
+   if (wake_up)
+   wake_up_all(bo-event_queue);
+
+   return 0;
+}
+
+int ttm_bo_reserve_slowpath(struct ttm_buffer_object *bo,
+   bool interruptible, uint32_t sequence)
+{
+   struct ttm_bo_global *glob = bo-glob;
+   int put_count, ret;
+
+   ret = ttm_bo_reserve_slowpath_nolru(bo, interruptible, sequence);
+   if (likely(!ret)) {
+   spin_lock(glob-lru_lock);
+   put_count = ttm_bo_del_from_lru(bo);
+   spin_unlock(glob-lru_lock);
+   ttm_bo_list_ref_sub(bo, put_count, true);
+   }
+   return ret;
+}
+EXPORT_SYMBOL(ttm_bo_reserve_slowpath);
+
 void ttm_bo_unreserve_locked(struct ttm_buffer_object *bo)
 {
ttm_bo_add_to_lru(bo);
diff --git a/include/drm/ttm/ttm_bo_driver.h b/include/drm/ttm/ttm_bo_driver.h
index 6fff432..5af71af 100644
--- a/include/drm/ttm/ttm_bo_driver.h
+++ b/include/drm/ttm/ttm_bo_driver.h
@@ -821,6 +821,36 @@ extern int ttm_bo_reserve(struct ttm_buffer_object *bo,
  bool interruptible,
  bool no_wait, bool use_sequence, uint32_t sequence);
 
+/**
+ * ttm_bo_reserve_slowpath_nolru:
+ * @bo: A pointer to a struct ttm_buffer_object.
+ * @interruptible: Sleep interruptible if waiting.
+ * @sequence: Set (@bo)-sequence to this value after lock
+ *
+ * This is called after ttm_bo_reserve returns -EAGAIN and we backed off
+ * from all our other reservations. Because there are no other reservations
+ * held by us, this function cannot deadlock any more.
+ *
+ * Will not remove reserved buffers from the lru lists.
+ * Otherwise identical to ttm_bo_reserve_slowpath.
+ */
+extern int ttm_bo_reserve_slowpath_nolru(struct ttm_buffer_object *bo,
+bool interruptible,
+uint32_t sequence);
+
+
+/**
+ * ttm_bo_reserve_slowpath:
+ * @bo: A pointer to a struct ttm_buffer_object.
+ * @interruptible: Sleep interruptible if waiting.
+ * @sequence: Set (@bo)-sequence to this value after lock
+ *
+ * This is called after ttm_bo_reserve returns -EAGAIN and we backed off
+ * from all our other reservations. Because there are no other reservations
+ * held by us, this function cannot deadlock any more.
+ */
+extern int ttm_bo_reserve_slowpath(struct ttm_buffer_object *bo,
+  bool interruptible, uint32_t sequence);
 
 /**
  * ttm_bo_reserve_nolru:
-- 
1.8.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 5/7] drm/ttm: use ttm_bo_reserve_slowpath_nolru in ttm_eu_reserve_buffers, v2

[Maarten Lankhorst]

This requires re-use of the seqno, which increases fairness slightly.
Instead of spinning with a new seqno every time we keep the current one,
but still drop all other reservations we hold. Only when we succeed,
we try to get back our other reservations again.

This should increase fairness slightly as well.

Changes since v1:
 - Increase val_seq before calling ttm_bo_reserve_slowpath_nolru and
   retrying to take all entries to prevent a race.

Signed-off-by: Maarten Lankhorst maarten.lankho...@canonical.com
---
 drivers/gpu/drm/ttm/ttm_execbuf_util.c | 23 +--
 1 file changed, 21 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/ttm/ttm_execbuf_util.c 
b/drivers/gpu/drm/ttm/ttm_execbuf_util.c
index c7d3236..7b90def 100644
--- a/drivers/gpu/drm/ttm/ttm_execbuf_util.c
+++ b/drivers/gpu/drm/ttm/ttm_execbuf_util.c
@@ -129,13 +129,17 @@ int ttm_eu_reserve_buffers(struct list_head *list)
entry = list_first_entry(list, struct ttm_validate_buffer, head);
glob = entry-bo-glob;
 
-retry:
spin_lock(glob-lru_lock);
val_seq = entry-bo-bdev-val_seq++;
 
+retry:
list_for_each_entry(entry, list, head) {
struct ttm_buffer_object *bo = entry-bo;
 
+   /* already slowpath reserved? */
+   if (entry-reserved)
+   continue;
+
ret = ttm_bo_reserve_nolru(bo, true, true, true, val_seq);
switch (ret) {
case 0:
@@ -155,11 +159,26 @@ retry:
/* fallthrough */
case -EAGAIN:
ttm_eu_backoff_reservation_locked(list);
+
+   /*
+* temporarily increase sequence number every retry,
+* to prevent us from seeing our old reservation
+* sequence when someone else reserved the buffer,
+* but hasn't updated the seq_valid/seqno members yet.
+*/
+   val_seq = entry-bo-bdev-val_seq++;
+
spin_unlock(glob-lru_lock);
ttm_eu_list_ref_sub(list);
-   ret = ttm_bo_wait_unreserved(bo, true);
+   ret = ttm_bo_reserve_slowpath_nolru(bo, true, val_seq);
if (unlikely(ret != 0))
return ret;
+   spin_lock(glob-lru_lock);
+   entry-reserved = true;
+   if (unlikely(atomic_read(bo-cpu_writers)  0)) {
+   ret = -EBUSY;
+   goto err;
+   }
goto retry;
default:
goto err;
-- 
1.8.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 6/7] drm/nouveau: use ttm_bo_reserve_slowpath in validate_init, v2

[Maarten Lankhorst]

Similar rationale to the identical commit in drm/ttm.
Instead of only waiting for unreservation, we make sure we actually
own the reservation, then retry to get the rest.

Changes since v1:
 - Increase the seqno before calling ttm_bo_reserve_slowpath

Signed-off-by: Maarten Lankhorst maarten.lankho...@canonical.com
---
 drivers/gpu/drm/nouveau/nouveau_gem.c | 22 +-
 1 file changed, 17 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/nouveau_gem.c 
b/drivers/gpu/drm/nouveau/nouveau_gem.c
index f2bd59e..afcba1a 100644
--- a/drivers/gpu/drm/nouveau/nouveau_gem.c
+++ b/drivers/gpu/drm/nouveau/nouveau_gem.c
@@ -321,9 +321,10 @@ validate_init(struct nouveau_channel *chan, struct 
drm_file *file_priv,
uint32_t sequence;
int trycnt = 0;
int ret, i;
+   struct nouveau_bo *res_bo = NULL;
 
-retry:
sequence = atomic_add_return(1, drm-ttm.validate_sequence);
+retry:
if (++trycnt  10) {
NV_ERROR(drm, %s failed and gave up.\n, __func__);
return -EINVAL;
@@ -341,6 +342,11 @@ retry:
return -ENOENT;
}
nvbo = gem-driver_private;
+   if (nvbo == res_bo) {
+   res_bo = NULL;
+   drm_gem_object_unreference_unlocked(gem);
+   continue;
+   }
 
if (nvbo-reserved_by  nvbo-reserved_by == file_priv) {
NV_ERROR(drm, multiple instances of buffer %d on 
@@ -353,15 +359,19 @@ retry:
ret = ttm_bo_reserve(nvbo-bo, true, false, true, sequence);
if (ret) {
validate_fini(op, NULL);
-   if (unlikely(ret == -EAGAIN))
-   ret = ttm_bo_wait_unreserved(nvbo-bo, true);
-   drm_gem_object_unreference_unlocked(gem);
+   if (unlikely(ret == -EAGAIN)) {
+   sequence = atomic_add_return(1, 
drm-ttm.validate_sequence);
+   ret = ttm_bo_reserve_slowpath(nvbo-bo, true,
+ sequence);
+   if (!ret)
+   res_bo = nvbo;
+   }
if (unlikely(ret)) {
+   drm_gem_object_unreference_unlocked(gem);
if (ret != -ERESTARTSYS)
NV_ERROR(drm, fail reserve\n);
return ret;
}
-   goto retry;
}
 
b-user_priv = (uint64_t)(unsigned long)nvbo;
@@ -383,6 +393,8 @@ retry:
validate_fini(op, NULL);
return -EINVAL;
}
+   if (nvbo == res_bo)
+   goto retry;
}
 
return 0;
-- 
1.8.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 7/7] drm/ttm: unexport ttm_bo_wait_unreserved

[Maarten Lankhorst]

All legitimate users of this function outside ttm_bo.c are gone, now
it's only an implementation detail.

Signed-off-by: Maarten Lankhorst maarten.lankho...@canonical.com
Reviewed-by: Jerome Glisse jgli...@redhat.com
---
 drivers/gpu/drm/ttm/ttm_bo.c|  4 ++--
 include/drm/ttm/ttm_bo_driver.h | 12 
 2 files changed, 2 insertions(+), 14 deletions(-)

diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index 174b325..fd78104 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -158,7 +158,8 @@ static void ttm_bo_release_list(struct kref *list_kref)
ttm_mem_global_free(bdev-glob-mem_glob, acc_size);
 }
 
-int ttm_bo_wait_unreserved(struct ttm_buffer_object *bo, bool interruptible)
+static int ttm_bo_wait_unreserved(struct ttm_buffer_object *bo,
+ bool interruptible)
 {
if (interruptible) {
return wait_event_interruptible(bo-event_queue,
@@ -168,7 +169,6 @@ int ttm_bo_wait_unreserved(struct ttm_buffer_object *bo, 
bool interruptible)
return 0;
}
 }
-EXPORT_SYMBOL(ttm_bo_wait_unreserved);
 
 void ttm_bo_add_to_lru(struct ttm_buffer_object *bo)
 {
diff --git a/include/drm/ttm/ttm_bo_driver.h b/include/drm/ttm/ttm_bo_driver.h
index 5af71af..0fbd046 100644
--- a/include/drm/ttm/ttm_bo_driver.h
+++ b/include/drm/ttm/ttm_bo_driver.h
@@ -898,18 +898,6 @@ extern void ttm_bo_unreserve(struct ttm_buffer_object *bo);
  */
 extern void ttm_bo_unreserve_locked(struct ttm_buffer_object *bo);
 
-/**
- * ttm_bo_wait_unreserved
- *
- * @bo: A pointer to a struct ttm_buffer_object.
- *
- * Wait for a struct ttm_buffer_object to become unreserved.
- * This is typically used in the execbuf code to relax cpu-usage when
- * a potential deadlock condition backoff.
- */
-extern int ttm_bo_wait_unreserved(struct ttm_buffer_object *bo,
- bool interruptible);
-
 /*
  * ttm_bo_util.c
  */
-- 
1.8.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 0/3] add mie driver for exynos

[Inki Dae]

2012/12/10 Stéphane Marchesin stephane.marche...@gmail.com

 On Sun, Dec 9, 2012 at 10:26 PM, Inki Dae inki@samsung.com wrote:
 
 
  2012/12/6 R. Chandrasekar rcse...@samsung.com
 
  From: R. Chandrasekar rcse...@samsung.com
 
  this patch set adds the driver support for the dithering functionality
 of
  the
  mobile image enhancement (mie) module.
 
  device tree support is added for mie.
 
  fimd adds the mie module as plugin and calls the dithering function.
  dithere is
  required when the panels bpp is less then fimd output.
 
  though mie mie has other functionalities, current system uses only
  dithereing.
 
 
  Please, move mie module into drivers/video/exynos. The mie is a interface
  between fimd and lcd panel(or mipi-dsi, eDP) to enhance image to be
  displayed. And it seems like that this doesn't need drm
 framework-relevant
  interfaces, such as gem.

 Well, if you want to support it from the DRM, it should live in
 drivers/gpu/drm, and I don't think you should add another platform
 driver in the first place. The profusion of platform drivers in exynos
 makes it really difficult to support suspend/resume and initialization
 properly as many devices which operate separately need to sync through
 global variables.


MIE could be used by linux framebuffer-based specific driver(s3c-fb) also.
If linux framebuffer-based driver want to use this mie module, should the
mie module be placed in drivers/video coping it? I think it's not good so
it's better way to use this mie module commonly without duplicated codes.
And mipi-dsi and eDP drivers also have their own platform device/driver and
are being used by exynos drm driver or s3c-fb driver. Of course, for some
IPs such as mie between display controller and lcd panel, It seems like
that there should be proper framework or interfaces in drivers/video/exynos
or somewhere so that other frameworks can use it commonly. And drm and
linux framebuffer drivers should call the interfaces.

Thanks,
Inki Dae

Stéphane


 
  And also, please refer to the below link, Common Display Framework, for
 more
  generic way.
 
 
 http://lists.freedesktop.org/archives/dri-devel/2012-November/030888.html
 
  Thanks,
  Inki Dae
 
 
  R. Chandrasekar (3):
DTS: exynos: add device tree support for exynos mie
drm: fimd: add mie plugin support for dithering
drm: mie: add mie driver for exynos
 
   arch/arm/boot/dts/exynos5250.dtsi   |7 +-
   drivers/gpu/drm/exynos/Kconfig  |7 +
   drivers/gpu/drm/exynos/Makefile |1 +
   drivers/gpu/drm/exynos/exynos_drm_fimd.c|   58 +-
   drivers/gpu/drm/exynos/exynos_drm_fimd_common.h |   20 ++
   drivers/gpu/drm/exynos/exynos_drm_mie.c |  250
  +++
   drivers/gpu/drm/exynos/exynos_drm_mie.h |   50 +
   drivers/gpu/drm/exynos/exynos_regs-mie.h|   75 +++
   8 files changed, 465 insertions(+), 3 deletions(-)
   create mode 100644 drivers/gpu/drm/exynos/exynos_drm_fimd_common.h
   create mode 100644 drivers/gpu/drm/exynos/exynos_drm_mie.c
   create mode 100644 drivers/gpu/drm/exynos/exynos_drm_mie.h
   create mode 100644 drivers/gpu/drm/exynos/exynos_regs-mie.h
 
  --
  1.7.9.5
 
  ___
  dri-devel mailing list
  dri-devel@lists.freedesktop.org
  http://lists.freedesktop.org/mailman/listinfo/dri-devel
 
 
 
  ___
  dri-devel mailing list
  dri-devel@lists.freedesktop.org
  http://lists.freedesktop.org/mailman/listinfo/dri-devel
 
 ___
 dri-devel mailing list
 dri-devel@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/dri-devel

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RFC,v2,1/8] video: tegra: Add nvhost driver

[Terje Bergström]

On 29.11.2012 11:10, Mark Zhang wrote:
 +
 +/**
 + * Write a cpu syncpoint increment to the hardware, without touching
 + * the cache. Caller is responsible for host being powered.
 + */
 +static void host1x_syncpt_cpu_incr(struct nvhost_syncpt *sp, u32 id)
 +{
 + struct nvhost_master *dev = syncpt_to_dev(sp);
 + u32 reg_offset = id / 32;
 +
 + if (!nvhost_module_powered(dev-dev)) {
 + dev_err(syncpt_to_dev(sp)-dev-dev,
 + Trying to access host1x when it's off);
 + return;
 + }
 +
 + if (!nvhost_syncpt_client_managed(sp, id)
 +  nvhost_syncpt_min_eq_max(sp, id)) {
 + dev_err(syncpt_to_dev(sp)-dev-dev,
 + Trying to increment syncpoint id %d beyond max\n,
 + id);
 + return;
 + }
 + writel(BIT_MASK(id), dev-sync_aperture +
 + host1x_sync_syncpt_cpu_incr_r() + reg_offset * 4);
 
 I have a stupid question: According to the name and the context of this
 function, seems it increases the syncpt value which specified by param
 id. So how does this writel increase the value? I don't know much
 about host1x/syncpt reg operations, so could you explain a little bit or
 I just completely have a wrong understanding?

I believe I've implemented most of the requests in this mail, but I seem
to have missed answering this question.

writel() to that register invokes a method in host1x, which increments
the sync point indicated by the value of the register by one.

Best regards,
Terje
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/ttm: move ttm_lock.c to drm/vmwgfx

[Daniel Vetter]

... it's the only user. Also move the header fil there.

mlankhorst but seriously, ttm_lock is best left undocumented since
nobody should use that unholy thing..
danvet agreed ;-)
danvet imo we should shovel that under drm/vmwgfx ...
airlied amen
airlied that thing scares me
danvet out of sight, out of mind ...

Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
 drivers/gpu/drm/ttm/Makefile|2 +-
 drivers/gpu/drm/ttm/ttm_lock.c  |  310 ---
 drivers/gpu/drm/vmwgfx/Makefile |2 +-
 drivers/gpu/drm/vmwgfx/ttm_lock.c   |  310 +++
 drivers/gpu/drm/vmwgfx/ttm_lock.h   |  247 
 drivers/gpu/drm/vmwgfx/vmwgfx_drv.h |2 +-
 include/drm/ttm/ttm_lock.h  |  247 
 7 files changed, 560 insertions(+), 560 deletions(-)
 delete mode 100644 drivers/gpu/drm/ttm/ttm_lock.c
 create mode 100644 drivers/gpu/drm/vmwgfx/ttm_lock.c
 create mode 100644 drivers/gpu/drm/vmwgfx/ttm_lock.h
 delete mode 100644 include/drm/ttm/ttm_lock.h

diff --git a/drivers/gpu/drm/ttm/Makefile b/drivers/gpu/drm/ttm/Makefile
index b2b33dd..607a0b6 100644
--- a/drivers/gpu/drm/ttm/Makefile
+++ b/drivers/gpu/drm/ttm/Makefile
@@ -4,7 +4,7 @@
 ccflags-y := -Iinclude/drm
 ttm-y := ttm_agp_backend.o ttm_memory.o ttm_tt.o ttm_bo.o \
ttm_bo_util.o ttm_bo_vm.o ttm_module.o \
-   ttm_object.o ttm_lock.o ttm_execbuf_util.o ttm_page_alloc.o \
+   ttm_object.o ttm_execbuf_util.o ttm_page_alloc.o \
ttm_bo_manager.o
 
 ifeq ($(CONFIG_SWIOTLB),y)
diff --git a/drivers/gpu/drm/ttm/ttm_lock.c b/drivers/gpu/drm/ttm/ttm_lock.c
deleted file mode 100644
index 3daa9a3..000
--- a/drivers/gpu/drm/ttm/ttm_lock.c
+++ /dev/null
@@ -1,310 +0,0 @@
-/**
- *
- * Copyright (c) 2007-2009 VMware, Inc., Palo Alto, CA., USA
- * All Rights Reserved.
- *
- * 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, sub license, 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 NON-INFRINGEMENT. IN NO EVENT SHALL
- * THE COPYRIGHT HOLDERS, AUTHORS AND/OR ITS SUPPLIERS 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: Thomas Hellstrom thellstrom-at-vmware-dot-com
- */
-
-#include drm/ttm/ttm_lock.h
-#include drm/ttm/ttm_module.h
-#include linux/atomic.h
-#include linux/errno.h
-#include linux/wait.h
-#include linux/sched.h
-#include linux/module.h
-
-#define TTM_WRITE_LOCK_PENDING(1  0)
-#define TTM_VT_LOCK_PENDING   (1  1)
-#define TTM_SUSPEND_LOCK_PENDING  (1  2)
-#define TTM_VT_LOCK   (1  3)
-#define TTM_SUSPEND_LOCK  (1  4)
-
-void ttm_lock_init(struct ttm_lock *lock)
-{
-   spin_lock_init(lock-lock);
-   init_waitqueue_head(lock-queue);
-   lock-rw = 0;
-   lock-flags = 0;
-   lock-kill_takers = false;
-   lock-signal = SIGKILL;
-}
-EXPORT_SYMBOL(ttm_lock_init);
-
-void ttm_read_unlock(struct ttm_lock *lock)
-{
-   spin_lock(lock-lock);
-   if (--lock-rw == 0)
-   wake_up_all(lock-queue);
-   spin_unlock(lock-lock);
-}
-EXPORT_SYMBOL(ttm_read_unlock);
-
-static bool __ttm_read_lock(struct ttm_lock *lock)
-{
-   bool locked = false;
-
-   spin_lock(lock-lock);
-   if (unlikely(lock-kill_takers)) {
-   send_sig(lock-signal, current, 0);
-   spin_unlock(lock-lock);
-   return false;
-   }
-   if (lock-rw = 0  lock-flags == 0) {
-   ++lock-rw;
-   locked = true;
-   }
-   spin_unlock(lock-lock);
-   return locked;
-}
-
-int ttm_read_lock(struct ttm_lock *lock, bool interruptible)
-{
-   int ret = 0;
-
-   if (interruptible)
-   ret = wait_event_interruptible(lock-queue,
-  __ttm_read_lock(lock));
-   else
-   wait_event(lock-queue, __ttm_read_lock(lock));
-   return ret;
-}
-EXPORT_SYMBOL(ttm_read_lock);
-
-static bool 

Re: [RFC v2 6/8] gpu: drm: tegra: Remove redundant host1x

[Terje Bergström]

On 05.12.2012 14:04, Thierry Reding wrote:
 On Wed, Dec 05, 2012 at 01:47:38PM +0200, Terje Bergström wrote:
 You're right in that binding to a sub-device is not a nice way. DRM
 framework just needs a struct device to bind to. exynos seems to solve
 this by introducing a virtual device and bind to that. I'm not sure if
 this is the best way, but worth considering?
 
 That was discussed a few months back already and nobody seemed to like
 the idea. In fact it was as a result of that discussion that Stephen
 brought up the idea to register the DRM driver from a central host1x
 driver (it may also have been part of a discussion on IRC, I don't
 remember exactly).
 
 At the time I spent some time on a patch that introduced drm_soc_init()
 to solve this by creating a dummy struct device and registering the
 driver on top of that. But I abandoned it in favour of fixing the DRM
 platform support code. The approach also didn't provide for the proper
 encapsulation.

I've managed to go through all the other feedback and implement a
solution to most of them, so now I have some slack to actually think
about the initialization. Sorry about this, but you (meaning all the
reviewers) did give us a _lot_ to do. :-) Fortunately, the driver
actually became a lot better, too.

Back to the topic of tegradrm init. The root cause of the problem is
that DRM framework needs some device to assign itself to. The problem is
that this device doesn't have any physical counterpart, as it's only for
storing a pointer in DRM framework. Please correct me if this is wrong.

Moving the client registration to ping pong between DRM and host1x has
its problems. host1x driver itself has no use for a list of client
devices. It can just iterate its children in case it needs them. In
tegradrm, you need a list of devices under tegradrm control, which might
or might not be the same as list of devices under host1x hardware.

The solutions that many other DRM drivers seem to employ are the virtual
devices. Exynos and OMAP drivers do this, as does SH Mobile DRM driver.
So I think I'd still go this way, as it's the path of minimum
resistance, least amount of code and most localized change. I know it's
not ideal, but I'd also not like to get stuck in this.

Terje
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[RFC v2 2/5] drm/exynos: add iommu support for ipp

[Eunchul Kim]

This patch adds iommu support for ipp. For this, it
adds subdrv_probe/remove callback to enable or disable ipp iommu.
we can get or put device address to a gem handle from user
through exynos_drm_gem_get/put_dma_addr().

Signed-off-by: Eunchul Kim chulspro@samsung.com
Signed-off-by: Jinyoung Jeon jy0.j...@samsung.com
---
 drivers/gpu/drm/exynos/exynos_drm_ipp.c |   18 ++
 1 files changed, 18 insertions(+), 0 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_ipp.c 
b/drivers/gpu/drm/exynos/exynos_drm_ipp.c
index 2d84477..c582300 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_ipp.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_ipp.c
@@ -23,6 +23,7 @@
 #include exynos_drm_drv.h
 #include exynos_drm_gem.h
 #include exynos_drm_ipp.h
+#include exynos_drm_iommu.h
 
 /*
  * IPP is stand for Image Post Processing and
@@ -1668,10 +1669,24 @@ static int ipp_subdrv_probe(struct drm_device *drm_dev, 
struct device *dev)
ippdrv-event_workq = ctx-event_workq;
ippdrv-sched_event = ipp_sched_event;
INIT_LIST_HEAD(ippdrv-cmd_list);
+
+   if (is_drm_iommu_supported(drm_dev)) {
+   ret = drm_iommu_attach_device(drm_dev, ippdrv-dev);
+   if (ret) {
+   DRM_ERROR(failed to activate iommu\n);
+   goto err_iommu;
+   }
+   }
}
 
return 0;
 
+err_iommu:
+   /* get ipp driver entry */
+   list_for_each_entry_reverse(ippdrv, exynos_drm_ippdrv_list, drv_list)
+   if (is_drm_iommu_supported(drm_dev))
+   drm_iommu_detach_device(drm_dev, ippdrv-dev);
+
 err_idr:
idr_remove_all(ctx-ipp_idr);
idr_remove_all(ctx-prop_idr);
@@ -1689,6 +1704,9 @@ static void ipp_subdrv_remove(struct drm_device *drm_dev, 
struct device *dev)
 
/* get ipp driver entry */
list_for_each_entry(ippdrv, exynos_drm_ippdrv_list, drv_list) {
+   if (is_drm_iommu_supported(drm_dev))
+   drm_iommu_detach_device(drm_dev, ippdrv-dev);
+
ippdrv-drm_dev = NULL;
exynos_drm_ippdrv_unregister(ippdrv);
}
-- 
1.7.0.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[RFC v2 0/5] drm/exynos: add ipp subsystem and each ipp drivers

[Eunchul Kim]

Changelog v2:
Hi All.

This RFC v2 supports iommu in ipp. and Added/Removed comment from Inki.Dae.
Fixed GSC part bugs and next time I will send our local git commit.
and We finished implementation of SC for post-processing.
SC driver not fully tested yet. so, I didn't add SC feature in this patch.

Thank's

Changelog v1:

Hi All.

I am responsible for a display part from Samsung Electronics Telecommunication 
Division.
and I am going to add post-processing features in exynos drm.
If you have some opinions of this patch,
please give some comments about my patch.

This patch is post-processing(IPP) support for exynos drm driver.

IPP is stands for Image Post Processing and supports image scaler/rotator
and input/output DMA operations using IPP drivers(FIMC, Rotator, GSC, SC, so 
on.)
IPP is integration device driver of same attibute hardware.

Exynos4 SoC support FIMC, Rotator for post-processing.
and Exynos5 SoC support GSC, Rotator, SC for post-processing.
SC driver not tested yet. so, I didn't add SC feature in this patch.
and IPP subsystem works on Exynos SoC version independently.

IPP drivers supports Memory to Memory operations with various converting.
and some drivers supports Writeback and Display output operations using local 
path.
User can make converted image using this driver.
and also supports streaming concept for multimedia data processing.

And supports various operations
1. Scale operation generates various sizes of image.
2. CSC(Color Space Conversion) operation supports format converting.
3. Crop operation supports cutting the image.
4. Rotate operation supports to 90, 180, 270 degree.
5. Flip operation supports to vertical, horizontal, and both.
6. Writeback operation genertates cloned image from display controller(FIMD).
7. Display output operation support various format display to display 
controller(FIMD).
8. Input DMA reads image data from the memory.
9. Output DMA writes image data to memory.
10. Supports image effect functions.

Descriptions)
User should make property informations and set this property to registers.
and IPP subsystem manages property id using command node and make queue list 
using memory node.
IPP subsystem supports register function of IPP drivers.
IPP driver manages input/output DMA with various operations. and some driver 
supports
optional operations(writeback, output).
IPP driver needs various informations, so User set property information to IPP 
driver.
and also IPP driver needs memory base address of image for various operations.
User doesn't know its address, so fills the gem handle of that memory than 
address of image base.
and than IPP driver start operation.

Ioctls)
We adds four ioctls and one event for IPP subsystem.

- ioctls
DRM_EXYNOS_IPP_GET_PROPERTY : get ipp driver capabilitis and id.
DRM_EXYNOS_IPP_SET_PROPERTY : set format, position, rotation, flip about 
source/destination.
DRM_EXYNOS_IPP_QUEUE_BUF : enqueue/dequeue buffer and make event list.
DRM_EXYNOS_IPP_CMD_CTRL : play/stop/pause/resume control.

- event
DRM_EXYNOS_IPP_EVENT : event to give notification completion of buffer DMA with 
buffer list

Basic control flow and Sample pseudo application)
1. Basic control flow is same as below
Open - Get properties - User choose IPP driver and set property information 
- Set Property - Create gem handle -
Queue buffer(Enqueue) of source/destination - Command control(Play) - Event 
occured to User
- User handle converted image - (Queue buffer(Enqueue) of source/destination 
- Event occured to User)*N -
Queue buffer(Dequeue) of source/destination - Command control(Stop) - Free 
gem handle - Close

2. Sample pseudo application
#include exynos_drm.h
static int exynos_drm_ipp_set_property(int fd ...)
{
struct drm_exynos_pos crop_pos = {0, 0, hsize, vsize};
struct drm_exynos_pos scale_pos = {0, 0, hsize, vsize};
struct drm_exynos_sz src_sz = {hsize, vsize};
struct drm_exynos_sz dst_sz = {hsize, vsize};
int ret = 0;

memset(property, 0x00, sizeof(struct drm_exynos_ipp_property));
property-cmd = cmd;

property-config[EXYNOS_DRM_OPS_SRC].ops_id = EXYNOS_DRM_OPS_SRC;
property-config[EXYNOS_DRM_OPS_SRC].flip = EXYNOS_DRM_FLIP_NONE;
property-config[EXYNOS_DRM_OPS_SRC].degree = EXYNOS_DRM_DEGREE_0;
property-config[EXYNOS_DRM_OPS_SRC].fmt = DRM_FORMAT_XRGB;
property-config[EXYNOS_DRM_OPS_SRC].pos = crop_pos;
property-config[EXYNOS_DRM_OPS_SRC].sz = src_sz;

property-config[EXYNOS_DRM_OPS_DST].ops_id = EXYNOS_DRM_OPS_DST;
property-config[EXYNOS_DRM_OPS_DST].flip = EXYNOS_DRM_FLIP_NONE;
property-config[EXYNOS_DRM_OPS_DST].degree = degree;
property-config[EXYNOS_DRM_OPS_DST].fmt = DRM_FORMAT_XRGB;
property-config[EXYNOS_DRM_OPS_DST].pos = scale_pos;
property-config[EXYNOS_DRM_OPS_DST].sz = dst_sz;

ret = ioctl(fd, DRM_IOCTL_EXYNOS_IPP_SET_PROPERTY, property);
if (ret)
   

[RFC v2 4/5] drm/exynos: add rotator ipp driver

[Eunchul Kim]

Rotator supports rotation/crop/flip and input/output DMA operations
Rotator ipp driver supports 90,180,270 degree rotaion and vertical, horizontal 
flip.
and has some limitations(source and destination format have to be same, no 
scaler)

Signed-off-by: Eunchul Kim chulspro@samsung.com
Signed-off-by: Youngjun Cho yj44@samsung.com
---
 drivers/gpu/drm/exynos/Kconfig  |7 +
 drivers/gpu/drm/exynos/Makefile |1 +
 drivers/gpu/drm/exynos/exynos_drm_drv.c |   15 +
 drivers/gpu/drm/exynos/exynos_drm_drv.h |1 +
 drivers/gpu/drm/exynos/exynos_drm_rotator.c |  801 +++
 drivers/gpu/drm/exynos/exynos_drm_rotator.h |   13 +
 drivers/gpu/drm/exynos/regs-rotator.h   |   73 +++
 7 files changed, 911 insertions(+), 0 deletions(-)
 create mode 100644 drivers/gpu/drm/exynos/exynos_drm_rotator.c
 create mode 100644 drivers/gpu/drm/exynos/exynos_drm_rotator.h
 create mode 100644 drivers/gpu/drm/exynos/regs-rotator.h

diff --git a/drivers/gpu/drm/exynos/Kconfig b/drivers/gpu/drm/exynos/Kconfig
index 4915ab6..4860835 100644
--- a/drivers/gpu/drm/exynos/Kconfig
+++ b/drivers/gpu/drm/exynos/Kconfig
@@ -57,3 +57,10 @@ config DRM_EXYNOS_FIMC
depends on DRM_EXYNOS_IPP
help
  Choose this option if you want to use Exynos FIMC for DRM.
+
+config DRM_EXYNOS_ROTATOR
+   bool Exynos DRM Rotator
+   depends on DRM_EXYNOS_IPP
+   help
+ Choose this option if you want to use Exynos Rotator for DRM.
+
diff --git a/drivers/gpu/drm/exynos/Makefile b/drivers/gpu/drm/exynos/Makefile
index 9710024..3b70668 100644
--- a/drivers/gpu/drm/exynos/Makefile
+++ b/drivers/gpu/drm/exynos/Makefile
@@ -18,5 +18,6 @@ exynosdrm-$(CONFIG_DRM_EXYNOS_VIDI)   += exynos_drm_vidi.o
 exynosdrm-$(CONFIG_DRM_EXYNOS_G2D) += exynos_drm_g2d.o
 exynosdrm-$(CONFIG_DRM_EXYNOS_IPP) += exynos_drm_ipp.o
 exynosdrm-$(CONFIG_DRM_EXYNOS_FIMC)+= exynos_drm_fimc.o
+exynosdrm-$(CONFIG_DRM_EXYNOS_ROTATOR) += exynos_drm_rotator.o
 
 obj-$(CONFIG_DRM_EXYNOS)   += exynosdrm.o
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c 
b/drivers/gpu/drm/exynos/exynos_drm_drv.c
index 73f02ac..09d884b 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
@@ -378,6 +378,12 @@ static int __init exynos_drm_init(void)
goto out_fimc;
 #endif
 
+#ifdef CONFIG_DRM_EXYNOS_ROTATOR
+   ret = platform_driver_register(rotator_driver);
+   if (ret  0)
+   goto out_rotator;
+#endif
+
 #ifdef CONFIG_DRM_EXYNOS_IPP
ret = platform_driver_register(ipp_driver);
if (ret  0)
@@ -406,6 +412,11 @@ out_drm:
 out_ipp:
 #endif
 
+#ifdef CONFIG_DRM_EXYNOS_ROTATOR
+   platform_driver_unregister(rotator_driver);
+out_rotator:
+#endif
+
 #ifdef CONFIG_DRM_EXYNOS_FIMC
platform_driver_unregister(fimc_driver);
 out_fimc:
@@ -451,6 +462,10 @@ static void __exit exynos_drm_exit(void)
platform_driver_unregister(ipp_driver);
 #endif
 
+#ifdef CONFIG_DRM_EXYNOS_ROTATOR
+   platform_driver_unregister(rotator_driver);
+#endif
+
 #ifdef CONFIG_DRM_EXYNOS_FIMC
platform_driver_unregister(fimc_driver);
 #endif
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.h 
b/drivers/gpu/drm/exynos/exynos_drm_drv.h
index 14f9490..a74e37c 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.h
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.h
@@ -353,5 +353,6 @@ extern struct platform_driver exynos_drm_common_hdmi_driver;
 extern struct platform_driver vidi_driver;
 extern struct platform_driver g2d_driver;
 extern struct platform_driver fimc_driver;
+extern struct platform_driver rotator_driver;
 extern struct platform_driver ipp_driver;
 #endif
diff --git a/drivers/gpu/drm/exynos/exynos_drm_rotator.c 
b/drivers/gpu/drm/exynos/exynos_drm_rotator.c
new file mode 100644
index 000..347de99
--- /dev/null
+++ b/drivers/gpu/drm/exynos/exynos_drm_rotator.c
@@ -0,0 +1,801 @@
+/*
+ * Copyright (C) 2012 Samsung Electronics Co.Ltd
+ * Authors:
+ * YoungJun Cho yj44@samsung.com
+ * Eunchul Kim chulspro@samsung.com
+ *
+ * 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 Foundationr
+ */
+
+#include linux/kernel.h
+#include linux/module.h
+#include linux/err.h
+#include linux/interrupt.h
+#include linux/io.h
+#include linux/platform_device.h
+#include linux/clk.h
+#include linux/pm_runtime.h
+
+#include drm/drmP.h
+#include drm/exynos_drm.h
+#include regs-rotator.h
+#include exynos_drm.h
+#include exynos_drm_drv.h
+#include exynos_drm_ipp.h
+
+enum rot_irq_status {
+   ROT_IRQ_STATUS_COMPLETE = 8,
+   ROT_IRQ_STATUS_ILLEGAL  = 9,
+};
+
+struct rot_limit {
+   u32 min_w;
+   u32 min_h;
+   u32 max_w;
+   u32 max_h;
+   u32 align;
+};
+
+struct rot_limit_table {
+   struct rot_limitycbcr420_2p;
+ 

[RFC v2 5/5] drm/exynos: add gsc ipp driver

[Eunchul Kim]

GSC is stand for General SCaler and supports supports
image scaler/rotator/crop/flip/csc and input/output DMA operations.
input DMA reads image data from the memory.
output DMA writes image data to memory.
GSC supports image rotation and imag effect functions.
also supports writeback and display output operations.

Signed-off-by: Eunchul Kim chulspro@samsung.com
Signed-off-by: Jinyoung Jeon jy0.j...@samsung.com
---
 drivers/gpu/drm/exynos/Kconfig  |5 +
 drivers/gpu/drm/exynos/Makefile |1 +
 drivers/gpu/drm/exynos/exynos_drm_drv.c |   15 +
 drivers/gpu/drm/exynos/exynos_drm_drv.h |1 +
 drivers/gpu/drm/exynos/exynos_drm_gsc.c | 1476 +++
 drivers/gpu/drm/exynos/exynos_drm_gsc.h |   35 +
 drivers/gpu/drm/exynos/regs-gsc.h   |  295 ++
 include/drm/exynos_drm.h|   15 +
 8 files changed, 1843 insertions(+), 0 deletions(-)
 create mode 100644 drivers/gpu/drm/exynos/exynos_drm_gsc.c
 create mode 100644 drivers/gpu/drm/exynos/exynos_drm_gsc.h
 create mode 100644 drivers/gpu/drm/exynos/regs-gsc.h

diff --git a/drivers/gpu/drm/exynos/Kconfig b/drivers/gpu/drm/exynos/Kconfig
index 4860835..c93d776 100644
--- a/drivers/gpu/drm/exynos/Kconfig
+++ b/drivers/gpu/drm/exynos/Kconfig
@@ -64,3 +64,8 @@ config DRM_EXYNOS_ROTATOR
help
  Choose this option if you want to use Exynos Rotator for DRM.
 
+config DRM_EXYNOS_GSC
+   bool Exynos DRM GSC
+   depends on DRM_EXYNOS_IPP  ARCH_EXYNOS5
+   help
+ Choose this option if you want to use Exynos GSC for DRM.
diff --git a/drivers/gpu/drm/exynos/Makefile b/drivers/gpu/drm/exynos/Makefile
index 3b70668..639b49e 100644
--- a/drivers/gpu/drm/exynos/Makefile
+++ b/drivers/gpu/drm/exynos/Makefile
@@ -19,5 +19,6 @@ exynosdrm-$(CONFIG_DRM_EXYNOS_G2D)+= exynos_drm_g2d.o
 exynosdrm-$(CONFIG_DRM_EXYNOS_IPP) += exynos_drm_ipp.o
 exynosdrm-$(CONFIG_DRM_EXYNOS_FIMC)+= exynos_drm_fimc.o
 exynosdrm-$(CONFIG_DRM_EXYNOS_ROTATOR) += exynos_drm_rotator.o
+exynosdrm-$(CONFIG_DRM_EXYNOS_GSC) += exynos_drm_gsc.o
 
 obj-$(CONFIG_DRM_EXYNOS)   += exynosdrm.o
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c 
b/drivers/gpu/drm/exynos/exynos_drm_drv.c
index 09d884b..e0a8e80 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
@@ -384,6 +384,12 @@ static int __init exynos_drm_init(void)
goto out_rotator;
 #endif
 
+#ifdef CONFIG_DRM_EXYNOS_GSC
+   ret = platform_driver_register(gsc_driver);
+   if (ret  0)
+   goto out_gsc;
+#endif
+
 #ifdef CONFIG_DRM_EXYNOS_IPP
ret = platform_driver_register(ipp_driver);
if (ret  0)
@@ -412,6 +418,11 @@ out_drm:
 out_ipp:
 #endif
 
+#ifdef CONFIG_DRM_EXYNOS_GSC
+   platform_driver_unregister(gsc_driver);
+out_gsc:
+#endif
+
 #ifdef CONFIG_DRM_EXYNOS_ROTATOR
platform_driver_unregister(rotator_driver);
 out_rotator:
@@ -462,6 +473,10 @@ static void __exit exynos_drm_exit(void)
platform_driver_unregister(ipp_driver);
 #endif
 
+#ifdef CONFIG_DRM_EXYNOS_GSC
+   platform_driver_unregister(gsc_driver);
+#endif
+
 #ifdef CONFIG_DRM_EXYNOS_ROTATOR
platform_driver_unregister(rotator_driver);
 #endif
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.h 
b/drivers/gpu/drm/exynos/exynos_drm_drv.h
index a74e37c..afe556c 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.h
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.h
@@ -354,5 +354,6 @@ extern struct platform_driver vidi_driver;
 extern struct platform_driver g2d_driver;
 extern struct platform_driver fimc_driver;
 extern struct platform_driver rotator_driver;
+extern struct platform_driver gsc_driver;
 extern struct platform_driver ipp_driver;
 #endif
diff --git a/drivers/gpu/drm/exynos/exynos_drm_gsc.c 
b/drivers/gpu/drm/exynos/exynos_drm_gsc.c
new file mode 100644
index 000..614365e
--- /dev/null
+++ b/drivers/gpu/drm/exynos/exynos_drm_gsc.c
@@ -0,0 +1,1476 @@
+/*
+ * Copyright (C) 2012 Samsung Electronics Co.Ltd
+ * Authors:
+ * Eunchul Kim chulspro@samsung.com
+ * Jinyoung Jeon jy0.j...@samsung.com
+ * Sangmin Lee lsmin@samsung.com
+ *
+ * This program is free software; you can redistribute  it and/or modify it
+ * under  the terms of  the GNU General  Public License as published by the
+ * Free Software Foundation;  either version 2 of the  License, or (at your
+ * option) any later version.
+ *
+ */
+#include linux/kernel.h
+#include linux/module.h
+#include linux/platform_device.h
+#include linux/clk.h
+#include linux/pm_runtime.h
+#include plat/map-base.h
+
+#include drm/drmP.h
+#include drm/exynos_drm.h
+#include regs-gsc.h
+#include exynos_drm_drv.h
+#include exynos_drm_gem.h
+#include exynos_drm_ipp.h
+#include exynos_drm_gsc.h
+
+/*
+ * GSC is stand for General SCaler and
+ * supports image scaler/rotator and input/output DMA operations.
+ * input DMA reads image data from the memory.
+ * output DMA writes image data to 

[Bug 22576] [KMS] mesa demo spectex broken on rv280

[bugzilla-daemon]

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

--- Comment #19 from Alan Swanson swan...@ukfsn.org ---
This fixes lighting bug 26809 with NWN on my rv250, but R200 untested as yet.
To correct the section size mismatch, add the following before the
BEGIN_BATCH_NO_AUTOSTATE() line;

  dwords += 2;

Thank you very much for finding this three year old radeon rewrite bug. I
assume you discerned this from cmdscl used for LIT_CMD_1 versus cmdvec used for
LIT_CMD_0?

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 57875] Second Life viewer bad rendering with git-ec83535

[bugzilla-daemon]

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

--- Comment #16 from Henri Verbeet hverb...@gmail.com ---
(In reply to comment #15)
 I've written an extension proposal for a new mesa extension that exposes the
 CLIP_DISABLE bit. The proposal is attached, please review and comment. There
 are some TODOs I'm not quite sure how to deal with, see the list in Status.
 
  - It probably makes sense to mention depth in the extension name somewhere,
we really only care about the near and far clipping planes. E.g.
MESA_depth_clip.
  - Perhaps it makes more sense to write the extension in terms of
ARB_depth_clamp. I.e., provide a subset of ARB_depth_clamp, that only disables
depth clipping, and generates undefined results in the depth test, except for
perhaps GL_ALWAYS / GL_NEVER. (Also, note that you can't really make fragment
depth values undefined before / in the fragment shader, because you have
interactions with e.g. texture filtering as well.) It would avoid the perhaps
somewhat questionable ARB_depth_clamp must not be supported, and you can just
defer to ARB_depth_clamp for most of the issues etc. The interaction between
the two extensions just becomes that if ARB_depth_clamp is also supported you
get defined depth test results.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 22576] [KMS] mesa demo spectex broken on rv280

[bugzilla-daemon]

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

--- Comment #20 from smoki smoki00...@gmail.com ---
 Yeah, i just see that, assume that it must be scl there then compared it with
radeon state, there is setup just like that, but with correct vec/scl as i
assume, so i changed it like that and that is it - tcl lighting works. Three
year old typo - i deserve a medal ;).

 Someone could pushed it in git.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 50655] ATI RV670 [Radeon HD 3870] Ioquake games causes GPU lockup (waiting for 0x00003039 last fence id 0x00003030)

[bugzilla-daemon]

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

--- Comment #20 from Alex Deucher ag...@yahoo.com ---
Created attachment 71271
  -- https://bugs.freedesktop.org/attachment.cgi?id=71271action=edit
possible fix

Does this patch help?

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 58033] [r300g] Black gap artifacts when playing WoW

[bugzilla-daemon]

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

--- Comment #4 from Alex Deucher ag...@yahoo.com ---
Can you bisect?

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 58042] Garbled UI in Team Fortress 2 Beta

[bugzilla-daemon]

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

--- Comment #2 from Alex Deucher ag...@yahoo.com ---
Is this a regression or has it always had rendering problems?  Does it render
ok with mesa 9.0.x or 8.0.x?  If so, can you bisect?

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 22576] [KMS] mesa demo spectex broken on rv280

[bugzilla-daemon]

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

Roland Scheidegger srol...@vmware.com changed:

   What|Removed |Added

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

--- Comment #21 from Roland Scheidegger srol...@vmware.com ---
(In reply to comment #18)
  I think i've found source of these lighting problems on r200 in this and
 other bugs. It is just a typo it seems in r200_state_init.c lit_emit()
 
  OUT_VEC(atom-cmd[LIT_CMD_1], atom-cmd+LIT_CMD_1+1);
 
  instead of OUT_VEC it needs to be OUT_SCL:
 
  OUT_SCL(atom-cmd[LIT_CMD_1], atom-cmd+LIT_CMD_1+1);

Should be fixed by 320d531373e7b0873f5de42f6173b986290f593f, thanks!
FWIW the command emit mechanism looks a bit too complicated it could profit
from some refactoring. For instance it is still based on the fake
drm_radeon_cmd_header_t structure, the scl vs. scl2 and vec vs. veclinear emits
are nothing but crude hacks around limitations in that structure, even though
since ums is gone there is absolutely no point in using that struct...
Section size calcs are also somewhat confusing, the sanity code (which was
really great back then) is totally unused etc.
Maybe another day...

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 26809] KMS/R200: Bad shading in NWN since Mesa rewrite

[bugzilla-daemon]

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

Roland Scheidegger srol...@vmware.com changed:

   What|Removed |Added

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

--- Comment #2 from Roland Scheidegger srol...@vmware.com ---
Ought to be fixed by 320d531373e7b0873f5de42f6173b986290f593f.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 56405] Distorted graphics on Radeon HD 6620G

[bugzilla-daemon]

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

--- Comment #40 from klausenb...@hotmail.com ---
Any update?

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Nouveau] [PATCH] drm/nouveau: fix takedown in move_notify

[Emil Velikov]

On 21/11/12 13:15, Maarten Lankhorst wrote:
 move_notify is called by ttm after the the object is idle and about
 to be destroyed. Clean up the vm list properly in that case.
 
 This is not a problem right now, since the list should already be
 empty, but if it wasn't empty, vm_put was not called which leads to
 random corruption later.
 
 With this fix, nouveau_gem_object_close can be safely changed to a noop,
 forcing the vm bindings to be removed when the original object is. This
 is not done in this patch since it may lead to the object staying mapped
 in the vm space until the gem object refcount drops to 0. This shouldn't
 be a big issue however.
 
 If we choose to do so does allow us to use ttm's delayed destruction
 mechanism to unmap vm after object is idle, resulting in ioread32 no
 longer taking up 30% of cpu in Team Fortress 2 if I don't do the vma
 unmap in nouveau_gem_object_close.
 
 Signed-off-by: Maarten Lankhorst maarten.lankho...@canonical.com
 
Hi Maarten

I've noticed ioread32 of up-to 40% on of cpu my system. With your patch
if goes down to ~3% with no side effects. Frame-rate appears to be
slightly improved, although it's hard to say.

Is there any reason for holding this patch ?
For what it's worth you can add

Tested-by: Emil Velikov emil.l.veli...@gmail.com

 ---
 diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c 
 b/drivers/gpu/drm/nouveau/nouveau_bo.c
 index 35ac57f..e8a47f0 100644
 --- a/drivers/gpu/drm/nouveau/nouveau_bo.c
 +++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
 @@ -1139,12 +1139,22 @@ nouveau_bo_move_ntfy(struct ttm_buffer_object *bo, 
 struct ttm_mem_reg *new_mem)
   if (bo-destroy != nouveau_bo_del_ttm)
   return;
  
 + if (!new_mem) {
 + while (!list_empty(nvbo-vma_list)) {
 + vma = list_first_entry(nvbo-vma_list, struct 
 nouveau_vma, head);
 +
 + nouveau_vm_unmap(vma);
 + nouveau_vm_put(vma);
 + list_del(vma-head);
 + }
 + return;
 + }
 +
   list_for_each_entry(vma, nvbo-vma_list, head) {
 - if (new_mem  new_mem-mem_type == TTM_PL_VRAM) {
 + if (new_mem-mem_type == TTM_PL_VRAM) {
   nouveau_vm_map(vma, new_mem-mm_node);
 - } else
 - if (new_mem  new_mem-mem_type == TTM_PL_TT 
 - nvbo-page_shift == vma-vm-vmm-spg_shift) {
 + } else if (new_mem-mem_type == TTM_PL_TT 
 +nvbo-page_shift == vma-vm-vmm-spg_shift) {
   if (((struct nouveau_mem *)new_mem-mm_node)-sg)
   nouveau_vm_map_sg_table(vma, 0, new_mem-
 num_pages  PAGE_SHIFT,
 @@ -1153,8 +1163,6 @@ nouveau_bo_move_ntfy(struct ttm_buffer_object *bo, 
 struct ttm_mem_reg *new_mem)
   nouveau_vm_map_sg(vma, 0, new_mem-
 num_pages  PAGE_SHIFT,
 new_mem-mm_node);
 - } else {
 - nouveau_vm_unmap(vma);
   }
   }
  }
 
 ___
 Nouveau mailing list
 nouv...@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/nouveau
 

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 56405] Distorted graphics on Radeon HD 6620G

[bugzilla-daemon]

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

--- Comment #41 from Jerome Glisse gli...@freedesktop.org ---
Created attachment 71284
  -- https://bugs.freedesktop.org/attachment.cgi?id=71284action=edit
Patch gpu pipe

Does this kernel patch fix the issue ?

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Nouveau] [PATCH] drm/nouveau: fix takedown in move_notify

[Maarten Lankhorst]

Op 10-12-12 17:39, Emil Velikov schreef:
 On 21/11/12 13:15, Maarten Lankhorst wrote:
 move_notify is called by ttm after the the object is idle and about
 to be destroyed. Clean up the vm list properly in that case.

 This is not a problem right now, since the list should already be
 empty, but if it wasn't empty, vm_put was not called which leads to
 random corruption later.

 With this fix, nouveau_gem_object_close can be safely changed to a noop,
 forcing the vm bindings to be removed when the original object is. This
 is not done in this patch since it may lead to the object staying mapped
 in the vm space until the gem object refcount drops to 0. This shouldn't
 be a big issue however.

 If we choose to do so does allow us to use ttm's delayed destruction
 mechanism to unmap vm after object is idle, resulting in ioread32 no
 longer taking up 30% of cpu in Team Fortress 2 if I don't do the vma
 unmap in nouveau_gem_object_close.

 Signed-off-by: Maarten Lankhorst maarten.lankho...@canonical.com

 Hi Maarten

 I've noticed ioread32 of up-to 40% on of cpu my system. With your patch
 if goes down to ~3% with no side effects. Frame-rate appears to be
 slightly improved, although it's hard to say.

 Is there any reason for holding this patch ?
 For what it's worth you can add

 Tested-by: Emil Velikov emil.l.veli...@gmail.com
Well 2 reasons..

1) In the current form, you're guaranteed to cause memory corruption on forced 
client takedown. Locking needs more thought.
The warns you get are very real errors. ;-)

 ---
 diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c 
 b/drivers/gpu/drm/nouveau/nouveau_bo.c
 index 35ac57f..e8a47f0 100644
 --- a/drivers/gpu/drm/nouveau/nouveau_bo.c
 +++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
 @@ -1139,12 +1139,22 @@ nouveau_bo_move_ntfy(struct ttm_buffer_object *bo, 
 struct ttm_mem_reg *new_mem)
  if (bo-destroy != nouveau_bo_del_ttm)
  return;
  
 +if (!new_mem) {
 +while (!list_empty(nvbo-vma_list)) {
 +vma = list_first_entry(nvbo-vma_list, struct 
 nouveau_vma, head);
 +
 +nouveau_vm_unmap(vma);
 +nouveau_vm_put(vma);
 +list_del(vma-head);
2. I missed a kfree here ;-)

~Maarten
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 56405] Distorted graphics on Radeon HD 6620G

[bugzilla-daemon]

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

--- Comment #42 from Alex Deucher ag...@yahoo.com ---
 case CHIP_SUMO2:
-rdev-config.evergreen.num_ses = 1;
+rdev-config.evergreen.num_ses = 2;

None of the APUs have multiple SEs.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 56405] Distorted graphics on Radeon HD 6620G

[bugzilla-daemon]

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

--- Comment #43 from klausenb...@hotmail.com ---
(In reply to comment #42)
   case CHIP_SUMO2:
 - rdev-config.evergreen.num_ses = 1;
 + rdev-config.evergreen.num_ses = 2;
 
 None of the APUs have multiple SEs.

So it waste of time, to try that patch?

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 56405] Distorted graphics on Radeon HD 6620G

[bugzilla-daemon]

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

--- Comment #44 from Alex Deucher ag...@yahoo.com ---
(In reply to comment #43)
 (In reply to comment #42)
  case CHIP_SUMO2:
  -   rdev-config.evergreen.num_ses = 1;
  +   rdev-config.evergreen.num_ses = 2;
  
  None of the APUs have multiple SEs.
 
 So it waste of time, to try that patch?

Please try it.  Your card is not a SUMO2.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

glxgears frame rate when DPMS is in off state

[Ilija Hadzic]

Hi everyone,

With relatively recent versions of AMD/ATI DDX (xf86-video-ati library), I 
have noticed a behavior related to DPMS that looks incorrect to me.


Namely, if I run glxgears, the reported frame rate is equal to that of the 
monitor refresh rate, which is correct. Now if I enter DPMS off state, 
wait a while, and then exit it (back to DPMS on), I see that while in 
off mode the frame rate was up in the thousands. Consequently, the CPU 
utilization went up to 100% (split about 50%/50% between X and and 
glxgears process).


I have traced the problem to DDX and here are some findings. Now, thinking 
about how to fix it (elaborated later), I realize that I am not sure what 
would be the conceptually correct thing to do to fix this.


Here is how the problem happens:

* Screen is put into DPMS off mode.

* The application requests the buffer-swap and X eventually ends up in 
radeon_dri2_schedule_swap.


* radeon_dri2_schedule_swap tries to determine the CRTC by calling 
radeon_dri2_drawable_crtc which further leads into radeon_pick_best_crtc


* In radeon_pick_best_crtc, no CRTC is found because CRTCs are either 
unused by the affected drawable or the only right candidate CRTC is 
skipped by this check (radeon_crtc_is_enabled looks explicitly at DPMS 
state):


if (!radeon_crtc_is_enabled(crtc))
continue;

* Consequently, radeon_pick_best_crtc returns -1 to 
radeon_dri2_schedule_swap, which decides that it can't do the vblank

wait and jumps to blit_fallback label.

* blit_fallback does its thing, achieving the effect of swap, but now 
there is no pacing. It returns immediatelly and application proceeds with 
rendering the next frame without any pause.


* As a consequence, we get a glxgears and X to run at maximum speed 
allowed by the CPU and GPU combined.


Now, the reason DPMS exists is to conserve power, but it doesn't make much 
sense to conserve power through monitor shutoff if we will eat up much 
more power by thrashing the processor and the GPU.


One quick fix that came into my mind is to replace the 'if' in 
radeon_pick_best_crtc with something like this:


if (!crtc-enabled)
continue;

(whether by design or by accident, crtc in DPMS off state is still 
enabled as far as that flag is concerned). However, that will introduce 
the regression with regard to this bug:


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

(which is the reason the above check was originally added).

Another possibility would be to enforce some maximum rate per-drawable 
(using sleep for example) when radeon_dri2_schedule_swap decides to take 
the blit_fallback path. However, I don't personally like it and I have a 
gut feeling that sleeping in shedule_swap would probably do harm somewhere 
else. Also, there may be applications that would want to render an 
animated scene off-screen at maximum speed (e.g., off-line rendering) and

radeon_dri2_schedule_swap has no way of telling whether crtc is -1 because
the application wants it that way or because the associated crtc is in
power-savings mode.

Clearly, the behavior that we have now is wrong from the power-savings 
perspective (i.e., it completely defeats the purpose of DPMS), but before 
I try to hack up the fix, I would like to hear some suggestions on what 
the right thing to do would be.


thanks,

Ilija

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 1/2] drm/radeon: do not move bo to different placement at each cs

[Jerome Glisse]

On Thu, Nov 29, 2012 at 10:35 AM,  j.gli...@gmail.com wrote:
 From: Jerome Glisse jgli...@redhat.com

 The bo creation placement is where the bo will be. Instead of trying
 to move bo at each command stream let this work to another worker
 thread that will use more advance heuristic.

 Signed-off-by: Jerome Glisse jgli...@redhat.com

What about including this for 3.8 it will mostly fix all regression
performance and is a first valid step for proper bo placement.

Cheers,
Jerome

 ---
  drivers/gpu/drm/radeon/radeon.h|  1 +
  drivers/gpu/drm/radeon/radeon_object.c | 17 -
  2 files changed, 9 insertions(+), 9 deletions(-)

 diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
 index 8c42d54..0a2664c 100644
 --- a/drivers/gpu/drm/radeon/radeon.h
 +++ b/drivers/gpu/drm/radeon/radeon.h
 @@ -313,6 +313,7 @@ struct radeon_bo {
 struct list_headlist;
 /* Protected by tbo.reserved */
 u32 placements[3];
 +   u32 busy_placements[3];
 struct ttm_placementplacement;
 struct ttm_buffer_objecttbo;
 struct ttm_bo_kmap_obj  kmap;
 diff --git a/drivers/gpu/drm/radeon/radeon_object.c 
 b/drivers/gpu/drm/radeon/radeon_object.c
 index 3f9f3bb..e25ae20 100644
 --- a/drivers/gpu/drm/radeon/radeon_object.c
 +++ b/drivers/gpu/drm/radeon/radeon_object.c
 @@ -84,7 +84,6 @@ void radeon_ttm_placement_from_domain(struct radeon_bo 
 *rbo, u32 domain)
 rbo-placement.fpfn = 0;
 rbo-placement.lpfn = 0;
 rbo-placement.placement = rbo-placements;
 -   rbo-placement.busy_placement = rbo-placements;
 if (domain  RADEON_GEM_DOMAIN_VRAM)
 rbo-placements[c++] = TTM_PL_FLAG_WC | TTM_PL_FLAG_UNCACHED |
 TTM_PL_FLAG_VRAM;
 @@ -105,6 +104,14 @@ void radeon_ttm_placement_from_domain(struct radeon_bo 
 *rbo, u32 domain)
 if (!c)
 rbo-placements[c++] = TTM_PL_MASK_CACHING | 
 TTM_PL_FLAG_SYSTEM;
 rbo-placement.num_placement = c;
 +
 +   c = 0;
 +   rbo-placement.busy_placement = rbo-busy_placements;
 +   if (rbo-rdev-flags  RADEON_IS_AGP) {
 +   rbo-busy_placements[c++] = TTM_PL_FLAG_WC | TTM_PL_FLAG_TT;
 +   } else {
 +   rbo-busy_placements[c++] = TTM_PL_FLAG_CACHED | 
 TTM_PL_FLAG_TT;
 +   }
 rbo-placement.num_busy_placement = c;
  }

 @@ -360,17 +367,9 @@ int radeon_bo_list_validate(struct list_head *head)
 list_for_each_entry(lobj, head, tv.head) {
 bo = lobj-bo;
 if (!bo-pin_count) {
 -   domain = lobj-wdomain ? lobj-wdomain : 
 lobj-rdomain;
 -
 -   retry:
 -   radeon_ttm_placement_from_domain(bo, domain);
 r = ttm_bo_validate(bo-tbo, bo-placement,
 true, false, false);
 if (unlikely(r)) {
 -   if (r != -ERESTARTSYS  domain == 
 RADEON_GEM_DOMAIN_VRAM) {
 -   domain |= RADEON_GEM_DOMAIN_GTT;
 -   goto retry;
 -   }
 return r;
 }
 }
 --
 1.7.11.7

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel