[RFC PATCH 1/3] drm/exynos: make kms drivers to be independent modules

2014-11-19 Thread Inki Dae
This patch makes kms drivers to be independent modules.
For this, it removes all register codes to kms drivers
from exynos_drm_drv module and adds module_init/exit
for each kms driver so that each kms driver can be
called independently.

Signed-off-by: Inki Dae 
---
 drivers/gpu/drm/exynos/Kconfig   |8 +++---
 drivers/gpu/drm/exynos/exynos_dp_core.c  |   13 +
 drivers/gpu/drm/exynos/exynos_drm_drv.c  |   43 +++---
 drivers/gpu/drm/exynos/exynos_drm_drv.h  |5 
 drivers/gpu/drm/exynos/exynos_drm_dsi.c  |   13 +
 drivers/gpu/drm/exynos/exynos_drm_fimd.c |   13 +
 drivers/gpu/drm/exynos/exynos_hdmi.c |   13 +
 drivers/gpu/drm/exynos/exynos_mixer.c|   13 +
 8 files changed, 72 insertions(+), 49 deletions(-)

diff --git a/drivers/gpu/drm/exynos/Kconfig b/drivers/gpu/drm/exynos/Kconfig
index 7f9f6f9..3d5fa69 100644
--- a/drivers/gpu/drm/exynos/Kconfig
+++ b/drivers/gpu/drm/exynos/Kconfig
@@ -25,7 +25,7 @@ config DRM_EXYNOS_DMABUF
  Choose this option if you want to use DMABUF feature for DRM.

 config DRM_EXYNOS_FIMD
-   bool "Exynos DRM FIMD"
+   tristate "Exynos DRM FIMD"
depends on DRM_EXYNOS && !FB_S3C
select FB_MODE_HELPERS
select MFD_SYSCON
@@ -41,7 +41,7 @@ config DRM_EXYNOS_DPI
  This enables support for Exynos parallel output.

 config DRM_EXYNOS_DSI
-   bool "EXYNOS DRM MIPI-DSI driver support"
+   tristate "EXYNOS DRM MIPI-DSI driver support"
depends on DRM_EXYNOS_FIMD
select DRM_MIPI_DSI
select DRM_PANEL
@@ -50,7 +50,7 @@ config DRM_EXYNOS_DSI
  This enables support for Exynos MIPI-DSI device.

 config DRM_EXYNOS_DP
-   bool "EXYNOS DRM DP driver support"
+   tristate "EXYNOS DRM DP driver support"
depends on DRM_EXYNOS_FIMD && ARCH_EXYNOS && (DRM_PTN3460=n || 
DRM_PTN3460=y || DRM_PTN3460=DRM_EXYNOS)
default DRM_EXYNOS
select DRM_PANEL
@@ -58,7 +58,7 @@ config DRM_EXYNOS_DP
  This enables support for DP device.

 config DRM_EXYNOS_HDMI
-   bool "Exynos DRM HDMI"
+   tristate "Exynos DRM HDMI"
depends on DRM_EXYNOS && !VIDEO_SAMSUNG_S5P_TV
help
  Choose this option if you want to use Exynos HDMI for DRM.
diff --git a/drivers/gpu/drm/exynos/exynos_dp_core.c 
b/drivers/gpu/drm/exynos/exynos_dp_core.c
index ed818b9..b08d97b 100644
--- a/drivers/gpu/drm/exynos/exynos_dp_core.c
+++ b/drivers/gpu/drm/exynos/exynos_dp_core.c
@@ -1408,6 +1408,19 @@ struct platform_driver dp_driver = {
},
 };

+static int exynos_dp_init(void)
+{
+   return platform_driver_register(&dp_driver);
+}
+
+static void exynos_dp_exit(void)
+{
+   platform_driver_unregister(&dp_driver);
+}
+
+module_init(exynos_dp_init);
+module_exit(exynos_dp_exit);
+
 MODULE_AUTHOR("Jingoo Han ");
 MODULE_DESCRIPTION("Samsung SoC DP Driver");
 MODULE_LICENSE("GPL v2");
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c 
b/drivers/gpu/drm/exynos/exynos_drm_drv.c
index eab12f0..02d4772 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
@@ -484,12 +484,6 @@ static struct component_match *exynos_drm_match_add(struct 
device *dev)

mutex_lock(&drm_component_lock);

-   /* Do not retry to probe if there is no any kms driver regitered. */
-   if (list_empty(&drm_component_list)) {
-   mutex_unlock(&drm_component_lock);
-   return ERR_PTR(-ENODEV);
-   }
-
list_for_each_entry(cdev, &drm_component_list, list) {
/*
 * Add components to master only in case that crtc and
@@ -545,22 +539,6 @@ static const struct component_master_ops exynos_drm_ops = {
.unbind = exynos_drm_unbind,
 };

-static struct platform_driver *const exynos_drm_kms_drivers[] = {
-#ifdef CONFIG_DRM_EXYNOS_FIMD
-   &fimd_driver,
-#endif
-#ifdef CONFIG_DRM_EXYNOS_DP
-   &dp_driver,
-#endif
-#ifdef CONFIG_DRM_EXYNOS_DSI
-   &dsi_driver,
-#endif
-#ifdef CONFIG_DRM_EXYNOS_HDMI
-   &mixer_driver,
-   &hdmi_driver,
-#endif
-};
-
 static struct platform_driver *const exynos_drm_non_kms_drivers[] = {
 #ifdef CONFIG_DRM_EXYNOS_G2D
&g2d_driver,
@@ -587,22 +565,14 @@ static int exynos_drm_platform_probe(struct 
platform_device *pdev)
pdev->dev.coherent_dma_mask = DMA_BIT_MASK(32);
exynos_drm_driver.num_ioctls = ARRAY_SIZE(exynos_ioctls);

-   for (i = 0; i < ARRAY_SIZE(exynos_drm_kms_drivers); ++i) {
-   ret = platform_driver_register(exynos_drm_kms_drivers[i]);
-   if (ret < 0)
-   goto err_unregister_kms_drivers;
-   }
-
match = exynos_drm_match_add(&pdev->dev);
-   if (IS_ERR(match)) {
-   ret = PTR_ERR(match);
-   goto err_unregister_kms_drivers;
-   }
+   if (IS_ERR(match))
+   return PTR_ERR(match);

ret = component_master_add_with

[RFC PATCH 0/3] drm/exynos: add full modularity support to sub drivers

2014-11-19 Thread Inki Dae
Hi all,

   This patch set adds full modularity to sub drivers, kms and
   non kms drivers.

   For this, this patch sets consists into three patches.
   first patch modularizes kms drivers, second patch for non
   kms drivers, and third patch for vidi driver.

   I hope we could resolve infinite loop issue and kernel lockup
   reported by other people. This patch set is RFC so there might
   be my missing points. Welcome to any comments.

   This patch set is based on top of exynos-drm-next branch.

   Thanks,
   Inki Dae

Inki Dae (3):
  drm/exynos: make kms drivers to be independent modules
  drm/exynos: make non kms drivers to be indenpendent modules
  drm/exynos: make vidi driver to be independent module

 drivers/gpu/drm/exynos/Kconfig  |8 +-
 drivers/gpu/drm/exynos/exynos_dp_core.c |   13 +++
 drivers/gpu/drm/exynos/exynos_drm_core.c|  166 +++
 drivers/gpu/drm/exynos/exynos_drm_drv.c |  105 +
 drivers/gpu/drm/exynos/exynos_drm_drv.h |   42 ++-
 drivers/gpu/drm/exynos/exynos_drm_dsi.c |   13 +++
 drivers/gpu/drm/exynos/exynos_drm_fimc.c|   13 +++
 drivers/gpu/drm/exynos/exynos_drm_fimd.c|   13 +++
 drivers/gpu/drm/exynos/exynos_drm_g2d.c |   34 ++
 drivers/gpu/drm/exynos/exynos_drm_gsc.c |   12 ++
 drivers/gpu/drm/exynos/exynos_drm_ipp.c |   39 ++-
 drivers/gpu/drm/exynos/exynos_drm_rotator.c |   13 +++
 drivers/gpu/drm/exynos/exynos_drm_vidi.c|   81 -
 drivers/gpu/drm/exynos/exynos_hdmi.c|   13 +++
 drivers/gpu/drm/exynos/exynos_mixer.c   |   13 +++
 15 files changed, 391 insertions(+), 187 deletions(-)

-- 
1.7.9.5



[RFC PATCH 2/3] drm/exynos: make non kms drivers to be indenpendent modules

2014-11-19 Thread Inki Dae
This patch makes non kms drivers to be independent modules.
For this, it removes all register codes to non kms drivers
from exynos_drm_drv module and adds module_init/exit
for each non kms driver so that each non kms driver can be
called independently.

In addition, this patch adds non kms register/unregister functions
to exynos_drm_core module and also modifies existing codes relevant
to sub driver.

The idea is that non kms driver is registered by entry point,
module_init, of each non kms driver and sets its own sub driver
to registered non kms driver object when the sub driver is probed.
For this, this patch adds a new structure, exynos_drm_non_kms_dev,
to exynos_drm_core module.

Signed-off-by: Inki Dae 
---
 drivers/gpu/drm/exynos/exynos_drm_core.c|  166 +++
 drivers/gpu/drm/exynos/exynos_drm_drv.c |   50 +---
 drivers/gpu/drm/exynos/exynos_drm_drv.h |   28 ++---
 drivers/gpu/drm/exynos/exynos_drm_fimc.c|   13 +++
 drivers/gpu/drm/exynos/exynos_drm_g2d.c |   34 ++
 drivers/gpu/drm/exynos/exynos_drm_gsc.c |   12 ++
 drivers/gpu/drm/exynos/exynos_drm_ipp.c |   39 ++-
 drivers/gpu/drm/exynos/exynos_drm_rotator.c |   13 +++
 8 files changed, 265 insertions(+), 90 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_core.c 
b/drivers/gpu/drm/exynos/exynos_drm_core.c
index 4c9f972..2ce63bc 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_core.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_core.c
@@ -19,6 +19,13 @@
 #include "exynos_drm_fbdev.h"

 static LIST_HEAD(exynos_drm_subdrv_list);
+DEFINE_MUTEX(list_lock);
+
+struct exynos_drm_non_kms_dev {
+   struct list_head list;
+   struct exynos_drm_subdrv *subdrv;
+   unsigned int device_type;
+};

 int exynos_drm_create_enc_conn(struct drm_device *dev,
struct exynos_drm_display *display)
@@ -55,12 +62,66 @@ err_destroy_encoder:
return ret;
 }

+int exynos_drm_non_kms_register(unsigned int device_type)
+{
+   struct exynos_drm_non_kms_dev *dev;
+
+   dev = kzalloc(sizeof(*dev), GFP_KERNEL);
+   if (!dev)
+   return -ENOMEM;
+
+   dev->device_type = device_type;
+
+   mutex_lock(&list_lock);
+   list_add_tail(&dev->list, &exynos_drm_subdrv_list);
+   mutex_unlock(&list_lock);
+
+   return 0;
+}
+
+void exynos_drm_non_kms_unregister(unsigned int device_type)
+{
+   struct exynos_drm_non_kms_dev *dev, *next;
+
+   mutex_lock(&list_lock);
+   list_for_each_entry_safe(dev, next, &exynos_drm_subdrv_list, list) {
+   mutex_unlock(&list_lock);
+   if (dev->device_type == device_type) {
+   list_del_init(&dev->list);
+   kfree(dev);
+   mutex_lock(&list_lock);
+   break;
+   }
+   mutex_lock(&list_lock);
+   }
+   mutex_unlock(&list_lock);
+}
+
 int exynos_drm_subdrv_register(struct exynos_drm_subdrv *subdrv)
 {
+   struct exynos_drm_non_kms_dev *dev;
+
if (!subdrv)
return -EINVAL;

-   list_add_tail(&subdrv->list, &exynos_drm_subdrv_list);
+   mutex_lock(&list_lock);
+   if (list_empty(&exynos_drm_subdrv_list)) {
+   mutex_unlock(&list_lock);
+   return -ENODEV;
+   }
+   mutex_unlock(&list_lock);
+
+   mutex_lock(&list_lock);
+   list_for_each_entry(dev, &exynos_drm_subdrv_list, list) {
+   mutex_unlock(&list_lock);
+   if (dev->device_type == subdrv->device_type) {
+   dev->subdrv = subdrv;
+   mutex_lock(&list_lock);
+   break;
+   }
+   mutex_lock(&list_lock);
+   }
+   mutex_unlock(&list_lock);

return 0;
 }
@@ -68,94 +129,151 @@ EXPORT_SYMBOL_GPL(exynos_drm_subdrv_register);

 int exynos_drm_subdrv_unregister(struct exynos_drm_subdrv *subdrv)
 {
+   struct exynos_drm_non_kms_dev *dev;
+
if (!subdrv)
return -EINVAL;

-   list_del(&subdrv->list);
+   mutex_lock(&list_lock);
+   list_for_each_entry(dev, &exynos_drm_subdrv_list, list) {
+   mutex_unlock(&list_lock);
+   if (dev->device_type == subdrv->device_type) {
+   dev->subdrv = NULL;
+   break;
+   }
+   mutex_lock(&list_lock);
+   }
+   mutex_unlock(&list_lock);

return 0;
 }
 EXPORT_SYMBOL_GPL(exynos_drm_subdrv_unregister);

-int exynos_drm_device_subdrv_probe(struct drm_device *dev)
+int exynos_drm_device_subdrv_probe(struct drm_device *drm_dev)
 {
-   struct exynos_drm_subdrv *subdrv, *n;
+   struct exynos_drm_non_kms_dev *dev, *n;
int err;

-   if (!dev)
+   if (!drm_dev)
return -EINVAL;

-   list_for_each_entry_safe(subdrv, n, &exynos_drm_subdrv_list, list) {
+   mutex_lock(&list_lock);
+   if (list_e

[RFC PATCH 3/3] drm/exynos: make vidi driver to be independent module

2014-11-19 Thread Inki Dae
This patch makes vidi driver to be independent module.
For this, it removes register codes to vidi driver
from exynos_drm_drv module and adds module_init/exit
for vidi driver so that this driver can be called
independently.

In addition, this patch adds component support
to vidi driver, which is required for modularity.

Signed-off-by: Inki Dae 
---
 drivers/gpu/drm/exynos/exynos_drm_drv.c  |   12 +
 drivers/gpu/drm/exynos/exynos_drm_drv.h  |9 
 drivers/gpu/drm/exynos/exynos_drm_vidi.c |   81 +++---
 3 files changed, 54 insertions(+), 48 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c 
b/drivers/gpu/drm/exynos/exynos_drm_drv.c
index 7f1186e..3ac39b6 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
@@ -608,19 +608,12 @@ static int exynos_drm_init(void)
if (IS_ERR(exynos_drm_pdev))
return PTR_ERR(exynos_drm_pdev);

-   ret = exynos_drm_probe_vidi();
-   if (ret < 0)
-   goto err_unregister_pd;
-
ret = platform_driver_register(&exynos_drm_platform_driver);
if (ret)
-   goto err_remove_vidi;
+   goto err_unregister_pd;

return 0;

-err_remove_vidi:
-   exynos_drm_remove_vidi();
-
 err_unregister_pd:
platform_device_unregister(exynos_drm_pdev);

@@ -630,9 +623,6 @@ err_unregister_pd:
 static void exynos_drm_exit(void)
 {
platform_driver_unregister(&exynos_drm_platform_driver);
-
-   exynos_drm_remove_vidi();
-
platform_device_unregister(exynos_drm_pdev);
 }

diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.h 
b/drivers/gpu/drm/exynos/exynos_drm_drv.h
index 5b3305c..7c2ba06 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.h
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.h
@@ -310,14 +310,6 @@ exynos_dpi_probe(struct device *dev) { return NULL; }
 static inline int exynos_dpi_remove(struct device *dev) { return 0; }
 #endif

-#ifdef CONFIG_DRM_EXYNOS_VIDI
-int exynos_drm_probe_vidi(void);
-void exynos_drm_remove_vidi(void);
-#else
-static inline int exynos_drm_probe_vidi(void) { return 0; }
-static inline void exynos_drm_remove_vidi(void) {}
-#endif
-
 /* This function creates a encoder and a connector, and initializes them. */
 int exynos_drm_create_enc_conn(struct drm_device *dev,
struct exynos_drm_display *display);
@@ -333,5 +325,4 @@ extern int exynos_drm_non_kms_register(unsigned int 
device_type);
 extern void exynos_drm_non_kms_unregister(unsigned int device_type);

 extern struct platform_driver exynos_drm_common_hdmi_driver;
-extern struct platform_driver vidi_driver;
 #endif
diff --git a/drivers/gpu/drm/exynos/exynos_drm_vidi.c 
b/drivers/gpu/drm/exynos/exynos_drm_vidi.c
index 50faf91..e1153aa 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_vidi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_vidi.c
@@ -14,6 +14,7 @@

 #include 
 #include 
+#include 

 #include 

@@ -48,10 +49,10 @@ struct vidi_win_data {

 struct vidi_context {
struct drm_device   *drm_dev;
+   struct platform_device  *pdev;
struct drm_crtc *crtc;
struct drm_encoder  *encoder;
struct drm_connectorconnector;
-   struct exynos_drm_subdrvsubdrv;
struct vidi_win_datawin_data[WINDOWS_NR];
struct edid *raw_edid;
unsigned intclkdiv;
@@ -561,14 +562,13 @@ static struct exynos_drm_display vidi_display = {
.ops = &vidi_display_ops,
 };

-static int vidi_subdrv_probe(struct drm_device *drm_dev, struct device *dev)
+static int vidi_bind(struct device *dev, struct device *master, void *data)
 {
-   struct exynos_drm_manager *mgr = get_vidi_mgr(dev);
-   struct vidi_context *ctx = mgr->ctx;
-   struct drm_crtc *crtc = ctx->crtc;
+   struct drm_crtc *crtc = vidi_manager.crtc;
+   struct drm_device *drm_dev = data;
int ret;

-   vidi_mgr_initialize(mgr, drm_dev);
+   vidi_mgr_initialize(&vidi_manager, drm_dev);

ret = exynos_drm_crtc_create(&vidi_manager);
if (ret) {
@@ -586,20 +586,42 @@ static int vidi_subdrv_probe(struct drm_device *drm_dev, 
struct device *dev)
return 0;
 }

+static void vidi_unbind(struct device *dev, struct device *master,
+   void *data)
+{
+}
+
+static const struct component_ops vidi_component_ops = {
+   .bind   = vidi_bind,
+   .unbind = vidi_unbind,
+};
+
 static int vidi_probe(struct platform_device *pdev)
 {
-   struct exynos_drm_subdrv *subdrv;
struct vidi_context *ctx;
int ret;

+   ret = exynos_drm_component_add(&pdev->dev, EXYNOS_DEVICE_TYPE_CRTC,
+   vidi_manager.type);
+   if (ret)
+   return ret;
+
+   ret = exynos_drm_component_add(&pdev->dev, EXYNOS_DEVICE_TYPE_CONNECTOR,
+

[Bug 88481] New: Kernel oops leaves system without graphical output [radeon]

2014-11-19 Thread bugzilla-dae...@bugzilla.kernel.org
https://bugzilla.kernel.org/show_bug.cgi?id=88481

Bug ID: 88481
   Summary: Kernel oops leaves system without graphical output
[radeon]
   Product: Drivers
   Version: 2.5
Kernel Version: v3.17.3
  Hardware: x86-64
OS: Linux
  Tree: Mainline
Status: NEW
  Severity: normal
  Priority: P1
 Component: Video(DRI - non Intel)
  Assignee: drivers_video-dri at kernel-bugs.osdl.org
  Reporter: daniel.otero at outlook.com
Regression: No

Created attachment 158101
  --> https://bugzilla.kernel.org/attachment.cgi?id=158101&action=edit
dmesg output

When trying to start the X server through the the login manager, the radeon
module seems to crash leaving the system without graphical output (but
otherwise working). This happens every time as soon as PC boots.

Going back to v3.17.2 fixes the issue.

This seems to be relevant dmesg part:

[2.640374] BUG: unable to handle kernel paging request at ec200900
[2.640419] IP: [] kfree+0x56/0x1a0
[2.640449] PGD 0 
[2.640462] Oops:  [#1] PREEMPT SMP 
[2.640488] Modules linked in: [...]
[2.641120] CPU: 0 PID: 287 Comm: Xorg.bin Not tainted 3.17.3-1-ARCH #1
[2.641152] Hardware name: Gigabyte Technology Co., Ltd. To be filled by
O.E.M./Q77M-D2H, BIOS F2 12/20/2012
[2.641197] task: 8800dc131420 ti: 8800dc168000 task.ti:
8800dc168000
[2.641232] RIP: 0010:[]  []
kfree+0x56/0x1a0
[2.641269] RSP: 0018:8800dc16ba30  EFLAGS: 00010286
[2.641294] RAX: 02200900 RBX: 10024414 RCX:
00010005
[2.641328] RDX: 77ff8000 RSI: 0005 RDI:
10024414
[2.641361] RBP: 8800dc16ba48 R08: 0005 R09:
ec200900
[2.641393] R10: 0010 R11:  R12:
8800dd430800
[2.641426] R13: a0736e8c R14: 000120f0 R15:
1800
[2.641460] FS:  7f3efe93e8c0() GS:88021dc0()
knlGS:
[2.641497] CS:  0010 DS:  ES:  CR0: 80050033
[2.641524] CR2: ec200900 CR3: 00020e2e2000 CR4:
001407f0
[2.641556] Stack:
[2.641567]  8800dd9d4000 8800dd430800 8800dd9d4000
8800dc16bb30
[2.641607]  a0736e8c 004c 000120480001212c
8808
[2.641648]  00012044 0001212c 00012048
00012044
[2.641688] Call Trace:
[2.641721]  [] evergreen_hdmi_setmode+0xd8c/0x1970
[radeon]
[2.641763]  [] ? drm_detect_hdmi_monitor+0x74/0xc0 [drm]
[2.641810]  [] radeon_atom_encoder_mode_set+0x178/0x3c0
[radeon]
[2.641849]  [] drm_crtc_helper_set_mode+0x356/0x530
[drm_kms_helper]
[2.641897]  []
radeon_property_change_mode.isra.1+0x3c/0x40 [radeon]
[2.641943]  [] radeon_connector_set_property+0x1ae/0x3f0
[radeon]
[2.641986]  []
drm_mode_obj_set_property_ioctl+0x1b2/0x3a0 [drm]
[2.642027]  []
drm_mode_connector_property_set_ioctl+0x3f/0x60 [drm]
[2.642069]  [] drm_ioctl+0x1df/0x680 [drm]
[2.642100]  [] ? __do_page_fault+0x2ec/0x600
[2.642134]  [] radeon_drm_ioctl+0x4c/0x80 [radeon]
[2.642166]  [] do_vfs_ioctl+0x2d0/0x4b0
[2.642194]  [] ? __sb_end_write+0x31/0x60
[2.64]  [] SyS_ioctl+0x81/0xa0
[2.642249]  [] system_call_fastpath+0x16/0x1b
[2.642277] Code: 00 00 00 80 ff 77 00 00 49 b9 00 00 00 00 00 ea ff ff 48
01 d8 48 0f 42 15 38 bb 66 00 48 01 d0 48 c1 e8 0c 48 c1 e0 06 49 01 c1 <49> 8b
01 f6 c4 80 0f 85 0e 01 00 00 49 8b 01 a8 80 0f 84 83 00 
[2.644387] RIP  [] kfree+0x56/0x1a0
[2.646397]  RSP 
[2.648359] CR2: ec200900

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


[Bug 86413] Euro Truck Simulator 2: Severe stuttering with Kernel >=3.17

2014-11-19 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=86413

--- Comment #7 from Michel Dänzer  ---
Excellent, so can this report be 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/20141119/10322d24/attachment.html>


[PATCH 1/2] exynos: Don't use DRM_EXYNOS_GEM_{MAP_OFFSET/MMAP} ioctls

2014-11-19 Thread Inki Dae
On 2014년 10월 31일 10:28, Hyungwon Hwang wrote:
> The ioctl DRM_EXYNOS_GEM_MAP_OFFSET and DRM_EXYNOS_GEM_MMAP are removed from
> the linux kernel. This patch modifies libdrm and libkms to use drm generic
> ioctls instead of the removed ioctls.


Signed-off-by: Inki Dae 

> 
> Signed-off-by: Hyungwon Hwang 
> ---
>  exynos/exynos_drm.c | 24 +---
>  libkms/exynos.c |  7 ---
>  2 files changed, 17 insertions(+), 14 deletions(-)
> 
> diff --git a/exynos/exynos_drm.c b/exynos/exynos_drm.c
> index 4c7dd13..4cb6a6d 100644
> --- a/exynos/exynos_drm.c
> +++ b/exynos/exynos_drm.c
> @@ -283,20 +283,22 @@ drm_public void *exynos_bo_map(struct exynos_bo *bo)
>  {
>   if (!bo->vaddr) {
>   struct exynos_device *dev = bo->dev;
> - struct drm_exynos_gem_mmap req = {
> - .handle = bo->handle,
> - .size   = bo->size,
> - };
> + struct drm_mode_map_dumb arg;
> + void *map = NULL;
>   int ret;
>  
> - ret = drmIoctl(dev->fd, DRM_IOCTL_EXYNOS_GEM_MMAP, &req);
> - if (ret) {
> - fprintf(stderr, "failed to mmap[%s].\n",
> - strerror(errno));
> - return NULL;
> - }
> + memset(&arg, 0, sizeof(arg));
> + arg.handle = bo->handle;
> +
> + ret = drmIoctl(dev->fd, DRM_IOCTL_MODE_MAP_DUMB, &arg);
> + if (ret)
> + return ret;
>  
> - bo->vaddr = (void *)(uintptr_t)req.mapped;
> + map = drm_mmap(0, bo->size, PROT_READ | PROT_WRITE, MAP_SHARED,
> + dev->fd, arg.offset);
> +
> + if (map == MAP_FAILED)
> + return NULL;
>   }
>  
>   return bo->vaddr;
> diff --git a/libkms/exynos.c b/libkms/exynos.c
> index 92e329c..1123482 100644
> --- a/libkms/exynos.c
> +++ b/libkms/exynos.c
> @@ -25,6 +25,7 @@
>  #include 
>  #include "xf86drm.h"
>  
> +#include "libdrm.h"
>  #include "exynos_drm.h"
>  
>  struct exynos_bo
> @@ -124,7 +125,7 @@ static int
>  exynos_bo_map(struct kms_bo *_bo, void **out)
>  {
>   struct exynos_bo *bo = (struct exynos_bo *)_bo;
> - struct drm_exynos_gem_map_off arg;
> + struct drm_mode_map_dumb arg;
>   void *map = NULL;
>   int ret;
>  
> @@ -137,11 +138,11 @@ exynos_bo_map(struct kms_bo *_bo, void **out)
>   memset(&arg, 0, sizeof(arg));
>   arg.handle = bo->base.handle;
>  
> - ret = drmCommandWriteRead(bo->base.kms->fd, DRM_EXYNOS_GEM_MAP_OFFSET, 
> &arg, sizeof(arg));
> + ret = drmIoctl(bo->base.kms->fd, DRM_IOCTL_MODE_MAP_DUMB, &arg);
>   if (ret)
>   return ret;
>  
> - map = mmap(0, bo->base.size, PROT_READ | PROT_WRITE, MAP_SHARED, 
> bo->base.kms->fd, arg.offset);
> + map = drm_mmap(0, bo->base.size, PROT_READ | PROT_WRITE, MAP_SHARED, 
> bo->base.kms->fd, arg.offset);
>   if (map == MAP_FAILED)
>   return -errno;
>  
> 



[PATCH 2/2] exynos: remove DRM_EXYNOS_GEM_{MAP_OFFSET/MMAP} ioctls

2014-11-19 Thread Inki Dae
On 2014년 10월 31일 10:28, Hyungwon Hwang wrote:
> This patch removes the ioctls which are removed from the linux kernel.

Signed-off-by: Inki Dae 

> 
> Signed-off-by: Hyungwon Hwang 
> ---
>  exynos/exynos_drm.h | 40 
>  1 file changed, 40 deletions(-)
> 
> diff --git a/exynos/exynos_drm.h b/exynos/exynos_drm.h
> index c3c6579..256c02f 100644
> --- a/exynos/exynos_drm.h
> +++ b/exynos/exynos_drm.h
> @@ -47,38 +47,6 @@ struct drm_exynos_gem_create {
>  };
>  
>  /**
> - * A structure for getting buffer offset.
> - *
> - * @handle: a pointer to gem object created.
> - * @pad: just padding to be 64-bit aligned.
> - * @offset: relatived offset value of the memory region allocated.
> - *   - this value should be set by user.
> - */
> -struct drm_exynos_gem_map_off {
> - unsigned int handle;
> - unsigned int pad;
> - uint64_t offset;
> -};
> -
> -/**
> - * A structure for mapping buffer.
> - *
> - * @handle: a handle to gem object created.
> - * @pad: just padding to be 64-bit aligned.
> - * @size: memory size to be mapped.
> - * @mapped: having user virtual address mmaped.
> - *   - this variable would be filled by exynos gem module
> - *   of kernel side with user virtual address which is allocated
> - *   by do_mmap().
> - */
> -struct drm_exynos_gem_mmap {
> - unsigned int handle;
> - unsigned int pad;
> - uint64_t size;
> - uint64_t mapped;
> -};
> -
> -/**
>   * A structure to gem information.
>   *
>   * @handle: a handle to gem object created.
> @@ -164,8 +132,6 @@ struct drm_exynos_g2d_exec {
>  };
>  
>  #define DRM_EXYNOS_GEM_CREATE0x00
> -#define DRM_EXYNOS_GEM_MAP_OFFSET0x01
> -#define DRM_EXYNOS_GEM_MMAP  0x02
>  /* Reserved 0x04 ~ 0x05 for exynos specific gem ioctl */
>  #define DRM_EXYNOS_GEM_GET   0x04
>  #define DRM_EXYNOS_VIDI_CONNECTION   0x07
> @@ -178,12 +144,6 @@ struct drm_exynos_g2d_exec {
>  #define DRM_IOCTL_EXYNOS_GEM_CREATE  DRM_IOWR(DRM_COMMAND_BASE + \
>   DRM_EXYNOS_GEM_CREATE, struct drm_exynos_gem_create)
>  
> -#define DRM_IOCTL_EXYNOS_GEM_MAP_OFFSET  DRM_IOWR(DRM_COMMAND_BASE + \
> - DRM_EXYNOS_GEM_MAP_OFFSET, struct drm_exynos_gem_map_off)
> -
> -#define DRM_IOCTL_EXYNOS_GEM_MMAPDRM_IOWR(DRM_COMMAND_BASE + \
> - DRM_EXYNOS_GEM_MMAP, struct drm_exynos_gem_mmap)
> -
>  #define DRM_IOCTL_EXYNOS_GEM_GET DRM_IOWR(DRM_COMMAND_BASE + \
>   DRM_EXYNOS_GEM_GET, struct drm_exynos_gem_info)
>  
> 



[PATCH 2/2] drm/exynos: use drm generic mmap interface

2014-11-19 Thread Inki Dae
On 2014년 11월 19일 07:09, Tobias Jakobi wrote:
> Inki Dae wrote:
>> Hi Tomasz,
>>
>> Yes, of course.
>>
>> We will fix it soon. For this, I mentioned earlier,
>> http://web.archiveorange.com/archive/v/hhSc574WhqJAKgdBq7KL
>>
>> Thanks,
>> Inki Dae
> 
> 
> Hello,
> 
> it looks like libdrm git master is still using the EXYNOS_GEM_MMAP ioctl
> that was removed by this patch. Is there any news on the patches for libdrm?

The patch set already was posted. You can refer to below link,
http://www.spinics.net/lists/dri-devel/msg70737.html

Thanks,
Inki Dae

> 
> With best wishes,
> Tobias
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" 
> in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 



[PATCH 2/2] drm/exynos: use drm generic mmap interface

2014-11-19 Thread Tobias Jakobi
Inki Dae wrote:
>>
>> Hello,
>>
>> it looks like libdrm git master is still using the EXYNOS_GEM_MMAP ioctl
>> that was removed by this patch. Is there any news on the patches for libdrm?
> 
> The patch set already was posted. You can refer to below link,
>   http://www.spinics.net/lists/dri-devel/msg70737.html
> 
> Thanks,
> Inki Dae
> 

Looks like I missed that, thanks for the heads up!

With best wishes,
Tobias



[Bug 82186] [r600g] BARTS GPU lockup with minecraft shaders

2014-11-19 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=82186

--- Comment #5 from MWATTT  ---
I've got this bug too.
I've bisected and found that most shaders packs starts to hang at commit
7e414b58640aee6e243d337e72cea290c354f632
"glsl: break the gl_FragData array into separate gl_FragData[i] variables"
However, one of them starts to hang with an earlier commit:
edbbfac6cfc634e697d7f981155a5072c52d77ac
"r600g: fast color clears for single-sample buffers"

This only happens on evergreen+ hardware(tested on JUNIPER and THAMES, works
fine on RV770).

A workaround is to set the environment variable R600_DEBUG=notiling.

This bug also happens in various Unreal Engine 4 demos. (tested on Reflections
Subway Demo, where the hang happens at the beginning). The environment variable
also solves the problem.

-- 
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/20141119/503eb9fe/attachment.html>


[RFC PATCH v2] drm/exynos: make non kms drivers to be indenpendent modules

2014-11-19 Thread Inki Dae
This patch makes non kms drivers to be independent modules.
For this, it removes all register codes to non kms drivers
from exynos_drm_drv module and adds module_init/exit
for each non kms driver so that each non kms driver can be
called independently.

In addition, this patch adds non kms register/unregister functions
to exynos_drm_core module and also modifies existing codes relevant
to sub driver.

The idea is that non kms driver is registered by entry point,
module_init, of each non kms driver and sets its own sub driver
to registered non kms driver object when the sub driver is probed.
For this, this patch adds a new structure, exynos_drm_non_kms_dev,
to exynos_drm_core module.

Changelog v2:
- check if available g2d device node.
- return 0 instead of -EPROBE_DEFER in case of no non kms device
  registered. This case is not error.

Signed-off-by: Inki Dae 
---
 drivers/gpu/drm/exynos/exynos_drm_core.c|  164 +++
 drivers/gpu/drm/exynos/exynos_drm_drv.c |   50 +---
 drivers/gpu/drm/exynos/exynos_drm_drv.h |   28 ++---
 drivers/gpu/drm/exynos/exynos_drm_fimc.c|   13 +++
 drivers/gpu/drm/exynos/exynos_drm_g2d.c |   42 +++
 drivers/gpu/drm/exynos/exynos_drm_gsc.c |   12 ++
 drivers/gpu/drm/exynos/exynos_drm_ipp.c |   39 ++-
 drivers/gpu/drm/exynos/exynos_drm_rotator.c |   13 +++
 8 files changed, 271 insertions(+), 90 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_core.c 
b/drivers/gpu/drm/exynos/exynos_drm_core.c
index 4c9f972..715a0ad 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_core.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_core.c
@@ -19,6 +19,13 @@
 #include "exynos_drm_fbdev.h"

 static LIST_HEAD(exynos_drm_subdrv_list);
+DEFINE_MUTEX(list_lock);
+
+struct exynos_drm_non_kms_dev {
+   struct list_head list;
+   struct exynos_drm_subdrv *subdrv;
+   unsigned int device_type;
+};

 int exynos_drm_create_enc_conn(struct drm_device *dev,
struct exynos_drm_display *display)
@@ -55,12 +62,66 @@ err_destroy_encoder:
return ret;
 }

+int exynos_drm_non_kms_register(unsigned int device_type)
+{
+   struct exynos_drm_non_kms_dev *dev;
+
+   dev = kzalloc(sizeof(*dev), GFP_KERNEL);
+   if (!dev)
+   return -ENOMEM;
+
+   dev->device_type = device_type;
+
+   mutex_lock(&list_lock);
+   list_add_tail(&dev->list, &exynos_drm_subdrv_list);
+   mutex_unlock(&list_lock);
+
+   return 0;
+}
+
+void exynos_drm_non_kms_unregister(unsigned int device_type)
+{
+   struct exynos_drm_non_kms_dev *dev, *next;
+
+   mutex_lock(&list_lock);
+   list_for_each_entry_safe(dev, next, &exynos_drm_subdrv_list, list) {
+   mutex_unlock(&list_lock);
+   if (dev->device_type == device_type) {
+   list_del_init(&dev->list);
+   kfree(dev);
+   mutex_lock(&list_lock);
+   break;
+   }
+   mutex_lock(&list_lock);
+   }
+   mutex_unlock(&list_lock);
+}
+
 int exynos_drm_subdrv_register(struct exynos_drm_subdrv *subdrv)
 {
+   struct exynos_drm_non_kms_dev *dev;
+
if (!subdrv)
return -EINVAL;

-   list_add_tail(&subdrv->list, &exynos_drm_subdrv_list);
+   mutex_lock(&list_lock);
+   if (list_empty(&exynos_drm_subdrv_list)) {
+   mutex_unlock(&list_lock);
+   return -ENODEV;
+   }
+   mutex_unlock(&list_lock);
+
+   mutex_lock(&list_lock);
+   list_for_each_entry(dev, &exynos_drm_subdrv_list, list) {
+   mutex_unlock(&list_lock);
+   if (dev->device_type == subdrv->device_type) {
+   dev->subdrv = subdrv;
+   mutex_lock(&list_lock);
+   break;
+   }
+   mutex_lock(&list_lock);
+   }
+   mutex_unlock(&list_lock);

return 0;
 }
@@ -68,94 +129,149 @@ EXPORT_SYMBOL_GPL(exynos_drm_subdrv_register);

 int exynos_drm_subdrv_unregister(struct exynos_drm_subdrv *subdrv)
 {
+   struct exynos_drm_non_kms_dev *dev;
+
if (!subdrv)
return -EINVAL;

-   list_del(&subdrv->list);
+   mutex_lock(&list_lock);
+   list_for_each_entry(dev, &exynos_drm_subdrv_list, list) {
+   mutex_unlock(&list_lock);
+   if (dev->device_type == subdrv->device_type) {
+   dev->subdrv = NULL;
+   break;
+   }
+   mutex_lock(&list_lock);
+   }
+   mutex_unlock(&list_lock);

return 0;
 }
 EXPORT_SYMBOL_GPL(exynos_drm_subdrv_unregister);

-int exynos_drm_device_subdrv_probe(struct drm_device *dev)
+int exynos_drm_device_subdrv_probe(struct drm_device *drm_dev)
 {
-   struct exynos_drm_subdrv *subdrv, *n;
+   struct exynos_drm_non_kms_dev *dev, *n;
int err;

-   if (!dev)
+   if (!drm_dev)
   

[Bug 88481] Kernel oops leaves system without graphical output [radeon]

2014-11-19 Thread bugzilla-dae...@bugzilla.kernel.org
https://bugzilla.kernel.org/show_bug.cgi?id=88481

Christopher Frömmel  changed:

   What|Removed |Added

 CC||cfroemmel at web.de

--- Comment #1 from Christopher Frömmel  ---
I can confirm this.
My laptop can boot with 3.17.3 with 2 additional monitors connected (DVI +
HDMI) and all 3 screens are working.
But when X is starting, kernel goes OOPS if HDMI is connected. I can reboot via
ssh then.
If HDMI is connected AFTER X has been started, system will enter a hard lockup
state.

Will add my current .config and dmesg part.

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


[Bug 88481] Kernel oops leaves system without graphical output [radeon]

2014-11-19 Thread bugzilla-dae...@bugzilla.kernel.org
https://bugzilla.kernel.org/show_bug.cgi?id=88481

--- Comment #2 from Christopher Frömmel  ---
Created attachment 158131
  --> https://bugzilla.kernel.org/attachment.cgi?id=158131&action=edit
kernel config

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


[Bug 88481] Kernel oops leaves system without graphical output [radeon]

2014-11-19 Thread bugzilla-dae...@bugzilla.kernel.org
https://bugzilla.kernel.org/show_bug.cgi?id=88481

--- Comment #3 from Christopher Frömmel  ---
Created attachment 158141
  --> https://bugzilla.kernel.org/attachment.cgi?id=158141&action=edit
complete dmesg when X starts and HDMI (with audio) is connected, dpm enabled

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


[Bug 88481] Kernel oops leaves system without graphical output [radeon]

2014-11-19 Thread bugzilla-dae...@bugzilla.kernel.org
https://bugzilla.kernel.org/show_bug.cgi?id=88481

--- Comment #4 from Christopher Frömmel  ---
Created attachment 158151
  --> https://bugzilla.kernel.org/attachment.cgi?id=158151&action=edit
lspci -nn

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


[RFC PATCH v2] drm/exynos: make non kms drivers to be indenpendent modules

2014-11-19 Thread YoungJun Cho
Hi Inki,

There are 3 comments below.

On 11/19/2014 12:19 PM, Inki Dae wrote:
> This patch makes non kms drivers to be independent modules.
> For this, it removes all register codes to non kms drivers
> from exynos_drm_drv module and adds module_init/exit
> for each non kms driver so that each non kms driver can be
> called independently.
>
> In addition, this patch adds non kms register/unregister functions
> to exynos_drm_core module and also modifies existing codes relevant
> to sub driver.
>
> The idea is that non kms driver is registered by entry point,
> module_init, of each non kms driver and sets its own sub driver
> to registered non kms driver object when the sub driver is probed.
> For this, this patch adds a new structure, exynos_drm_non_kms_dev,
> to exynos_drm_core module.
>
> Changelog v2:
> - check if available g2d device node.
> - return 0 instead of -EPROBE_DEFER in case of no non kms device
>registered. This case is not error.
>
> Signed-off-by: Inki Dae 
> ---
>   drivers/gpu/drm/exynos/exynos_drm_core.c|  164 
> +++
>   drivers/gpu/drm/exynos/exynos_drm_drv.c |   50 +---
>   drivers/gpu/drm/exynos/exynos_drm_drv.h |   28 ++---
>   drivers/gpu/drm/exynos/exynos_drm_fimc.c|   13 +++
>   drivers/gpu/drm/exynos/exynos_drm_g2d.c |   42 +++
>   drivers/gpu/drm/exynos/exynos_drm_gsc.c |   12 ++
>   drivers/gpu/drm/exynos/exynos_drm_ipp.c |   39 ++-
>   drivers/gpu/drm/exynos/exynos_drm_rotator.c |   13 +++
>   8 files changed, 271 insertions(+), 90 deletions(-)
>
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_core.c 
> b/drivers/gpu/drm/exynos/exynos_drm_core.c
> index 4c9f972..715a0ad 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_core.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_core.c
> @@ -19,6 +19,13 @@
>   #include "exynos_drm_fbdev.h"
>
>   static LIST_HEAD(exynos_drm_subdrv_list);
> +DEFINE_MUTEX(list_lock);
> +
> +struct exynos_drm_non_kms_dev {
> + struct list_head list;
> + struct exynos_drm_subdrv *subdrv;
> + unsigned int device_type;
> +};
>
>   int exynos_drm_create_enc_conn(struct drm_device *dev,
>   struct exynos_drm_display *display)
> @@ -55,12 +62,66 @@ err_destroy_encoder:
>   return ret;
>   }
>
> +int exynos_drm_non_kms_register(unsigned int device_type)
> +{
> + struct exynos_drm_non_kms_dev *dev;
> +
> + dev = kzalloc(sizeof(*dev), GFP_KERNEL);
> + if (!dev)
> + return -ENOMEM;
> +
> + dev->device_type = device_type;
> +
> + mutex_lock(&list_lock);
> + list_add_tail(&dev->list, &exynos_drm_subdrv_list);
> + mutex_unlock(&list_lock);
> +
> + return 0;
> +}
> +
> +void exynos_drm_non_kms_unregister(unsigned int device_type)
> +{
> + struct exynos_drm_non_kms_dev *dev, *next;
> +
> + mutex_lock(&list_lock);
> + list_for_each_entry_safe(dev, next, &exynos_drm_subdrv_list, list) {
> + mutex_unlock(&list_lock);
> + if (dev->device_type == device_type) {
> + list_del_init(&dev->list);
> + kfree(dev);
> + mutex_lock(&list_lock);
> + break;
> + }
> + mutex_lock(&list_lock);
> + }
> + mutex_unlock(&list_lock);
> +}
> +
>   int exynos_drm_subdrv_register(struct exynos_drm_subdrv *subdrv)
>   {
> + struct exynos_drm_non_kms_dev *dev;
> +
>   if (!subdrv)
>   return -EINVAL;
>
> - list_add_tail(&subdrv->list, &exynos_drm_subdrv_list);
> + mutex_lock(&list_lock);
> + if (list_empty(&exynos_drm_subdrv_list)) {
> + mutex_unlock(&list_lock);
> + return -ENODEV;
> + }
> + mutex_unlock(&list_lock);

The list_for_each_entry() could handle empty list, so list_empty() could 
be removed.

> +
> + mutex_lock(&list_lock);
> + list_for_each_entry(dev, &exynos_drm_subdrv_list, list) {
> + mutex_unlock(&list_lock);
> + if (dev->device_type == subdrv->device_type) {
> + dev->subdrv = subdrv;
> + mutex_lock(&list_lock);
> + break;
> + }
> + mutex_lock(&list_lock);
> + }
> + mutex_unlock(&list_lock);
>
>   return 0;
>   }
> @@ -68,94 +129,149 @@ EXPORT_SYMBOL_GPL(exynos_drm_subdrv_register);
>
>   int exynos_drm_subdrv_unregister(struct exynos_drm_subdrv *subdrv)
>   {
> + struct exynos_drm_non_kms_dev *dev;
> +
>   if (!subdrv)
>   return -EINVAL;
>
> - list_del(&subdrv->list);
> + mutex_lock(&list_lock);
> + list_for_each_entry(dev, &exynos_drm_subdrv_list, list) {
> + mutex_unlock(&list_lock);
> + if (dev->device_type == subdrv->device_type) {
> + dev->subdrv = NULL;
> + break;
> + }
> + mutex_lock(&list_lock);
> + }
> + mutex_unlock(&list_lock);
>
>   return 0;
>   

[RFC PATCH v2] drm/exynos: make non kms drivers to be indenpendent modules

2014-11-19 Thread Inki Dae

Hi YoungJun,

On 2014년 11월 19일 13:39, YoungJun Cho wrote:
> Hi Inki,
> 
> There are 3 comments below.
> 
> On 11/19/2014 12:19 PM, Inki Dae wrote:
>> This patch makes non kms drivers to be independent modules.
>> For this, it removes all register codes to non kms drivers
>> from exynos_drm_drv module and adds module_init/exit
>> for each non kms driver so that each non kms driver can be
>> called independently.
>>
>> In addition, this patch adds non kms register/unregister functions
>> to exynos_drm_core module and also modifies existing codes relevant
>> to sub driver.
>>
>> The idea is that non kms driver is registered by entry point,
>> module_init, of each non kms driver and sets its own sub driver
>> to registered non kms driver object when the sub driver is probed.
>> For this, this patch adds a new structure, exynos_drm_non_kms_dev,
>> to exynos_drm_core module.
>>
>> Changelog v2:
>> - check if available g2d device node.
>> - return 0 instead of -EPROBE_DEFER in case of no non kms device
>>registered. This case is not error.
>>
>> Signed-off-by: Inki Dae 
>> ---
>>   drivers/gpu/drm/exynos/exynos_drm_core.c|  164
>> +++
>>   drivers/gpu/drm/exynos/exynos_drm_drv.c |   50 +---
>>   drivers/gpu/drm/exynos/exynos_drm_drv.h |   28 ++---
>>   drivers/gpu/drm/exynos/exynos_drm_fimc.c|   13 +++
>>   drivers/gpu/drm/exynos/exynos_drm_g2d.c |   42 +++
>>   drivers/gpu/drm/exynos/exynos_drm_gsc.c |   12 ++
>>   drivers/gpu/drm/exynos/exynos_drm_ipp.c |   39 ++-
>>   drivers/gpu/drm/exynos/exynos_drm_rotator.c |   13 +++
>>   8 files changed, 271 insertions(+), 90 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_core.c
>> b/drivers/gpu/drm/exynos/exynos_drm_core.c
>> index 4c9f972..715a0ad 100644
>> --- a/drivers/gpu/drm/exynos/exynos_drm_core.c
>> +++ b/drivers/gpu/drm/exynos/exynos_drm_core.c
>> @@ -19,6 +19,13 @@
>>   #include "exynos_drm_fbdev.h"
>>
>>   static LIST_HEAD(exynos_drm_subdrv_list);
>> +DEFINE_MUTEX(list_lock);
>> +
>> +struct exynos_drm_non_kms_dev {
>> +struct list_head list;
>> +struct exynos_drm_subdrv *subdrv;
>> +unsigned int device_type;
>> +};
>>
>>   int exynos_drm_create_enc_conn(struct drm_device *dev,
>>   struct exynos_drm_display *display)
>> @@ -55,12 +62,66 @@ err_destroy_encoder:
>>   return ret;
>>   }
>>
>> +int exynos_drm_non_kms_register(unsigned int device_type)
>> +{
>> +struct exynos_drm_non_kms_dev *dev;
>> +
>> +dev = kzalloc(sizeof(*dev), GFP_KERNEL);
>> +if (!dev)
>> +return -ENOMEM;
>> +
>> +dev->device_type = device_type;
>> +
>> +mutex_lock(&list_lock);
>> +list_add_tail(&dev->list, &exynos_drm_subdrv_list);
>> +mutex_unlock(&list_lock);
>> +
>> +return 0;
>> +}
>> +
>> +void exynos_drm_non_kms_unregister(unsigned int device_type)
>> +{
>> +struct exynos_drm_non_kms_dev *dev, *next;
>> +
>> +mutex_lock(&list_lock);
>> +list_for_each_entry_safe(dev, next, &exynos_drm_subdrv_list, list) {
>> +mutex_unlock(&list_lock);
>> +if (dev->device_type == device_type) {
>> +list_del_init(&dev->list);
>> +kfree(dev);
>> +mutex_lock(&list_lock);
>> +break;
>> +}
>> +mutex_lock(&list_lock);
>> +}
>> +mutex_unlock(&list_lock);
>> +}
>> +
>>   int exynos_drm_subdrv_register(struct exynos_drm_subdrv *subdrv)
>>   {
>> +struct exynos_drm_non_kms_dev *dev;
>> +
>>   if (!subdrv)
>>   return -EINVAL;
>>
>> -list_add_tail(&subdrv->list, &exynos_drm_subdrv_list);
>> +mutex_lock(&list_lock);
>> +if (list_empty(&exynos_drm_subdrv_list)) {
>> +mutex_unlock(&list_lock);
>> +return -ENODEV;
>> +}
>> +mutex_unlock(&list_lock);
> 
> The list_for_each_entry() could handle empty list, so list_empty() could
> be removed.

This is required for some codes for checking which error type should be
returned. So it would  better to just check list_empty.

> 
>> +
>> +mutex_lock(&list_lock);
>> +list_for_each_entry(dev, &exynos_drm_subdrv_list, list) {
>> +mutex_unlock(&list_lock);
>> +if (dev->device_type == subdrv->device_type) {
>> +dev->subdrv = subdrv;
>> +mutex_lock(&list_lock);
>> +break;
>> +}
>> +mutex_lock(&list_lock);
>> +}
>> +mutex_unlock(&list_lock);
>>
>>   return 0;
>>   }
>> @@ -68,94 +129,149 @@ EXPORT_SYMBOL_GPL(exynos_drm_subdrv_register);
>>
>>   int exynos_drm_subdrv_unregister(struct exynos_drm_subdrv *subdrv)
>>   {
>> +struct exynos_drm_non_kms_dev *dev;
>> +
>>   if (!subdrv)
>>   return -EINVAL;
>>
>> -list_del(&subdrv->list);
>> +mutex_lock(&list_lock);
>> +list_for_each_entry(dev, &exynos_drm_subdrv_list, list) {
>> +mutex_unlock(&list_lock);
>> +if (dev->device_type == subdrv->device_type) {
>> +dev->subdrv = NULL;
>>

[Bug 82186] [r600g] BARTS GPU lockup with minecraft shaders

2014-11-19 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=82186

Michel Dänzer  changed:

   What|Removed |Added

 CC||greg at chown.ath.cx

--- Comment #6 from Michel Dänzer  ---
(In reply to MWATTT from comment #5)
> However, one of them starts to hang with an earlier commit:
> edbbfac6cfc634e697d7f981155a5072c52d77ac
> "r600g: fast color clears for single-sample buffers"
> 
> This only happens on evergreen+ hardware(tested on JUNIPER and THAMES, works
> fine on RV770).
> 
> A workaround is to set the environment variable R600_DEBUG=notiling.

Fast clears only work with tiled surfaces, so R600_DEBUG=notiling makes the
commit above ineffective. Adding the author of that commit to CC.

-- 
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/20141119/91ebca96/attachment-0001.html>


[Bug 86267] [drm:evergreen_resume] *ERROR* evergreen startup failed on resume

2014-11-19 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=86267

--- Comment #4 from Michel Dänzer  ---
(In reply to jbart from comment #3)
> As for bisection I can definitely give it a shot, but it's pointless until I
> can reproduce the issue at will...

Not really, if you can get a feeling for how many times you need to test before
you can be confident that the problem is not present.

Anyway, were you using older kernels before where the problem never occurred?
What was the newest kernel where that was the case?

-- 
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/20141119/aeb8125d/attachment.html>


Long radeon stalls on recent kernels

2014-11-19 Thread Michel Dänzer
On 19.11.2014 09:21, Andy Lutomirski wrote:
> On Mon, Nov 17, 2014 at 1:51 AM, Michel Dänzer  wrote:
>> On 15.11.2014 07:21, Andy Lutomirski wrote:
>>>
>>> On recent kernels (3.16 through 3.18-rc4, perhaps), doing anything
>>> graphics intensive seems to cause my system to become unusable for
>>> tens of seconds.  Pointing Firefox at Google Maps is a big offender --
>>> it can take several minutes for me to move my mouse far enough to
>>> close the tab and get my computer back.
>>>
>>> On bootup, I get this warning:
>>> [drm:btc_dpm_set_power_state] *ERROR*
>>> rv770_restrict_performance_levels_before_switch failed
>>>
>>> Setting radeon.dpm=0 seems to work around this problem at the cost of
>>> giving my rather slow graphics.
>>>
>>> Are there known issues here?
>>
>>
>> Can you bisect the kernel, or at least isolate which kernel version first
>> introduced the problem?
>
> With whatever userspace I'm running, I'm seeing it 3.13, 3.14, 3.15,
> 3.16, and 3.18-rc4+.  I haven't tried other versions.
>
> With radeon.dpm=0, I can still trigger short stalls (around one
> second), but I seem unable to trigger long stalls easily.  (I say
> easily because, just as I was typing this email, my system stalled for
> about a minute.)

I can only think of two things offhand that could cause such extremely 
long stalls: Swap thrashing or IRQ storms.

With a setup where you can easily trigger long stalls, can you try 
getting a CPU profile for a stall with sysprof or perf?


-- 
Earthling Michel Dänzer   |   http://www.amd.com
Libre software enthusiast | Mesa and X developer


[Bug 88481] Kernel oops leaves system without graphical output [radeon]

2014-11-19 Thread bugzilla-dae...@bugzilla.kernel.org
https://bugzilla.kernel.org/show_bug.cgi?id=88481

--- Comment #5 from Michel Dänzer  ---
Does reverting commit ffe0245532b98efc4bc0e06f29c51d3f0e471152 help? If not,
can you bisect?

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


3.18-rc regression: drm/nouveau: use shared fences for readable objects

2014-11-19 Thread Maarten Lankhorst
Hey,

On 19-11-14 07:43, Michael Marineau wrote:
> On 3.18-rc kernel's I have been intermittently experiencing GPU
> lockups shortly after startup, accompanied with one or both of the
> following errors:
> 
> nouveau E[   PFIFO][:01:00.0] read fault at 0x000734a000 [PTE]
> from PBDMA0/HOST_CPU on channel 0x007faa3000 [unknown]
> nouveau E[ DRM] GPU lockup - switching to software fbcon
> 
> I was able to trace the issue with bisect to commit
> 809e9447b92ffe1346b2d6ec390e212d5307f61c "drm/nouveau: use shared
> fences for readable objects". The lockups appear to have cleared up
> since reverting that and a few related followup commits:
> 
> 809e9447: "drm/nouveau: use shared fences for readable objects"
> 055dffdf: "drm/nouveau: bump driver patchlevel to 1.2.1"
> e3be4c23: "drm/nouveau: specify if interruptible wait is desired in
> nouveau_fence_sync"
> 15a996bb: "drm/nouveau: assign fence_chan->name correctly"

Weird. I'm not sure yet what causes it.

http://cgit.freedesktop.org/~mlankhorst/linux/commit/?h=fixed-fences-for-bisect&id=86be4f216bbb9ea3339843a5658d4c21162c7ee2

On the EDITED patch from fixed-fences-for-bisect, can you do the following:

In nouveau/nv84_fence.c function nv84_fence_context_new, remove

fctx->base.sequence = nv84_fence_read(chan);

and add back

nouveau_bo_wr32(priv->bo, chan->chid * 16/4, 0x);

If that fails you should compile your kernel with trace events, to get some 
debugging info from the fences. I'll post debugging info if this does not fix 
it.

~Maarten


[RFC PATCH 1/3] drm/exynos: make kms drivers to be independent modules

2014-11-19 Thread Andrzej Hajda
On 11/18/2014 04:26 PM, Inki Dae wrote:
> This patch makes kms drivers to be independent modules.
> For this, it removes all register codes to kms drivers
> from exynos_drm_drv module and adds module_init/exit
> for each kms driver so that each kms driver can be
> called independently.


It is hard to test if modules are working because I am not able to build
modules :), see comments below.


> 
> Signed-off-by: Inki Dae 
> ---
>  drivers/gpu/drm/exynos/Kconfig   |8 +++---
>  drivers/gpu/drm/exynos/exynos_dp_core.c  |   13 +
>  drivers/gpu/drm/exynos/exynos_drm_drv.c  |   43 
> +++---
>  drivers/gpu/drm/exynos/exynos_drm_drv.h  |5 
>  drivers/gpu/drm/exynos/exynos_drm_dsi.c  |   13 +
>  drivers/gpu/drm/exynos/exynos_drm_fimd.c |   13 +
>  drivers/gpu/drm/exynos/exynos_hdmi.c |   13 +
>  drivers/gpu/drm/exynos/exynos_mixer.c|   13 +
>  8 files changed, 72 insertions(+), 49 deletions(-)
> 
> diff --git a/drivers/gpu/drm/exynos/Kconfig b/drivers/gpu/drm/exynos/Kconfig
> index 7f9f6f9..3d5fa69 100644
> --- a/drivers/gpu/drm/exynos/Kconfig
> +++ b/drivers/gpu/drm/exynos/Kconfig
> @@ -25,7 +25,7 @@ config DRM_EXYNOS_DMABUF
> Choose this option if you want to use DMABUF feature for DRM.
>  
>  config DRM_EXYNOS_FIMD
> - bool "Exynos DRM FIMD"
> + tristate "Exynos DRM FIMD"
>   depends on DRM_EXYNOS && !FB_S3C
>   select FB_MODE_HELPERS
>   select MFD_SYSCON
> @@ -41,7 +41,7 @@ config DRM_EXYNOS_DPI
> This enables support for Exynos parallel output.
>  
>  config DRM_EXYNOS_DSI
> - bool "EXYNOS DRM MIPI-DSI driver support"
> + tristate "EXYNOS DRM MIPI-DSI driver support"
>   depends on DRM_EXYNOS_FIMD
>   select DRM_MIPI_DSI
>   select DRM_PANEL
> @@ -50,7 +50,7 @@ config DRM_EXYNOS_DSI
> This enables support for Exynos MIPI-DSI device.
>  
>  config DRM_EXYNOS_DP
> - bool "EXYNOS DRM DP driver support"
> + tristate "EXYNOS DRM DP driver support"
>   depends on DRM_EXYNOS_FIMD && ARCH_EXYNOS && (DRM_PTN3460=n || 
> DRM_PTN3460=y || DRM_PTN3460=DRM_EXYNOS)
>   default DRM_EXYNOS
>   select DRM_PANEL
> @@ -58,7 +58,7 @@ config DRM_EXYNOS_DP
> This enables support for DP device.
>  
>  config DRM_EXYNOS_HDMI
> - bool "Exynos DRM HDMI"
> + tristate "Exynos DRM HDMI"
>   depends on DRM_EXYNOS && !VIDEO_SAMSUNG_S5P_TV
>   help
> Choose this option if you want to use Exynos HDMI for DRM.


Without corresponding changes in Makefiles you cannot build it as modules.


> diff --git a/drivers/gpu/drm/exynos/exynos_dp_core.c 
> b/drivers/gpu/drm/exynos/exynos_dp_core.c
> index ed818b9..b08d97b 100644
> --- a/drivers/gpu/drm/exynos/exynos_dp_core.c
> +++ b/drivers/gpu/drm/exynos/exynos_dp_core.c
> @@ -1408,6 +1408,19 @@ struct platform_driver dp_driver = {
>   },
>  };
>  
> +static int exynos_dp_init(void)
> +{
> + return platform_driver_register(&dp_driver);
> +}
> +
> +static void exynos_dp_exit(void)
> +{
> + platform_driver_unregister(&dp_driver);
> +}
> +
> +module_init(exynos_dp_init);
> +module_exit(exynos_dp_exit);
> +

Here and in other modules you can use module_platform_driver macro.

>  MODULE_AUTHOR("Jingoo Han ");
>  MODULE_DESCRIPTION("Samsung SoC DP Driver");
>  MODULE_LICENSE("GPL v2");
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c 
> b/drivers/gpu/drm/exynos/exynos_drm_drv.c
> index eab12f0..02d4772 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
> @@ -484,12 +484,6 @@ static struct component_match 
> *exynos_drm_match_add(struct device *dev)
>  
>   mutex_lock(&drm_component_lock);
>  
> - /* Do not retry to probe if there is no any kms driver regitered. */
> - if (list_empty(&drm_component_list)) {
> - mutex_unlock(&drm_component_lock);
> - return ERR_PTR(-ENODEV);
> - }
> -

It is hard to guess how and why it should work with modules.
For example what should happen if fimd/dsi modules are loaded but
hdmi/mixer not. When exynos_drv should wait with initialization for hdmi
and when it should create drmdev.

DRM system is rather monolithic splitting its components to modules
seems strange.

Regards
Andrzej

>   list_for_each_entry(cdev, &drm_component_list, list) {
>   /*
>* Add components to master only in case that crtc and
> @@ -545,22 +539,6 @@ static const struct component_master_ops exynos_drm_ops 
> = {
>   .unbind = exynos_drm_unbind,
>  };
>  
> -static struct platform_driver *const exynos_drm_kms_drivers[] = {
> -#ifdef CONFIG_DRM_EXYNOS_FIMD
> - &fimd_driver,
> -#endif
> -#ifdef CONFIG_DRM_EXYNOS_DP
> - &dp_driver,
> -#endif
> -#ifdef CONFIG_DRM_EXYNOS_DSI
> - &dsi_driver,
> -#endif
> -#ifdef CONFIG_DRM_EXYNOS_HDMI
> - &mixer_driver,
> - &hdmi_driver,
> -#endif
> -};
> -
>  static struct platform_driver *const exynos

[PATCH 2/2] drm/panel: Add support for Giantplus GPG482739QS5 panel

2014-11-19 Thread Lucas Stach
From: Philipp Zabel 

This patch adds support for the GiantPlus GPG48273QS5 4.3" WQVGA TFT LCD panel
to the simple-panel driver.

This panel is connected via a parallel bus and uses both HSYNC and VSYNC,
whose lengths are unfortunately not clearly defined. The datasheet only
specifies the front- and backporch length, but the timing diagram suggests
that both sync signals should be asserted for exactly one clock cycle.

Signed-off-by: Philipp Zabel 
Signed-off-by: Lucas Stach 
---
[lst]: rebased on top of drm/panel/for-next + added commit message
---
 .../bindings/panel/giantplus,gpg482739qs5.txt  |  7 ++
 drivers/gpu/drm/panel/panel-simple.c   | 26 ++
 2 files changed, 33 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/panel/giantplus,gpg482739qs5.txt

diff --git a/Documentation/devicetree/bindings/panel/giantplus,gpg482739qs5.txt 
b/Documentation/devicetree/bindings/panel/giantplus,gpg482739qs5.txt
new file mode 100644
index ..24b0b624434b
--- /dev/null
+++ b/Documentation/devicetree/bindings/panel/giantplus,gpg482739qs5.txt
@@ -0,0 +1,7 @@
+GiantPlus GPG48273QS5 4.3" (480x272) WQVGA TFT LCD panel
+
+Required properties:
+- compatible: should be "giantplus,gpg48273qs5"
+
+This binding is compatible with the simple-panel binding, which is specified
+in simple-panel.txt in this directory.
diff --git a/drivers/gpu/drm/panel/panel-simple.c 
b/drivers/gpu/drm/panel/panel-simple.c
index c4b6167a8bf3..1d8ed2062841 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -560,6 +560,29 @@ static const struct panel_desc foxlink_fl500wvr00_a0t = {
},
 };

+static const struct drm_display_mode giantplus_gpg482739qs5_mode = {
+   .clock = 9000,
+   .hdisplay = 480,
+   .hsync_start = 480 + 5,
+   .hsync_end = 480 + 5 + 1,
+   .htotal = 480 + 5 + 1 + 40,
+   .vdisplay = 272,
+   .vsync_start = 272 + 8,
+   .vsync_end = 272 + 8 + 1,
+   .vtotal = 272 + 8 + 1 + 8,
+   .vrefresh = 60,
+};
+
+static const struct panel_desc giantplus_gpg482739qs5 = {
+   .modes = &giantplus_gpg482739qs5_mode,
+   .num_modes = 1,
+   .bpc = 8,
+   .size = {
+   .width = 95,
+   .height = 54,
+   },
+};
+
 static const struct drm_display_mode hannstar_hsd070pww1_mode = {
.clock = 71100,
.hdisplay = 1280,
@@ -757,6 +780,9 @@ static const struct of_device_id platform_of_match[] = {
.compatible = "foxlink,fl500wvr00-a0t",
.data = &foxlink_fl500wvr00_a0t,
}, {
+   .compatible = "giantplus,gpg482739qs5",
+   .data = &giantplus_gpg482739qs5
+   }, {
.compatible = "hannstar,hsd070pww1",
.data = &hannstar_hsd070pww1,
}, {
-- 
2.1.1



[PATCH 1/2] of: Add vendor prefix for Giantplus Technology Co., Ltd.

2014-11-19 Thread Lucas Stach
From: Philipp Zabel 

Signed-off-by: Philipp Zabel 
Signed-off-by: Lucas Stach 
---
 Documentation/devicetree/bindings/vendor-prefixes.txt | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt 
b/Documentation/devicetree/bindings/vendor-prefixes.txt
index 0b2fc732f1f3..c678ee63e91c 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.txt
+++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
@@ -59,6 +59,7 @@ fsl   Freescale Semiconductor
 GEFanucGE Fanuc Intelligent Platforms Embedded Systems, Inc.
 gefGE Fanuc Intelligent Platforms Embedded Systems, Inc.
 geniatech  Geniatech, Inc.
+giantplus  Giantplus Technology Co., Ltd.
 globalscaleGlobalscale Technologies, Inc.
 gmtGlobal Mixed-mode Technology, Inc.
 google Google, Inc.
-- 
2.1.1



[PATCH V8 00/14] drm/exynos: few patches to enhance bridge chip support

2014-11-19 Thread Ajay kumar
Hi Javier,

In the cover letter, I have mentioned that it is tested on Linus tree:

"This series is based on master branch of Linus tree at:
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git"

Kindly test the patches with that.

Ajay

On Wed, Nov 19, 2014 at 3:05 PM, Javier Martinez Canillas
 wrote:
> Hello Ajay,
>
> On 11/18/2014 07:20 AM, Ajay kumar wrote:
>> On Sat, Nov 15, 2014 at 3:24 PM, Ajay Kumar  
>> wrote:
>>> This series is based on master branch of Linus tree at:
>>> git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
>
> I applied your series on top of 3.18-rc5 + linux-next's commit:
>
> 0ef76ae ("ARM: exynos_defconfig: Enable options for display panel support").
>
> I think you should had mentioned what other patches are needed as a
> dependency since I spent quite a bit of time figuring out why the
> ps8622 bridge driver probe was always deferred due of_drm_find_panel()
> failing and then I noticed that a patch from linux-next was needed:
>
> e35e305 ("drm/panel: simple: Add AUO B116XW03 panel support")
>
> With that commit the ps8622 drm bridge driver probe succeed but I still
> don't have display working on an Exynos5240 Peach Pit, the kernel log shows:
>
> platform 145b.dp-controller: Driver exynos-dp requests probe deferral
> exynos-drm exynos-drm: bound 1440.fimd (ops fimd_component_ops)
> exynos-drm exynos-drm: failed to bind 145b.dp-controller (ops 
> exynos_dp_ops): -517
> exynos-drm exynos-drm: master bind failed: -517
> platform 145b.dp-controller: Driver exynos-dp requests probe deferral
>
> Any idea what else I could be missing here?
>
> Your patches don't apply cleanly in linux-next btw, although the are many
> issues with the Exynos DRM currently in linux-next anyways so probably using
> 3.18-rc as a base makes more sense for now until all those things get fixed
> but you should rebase so they can be picked.
>
> Best regards,
> Javier


[PATCH v12 1/3] drm: rockchip: Add basic drm driver

2014-11-19 Thread Boris Brezillon
On Wed, 19 Nov 2014 10:02:53 +0800
Mark yao  wrote:

> On 2014年11月19日 09:09, Mark yao wrote:
> > On 2014年11月18日 22:24, Daniel Vetter wrote:
> >> On Tue, Nov 18, 2014 at 02:21:30PM +0100, Boris Brezillon wrote:
> >>> Hi Daniel,
> >>>
> >>> On Tue, 18 Nov 2014 09:32:34 +0100
> >>> Daniel Vetter  wrote:
> >>>
>  On Tue, Nov 18, 2014 at 04:00:29PM +0800, Mark Yao wrote:
> > From: Mark yao 
> >
> > This patch adds the basic structure of a DRM Driver for Rockchip 
> > Socs.
> >
> > Signed-off-by: Mark Yao 
> > Signed-off-by: Daniel Kurtz 
> > Acked-by: Daniel Vetter 
> > Reviewed-by: Rob Clark 
> > ---
> > Changes in v2:
> > - use the component framework to defer main drm driver probe
> >until all VOP devices have been probed.
> > - use dma-mapping API with ARM_DMA_USE_IOMMU, create dma mapping by
> >master device and each vop device can shared the drm dma mapping.
> > - use drm_crtc_init_with_planes and drm_universal_plane_init.
> > - remove unnecessary middle layers.
> > - add cursor set, move funcs to rockchip drm crtc.
> > - use vop reset at first init
> > - reference framebuffer when used and unreference when swap out vop
> >
> > Changes in v3:
> > - change "crtc->fb" to "crtc->primary-fb"
> > Adviced by Daniel Vetter
> > - init cursor plane with universal api, remove unnecessary cursor 
> > set,move
> >
> > Changes in v4:
> > Adviced by David Herrmann
> > - remove drm_platform_*() usage, use register drm device directly.
>  Minor fixup for that part below.
> 
>  [snip]
> 
> > +static int rockchip_drm_bind(struct device *dev)
> > +{
> > +struct drm_device *drm;
> > +int ret;
> > +
> > +drm = drm_dev_alloc(&rockchip_drm_driver, dev);
> > +if (!drm)
> > +return -ENOMEM;
> > +
> > +ret = drm_dev_set_unique(drm, "%s", dev_name(dev));
> > +if (ret)
> > +goto err_free;
>  Please call rockchip_drm_load here directly and don't put it as the 
>  ->load
>  function into the driver vtable. The point of the alloc/register 
>  split is
>  that the driver can be completely set up _before_ we register 
>  anything.
>  But for backwards compat and historical reasons ->load is called 
>  somewhere
>  in the middle (so that you could access the minor nodes if needed, 
>  since
>  some drivers do that).
> >>> I tried to do the same in the atmel-hlcdc DRM driver, but I need the
> >>> primary drm_minor to register the connectors (see this kernel
> >>> backtrace [1]), which means I either initialize the connector in the
> >>> wrong place (currently part of the drm load process), or I just can't
> >>> call atmel_hlcdc_dc_load before registering the drm device...
> >> Hm right, wonder who that works with rockchip tbh.
> >>
> >> We did split up the drm_connector setup into _init and register, so 
> >> if you
> >> want to do this then you need to move the call to drm_connector_register
> >> below the call to drm_dev_register.
> >>
> >> We should probably have a drm_connectors_register_all helper which does
> >> this for all connectors on the connector list. And also grabs the
> >> appropriate lock.
> >>
> >> I guess it's somewhat obvious that no one yet actually tried this ;-)
> >> -Daniel
> > right, I re-test the driver with it, get the same problem with Boris.
> > I should move drm_connector_register below the drm_dev_register.
> I try move connector_register below drm_dev_register, but unfortunately, 
> drm_dev_register call
> drm_mode_group_init_legacy_group to save crtc, connector into list, it 
> need below  connector_register.
> so that problem is that now: connector_register need bewteen minor node 
> create and
> drm_mode_group_init_legacy_group.

AFAIU, the suggestion was to split drm_connector_init and
drm_connector_register calls:
 - drm_connector_init call should still be part of the load procedure
   (this function adds the connector to the connector list which is used
   by drm_mode_group_init_legacy_group)
 - drm_connector_register should be called after the device has been
   registered

Here what I've done and it seems to work:

static int atmel_hlcdc_dc_connector_plug_all(struct drm_device *dev)
{
struct drm_connector *connector, *failed;
int ret;

mutex_lock(&dev->mode_config.mutex);
list_for_each_entry(connector,
&dev->mode_config.connector_list, head) { ret =
drm_connector_register(connector); if (ret) {
failed = connector;
goto err;
}
}
mutex_unlock(&dev->mode_config.mutex);
return 0;

err:
list_for_each_entry(connector, &dev->mode_config.connector_list, head) {
if (failed == connector)
break;

drm_connector_unregister(connecto

[RFC PATCH 1/1] drm/exynos: Move platform drivers registration to module init

2014-11-19 Thread Javier Martinez Canillas
Hello Kevin,

On 11/18/2014 11:46 PM, Kevin Hilman wrote:
>>> Is anyone at Samsung testing linux-next?  If so, on what platforms?  It
>>> would really be nice if your linux-next work was tested on these
>>> publically-available 542x/5800 platforms (peach-pi, peach-pit,
>>> odroid-xu3) which would also allow lots of others to help you test and
>>> validate.
>>
>> It would also be good to add drm-exynos-next to the daily linux-next build.
>> Currently drm-exynos-next is ahead of linux-next. This patch from Javier for
>> example only applies on linux-next.
> 
> Which tree is the drm-exynos-next branch in?
> 

It is in Inki Dae's drm-exynos tree:

git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos.git

Best regards,
Javier



[PATCH V8 00/14] drm/exynos: few patches to enhance bridge chip support

2014-11-19 Thread Javier Martinez Canillas
Hello Paolo,

On 11/19/2014 11:55 AM, Paolo Pisati wrote:
> to get a working framebuffer out of linus 318rc4 on my peach pi, i had
> to cherry pick these 3 patches:
> 
> arm: dts: Exynos5: Use pmu_system_controller phandle for dp phy

I was missing this patch, I've display working now. Thanks for the pointer!

If someone else is interested, I've pushed a branch [0] with 3.18-rc5 + all
the needed patches.

Ajay, feel free to add to your series:

Tested-by: Javier Martinez Canillas 

Best regards,
Javier

[0]: git://git.collabora.co.uk/git/user/javier/linux.git wip/exynos/dp-integ


[PATCH v12 1/3] drm: rockchip: Add basic drm driver

2014-11-19 Thread Mark yao
On 2014年11月18日 22:24, Daniel Vetter wrote:
> On Tue, Nov 18, 2014 at 02:21:30PM +0100, Boris Brezillon wrote:
>> Hi Daniel,
>>
>> On Tue, 18 Nov 2014 09:32:34 +0100
>> Daniel Vetter  wrote:
>>
>>> On Tue, Nov 18, 2014 at 04:00:29PM +0800, Mark Yao wrote:
 From: Mark yao 

 This patch adds the basic structure of a DRM Driver for Rockchip Socs.

 Signed-off-by: Mark Yao 
 Signed-off-by: Daniel Kurtz 
 Acked-by: Daniel Vetter 
 Reviewed-by: Rob Clark 
 ---
 Changes in v2:
 - use the component framework to defer main drm driver probe
until all VOP devices have been probed.
 - use dma-mapping API with ARM_DMA_USE_IOMMU, create dma mapping by
master device and each vop device can shared the drm dma mapping.
 - use drm_crtc_init_with_planes and drm_universal_plane_init.
 - remove unnecessary middle layers.
 - add cursor set, move funcs to rockchip drm crtc.
 - use vop reset at first init
 - reference framebuffer when used and unreference when swap out vop

 Changes in v3:
 - change "crtc->fb" to "crtc->primary-fb"
 Adviced by Daniel Vetter
 - init cursor plane with universal api, remove unnecessary cursor set,move

 Changes in v4:
 Adviced by David Herrmann
 - remove drm_platform_*() usage, use register drm device directly.
>>> Minor fixup for that part below.
>>>
>>> [snip]
>>>
 +static int rockchip_drm_bind(struct device *dev)
 +{
 +  struct drm_device *drm;
 +  int ret;
 +
 +  drm = drm_dev_alloc(&rockchip_drm_driver, dev);
 +  if (!drm)
 +  return -ENOMEM;
 +
 +  ret = drm_dev_set_unique(drm, "%s", dev_name(dev));
 +  if (ret)
 +  goto err_free;
>>> Please call rockchip_drm_load here directly and don't put it as the ->load
>>> function into the driver vtable. The point of the alloc/register split is
>>> that the driver can be completely set up _before_ we register anything.
>>> But for backwards compat and historical reasons ->load is called somewhere
>>> in the middle (so that you could access the minor nodes if needed, since
>>> some drivers do that).
>> I tried to do the same in the atmel-hlcdc DRM driver, but I need the
>> primary drm_minor to register the connectors (see this kernel
>> backtrace [1]), which means I either initialize the connector in the
>> wrong place (currently part of the drm load process), or I just can't
>> call atmel_hlcdc_dc_load before registering the drm device...
> Hm right, wonder who that works with rockchip tbh.
>
> We did split up the drm_connector setup into _init and register, so if you
> want to do this then you need to move the call to drm_connector_register
> below the call to drm_dev_register.
>
> We should probably have a drm_connectors_register_all helper which does
> this for all connectors on the connector list. And also grabs the
> appropriate lock.
>
> I guess it's somewhat obvious that no one yet actually tried this ;-)
> -Daniel
right, I re-test the driver with it, get the same problem with Boris.
I should move drm_connector_register below the drm_dev_register.



[PATCH v12 1/3] drm: rockchip: Add basic drm driver

2014-11-19 Thread Mark yao
On 2014年11月19日 09:09, Mark yao wrote:
> On 2014年11月18日 22:24, Daniel Vetter wrote:
>> On Tue, Nov 18, 2014 at 02:21:30PM +0100, Boris Brezillon wrote:
>>> Hi Daniel,
>>>
>>> On Tue, 18 Nov 2014 09:32:34 +0100
>>> Daniel Vetter  wrote:
>>>
>>>> On Tue, Nov 18, 2014 at 04:00:29PM +0800, Mark Yao wrote:
>>>>> From: Mark yao 
>>>>>
>>>>> This patch adds the basic structure of a DRM Driver for Rockchip 
>>>>> Socs.
>>>>>
>>>>> Signed-off-by: Mark Yao 
>>>>> Signed-off-by: Daniel Kurtz 
>>>>> Acked-by: Daniel Vetter 
>>>>> Reviewed-by: Rob Clark 
>>>>> ---
>>>>> Changes in v2:
>>>>> - use the component framework to defer main drm driver probe
>>>>>until all VOP devices have been probed.
>>>>> - use dma-mapping API with ARM_DMA_USE_IOMMU, create dma mapping by
>>>>>master device and each vop device can shared the drm dma mapping.
>>>>> - use drm_crtc_init_with_planes and drm_universal_plane_init.
>>>>> - remove unnecessary middle layers.
>>>>> - add cursor set, move funcs to rockchip drm crtc.
>>>>> - use vop reset at first init
>>>>> - reference framebuffer when used and unreference when swap out vop
>>>>>
>>>>> Changes in v3:
>>>>> - change "crtc->fb" to "crtc->primary-fb"
>>>>> Adviced by Daniel Vetter
>>>>> - init cursor plane with universal api, remove unnecessary cursor 
>>>>> set,move
>>>>>
>>>>> Changes in v4:
>>>>> Adviced by David Herrmann
>>>>> - remove drm_platform_*() usage, use register drm device directly.
>>>> Minor fixup for that part below.
>>>>
>>>> [snip]
>>>>
>>>>> +static int rockchip_drm_bind(struct device *dev)
>>>>> +{
>>>>> +struct drm_device *drm;
>>>>> +int ret;
>>>>> +
>>>>> +drm = drm_dev_alloc(&rockchip_drm_driver, dev);
>>>>> +if (!drm)
>>>>> +return -ENOMEM;
>>>>> +
>>>>> +ret = drm_dev_set_unique(drm, "%s", dev_name(dev));
>>>>> +if (ret)
>>>>> +goto err_free;
>>>> Please call rockchip_drm_load here directly and don't put it as the 
>>>> ->load
>>>> function into the driver vtable. The point of the alloc/register 
>>>> split is
>>>> that the driver can be completely set up _before_ we register 
>>>> anything.
>>>> But for backwards compat and historical reasons ->load is called 
>>>> somewhere
>>>> in the middle (so that you could access the minor nodes if needed, 
>>>> since
>>>> some drivers do that).
>>> I tried to do the same in the atmel-hlcdc DRM driver, but I need the
>>> primary drm_minor to register the connectors (see this kernel
>>> backtrace [1]), which means I either initialize the connector in the
>>> wrong place (currently part of the drm load process), or I just can't
>>> call atmel_hlcdc_dc_load before registering the drm device...
>> Hm right, wonder who that works with rockchip tbh.
>>
>> We did split up the drm_connector setup into _init and register, so 
>> if you
>> want to do this then you need to move the call to drm_connector_register
>> below the call to drm_dev_register.
>>
>> We should probably have a drm_connectors_register_all helper which does
>> this for all connectors on the connector list. And also grabs the
>> appropriate lock.
>>
>> I guess it's somewhat obvious that no one yet actually tried this ;-)
>> -Daniel
> right, I re-test the driver with it, get the same problem with Boris.
> I should move drm_connector_register below the drm_dev_register.
I try move connector_register below drm_dev_register, but unfortunately, 
drm_dev_register call
drm_mode_group_init_legacy_group to save crtc, connector into list, it 
need below  connector_register.
so that problem is that now: connector_register need bewteen minor node 
create and
drm_mode_group_init_legacy_group.
I'm consider to revert the drm/rockchip v13.

-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141119/33a93ad0/attachment.html>


[PATCH V8 00/14] drm/exynos: few patches to enhance bridge chip support

2014-11-19 Thread Javier Martinez Canillas
Hello Ajay,

On 11/18/2014 07:20 AM, Ajay kumar wrote:
> On Sat, Nov 15, 2014 at 3:24 PM, Ajay Kumar  
> wrote:
>> This series is based on master branch of Linus tree at:
>> git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git

I applied your series on top of 3.18-rc5 + linux-next's commit:

0ef76ae ("ARM: exynos_defconfig: Enable options for display panel support").

I think you should had mentioned what other patches are needed as a
dependency since I spent quite a bit of time figuring out why the
ps8622 bridge driver probe was always deferred due of_drm_find_panel()
failing and then I noticed that a patch from linux-next was needed:

e35e305 ("drm/panel: simple: Add AUO B116XW03 panel support")

With that commit the ps8622 drm bridge driver probe succeed but I still
don't have display working on an Exynos5240 Peach Pit, the kernel log shows:

platform 145b.dp-controller: Driver exynos-dp requests probe deferral
exynos-drm exynos-drm: bound 1440.fimd (ops fimd_component_ops)
exynos-drm exynos-drm: failed to bind 145b.dp-controller (ops 
exynos_dp_ops): -517
exynos-drm exynos-drm: master bind failed: -517
platform 145b.dp-controller: Driver exynos-dp requests probe deferral

Any idea what else I could be missing here?

Your patches don't apply cleanly in linux-next btw, although the are many
issues with the Exynos DRM currently in linux-next anyways so probably using
3.18-rc as a base makes more sense for now until all those things get fixed
but you should rebase so they can be picked.

Best regards,
Javier


[PATCH V8 00/14] drm/exynos: few patches to enhance bridge chip support

2014-11-19 Thread Paolo Pisati
On Wed, Nov 19, 2014 at 10:35:40AM +0100, Javier Martinez Canillas wrote:
> Hello Ajay,
> 
> On 11/18/2014 07:20 AM, Ajay kumar wrote:
> > On Sat, Nov 15, 2014 at 3:24 PM, Ajay Kumar  
> > wrote:
> >> This series is based on master branch of Linus tree at:
> >> git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
> 
> I applied your series on top of 3.18-rc5 + linux-next's commit:
> 
> 0ef76ae ("ARM: exynos_defconfig: Enable options for display panel support").
> 
> I think you should had mentioned what other patches are needed as a
> dependency since I spent quite a bit of time figuring out why the
> ps8622 bridge driver probe was always deferred due of_drm_find_panel()
> failing and then I noticed that a patch from linux-next was needed:
> 
> e35e305 ("drm/panel: simple: Add AUO B116XW03 panel support")
> 
> With that commit the ps8622 drm bridge driver probe succeed but I still
> don't have display working on an Exynos5240 Peach Pit, the kernel log shows:
> 
> platform 145b.dp-controller: Driver exynos-dp requests probe deferral
> exynos-drm exynos-drm: bound 1440.fimd (ops fimd_component_ops)
> exynos-drm exynos-drm: failed to bind 145b.dp-controller (ops 
> exynos_dp_ops): -517
> exynos-drm exynos-drm: master bind failed: -517
> platform 145b.dp-controller: Driver exynos-dp requests probe deferral

do you have this in your dmesg?

...
exynos-dp-video-phy 10040728.video-phy: Failed to lookup PMU regmap
...

to get a working framebuffer out of linus 318rc4 on my peach pi, i had
to cherry pick these 3 patches:

arm: dts: Exynos5: Use pmu_system_controller phandle for dp phy
drm/exynos: dp: Remove support for unused dptx-phy
ARM: exynos_defconfig: Enable options for display panel support

Check if you have those.
-- 
bye,
p.


[PATCH] drm/i2c: tda998x: Allow for different audio sample rates

2014-11-19 Thread Andrew Jackson
On 11/18/14 18:00, Russell King - ARM Linux wrote:
> On Tue, Nov 18, 2014 at 05:39:30PM +, Andrew Jackson wrote:
>> On HDMI, the audio data are carried across the HDMI link which is
>> driven by the TDMS clock. The TDMS clock is dependent on the video pixel
>> rate.
>>
>> This patch sets the denominator (Cycle Time Stamp) appropriately
>> allowing the driver to send audio to a wider range of HDMI sinks
>> (i.e. monitors).
> 
> This is actually pointless, because we don't use "manual" CTS mode.
> 
> If the clocks for the video and audio are coherent, then you can program
> both the N and CTS values to allow the sink to properly recover the
> synchronous audio clock.
> 
> However, in most cases, the audio and video clocks are not coherent, and
> since the recovered audio clock has to match the source audio clock, the
> only way this can be done is by the TDA998x (or in fact other HDMI
> encoder) to measure the audio clock rate and generate the CTS value
> itself.
> 
> This is the mode we drive the TDA998x - so the programmed CTS value is
> irrelevant.

My apologies for the noise: I originally created the patch when one of the 
monitors with which I was working wouldn't play sound as expected.  However, I 
now find that the monitor plays sound with or without the patch so it must have 
been something else.  I'd missed the significance of the "auto CTS" comment a 
few lines earlier (partly because I've no datasheet on the TDA998x).

   Andrew




[PATCH V8 00/14] drm/exynos: few patches to enhance bridge chip support

2014-11-19 Thread Javier Martinez Canillas
Hello Ajay,

On 11/19/2014 10:38 AM, Ajay kumar wrote:
> Hi Javier,
> 
> In the cover letter, I have mentioned that it is tested on Linus tree:
> 
> "This series is based on master branch of Linus tree at:
> git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git"
> 
> Kindly test the patches with that.
> 

That's what I did... Linus' master branch is a moving target and if you
look at his current HEAD, it is commit fc14f9c1 ("Linux 3.18-rc5") but
as I said before, at least two patches that are needed didn't land in
Linus' tree yet. These are:

0ef76ae ("ARM: exynos_defconfig: Enable options for display panel support")
e35e305 ("drm/panel: simple: Add AUO B116XW03 panel support")

IOW, linux.git master branch + this series is not enough to have display
working AFAICT so I was wondering if I'm missing something else.

Do you have a public tree somewhere with the branch you are using to test?

Best regards,
Javier




[PATCH 0/4] bochs: little patch collection

2014-11-19 Thread Gerd Hoffmann
  Hi,

Here is a small patch collection for the bochsdrm (qemu stdvga) driver.

cheers,
  Gerd

Gerd Hoffmann (4):
  bochs: little cleanup
  bochs: add endian switching support
  bochs: fix bochsdrmfb mmap
  bochs: add page_flip

 drivers/gpu/drm/bochs/bochs_fbdev.c | 18 ++
 drivers/gpu/drm/bochs/bochs_hw.c| 23 ---
 drivers/gpu/drm/bochs/bochs_kms.c   | 21 +
 3 files changed, 55 insertions(+), 7 deletions(-)

-- 
1.8.3.1



[PATCH 1/4] bochs: little cleanup

2014-11-19 Thread Gerd Hoffmann
Drop some leftover, commented code.

Signed-off-by: Gerd Hoffmann 
---
 drivers/gpu/drm/bochs/bochs_hw.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/bochs/bochs_hw.c b/drivers/gpu/drm/bochs/bochs_hw.c
index dbe619e..e8b1dac 100644
--- a/drivers/gpu/drm/bochs/bochs_hw.c
+++ b/drivers/gpu/drm/bochs/bochs_hw.c
@@ -54,8 +54,7 @@ int bochs_hw_init(struct drm_device *dev, uint32_t flags)
unsigned long addr, size, mem, ioaddr, iosize;
u16 id;

-   if (/* (ent->driver_data == BOCHS_QEMU_STDVGA) && */
-   (pdev->resource[2].flags & IORESOURCE_MEM)) {
+   if (pdev->resource[2].flags & IORESOURCE_MEM) {
/* mmio bar with vga and bochs registers present */
if (pci_request_region(pdev, 2, "bochs-drm") != 0) {
DRM_ERROR("Cannot request mmio region\n");
-- 
1.8.3.1



[PATCH 2/4] bochs: add endian switching support

2014-11-19 Thread Gerd Hoffmann
Recently (qemu 2.2+) the qemu stdvga got a register to switch the vga
framebuffer endianness.  This patch adds code to explicitly set the
endianness of the framebuffer.  In most cases this has no effect as
the default is guest architecture endianness.  It is needed though in
case a architecture supports both big and little endian, i.e. for
ppc64le.

Signed-off-by: Gerd Hoffmann 
---
 drivers/gpu/drm/bochs/bochs_hw.c | 20 +++-
 1 file changed, 19 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/bochs/bochs_hw.c b/drivers/gpu/drm/bochs/bochs_hw.c
index e8b1dac..4603897 100644
--- a/drivers/gpu/drm/bochs/bochs_hw.c
+++ b/drivers/gpu/drm/bochs/bochs_hw.c
@@ -51,7 +51,7 @@ int bochs_hw_init(struct drm_device *dev, uint32_t flags)
 {
struct bochs_device *bochs = dev->dev_private;
struct pci_dev *pdev = dev->pdev;
-   unsigned long addr, size, mem, ioaddr, iosize;
+   unsigned long addr, size, mem, ioaddr, iosize, qext_size;
u16 id;

if (pdev->resource[2].flags & IORESOURCE_MEM) {
@@ -115,6 +115,24 @@ int bochs_hw_init(struct drm_device *dev, uint32_t flags)
 size / 1024, addr,
 bochs->ioports ? "ioports" : "mmio",
 ioaddr);
+
+   if (bochs->mmio && pdev->revision >= 2) {
+   qext_size = readl(bochs->mmio + 0x600);
+   if (qext_size < 4 || qext_size > iosize)
+   goto noext;
+   DRM_DEBUG("Found qemu ext regs, size %ld\n", qext_size);
+   if (qext_size >= 8) {
+#ifdef __BIG_ENDIAN
+   writel(0xbebebebe, bochs->mmio + 0x604);
+#else
+   writel(0x1e1e1e1e, bochs->mmio + 0x604);
+#endif
+   DRM_DEBUG("  qext endian: 0x%x\n",
+ readl(bochs->mmio + 0x604));
+   }
+   }
+
+noext:
return 0;
 }

-- 
1.8.3.1



[PATCH 4/4] bochs: add page_flip

2014-11-19 Thread Gerd Hoffmann
Implement crtc page_flip callback for bochsdrm.  The qemu stdvga has no
vblank signaling, so we have to fake it.  We do so by instantly calling
drm_send_vblank_event.  Tested with kmscon.

Signed-off-by: Gerd Hoffmann 
---
 drivers/gpu/drm/bochs/bochs_kms.c | 21 +
 1 file changed, 21 insertions(+)

diff --git a/drivers/gpu/drm/bochs/bochs_kms.c 
b/drivers/gpu/drm/bochs/bochs_kms.c
index 6b7efcf3..ee2013b 100644
--- a/drivers/gpu/drm/bochs/bochs_kms.c
+++ b/drivers/gpu/drm/bochs/bochs_kms.c
@@ -108,11 +108,32 @@ static void bochs_crtc_gamma_set(struct drm_crtc *crtc, 
u16 *red, u16 *green,
 {
 }

+static int bochs_crtc_page_flip(struct drm_crtc *crtc,
+   struct drm_framebuffer *fb,
+   struct drm_pending_vblank_event *event,
+   uint32_t page_flip_flags)
+{
+   struct bochs_device *bochs =
+   container_of(crtc, struct bochs_device, crtc);
+   struct drm_framebuffer *old_fb = crtc->primary->fb;
+   unsigned long irqflags;
+
+   crtc->primary->fb = fb;
+   bochs_crtc_mode_set_base(crtc, 0, 0, old_fb);
+   if (event) {
+   spin_lock_irqsave(&bochs->dev->event_lock, irqflags);
+   drm_send_vblank_event(bochs->dev, -1, event);
+   spin_unlock_irqrestore(&bochs->dev->event_lock, irqflags);
+   }
+   return 0;
+}
+
 /* These provide the minimum set of functions required to handle a CRTC */
 static const struct drm_crtc_funcs bochs_crtc_funcs = {
.gamma_set = bochs_crtc_gamma_set,
.set_config = drm_crtc_helper_set_config,
.destroy = drm_crtc_cleanup,
+   .page_flip = bochs_crtc_page_flip,
 };

 static const struct drm_crtc_helper_funcs bochs_helper_funcs = {
-- 
1.8.3.1



[PATCH 3/4] bochs: fix bochsdrmfb mmap

2014-11-19 Thread Gerd Hoffmann
Remove the mapping offset from the bo backing the fbdev framebuffer.
Wire up fbdev mmap function to map the backing bo using ttm_fbdev_mmap.
With that patch in place mmap(/dev/fb0) works as expected.

Signed-off-by: Gerd Hoffmann 
---
 drivers/gpu/drm/bochs/bochs_fbdev.c | 18 ++
 1 file changed, 14 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/bochs/bochs_fbdev.c 
b/drivers/gpu/drm/bochs/bochs_fbdev.c
index fe95d31..61dbf09 100644
--- a/drivers/gpu/drm/bochs/bochs_fbdev.c
+++ b/drivers/gpu/drm/bochs/bochs_fbdev.c
@@ -9,6 +9,17 @@

 /* -- */

+static int bochsfb_mmap(struct fb_info *info,
+   struct vm_area_struct *vma)
+{
+   struct drm_fb_helper *fb_helper = info->par;
+   struct bochs_device *bochs =
+   container_of(fb_helper, struct bochs_device, fb.helper);
+   struct bochs_bo *bo = gem_to_bochs_bo(bochs->fb.gfb.obj);
+
+   return ttm_fbdev_mmap(vma, &bo->bo);
+}
+
 static struct fb_ops bochsfb_ops = {
.owner = THIS_MODULE,
.fb_check_var = drm_fb_helper_check_var,
@@ -19,6 +30,7 @@ static struct fb_ops bochsfb_ops = {
.fb_pan_display = drm_fb_helper_pan_display,
.fb_blank = drm_fb_helper_blank,
.fb_setcmap = drm_fb_helper_setcmap,
+   .fb_mmap = bochsfb_mmap,
 };

 static int bochsfb_create_object(struct bochs_device *bochs,
@@ -123,11 +135,9 @@ static int bochsfb_create(struct drm_fb_helper *helper,
info->screen_base = bo->kmap.virtual;
info->screen_size = size;

-#if 0
-   /* FIXME: get this right for mmap(/dev/fb0) */
-   info->fix.smem_start = bochs_bo_mmap_offset(bo);
+   drm_vma_offset_remove(&bo->bo.bdev->vma_manager, &bo->bo.vma_node);
+   info->fix.smem_start = 0;
info->fix.smem_len = size;
-#endif

ret = fb_alloc_cmap(&info->cmap, 256, 0);
if (ret) {
-- 
1.8.3.1



[PATCH 06/11] drm/radeon: track VM update fences separately

2014-11-19 Thread Christian König
From: Christian König 

Note for each fence if it's a VM page table update or not. This allows
us to determine the last VM update in a sync object and so to figure
out if we need to flush the TLB or not.

Signed-off-by: Christian König 
---
 drivers/gpu/drm/radeon/radeon.h   | 18 ++
 drivers/gpu/drm/radeon/radeon_fence.c |  1 +
 drivers/gpu/drm/radeon/radeon_ib.c|  3 ++-
 drivers/gpu/drm/radeon/radeon_sync.c  |  7 +++
 drivers/gpu/drm/radeon/radeon_vm.c| 25 +
 5 files changed, 33 insertions(+), 21 deletions(-)

diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
index 5e88e75..ac4660a 100644
--- a/drivers/gpu/drm/radeon/radeon.h
+++ b/drivers/gpu/drm/radeon/radeon.h
@@ -360,14 +360,15 @@ struct radeon_fence_driver {
 };

 struct radeon_fence {
-   struct fence base;
+   struct fencebase;

-   struct radeon_device*rdev;
-   uint64_tseq;
+   struct radeon_device*rdev;
+   uint64_tseq;
/* RB, DMA, etc. */
-   unsignedring;
+   unsignedring;
+   boolis_vm_update;

-   wait_queue_tfence_wake;
+   wait_queue_tfence_wake;
 };

 int radeon_fence_driver_start_ring(struct radeon_device *rdev, int ring);
@@ -594,6 +595,7 @@ void radeon_semaphore_free(struct radeon_device *rdev,
 struct radeon_sync {
struct radeon_semaphore *semaphores[RADEON_NUM_SYNCS];
struct radeon_fence *sync_to[RADEON_NUM_RINGS];
+   struct radeon_fence *last_vm_update;
 };

 void radeon_sync_create(struct radeon_sync *sync);
@@ -922,8 +924,8 @@ struct radeon_vm {
struct mutexmutex;
/* last fence for cs using this vm */
struct radeon_fence *fence;
-   /* last flush or NULL if we still need to flush */
-   struct radeon_fence *last_flush;
+   /* last flushed PD/PT update */
+   struct radeon_fence *flushed_updates;
/* last use of vmid */
struct radeon_fence *last_id_use;
 };
@@ -2961,7 +2963,7 @@ struct radeon_fence *radeon_vm_grab_id(struct 
radeon_device *rdev,
   struct radeon_vm *vm, int ring);
 void radeon_vm_flush(struct radeon_device *rdev,
  struct radeon_vm *vm,
- int ring);
+int ring, struct radeon_fence *fence);
 void radeon_vm_fence(struct radeon_device *rdev,
 struct radeon_vm *vm,
 struct radeon_fence *fence);
diff --git a/drivers/gpu/drm/radeon/radeon_fence.c 
b/drivers/gpu/drm/radeon/radeon_fence.c
index 9951670..d13d1b5 100644
--- a/drivers/gpu/drm/radeon/radeon_fence.c
+++ b/drivers/gpu/drm/radeon/radeon_fence.c
@@ -140,6 +140,7 @@ int radeon_fence_emit(struct radeon_device *rdev,
(*fence)->rdev = rdev;
(*fence)->seq = seq;
(*fence)->ring = ring;
+   (*fence)->is_vm_update = false;
fence_init(&(*fence)->base, &radeon_fence_ops,
   &rdev->fence_queue.lock, rdev->fence_context + ring, seq);
radeon_fence_ring_emit(rdev, ring, *fence);
diff --git a/drivers/gpu/drm/radeon/radeon_ib.c 
b/drivers/gpu/drm/radeon/radeon_ib.c
index 56a1704..c39ce1f 100644
--- a/drivers/gpu/drm/radeon/radeon_ib.c
+++ b/drivers/gpu/drm/radeon/radeon_ib.c
@@ -154,7 +154,8 @@ int radeon_ib_schedule(struct radeon_device *rdev, struct 
radeon_ib *ib,
}

if (ib->vm)
-   radeon_vm_flush(rdev, ib->vm, ib->ring);
+   radeon_vm_flush(rdev, ib->vm, ib->ring,
+   ib->sync.last_vm_update);

if (const_ib) {
radeon_ring_ib_execute(rdev, const_ib->ring, const_ib);
diff --git a/drivers/gpu/drm/radeon/radeon_sync.c 
b/drivers/gpu/drm/radeon/radeon_sync.c
index ddd88fb..02ac8a1 100644
--- a/drivers/gpu/drm/radeon/radeon_sync.c
+++ b/drivers/gpu/drm/radeon/radeon_sync.c
@@ -48,6 +48,8 @@ void radeon_sync_create(struct radeon_sync *sync)

for (i = 0; i < RADEON_NUM_RINGS; ++i)
sync->sync_to[i] = NULL;
+
+   sync->last_vm_update = NULL;
 }

 /**
@@ -68,6 +70,11 @@ void radeon_sync_fence(struct radeon_sync *sync,

other = sync->sync_to[fence->ring];
sync->sync_to[fence->ring] = radeon_fence_later(fence, other);
+
+   if (fence->is_vm_update) {
+   other = sync->last_vm_update;
+   sync->last_vm_update = radeon_fence_later(fence, other);
+   }
 }

 /**
diff --git a/drivers/gpu/drm/radeon/radeon_vm.c 
b/drivers/gpu/drm/radeon/radeon_vm.c
index 4ca2779..6ff5741 100644
--- a/drivers/gpu/drm/radeon/radeon_vm.c
+++ b/drivers/gpu/drm/radeon/radeon_vm.c
@@ -190,7 +190,7 @@ struct radeon_fence *radeon_vm_grab_id(struct radeon_device 
*rdev,
return NULL;

/* we definat

[PATCH 10/11] drm/radeon: sync PT updates as shared v2

2014-11-19 Thread Christian König
From: Christian König 

Only invalidating PTEs needs to be executed synchronized to using the PT.

v2: fix sync to uses

Signed-off-by: Christian König 
---
 drivers/gpu/drm/radeon/radeon_vm.c | 9 -
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/radeon/radeon_vm.c 
b/drivers/gpu/drm/radeon/radeon_vm.c
index 470451c..0b10f3a 100644
--- a/drivers/gpu/drm/radeon/radeon_vm.c
+++ b/drivers/gpu/drm/radeon/radeon_vm.c
@@ -820,7 +820,7 @@ static void radeon_vm_update_ptes(struct radeon_device 
*rdev,
unsigned nptes;
uint64_t pte;

-   radeon_sync_resv(rdev, &ib->sync, pt->tbo.resv, false);
+   radeon_sync_resv(rdev, &ib->sync, pt->tbo.resv, true);

if ((addr & ~mask) == (end & ~mask))
nptes = end - addr;
@@ -980,6 +980,13 @@ int radeon_vm_bo_update(struct radeon_device *rdev,
return r;
ib.length_dw = 0;

+   if (!(bo_va->flags & RADEON_VM_PAGE_VALID)) {
+   unsigned i;
+
+   for (i = 0; i < RADEON_NUM_RINGS; ++i)
+   radeon_sync_fence(&ib.sync, vm->ids[i].last_id_use);
+   }
+
radeon_vm_update_ptes(rdev, vm, &ib, bo_va->it.start,
  bo_va->it.last + 1, addr,
  radeon_vm_page_flags(bo_va->flags));
-- 
1.9.1



[PATCH 04/11] drm/radeon: split semaphore and sync object handling v2

2014-11-19 Thread Christian König
From: Christian König 

Previously we just allocated space for four hardware semaphores
in each software semaphore object. Make software semaphore objects
represent only one hardware semaphore address again by splitting
the sync code into it's own object.

v2: fix typo in comment

Signed-off-by: Christian König 
---
 drivers/gpu/drm/radeon/Makefile   |   3 +-
 drivers/gpu/drm/radeon/cik.c  |  18 +--
 drivers/gpu/drm/radeon/cik_sdma.c |  18 +--
 drivers/gpu/drm/radeon/evergreen_dma.c|  18 +--
 drivers/gpu/drm/radeon/r600.c |  18 +--
 drivers/gpu/drm/radeon/r600_dma.c |  18 +--
 drivers/gpu/drm/radeon/radeon.h   |  42 +++---
 drivers/gpu/drm/radeon/radeon_cs.c|   8 +-
 drivers/gpu/drm/radeon/radeon_ib.c|  13 +-
 drivers/gpu/drm/radeon/radeon_semaphore.c | 154 +
 drivers/gpu/drm/radeon/radeon_sync.c  | 213 ++
 drivers/gpu/drm/radeon/radeon_vm.c|   4 +-
 drivers/gpu/drm/radeon/rv770_dma.c|  18 +--
 drivers/gpu/drm/radeon/si_dma.c   |  18 +--
 14 files changed, 303 insertions(+), 260 deletions(-)
 create mode 100644 drivers/gpu/drm/radeon/radeon_sync.c

diff --git a/drivers/gpu/drm/radeon/Makefile b/drivers/gpu/drm/radeon/Makefile
index d01b879..a02434a 100644
--- a/drivers/gpu/drm/radeon/Makefile
+++ b/drivers/gpu/drm/radeon/Makefile
@@ -80,7 +80,8 @@ radeon-y += radeon_device.o radeon_asic.o radeon_kms.o \
r600_dpm.o rs780_dpm.o rv6xx_dpm.o rv770_dpm.o rv730_dpm.o rv740_dpm.o \
rv770_smc.o cypress_dpm.o btc_dpm.o sumo_dpm.o sumo_smc.o trinity_dpm.o 
\
trinity_smc.o ni_dpm.o si_smc.o si_dpm.o kv_smc.o kv_dpm.o ci_smc.o \
-   ci_dpm.o dce6_afmt.o radeon_vm.o radeon_ucode.o radeon_ib.o radeon_mn.o
+   ci_dpm.o dce6_afmt.o radeon_vm.o radeon_ucode.o radeon_ib.o radeon_mn.o 
\
+   radeon_sync.o

 # add async DMA block
 radeon-y += \
diff --git a/drivers/gpu/drm/radeon/cik.c b/drivers/gpu/drm/radeon/cik.c
index d52ead9..6bb8b84 100644
--- a/drivers/gpu/drm/radeon/cik.c
+++ b/drivers/gpu/drm/radeon/cik.c
@@ -3979,31 +3979,27 @@ struct radeon_fence *cik_copy_cpdma(struct 
radeon_device *rdev,
unsigned num_gpu_pages,
struct reservation_object *resv)
 {
-   struct radeon_semaphore *sem = NULL;
struct radeon_fence *fence;
+   struct radeon_sync sync;
int ring_index = rdev->asic->copy.blit_ring_index;
struct radeon_ring *ring = &rdev->ring[ring_index];
u32 size_in_bytes, cur_size_in_bytes, control;
int i, num_loops;
int r = 0;

-   r = radeon_semaphore_create(rdev, &sem);
-   if (r) {
-   DRM_ERROR("radeon: moving bo (%d).\n", r);
-   return ERR_PTR(r);
-   }
+   radeon_sync_create(&sync);

size_in_bytes = (num_gpu_pages << RADEON_GPU_PAGE_SHIFT);
num_loops = DIV_ROUND_UP(size_in_bytes, 0x1f);
r = radeon_ring_lock(rdev, ring, num_loops * 7 + 18);
if (r) {
DRM_ERROR("radeon: moving bo (%d).\n", r);
-   radeon_semaphore_free(rdev, &sem, NULL);
+   radeon_sync_free(rdev, &sync, NULL);
return ERR_PTR(r);
}

-   radeon_semaphore_sync_resv(rdev, sem, resv, false);
-   radeon_semaphore_sync_rings(rdev, sem, ring->idx);
+   radeon_sync_resv(rdev, &sync, resv, false);
+   radeon_sync_rings(rdev, &sync, ring->idx);

for (i = 0; i < num_loops; i++) {
cur_size_in_bytes = size_in_bytes;
@@ -4027,12 +4023,12 @@ struct radeon_fence *cik_copy_cpdma(struct 
radeon_device *rdev,
r = radeon_fence_emit(rdev, &fence, ring->idx);
if (r) {
radeon_ring_unlock_undo(rdev, ring);
-   radeon_semaphore_free(rdev, &sem, NULL);
+   radeon_sync_free(rdev, &sync, NULL);
return ERR_PTR(r);
}

radeon_ring_unlock_commit(rdev, ring, false);
-   radeon_semaphore_free(rdev, &sem, fence);
+   radeon_sync_free(rdev, &sync, fence);

return fence;
 }
diff --git a/drivers/gpu/drm/radeon/cik_sdma.c 
b/drivers/gpu/drm/radeon/cik_sdma.c
index 7470a2e..604e2e7 100644
--- a/drivers/gpu/drm/radeon/cik_sdma.c
+++ b/drivers/gpu/drm/radeon/cik_sdma.c
@@ -541,31 +541,27 @@ struct radeon_fence *cik_copy_dma(struct radeon_device 
*rdev,
  unsigned num_gpu_pages,
  struct reservation_object *resv)
 {
-   struct radeon_semaphore *sem = NULL;
struct radeon_fence *fence;
+   struct radeon_sync sync;
int ring_index = rdev->asic->copy.dma_ring_index;
struct radeon_ring *ring = &rdev->ring[ring_index];
u32 size_in_bytes, cur_size_in_bytes;
int i, num_loops;
int r = 0;

-   r = radeon_semaphore_create(rdev, &sem);
-   if (r) {
-   DRM_ERROR("radeon: moving

[PATCH 02/11] drm/radeon: stop re-reserving the BO in radeon_vm_bo_set_addr

2014-11-19 Thread Christian König
From: Christian König 

That's useless when all callers drop the reservation
immediately after calling the function.

Signed-off-by: Christian König 
---
 drivers/gpu/drm/radeon/radeon_gem.c | 2 +-
 drivers/gpu/drm/radeon/radeon_kms.c | 2 --
 drivers/gpu/drm/radeon/radeon_vm.c  | 4 ++--
 3 files changed, 3 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/radeon/radeon_gem.c 
b/drivers/gpu/drm/radeon/radeon_gem.c
index c194497..f752c7f 100644
--- a/drivers/gpu/drm/radeon/radeon_gem.c
+++ b/drivers/gpu/drm/radeon/radeon_gem.c
@@ -601,6 +601,7 @@ int radeon_gem_va_ioctl(struct drm_device *dev, void *data,
if (bo_va->it.start) {
args->operation = RADEON_VA_RESULT_VA_EXIST;
args->offset = bo_va->it.start * RADEON_GPU_PAGE_SIZE;
+   radeon_bo_unreserve(rbo);
goto out;
}
r = radeon_vm_bo_set_addr(rdev, bo_va, args->offset, 
args->flags);
@@ -616,7 +617,6 @@ int radeon_gem_va_ioctl(struct drm_device *dev, void *data,
args->operation = RADEON_VA_RESULT_ERROR;
}
 out:
-   radeon_bo_unreserve(rbo);
drm_gem_object_unreference_unlocked(gobj);
return r;
 }
diff --git a/drivers/gpu/drm/radeon/radeon_kms.c 
b/drivers/gpu/drm/radeon/radeon_kms.c
index 8309b11..85ee6f7 100644
--- a/drivers/gpu/drm/radeon/radeon_kms.c
+++ b/drivers/gpu/drm/radeon/radeon_kms.c
@@ -621,8 +621,6 @@ int radeon_driver_open_kms(struct drm_device *dev, struct 
drm_file *file_priv)
  RADEON_VA_IB_OFFSET,
  RADEON_VM_PAGE_READABLE |
  RADEON_VM_PAGE_SNOOPED);
-
-   radeon_bo_unreserve(rdev->ring_tmp_bo.bo);
if (r) {
radeon_vm_fini(rdev, vm);
kfree(fpriv);
diff --git a/drivers/gpu/drm/radeon/radeon_vm.c 
b/drivers/gpu/drm/radeon/radeon_vm.c
index 9d0f87b..db0ed3a 100644
--- a/drivers/gpu/drm/radeon/radeon_vm.c
+++ b/drivers/gpu/drm/radeon/radeon_vm.c
@@ -450,7 +450,7 @@ error:
  * Validate and set the offset requested within the vm address space.
  * Returns 0 for success, error for failure.
  *
- * Object has to be reserved!
+ * Object has to be reserved and gets unreserved by this function!
  */
 int radeon_vm_bo_set_addr(struct radeon_device *rdev,
  struct radeon_bo_va *bo_va,
@@ -576,7 +576,7 @@ int radeon_vm_bo_set_addr(struct radeon_device *rdev,
}

mutex_unlock(&vm->mutex);
-   return radeon_bo_reserve(bo_va->bo, false);
+   return 0;
 }

 /**
-- 
1.9.1



[PATCH 03/11] drm/radeon: remove unnecessary VM syncs

2014-11-19 Thread Christian König
From: Christian König 

The PD/PTs reservation object now contains everything needed.

Signed-off-by: Christian König 
---
 drivers/gpu/drm/radeon/radeon_vm.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/gpu/drm/radeon/radeon_vm.c 
b/drivers/gpu/drm/radeon/radeon_vm.c
index db0ed3a..d8c49ad 100644
--- a/drivers/gpu/drm/radeon/radeon_vm.c
+++ b/drivers/gpu/drm/radeon/radeon_vm.c
@@ -701,7 +701,6 @@ int radeon_vm_update_page_directory(struct radeon_device 
*rdev,
radeon_asic_vm_pad_ib(rdev, &ib);

radeon_semaphore_sync_resv(rdev, ib.semaphore, pd->tbo.resv, 
false);
-   radeon_semaphore_sync_fence(ib.semaphore, vm->last_id_use);
WARN_ON(ib.length_dw > ndw);
r = radeon_ib_schedule(rdev, &ib, NULL, false);
if (r) {
@@ -969,7 +968,6 @@ int radeon_vm_bo_update(struct radeon_device *rdev,
radeon_asic_vm_pad_ib(rdev, &ib);
WARN_ON(ib.length_dw > ndw);

-   radeon_semaphore_sync_fence(ib.semaphore, vm->fence);
r = radeon_ib_schedule(rdev, &ib, NULL, false);
if (r) {
radeon_ib_free(rdev, &ib);
-- 
1.9.1



[PATCH 07/11] drm/radeon: use one VMID for each ring

2014-11-19 Thread Christian König
From: Christian König 

Use multiple VMIDs for each VM, one for each ring. That allows
us to execute flushes separately on each ring, still not ideal
cause in a lot of cases rings can share IDs.

Signed-off-by: Christian König 
---
 drivers/gpu/drm/radeon/cik.c   |  4 +--
 drivers/gpu/drm/radeon/cik_sdma.c  |  2 +-
 drivers/gpu/drm/radeon/ni.c|  6 ++--
 drivers/gpu/drm/radeon/ni_dma.c|  3 +-
 drivers/gpu/drm/radeon/radeon.h| 36 +--
 drivers/gpu/drm/radeon/radeon_vm.c | 59 +++---
 drivers/gpu/drm/radeon/si.c|  6 ++--
 7 files changed, 68 insertions(+), 48 deletions(-)

diff --git a/drivers/gpu/drm/radeon/cik.c b/drivers/gpu/drm/radeon/cik.c
index 6bb8b84..510aeef 100644
--- a/drivers/gpu/drm/radeon/cik.c
+++ b/drivers/gpu/drm/radeon/cik.c
@@ -4051,6 +4051,7 @@ struct radeon_fence *cik_copy_cpdma(struct radeon_device 
*rdev,
 void cik_ring_ib_execute(struct radeon_device *rdev, struct radeon_ib *ib)
 {
struct radeon_ring *ring = &rdev->ring[ib->ring];
+   unsigned vm_id = ib->vm ? ib->vm->ids[ib->ring].id : 0;
u32 header, control = INDIRECT_BUFFER_VALID;

if (ib->is_const_ib) {
@@ -4079,8 +4080,7 @@ void cik_ring_ib_execute(struct radeon_device *rdev, 
struct radeon_ib *ib)
header = PACKET3(PACKET3_INDIRECT_BUFFER, 2);
}

-   control |= ib->length_dw |
-   (ib->vm ? (ib->vm->id << 24) : 0);
+   control |= ib->length_dw | (vm_id << 24);

radeon_ring_write(ring, header);
radeon_ring_write(ring,
diff --git a/drivers/gpu/drm/radeon/cik_sdma.c 
b/drivers/gpu/drm/radeon/cik_sdma.c
index 604e2e7..54b9837 100644
--- a/drivers/gpu/drm/radeon/cik_sdma.c
+++ b/drivers/gpu/drm/radeon/cik_sdma.c
@@ -134,7 +134,7 @@ void cik_sdma_ring_ib_execute(struct radeon_device *rdev,
  struct radeon_ib *ib)
 {
struct radeon_ring *ring = &rdev->ring[ib->ring];
-   u32 extra_bits = (ib->vm ? ib->vm->id : 0) & 0xf;
+   u32 extra_bits = (ib->vm ? ib->vm->ids[ib->ring].id : 0) & 0xf;

if (rdev->wb.enabled) {
u32 next_rptr = ring->wptr + 5;
diff --git a/drivers/gpu/drm/radeon/ni.c b/drivers/gpu/drm/radeon/ni.c
index bee432d..360de9f 100644
--- a/drivers/gpu/drm/radeon/ni.c
+++ b/drivers/gpu/drm/radeon/ni.c
@@ -1373,6 +1373,7 @@ void cayman_fence_ring_emit(struct radeon_device *rdev,
 void cayman_ring_ib_execute(struct radeon_device *rdev, struct radeon_ib *ib)
 {
struct radeon_ring *ring = &rdev->ring[ib->ring];
+   unsigned vm_id = ib->vm ? ib->vm->ids[ib->ring].id : 0;
u32 cp_coher_cntl = PACKET3_FULL_CACHE_ENA | PACKET3_TC_ACTION_ENA |
PACKET3_SH_ACTION_ENA;

@@ -1395,15 +1396,14 @@ void cayman_ring_ib_execute(struct radeon_device *rdev, 
struct radeon_ib *ib)
 #endif
  (ib->gpu_addr & 0xFFFC));
radeon_ring_write(ring, upper_32_bits(ib->gpu_addr) & 0xFF);
-   radeon_ring_write(ring, ib->length_dw | 
- (ib->vm ? (ib->vm->id << 24) : 0));
+   radeon_ring_write(ring, ib->length_dw | (vm_id << 24));

/* flush read cache over gart for this vmid */
radeon_ring_write(ring, PACKET3(PACKET3_SURFACE_SYNC, 3));
radeon_ring_write(ring, PACKET3_ENGINE_ME | cp_coher_cntl);
radeon_ring_write(ring, 0x);
radeon_ring_write(ring, 0);
-   radeon_ring_write(ring, ((ib->vm ? ib->vm->id : 0) << 24) | 10); /* 
poll interval */
+   radeon_ring_write(ring, (vm_id << 24) | 10); /* poll interval */
 }

 static void cayman_cp_enable(struct radeon_device *rdev, bool enable)
diff --git a/drivers/gpu/drm/radeon/ni_dma.c b/drivers/gpu/drm/radeon/ni_dma.c
index 5a72404..50f8861 100644
--- a/drivers/gpu/drm/radeon/ni_dma.c
+++ b/drivers/gpu/drm/radeon/ni_dma.c
@@ -123,6 +123,7 @@ void cayman_dma_ring_ib_execute(struct radeon_device *rdev,
struct radeon_ib *ib)
 {
struct radeon_ring *ring = &rdev->ring[ib->ring];
+   unsigned vm_id = ib->vm ? ib->vm->ids[ib->ring].id : 0;

if (rdev->wb.enabled) {
u32 next_rptr = ring->wptr + 4;
@@ -140,7 +141,7 @@ void cayman_dma_ring_ib_execute(struct radeon_device *rdev,
 */
while ((ring->wptr & 7) != 5)
radeon_ring_write(ring, DMA_PACKET(DMA_PACKET_NOP, 0, 0, 0));
-   radeon_ring_write(ring, DMA_IB_PACKET(DMA_PACKET_INDIRECT_BUFFER, 
ib->vm ? ib->vm->id : 0, 0));
+   radeon_ring_write(ring, DMA_IB_PACKET(DMA_PACKET_INDIRECT_BUFFER, 
vm_id, 0));
radeon_ring_write(ring, (ib->gpu_addr & 0xFFE0));
radeon_ring_write(ring, (ib->length_dw << 12) | 
(upper_32_bits(ib->gpu_addr) & 0xFF));

diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
index ac4660a..e3e77f7 100644
--- a/drivers/gpu/drm/radeon/radeon.h
+++ b/drivers/gpu/drm/radeon/radeon.h
@@ -901,33 +901,39 @@ struct radeon_vm_pt {
uint6

[PATCH 01/11] drm/radeon: rework vm_flush parameters

2014-11-19 Thread Christian König
From: Christian König 

Use ring structure instead of index and provide vm_id and pd_addr separately.

Signed-off-by: Christian König 
---
 drivers/gpu/drm/radeon/cik.c | 23 ++-
 drivers/gpu/drm/radeon/cik_sdma.c| 22 +-
 drivers/gpu/drm/radeon/ni.c  | 14 +-
 drivers/gpu/drm/radeon/ni_dma.c  | 14 +-
 drivers/gpu/drm/radeon/radeon.h  |  5 +++--
 drivers/gpu/drm/radeon/radeon_asic.h | 18 --
 drivers/gpu/drm/radeon/radeon_vm.c   |  3 ++-
 drivers/gpu/drm/radeon/si.c  | 18 +++---
 drivers/gpu/drm/radeon/si_dma.c  | 19 ---
 9 files changed, 61 insertions(+), 75 deletions(-)

diff --git a/drivers/gpu/drm/radeon/cik.c b/drivers/gpu/drm/radeon/cik.c
index 57a359d..d52ead9 100644
--- a/drivers/gpu/drm/radeon/cik.c
+++ b/drivers/gpu/drm/radeon/cik.c
@@ -5967,26 +5967,23 @@ static void cik_vm_decode_fault(struct radeon_device 
*rdev,
  * Update the page table base and flush the VM TLB
  * using the CP (CIK).
  */
-void cik_vm_flush(struct radeon_device *rdev, int ridx, struct radeon_vm *vm)
+void cik_vm_flush(struct radeon_device *rdev, struct radeon_ring *ring,
+ unsigned vm_id, uint64_t pd_addr)
 {
-   struct radeon_ring *ring = &rdev->ring[ridx];
-   int usepfp = (ridx == RADEON_RING_TYPE_GFX_INDEX);
-
-   if (vm == NULL)
-   return;
+   int usepfp = (ring->idx == RADEON_RING_TYPE_GFX_INDEX);

radeon_ring_write(ring, PACKET3(PACKET3_WRITE_DATA, 3));
radeon_ring_write(ring, (WRITE_DATA_ENGINE_SEL(usepfp) |
 WRITE_DATA_DST_SEL(0)));
-   if (vm->id < 8) {
+   if (vm_id < 8) {
radeon_ring_write(ring,
- (VM_CONTEXT0_PAGE_TABLE_BASE_ADDR + (vm->id 
<< 2)) >> 2);
+ (VM_CONTEXT0_PAGE_TABLE_BASE_ADDR + (vm_id << 
2)) >> 2);
} else {
radeon_ring_write(ring,
- (VM_CONTEXT8_PAGE_TABLE_BASE_ADDR + ((vm->id 
- 8) << 2)) >> 2);
+ (VM_CONTEXT8_PAGE_TABLE_BASE_ADDR + ((vm_id - 
8) << 2)) >> 2);
}
radeon_ring_write(ring, 0);
-   radeon_ring_write(ring, vm->pd_gpu_addr >> 12);
+   radeon_ring_write(ring, pd_addr >> 12);

/* update SH_MEM_* regs */
radeon_ring_write(ring, PACKET3(PACKET3_WRITE_DATA, 3));
@@ -5994,7 +5991,7 @@ void cik_vm_flush(struct radeon_device *rdev, int ridx, 
struct radeon_vm *vm)
 WRITE_DATA_DST_SEL(0)));
radeon_ring_write(ring, SRBM_GFX_CNTL >> 2);
radeon_ring_write(ring, 0);
-   radeon_ring_write(ring, VMID(vm->id));
+   radeon_ring_write(ring, VMID(vm_id));

radeon_ring_write(ring, PACKET3(PACKET3_WRITE_DATA, 6));
radeon_ring_write(ring, (WRITE_DATA_ENGINE_SEL(usepfp) |
@@ -6015,7 +6012,7 @@ void cik_vm_flush(struct radeon_device *rdev, int ridx, 
struct radeon_vm *vm)
radeon_ring_write(ring, VMID(0));

/* HDP flush */
-   cik_hdp_flush_cp_ring_emit(rdev, ridx);
+   cik_hdp_flush_cp_ring_emit(rdev, ring->idx);

/* bits 0-15 are the VM contexts0-15 */
radeon_ring_write(ring, PACKET3(PACKET3_WRITE_DATA, 3));
@@ -6023,7 +6020,7 @@ void cik_vm_flush(struct radeon_device *rdev, int ridx, 
struct radeon_vm *vm)
 WRITE_DATA_DST_SEL(0)));
radeon_ring_write(ring, VM_INVALIDATE_REQUEST >> 2);
radeon_ring_write(ring, 0);
-   radeon_ring_write(ring, 1 << vm->id);
+   radeon_ring_write(ring, 1 << vm_id);

/* compute doesn't have PFP */
if (usepfp) {
diff --git a/drivers/gpu/drm/radeon/cik_sdma.c 
b/drivers/gpu/drm/radeon/cik_sdma.c
index 4e8432d..7470a2e 100644
--- a/drivers/gpu/drm/radeon/cik_sdma.c
+++ b/drivers/gpu/drm/radeon/cik_sdma.c
@@ -901,25 +901,21 @@ void cik_sdma_vm_pad_ib(struct radeon_ib *ib)
  * Update the page table base and flush the VM TLB
  * using sDMA (CIK).
  */
-void cik_dma_vm_flush(struct radeon_device *rdev, int ridx, struct radeon_vm 
*vm)
+void cik_dma_vm_flush(struct radeon_device *rdev, struct radeon_ring *ring,
+ unsigned vm_id, uint64_t pd_addr)
 {
-   struct radeon_ring *ring = &rdev->ring[ridx];
-
-   if (vm == NULL)
-   return;
-
radeon_ring_write(ring, SDMA_PACKET(SDMA_OPCODE_SRBM_WRITE, 0, 0xf000));
-   if (vm->id < 8) {
-   radeon_ring_write(ring, (VM_CONTEXT0_PAGE_TABLE_BASE_ADDR + 
(vm->id << 2)) >> 2);
+   if (vm_id < 8) {
+   radeon_ring_write(ring, (VM_CONTEXT0_PAGE_TABLE_BASE_ADDR + 
(vm_id << 2)) >> 2);
} else {
-   radeon_ring_write(ring, (VM_CONTEXT8_PAGE_TABLE_BASE_ADDR + 
((vm->id - 8) << 2)) >> 2);
+   radeon_ring_write(ring, (VM_CONTEXT8_PAGE_TABLE_BASE_ADDR + 
((vm_id - 8) << 2)) >> 2);
}
-   radeon_ring_write(ring, vm

[PATCH 08/11] drm/radeon: fence BO_VAs manually

2014-11-19 Thread Christian König
From: Christian König 

This allows us to finally remove the VM fence and
so allow concurrent use of it from different engines.

Signed-off-by: Christian König 
---
 drivers/gpu/drm/radeon/radeon.h|  7 +++
 drivers/gpu/drm/radeon/radeon_cs.c |  6 +-
 drivers/gpu/drm/radeon/radeon_vm.c | 17 ++---
 3 files changed, 14 insertions(+), 16 deletions(-)

diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
index e3e77f7..1805067 100644
--- a/drivers/gpu/drm/radeon/radeon.h
+++ b/drivers/gpu/drm/radeon/radeon.h
@@ -456,6 +456,7 @@ struct radeon_bo_va {
struct list_headbo_list;
uint32_tflags;
uint64_taddr;
+   struct radeon_fence *last_pt_update;
unsignedref_count;

/* protected by vm mutex */
@@ -911,6 +912,8 @@ struct radeon_vm_id {
 };

 struct radeon_vm {
+   struct mutexmutex;
+
struct rb_root  va;

/* BOs moved, but not yet updated in the PT */
@@ -928,10 +931,6 @@ struct radeon_vm {

struct radeon_bo_va *ib_bo_va;

-   struct mutexmutex;
-   /* last fence for cs using this vm */
-   struct radeon_fence *fence;
-
/* for id and flush management per ring */
struct radeon_vm_id ids[RADEON_NUM_RINGS];
 };
diff --git a/drivers/gpu/drm/radeon/radeon_cs.c 
b/drivers/gpu/drm/radeon/radeon_cs.c
index 30437aa..75f22e5 100644
--- a/drivers/gpu/drm/radeon/radeon_cs.c
+++ b/drivers/gpu/drm/radeon/radeon_cs.c
@@ -505,6 +505,9 @@ static int radeon_bo_vm_update_pte(struct radeon_cs_parser 
*p,
if (r)
return r;

+   radeon_sync_resv(p->rdev, &p->ib.sync, vm->page_directory->tbo.resv,
+true);
+
r = radeon_vm_clear_freed(rdev, vm);
if (r)
return r;
@@ -536,6 +539,8 @@ static int radeon_bo_vm_update_pte(struct radeon_cs_parser 
*p,
r = radeon_vm_bo_update(rdev, bo_va, &bo->tbo.mem);
if (r)
return r;
+
+   radeon_sync_fence(&p->ib.sync, bo_va->last_pt_update);
}

return radeon_vm_clear_invalids(rdev, vm);
@@ -580,7 +585,6 @@ static int radeon_cs_ib_vm_chunk(struct radeon_device *rdev,
DRM_ERROR("Failed to sync rings: %i\n", r);
goto out;
}
-   radeon_sync_fence(&parser->ib.sync, vm->fence);

if ((rdev->family >= CHIP_TAHITI) &&
(parser->chunk_const_ib_idx != -1)) {
diff --git a/drivers/gpu/drm/radeon/radeon_vm.c 
b/drivers/gpu/drm/radeon/radeon_vm.c
index e38efe4..f457614 100644
--- a/drivers/gpu/drm/radeon/radeon_vm.c
+++ b/drivers/gpu/drm/radeon/radeon_vm.c
@@ -275,9 +275,6 @@ void radeon_vm_fence(struct radeon_device *rdev,
 {
unsigned vm_id = vm->ids[fence->ring].id;

-   radeon_fence_unref(&vm->fence);
-   vm->fence = radeon_fence_ref(fence);
-
radeon_fence_unref(&rdev->vm_manager.active[vm_id]);
rdev->vm_manager.active[vm_id] = radeon_fence_ref(fence);

@@ -707,8 +704,6 @@ int radeon_vm_update_page_directory(struct radeon_device 
*rdev,
}
ib.fence->is_vm_update = true;
radeon_bo_fence(pd, ib.fence, false);
-   radeon_fence_unref(&vm->fence);
-   vm->fence = radeon_fence_ref(ib.fence);
}
radeon_ib_free(rdev, &ib);

@@ -999,8 +994,8 @@ int radeon_vm_bo_update(struct radeon_device *rdev,
}
ib.fence->is_vm_update = true;
radeon_vm_fence_pts(vm, bo_va->it.start, bo_va->it.last + 1, ib.fence);
-   radeon_fence_unref(&vm->fence);
-   vm->fence = radeon_fence_ref(ib.fence);
+   radeon_fence_unref(&bo_va->last_pt_update);
+   bo_va->last_pt_update = radeon_fence_ref(ib.fence);
radeon_ib_free(rdev, &ib);

return 0;
@@ -1026,6 +1021,7 @@ int radeon_vm_clear_freed(struct radeon_device *rdev,
list_for_each_entry_safe(bo_va, tmp, &vm->freed, vm_status) {
r = radeon_vm_bo_update(rdev, bo_va, NULL);
radeon_bo_unref(&bo_va->bo);
+   radeon_fence_unref(&bo_va->last_pt_update);
kfree(bo_va);
if (r)
return r;
@@ -1084,6 +1080,7 @@ void radeon_vm_bo_rmv(struct radeon_device *rdev,
bo_va->bo = radeon_bo_ref(bo_va->bo);
list_add(&bo_va->vm_status, &vm->freed);
} else {
+   radeon_fence_unref(&bo_va->last_pt_update);
kfree(bo_va);
}

@@ -1130,8 +1127,6 @@ int radeon_vm_init(struct radeon_device *rdev, struct 
radeon_vm *vm)
int i, r;

vm->ib_bo_va = NULL;
-   vm->fence = NULL;
-
for (i = 0; i < RADEON_NUM_RINGS; ++i) {
vm->ids[i].id = 0;
vm->ids[i].flushed_updates = NULL;
@@ -1192,11 +1187,13 @@ void radeon_vm

[PATCH 05/11] drm/radeon: fence PT updates manually v2

2014-11-19 Thread Christian König
From: Christian König 

This allows us to add the real execution fence as shared.

v2: fix typo

Signed-off-by: Christian König 
---
 drivers/gpu/drm/radeon/radeon_object.c | 19 ++
 drivers/gpu/drm/radeon/radeon_object.h |  2 ++
 drivers/gpu/drm/radeon/radeon_vm.c | 65 +-
 3 files changed, 62 insertions(+), 24 deletions(-)

diff --git a/drivers/gpu/drm/radeon/radeon_object.c 
b/drivers/gpu/drm/radeon/radeon_object.c
index 33e6c7a..686e450 100644
--- a/drivers/gpu/drm/radeon/radeon_object.c
+++ b/drivers/gpu/drm/radeon/radeon_object.c
@@ -818,3 +818,22 @@ int radeon_bo_wait(struct radeon_bo *bo, u32 *mem_type, 
bool no_wait)
ttm_bo_unreserve(&bo->tbo);
return r;
 }
+
+/**
+ * radeon_bo_fence - add fence to buffer object
+ *
+ * @bo: buffer object in question
+ * @fence: fence to add
+ * @shared: true if fence should be added shared
+ *
+ */
+void radeon_bo_fence(struct radeon_bo *bo, struct radeon_fence *fence,
+ bool shared)
+{
+   struct reservation_object *resv = bo->tbo.resv;
+
+   if (shared)
+   reservation_object_add_shared_fence(resv, &fence->base);
+   else
+   reservation_object_add_excl_fence(resv, &fence->base);
+}
diff --git a/drivers/gpu/drm/radeon/radeon_object.h 
b/drivers/gpu/drm/radeon/radeon_object.h
index 1b8ec79..3b0b377 100644
--- a/drivers/gpu/drm/radeon/radeon_object.h
+++ b/drivers/gpu/drm/radeon/radeon_object.h
@@ -155,6 +155,8 @@ extern void radeon_bo_move_notify(struct ttm_buffer_object 
*bo,
  struct ttm_mem_reg *new_mem);
 extern int radeon_bo_fault_reserve_notify(struct ttm_buffer_object *bo);
 extern int radeon_bo_get_surface_reg(struct radeon_bo *bo);
+extern void radeon_bo_fence(struct radeon_bo *bo, struct radeon_fence *fence,
+   bool shared);

 /*
  * sub allocation
diff --git a/drivers/gpu/drm/radeon/radeon_vm.c 
b/drivers/gpu/drm/radeon/radeon_vm.c
index 20ef826..4ca2779 100644
--- a/drivers/gpu/drm/radeon/radeon_vm.c
+++ b/drivers/gpu/drm/radeon/radeon_vm.c
@@ -143,7 +143,7 @@ struct radeon_cs_reloc *radeon_vm_get_bos(struct 
radeon_device *rdev,
list[0].prefered_domains = RADEON_GEM_DOMAIN_VRAM;
list[0].allowed_domains = RADEON_GEM_DOMAIN_VRAM;
list[0].tv.bo = &vm->page_directory->tbo;
-   list[0].tv.shared = false;
+   list[0].tv.shared = true;
list[0].tiling_flags = 0;
list[0].handle = 0;
list_add(&list[0].tv.head, head);
@@ -157,7 +157,7 @@ struct radeon_cs_reloc *radeon_vm_get_bos(struct 
radeon_device *rdev,
list[idx].prefered_domains = RADEON_GEM_DOMAIN_VRAM;
list[idx].allowed_domains = RADEON_GEM_DOMAIN_VRAM;
list[idx].tv.bo = &list[idx].robj->tbo;
-   list[idx].tv.shared = false;
+   list[idx].tv.shared = true;
list[idx].tiling_flags = 0;
list[idx].handle = 0;
list_add(&list[idx++].tv.head, head);
@@ -388,35 +388,25 @@ static void radeon_vm_set_pages(struct radeon_device 
*rdev,
 static int radeon_vm_clear_bo(struct radeon_device *rdev,
  struct radeon_bo *bo)
 {
-struct ttm_validate_buffer tv;
-struct ww_acquire_ctx ticket;
-struct list_head head;
struct radeon_ib ib;
unsigned entries;
uint64_t addr;
int r;

-memset(&tv, 0, sizeof(tv));
-tv.bo = &bo->tbo;
-   tv.shared = false;
-
-INIT_LIST_HEAD(&head);
-list_add(&tv.head, &head);
-
-r = ttm_eu_reserve_buffers(&ticket, &head, true);
-if (r)
+   r = radeon_bo_reserve(bo, false);
+   if (r)
return r;

-r = ttm_bo_validate(&bo->tbo, &bo->placement, true, false);
-if (r)
-goto error;
+   r = ttm_bo_validate(&bo->tbo, &bo->placement, true, false);
+   if (r)
+   goto error_unreserve;

addr = radeon_bo_gpu_offset(bo);
entries = radeon_bo_size(bo) / 8;

r = radeon_ib_get(rdev, R600_RING_TYPE_DMA_INDEX, &ib, NULL, 256);
if (r)
-goto error;
+   goto error_unreserve;

ib.length_dw = 0;

@@ -426,15 +416,15 @@ static int radeon_vm_clear_bo(struct radeon_device *rdev,

r = radeon_ib_schedule(rdev, &ib, NULL, false);
if (r)
-goto error;
+   goto error_free;

-   ttm_eu_fence_buffer_objects(&ticket, &head, &ib.fence->base);
-   radeon_ib_free(rdev, &ib);
+   radeon_bo_fence(bo, ib.fence, false);

-   return 0;
+error_free:
+   radeon_ib_free(rdev, &ib);

-error:
-   ttm_eu_backoff_reservation(&ticket, &head);
+error_unreserve:
+   radeon_bo_unreserve(bo);
return r;
 }

@@ -707,6 +697,7 @@ int radeon_vm_update_page_directory(struct radeon_device 
*rdev,
radeon_ib_free(rdev, &ib);

[PATCH 09/11] drm/radeon: sync PD updates as shared

2014-11-19 Thread Christian König
From: Christian König 

We never invalidate PD entries and making them valid can
run with other users in parallel.

Signed-off-by: Christian König 
---
 drivers/gpu/drm/radeon/radeon_vm.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/radeon/radeon_vm.c 
b/drivers/gpu/drm/radeon/radeon_vm.c
index f457614..470451c 100644
--- a/drivers/gpu/drm/radeon/radeon_vm.c
+++ b/drivers/gpu/drm/radeon/radeon_vm.c
@@ -695,7 +695,7 @@ int radeon_vm_update_page_directory(struct radeon_device 
*rdev,
if (ib.length_dw != 0) {
radeon_asic_vm_pad_ib(rdev, &ib);

-   radeon_sync_resv(rdev, &ib.sync, pd->tbo.resv, false);
+   radeon_sync_resv(rdev, &ib.sync, pd->tbo.resv, true);
WARN_ON(ib.length_dw > ndw);
r = radeon_ib_schedule(rdev, &ib, NULL, false);
if (r) {
-- 
1.9.1



[PATCH 11/11] drm/radeon: update the VM after setting BO address v3

2014-11-19 Thread Christian König
From: Christian König 

This way the necessary VM update is kicked off immediately
if all BOs involved are in GPU accessible memory.

v2: fix vm lock
v3: immediately update unmaps as well

Signed-off-by: Christian König 
---
 drivers/gpu/drm/radeon/radeon_gem.c | 64 +
 1 file changed, 64 insertions(+)

diff --git a/drivers/gpu/drm/radeon/radeon_gem.c 
b/drivers/gpu/drm/radeon/radeon_gem.c
index f752c7f..2e0e370 100644
--- a/drivers/gpu/drm/radeon/radeon_gem.c
+++ b/drivers/gpu/drm/radeon/radeon_gem.c
@@ -518,6 +518,68 @@ out:
return r;
 }

+/**
+ * radeon_gem_va_update_vm -update the bo_va in its VM
+ *
+ * @rdev: radeon_device pointer
+ * @bo_va: bo_va to update
+ *
+ * Update the bo_va directly after setting it's address. Errors are not
+ * vital here, so they are not reported back to userspace.
+ */
+static void radeon_gem_va_update_vm(struct radeon_device *rdev,
+   struct radeon_bo_va *bo_va)
+{
+   struct ttm_validate_buffer tv, *entry;
+   struct radeon_cs_reloc *vm_bos;
+   struct ww_acquire_ctx ticket;
+   struct list_head list;
+   unsigned domain;
+   int r;
+
+   INIT_LIST_HEAD(&list);
+
+   tv.bo = &bo_va->bo->tbo;
+   tv.shared = true;
+   list_add(&tv.head, &list);
+
+   vm_bos = radeon_vm_get_bos(rdev, bo_va->vm, &list);
+   if (!vm_bos)
+   return;
+
+   r = ttm_eu_reserve_buffers(&ticket, &list, true);
+   if (r)
+   goto error_free;
+
+   list_for_each_entry(entry, &list, head) {
+   domain = radeon_mem_type_to_domain(entry->bo->mem.mem_type);
+   /* if anything is swapped out don't swap it in here,
+  just abort and wait for the next CS */
+   if (domain == RADEON_GEM_DOMAIN_CPU)
+   goto error_unreserve;
+   }
+
+   mutex_lock(&bo_va->vm->mutex);
+   r = radeon_vm_clear_freed(rdev, bo_va->vm);
+   if (r)
+   goto error_unlock;
+
+   if (bo_va->it.start)
+   r = radeon_vm_bo_update(rdev, bo_va, &bo_va->bo->tbo.mem);
+
+error_unlock:
+   mutex_unlock(&bo_va->vm->mutex);
+
+error_unreserve:
+   ttm_eu_backoff_reservation(&ticket, &list);
+
+error_free:
+   kfree(vm_bos);
+
+   if (r)
+   DRM_ERROR("Couldn't update BO_VA (%d)\n", r);
+}
+
 int radeon_gem_va_ioctl(struct drm_device *dev, void *data,
  struct drm_file *filp)
 {
@@ -612,6 +674,8 @@ int radeon_gem_va_ioctl(struct drm_device *dev, void *data,
default:
break;
}
+   if (!r)
+   radeon_gem_va_update_vm(rdev, bo_va);
args->operation = RADEON_VA_RESULT_OK;
if (r) {
args->operation = RADEON_VA_RESULT_ERROR;
-- 
1.9.1



[PATCH 11/11] drm/radeon: update the VM after setting BO address v3

2014-11-19 Thread Kai Wasserbäch
Dear Christian,
Christian König wrote on 19.11.2014 14:01:
> From: Christian König 
> 
> This way the necessary VM update is kicked off immediately
> if all BOs involved are in GPU accessible memory.
> 
> v2: fix vm lock
> v3: immediately update unmaps as well
> 
> Signed-off-by: Christian König 
> ---
>  drivers/gpu/drm/radeon/radeon_gem.c | 64 
> +
>  1 file changed, 64 insertions(+)

Is this a fix for <http://thread.gmane.org/gmane.comp.video.dri.devel/118415>
which I bisected to the v2 of this patch
(<http://thread.gmane.org/gmane.comp.video.dri.devel/118415/focus=118425>) as
present on the drm-next-3.19-wip branch?

Cheers,
Kai

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


[RFC PATCH 1/3] drm/exynos: make kms drivers to be independent modules

2014-11-19 Thread Inki Dae
2014-11-19 17:49 GMT+09:00 Andrzej Hajda :
> On 11/18/2014 04:26 PM, Inki Dae wrote:
>> This patch makes kms drivers to be independent modules.
>> For this, it removes all register codes to kms drivers
>> from exynos_drm_drv module and adds module_init/exit
>> for each kms driver so that each kms driver can be
>> called independently.
>
>
> It is hard to test if modules are working because I am not able to build
> modules :), see comments below.
>
>
>>
>> Signed-off-by: Inki Dae 
>> ---
>>  drivers/gpu/drm/exynos/Kconfig   |8 +++---
>>  drivers/gpu/drm/exynos/exynos_dp_core.c  |   13 +
>>  drivers/gpu/drm/exynos/exynos_drm_drv.c  |   43 
>> +++---
>>  drivers/gpu/drm/exynos/exynos_drm_drv.h  |5 
>>  drivers/gpu/drm/exynos/exynos_drm_dsi.c  |   13 +
>>  drivers/gpu/drm/exynos/exynos_drm_fimd.c |   13 +
>>  drivers/gpu/drm/exynos/exynos_hdmi.c |   13 +
>>  drivers/gpu/drm/exynos/exynos_mixer.c|   13 +
>>  8 files changed, 72 insertions(+), 49 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/exynos/Kconfig b/drivers/gpu/drm/exynos/Kconfig
>> index 7f9f6f9..3d5fa69 100644
>> --- a/drivers/gpu/drm/exynos/Kconfig
>> +++ b/drivers/gpu/drm/exynos/Kconfig
>> @@ -25,7 +25,7 @@ config DRM_EXYNOS_DMABUF
>> Choose this option if you want to use DMABUF feature for DRM.
>>
>>  config DRM_EXYNOS_FIMD
>> - bool "Exynos DRM FIMD"
>> + tristate "Exynos DRM FIMD"
>>   depends on DRM_EXYNOS && !FB_S3C
>>   select FB_MODE_HELPERS
>>   select MFD_SYSCON
>> @@ -41,7 +41,7 @@ config DRM_EXYNOS_DPI
>> This enables support for Exynos parallel output.
>>
>>  config DRM_EXYNOS_DSI
>> - bool "EXYNOS DRM MIPI-DSI driver support"
>> + tristate "EXYNOS DRM MIPI-DSI driver support"
>>   depends on DRM_EXYNOS_FIMD
>>   select DRM_MIPI_DSI
>>   select DRM_PANEL
>> @@ -50,7 +50,7 @@ config DRM_EXYNOS_DSI
>> This enables support for Exynos MIPI-DSI device.
>>
>>  config DRM_EXYNOS_DP
>> - bool "EXYNOS DRM DP driver support"
>> + tristate "EXYNOS DRM DP driver support"
>>   depends on DRM_EXYNOS_FIMD && ARCH_EXYNOS && (DRM_PTN3460=n || 
>> DRM_PTN3460=y || DRM_PTN3460=DRM_EXYNOS)
>>   default DRM_EXYNOS
>>   select DRM_PANEL
>> @@ -58,7 +58,7 @@ config DRM_EXYNOS_DP
>> This enables support for DP device.
>>
>>  config DRM_EXYNOS_HDMI
>> - bool "Exynos DRM HDMI"
>> + tristate "Exynos DRM HDMI"
>>   depends on DRM_EXYNOS && !VIDEO_SAMSUNG_S5P_TV
>>   help
>> Choose this option if you want to use Exynos HDMI for DRM.
>
>
> Without corresponding changes in Makefiles you cannot build it as modules.
>
>
>> diff --git a/drivers/gpu/drm/exynos/exynos_dp_core.c 
>> b/drivers/gpu/drm/exynos/exynos_dp_core.c
>> index ed818b9..b08d97b 100644
>> --- a/drivers/gpu/drm/exynos/exynos_dp_core.c
>> +++ b/drivers/gpu/drm/exynos/exynos_dp_core.c
>> @@ -1408,6 +1408,19 @@ struct platform_driver dp_driver = {
>>   },
>>  };
>>
>> +static int exynos_dp_init(void)
>> +{
>> + return platform_driver_register(&dp_driver);
>> +}
>> +
>> +static void exynos_dp_exit(void)
>> +{
>> + platform_driver_unregister(&dp_driver);
>> +}
>> +
>> +module_init(exynos_dp_init);
>> +module_exit(exynos_dp_exit);
>> +
>
> Here and in other modules you can use module_platform_driver macro.
>
>>  MODULE_AUTHOR("Jingoo Han ");
>>  MODULE_DESCRIPTION("Samsung SoC DP Driver");
>>  MODULE_LICENSE("GPL v2");
>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c 
>> b/drivers/gpu/drm/exynos/exynos_drm_drv.c
>> index eab12f0..02d4772 100644
>> --- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
>> +++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
>> @@ -484,12 +484,6 @@ static struct component_match 
>> *exynos_drm_match_add(struct device *dev)
>>
>>   mutex_lock(&drm_component_lock);
>>
>> - /* Do not retry to probe if there is no any kms driver regitered. */
>> - if (list_empty(&drm_component_list)) {
>> - mutex_unlock(&drm_component_lock);
>> - return ERR_PTR(-ENODEV);
>> - }
>> -
>
> It is hard to guess how and why it should work with modules.
> For example what should happen if fimd/dsi modules are loaded but
> hdmi/mixer not. When exynos_drv should wait with initialization for hdmi

Right, hdmi/mixer cannot be probed, which means module doesn't work correctly.

> and when it should create drmdev.
>
> DRM system is rather monolithic splitting its components to modules
> seems strange.

Yes, good point. I missed a big point that DRM system should be
monolithic, integrated driver.
However I strongly think it's better to separate them into independent
drivers so that entry point of each sub driver can be called itself.
With this, the probe order of each sub driver can be handled by
component and Exynos drm core properly. it's really not good for all
register codes of sub drivers to be placed in exynos_drm_drv,
and this was my plan for cleanning up Ex

[PATCH v12 1/3] drm: rockchip: Add basic drm driver

2014-11-19 Thread Daniel Vetter
On Wed, Nov 19, 2014 at 10:04:13AM +0100, Boris Brezillon wrote:
> AFAIU, the suggestion was to split drm_connector_init and
> drm_connector_register calls:
>  - drm_connector_init call should still be part of the load procedure
>(this function adds the connector to the connector list which is used
>by drm_mode_group_init_legacy_group)
>  - drm_connector_register should be called after the device has been
>registered
> 
> Here what I've done and it seems to work:
> 
> static int atmel_hlcdc_dc_connector_plug_all(struct drm_device *dev)
> {
>   struct drm_connector *connector, *failed;
>   int ret;
> 
>   mutex_lock(&dev->mode_config.mutex);
>   list_for_each_entry(connector,
>   &dev->mode_config.connector_list, head) { ret =
>   drm_connector_register(connector); if (ret) {
>   failed = connector;
>   goto err;
>   }
>   }
>   mutex_unlock(&dev->mode_config.mutex);
>   return 0;
> 
> err:
>   list_for_each_entry(connector, &dev->mode_config.connector_list, head) {
>   if (failed == connector)
>   break;
> 
>   drm_connector_unregister(connector);
>   }
>   mutex_unlock(&dev->mode_config.mutex);
> 
>   return ret;
> }
> 
> [...]
> 
> static int atmel_hlcdc_dc_drm_probe(struct platform_device *pdev)
> {
>   struct drm_device *ddev;
>   int ret;
> 
>   ddev = drm_dev_alloc(&atmel_hlcdc_dc_driver, &pdev->dev);
>   if (!ddev)
>   return -ENOMEM;
> 
>   ret = drm_dev_set_unique(ddev, dev_name(ddev->dev));
>   if (ret)
>   goto err_unref;
> 
>   ret = atmel_hlcdc_dc_load(ddev);
>   if (ret)
>   goto err_unref;
> 
>   ret = drm_dev_register(ddev, 0);
>   if (ret)
>   goto err_unload;
> 
>   ret = atmel_hlcdc_dc_connector_plug_all(ddev);
>   if (ret)
>   goto err_unregister;
> 
>   return 0;
> 
> err_unregister:
>   drm_dev_unregister(ddev);
> 
> err_unload:
>   atmel_hlcdc_dc_unload(ddev);
> 
> err_unref:
>   drm_dev_unref(ddev);
> 
>   return ret;
> }
> 
> Daniel, can you confirm that's what you had in mind ?

Yup. To be able to have race-free driver load we need to split object
into an _init step (allocates structs and links to kernel-internal lists)
and _register (makes the object userspace-visible through sysfs and
dev-node kms object lookup idr).

This entire mess is all still fallout from the dark ages of the drm
midlayer and we'll probably have fun with this for another few years ;-)
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch


[RFC] drm: Start documenting userspace ABI

2014-11-19 Thread Daniel Vetter
On Tue, Nov 18, 2014 at 04:24:39PM +0100, Thierry Reding wrote:
> On Tue, Nov 18, 2014 at 04:05:08PM +0100, David Herrmann wrote:
> > Hi
> > 
> > On Tue, Nov 18, 2014 at 3:43 PM, Thierry Reding
> >  wrote:
> > > On Tue, Nov 18, 2014 at 03:27:27PM +0100, Daniel Vetter wrote:
> > >> On Tue, Nov 18, 2014 at 03:19:33PM +0100, Thierry Reding wrote:
> > >> > From: Thierry Reding 
> > >> >
> > >> > After seeing how the DRM_IOCTL_MODE_CREATE_DUMB was implemented with
> > >> > different semantics on different drivers it seems like a good idea to
> > >> > start to more rigorously document userspace ABI to avoid these things
> > >> > in the future.
> > >> >
> > >> > This is a first draft of what such documentation could look like. Not
> > >> > all IOCTLs are documented and some explanation about the other system
> > >> > calls (mmap(), poll(), read(), ...) would be good too. But I wanted to
> > >> > send this out for early review to see if the direction is reasonable.
> > >> > If so my plan is to continue to chip away at this as I find time.
> > >> >
> > >> > Signed-off-by: Thierry Reding 
> > >>
> > >> Imo for ioctls the right thing to do is having proper manpages, not
> > >> kerneldoc or DocBook sections. manpages really lend themselves well to
> > >> specify all the different facets of a single interface.
> > >
> > > I don't think I've ever seen manpages document IOCTLs at this level of
> > > detail. The intention of this is to add documentation about the IOCTLs
> > > at the kernel/userspace transition. Keeping this in the kernel has the
> > > advantage that it's a whole lot easier to keep updated, much like what
> > > we do with the other kerneldoc.
> > >
> > > That doesn't mean we shouldn't have manpages, but I think both are for
> > > the most part orthogonal, even though they may describe various facets
> > > of the same interfaces.
> > 
> > tty_ioctl(4)
> > console_ioctl(4)
> > 
> > I think a similar man-page ala drm_ioctl(4) makes a lot of sense.
> > 
> > >> Also, we already have some skeleton of that in libdrm, so I think
> > >> extending that would be best.
> > >
> > > One other reason why I don't think libdrm is the best fit for this is
> > > that libdrm is just one userspace implementation abstracting away the
> > > interfaces that this describes. Not everyone will use libdrm. So in my
> > > opinion its great if libdrm documents the API that it exposes, but I
> > > don't think it should document the kernel interfaces that it uses. The
> > > kernel exposes them, so it should provide the documentation for it as
> > > well.
> > 
> > I don't mind documenting this in the kernel-doc. But if we start
> > something like drm_ioctl(4) (I pushed some more generic man-pages to
> > libdrm a few years ago), we have this documented in 2 places, which is
> > always annoying for updates.
> 
> I wonder if it would somehow be possible to generate manpages from the
> DocBook to avoid this duplication. One of the things that
> DRM_IOCTL_MODE_CREATE_DUMB showed is that both drivers and userspace can
> interpret things wrongly, and I fear that if all we have is a manpage to
> document the IOCTLs, people writing the drivers may not be tempted
> enough to read that manpage. So I think we want documentation for both
> driver and userspace developers.

Imo docs don't help with that kind of fumble, only nasty testcases will.
People only read docs when they don't understand stuff (i.e. trying to
write drivers). Imo manpages an ioctl docs are only really good for
designing the interface (since it forces you to really think through the
semantics to be able to describe them concisely and precisely). But even
there I think having solid testcases is better invested time.

Documentation for developers is imo an entirely different matter, I think
that gets used a lot more. Or at least I find them fairly useful.

> Documenting this within the kernel is also pretty easy. I know that I'll
> be much more tempted to do it within the kernel than if I have to switch
> to some other repository, build system and whatnot.
> 
> Perhaps in this case having two places where it's documented isn't all
> that bad. It's ABI after all, so the documentation never needs to
> change. Theoretically.
> 
> > And even if people don't use libdrm, I think it's totally acceptable
> > to ship man-pages with libdrm. Distributions are free to provide
> > drm-man-pages as stand-alone package (which is _really_ easy to
> > generate from libdrm).
> 
> I guess one other home for these could be the man-pages project on
> kernel.org. It's what carries most (all?) of the Linux kernel-specific
> man-pages (like the tty_ioctl and console_ioctl ones that you referred
> to).

There has been talks about merging the linux manpages back into the kernel
actually. But yeah that seems like a good home, especially since Micheal
Kerrisk seems pretty sharp with reviewing manpages.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch


[PATCH 11/11] drm/radeon: update the VM after setting BO address v3

2014-11-19 Thread Christian König
Am 19.11.2014 um 14:16 schrieb Kai Wasserbäch:
> Dear Christian,
> Christian König wrote on 19.11.2014 14:01:
>> From: Christian König 
>>
>> This way the necessary VM update is kicked off immediately
>> if all BOs involved are in GPU accessible memory.
>>
>> v2: fix vm lock
>> v3: immediately update unmaps as well
>>
>> Signed-off-by: Christian König 
>> ---
>>   drivers/gpu/drm/radeon/radeon_gem.c | 64 
>> +
>>   1 file changed, 64 insertions(+)
> Is this a fix for 
> which I bisected to the v2 of this patch
> () as
> present on the drm-next-3.19-wip branch?

Yes and no, it was actually the patch before this one which triggered 
the problem. The last one just made it much more likely to appear.

Please test the whole patchset on top of Dave's drm-next tree if your 
problem still exists.

Thanks,
Christian.

>
> Cheers,
> Kai
>



[PATCH v8 0/2] drm: add support for Atmel HLCDC Display Controller

2014-11-19 Thread Boris Brezillon
Hello,

This patch series adds support for the Atmel HLCDC Display Controller
embedded in the HLCDC block.

The drivers supports basic CRTC functionalities, several overlays and
provides an hardware cursor.

At the moment, it only supports connection to LCD panels through an RGB
connector (defined as an LVDS connector in my implementation), though
connection to other kind of devices (like DRM bridges) could be added later.

It also supports several RGB formats on all planes and some YUV formats on
the HEO overlay plane.

Best Regards,

Boris

Changes since v7:
 - split MFD, PWM and Display Controller drivers in several patch series
 - fix inline documentation (suggested by Nicolas)
 - fix DMA BURST LEN config (suggested by Nicolas)
 - call load and unload in probe and remove functions instead of setting
   them in drm_driver struct

Changes since v6:
- move interrupts property from hlcdc display controller node to its
  parent node (the MFD device)
- add mode_set_base implementation
- rework page flip handling to rely on vblank events instead of DMA
  transfer events (the end of a DMA transfer does not mean the frame
  is actually flipped: data are first copied to an output FIFO before
  being sent on the RGB/DPI connector)
- few minor coding style fixes

Changes since v5:
- fix Kconfig dependency bug
- use adjusted mode in crtc config
- move signal config (clk, hsync, vsync) from connector to crtc mode_set
  function
- use standard rotation property
- check display_mode validity in connecto mode_valid function
- remove dma_set_coherent mask call (now done in MFD core)
- do not use drm_platform_init

Changes since v4:
- fix a few more bugs in rotation handling (rotation was buggy on some
  formats)
- return connector_status_unknown until a panel is exposed by the
  drm_panel infrastructure (prevent fbdev creation until everyting is
  in place)
- rework Kconfig MFD_ATMEL_HLCDC selection to simplify the configuration
  (automatically select this option when selecting the HLCDC PMW or DRM
  driver, instead of depending on this option)

Changes since v3:
- rework the layer code to simplify several parts (locking and layer
  disabling)
- make use of the drm_flip_work infrastructure
- rely on default HW cursor implementation using on the cursor plane
- rework the display controller DT bindings (based on OF graph
  representation)
- add rotation support
- retrive RGB bus format from drm_display_info
- drop the dynamic pinctrl state selection
- rework HLCDC output handling (previously specialized to interface
  with LCD panels)
- drop ".module = THIS_MODULE" lines
- change display controller compatible string

Changes since v2:
- fix coding style issues (macro indentation)
- make use of GENMASK in several places
- declare regmap config as a static structure
- rework hlcdc plane update API
- rework cursor handling to make use of the new plane update API
- fix backporch config
- do not use devm_regmap_init_mmio_clk to avoid extra clk_enable
  clk disable calls when accessing registers
- explicitely include regmap and clk headers instead of relying on
  atmel-hlcdc.h inclusions
- make the atmel-hlcdc driver depends on CONFIG_OF
- separate DT bindings documentation from driver implementation
- support several pin muxing for HLCDC pins on sama5d3 SoCs

Changes since v1:
- replace the backlight driver by a PWM driver
- make use of drm_panel infrastructure
- split driver code in several subsystem: MFD, PWM and DRM
- add support for overlays
- add support for hardware cursor

Boris Brezillon (2):
  drm: add Atmel HLCDC Display Controller support
  drm: add DT bindings documentation for atmel-hlcdc-dc driver

 .../devicetree/bindings/drm/atmel/hlcdc-dc.txt |  53 ++
 drivers/gpu/drm/Kconfig|   2 +
 drivers/gpu/drm/Makefile   |   1 +
 drivers/gpu/drm/atmel-hlcdc/Kconfig|  11 +
 drivers/gpu/drm/atmel-hlcdc/Makefile   |   7 +
 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c | 406 ++
 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c   | 579 ++
 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.h   | 213 +
 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_layer.c| 667 
 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_layer.h| 398 ++
 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_output.c   | 323 
 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c| 856 +
 12 files changed, 3516 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/drm/atmel/hlcdc-dc.txt
 create mode 100644 drivers/gpu/drm/atmel-hlcdc/Kconfig
 create mode 100644 drivers/gpu/drm/atmel-hlcdc/Makefile
 create mode 100644 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c
 create mode 100644 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
 create mode 100644 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.h
 create mode 100644 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_layer.c
 create mode 100644 drivers/gpu/drm/atmel-hlcdc/

[PATCH v8 1/2] drm: add Atmel HLCDC Display Controller support

2014-11-19 Thread Boris Brezillon
The Atmel HLCDC (HLCD Controller) IP available on some Atmel SoCs (i.e.
at91sam9n12, at91sam9x5 family or sama5d3 family) provides a display
controller device.

This display controller supports at least one primary plane and might
provide several overlays and an hardware cursor depending on the IP
version.

At the moment, this driver only implements an RGB connector to interface
with LCD panels, but support for other kind of external devices might be
added later.

Signed-off-by: Boris Brezillon 
Reviewed-by: Rob Clark 
Tested-by: Anthony Harivel 
Tested-by: Ludovic Desroches 
---
 drivers/gpu/drm/Kconfig  |   2 +
 drivers/gpu/drm/Makefile |   1 +
 drivers/gpu/drm/atmel-hlcdc/Kconfig  |  11 +
 drivers/gpu/drm/atmel-hlcdc/Makefile |   7 +
 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c   | 406 +++
 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c | 579 +++
 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.h | 213 ++
 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_layer.c  | 667 ++
 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_layer.h  | 398 +++
 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_output.c | 323 +
 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c  | 856 +++
 11 files changed, 3463 insertions(+)
 create mode 100644 drivers/gpu/drm/atmel-hlcdc/Kconfig
 create mode 100644 drivers/gpu/drm/atmel-hlcdc/Makefile
 create mode 100644 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c
 create mode 100644 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
 create mode 100644 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.h
 create mode 100644 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_layer.c
 create mode 100644 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_layer.h
 create mode 100644 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_output.c
 create mode 100644 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c

diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index e3b4b0f..7b0f7fe 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -181,6 +181,8 @@ source "drivers/gpu/drm/cirrus/Kconfig"

 source "drivers/gpu/drm/armada/Kconfig"

+source "drivers/gpu/drm/atmel-hlcdc/Kconfig"
+
 source "drivers/gpu/drm/rcar-du/Kconfig"

 source "drivers/gpu/drm/shmobile/Kconfig"
diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index 9292a76..223dbca 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -53,6 +53,7 @@ obj-$(CONFIG_DRM_GMA500) += gma500/
 obj-$(CONFIG_DRM_UDL) += udl/
 obj-$(CONFIG_DRM_AST) += ast/
 obj-$(CONFIG_DRM_ARMADA) += armada/
+obj-$(CONFIG_DRM_ATMEL_HLCDC)  += atmel-hlcdc/
 obj-$(CONFIG_DRM_RCAR_DU) += rcar-du/
 obj-$(CONFIG_DRM_SHMOBILE) +=shmobile/
 obj-$(CONFIG_DRM_OMAP) += omapdrm/
diff --git a/drivers/gpu/drm/atmel-hlcdc/Kconfig 
b/drivers/gpu/drm/atmel-hlcdc/Kconfig
new file mode 100644
index 000..1a08562
--- /dev/null
+++ b/drivers/gpu/drm/atmel-hlcdc/Kconfig
@@ -0,0 +1,11 @@
+config DRM_ATMEL_HLCDC
+   tristate "DRM Support for ATMEL HLCDC Display Controller"
+   depends on DRM && OF && COMMON_CLK && MFD_ATMEL_HLCDC
+   select DRM_GEM_CMA_HELPER
+   select DRM_KMS_HELPER
+   select DRM_KMS_FB_HELPER
+   select DRM_KMS_CMA_HELPER
+   select DRM_PANEL
+   help
+ Choose this option if you have an ATMEL SoC with an HLCDC display
+ controller (i.e. at91sam9n12, at91sam9x5 family or sama5d3 family).
diff --git a/drivers/gpu/drm/atmel-hlcdc/Makefile 
b/drivers/gpu/drm/atmel-hlcdc/Makefile
new file mode 100644
index 000..10ae426
--- /dev/null
+++ b/drivers/gpu/drm/atmel-hlcdc/Makefile
@@ -0,0 +1,7 @@
+atmel-hlcdc-dc-y := atmel_hlcdc_crtc.o \
+   atmel_hlcdc_dc.o \
+   atmel_hlcdc_layer.o \
+   atmel_hlcdc_output.o \
+   atmel_hlcdc_plane.o
+
+obj-$(CONFIG_DRM_ATMEL_HLCDC)  += atmel-hlcdc-dc.o
diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c 
b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c
new file mode 100644
index 000..0409b90
--- /dev/null
+++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c
@@ -0,0 +1,406 @@
+/*
+ * Copyright (C) 2014 Traphandler
+ * Copyright (C) 2014 Free Electrons
+ *
+ * Author: Jean-Jacques Hiblot 
+ * Author: Boris BREZILLON 
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published by
+ * the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License along with
+ * this program.  If not, see .
+ */
+
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+
+#include 
+
+#in

[PATCH v8 2/2] drm: add DT bindings documentation for atmel-hlcdc-dc driver

2014-11-19 Thread Boris Brezillon
The Atmel HLCDC (HLCD Controller) IP available on some Atmel SoCs (i.e.
at91sam9n12, at91sam9x5 family or sama5d3 family) provides a display
controller device.

The HLCDC block provides a single RGB output port, and only supports LCD
panels connection to LCD panels for now.

The atmel,panel property link the HLCDC RGB output with the LCD panel
connected on this port (note that the HLCDC RGB connector implementation
makes use of the DRM panel framework).

Connection to other external devices (DRM bridges) might be added later by
mean of a new atmel,xxx (atmel,bridge) property.

Signed-off-by: Boris Brezillon 
---
 .../devicetree/bindings/drm/atmel/hlcdc-dc.txt | 53 ++
 1 file changed, 53 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/drm/atmel/hlcdc-dc.txt

diff --git a/Documentation/devicetree/bindings/drm/atmel/hlcdc-dc.txt 
b/Documentation/devicetree/bindings/drm/atmel/hlcdc-dc.txt
new file mode 100644
index 000..ebc1a91
--- /dev/null
+++ b/Documentation/devicetree/bindings/drm/atmel/hlcdc-dc.txt
@@ -0,0 +1,53 @@
+Device-Tree bindings for Atmel's HLCDC (High LCD Controller) DRM driver
+
+The Atmel HLCDC Display Controller is subdevice of the HLCDC MFD device.
+See ../mfd/atmel-hlcdc.txt for more details.
+
+Required properties:
+ - compatible: value should be "atmel,hlcdc-display-controller"
+ - pinctrl-names: the pin control state names. Should contain "default".
+ - pinctrl-0: should contain the default pinctrl states.
+ - #address-cells: should be set to 1.
+ - #size-cells: should be set to 0.
+
+Required children nodes:
+ Children nodes are encoding available output ports and their connections
+ to external devices using the OF graph reprensentation (see ../graph.txt).
+ At least one port node is required.
+
+Example:
+
+   hlcdc: hlcdc at f003 {
+   compatible = "atmel,sama5d3-hlcdc";
+   reg = <0xf003 0x2000>;
+   interrupts = <36 IRQ_TYPE_LEVEL_HIGH 0>;
+   clocks = <&lcdc_clk>, <&lcdck>, <&clk32k>;
+   clock-names = "periph_clk","sys_clk", "slow_clk";
+   status = "disabled";
+
+   hlcdc-display-controller {
+   compatible = "atmel,hlcdc-display-controller";
+   pinctrl-names = "default";
+   pinctrl-0 = <&pinctrl_lcd_base &pinctrl_lcd_rgb888>;
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   port at 0 {
+   #address-cells = <1>;
+   #size-cells = <0>;
+   reg = <0>;
+
+   hlcdc_panel_output: endpoint at 0 {
+   reg = <0>;
+   remote-endpoint = <&panel_input>;
+   };
+   };
+   };
+
+   hlcdc_pwm: hlcdc-pwm {
+   compatible = "atmel,hlcdc-pwm";
+   pinctrl-names = "default";
+   pinctrl-0 = <&pinctrl_lcd_pwm>;
+   #pwm-cells = <3>;
+   };
+   };
-- 
1.9.1



[PATCH] device coredump: fix minor issue in Kconfig file

2014-11-19 Thread Johannes Berg
On Wed, 2014-11-19 at 05:28 -0800, Amitkumar Karwar wrote:
> if "CONFIG_DEV_COREDUMP=y" is added to configuration file, it
> gets removed when final configuration file is generated. The
> reason is it requires CONFIG_WANT_DEV_COREDUMP to be enabled.
> 
> Currently "make menuconfig" doesn't display an option to enable
> WANT_DEV_COREDUMP. This patch updates Kconfig so that user can
> enable WANT_DEV_COREDUMP.

This is completely intentional - drivers should "select
WANT_DEV_COREDUMP" and users are only able to set "ALLOW_DEV_COREDUMP=n"
to prevent it.

johannes



[Bug 88481] Kernel oops leaves system without graphical output [radeon]

2014-11-19 Thread bugzilla-dae...@bugzilla.kernel.org
https://bugzilla.kernel.org/show_bug.cgi?id=88481

--- Comment #6 from Daniel Otero  ---
Reverting the commit ffe0245532b98efc4bc0e06f29c51d3f0e471152 from the tag
v3.17.3 does resolve the issue.

Thanks for your time.

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


[Bug 86320] Monitor on DisplayPort doesn't wake up

2014-11-19 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=86320

--- Comment #3 from Stefan Brüns  ---
Please attach the whole dmesg output/Xorg log, as requested. Otherwise it is
really difficult to get the whole picture.

Currently, there is no information provided by you indicating kernel version,
XOrg server version, radeon xorg driver version, distribution. All this would
be available when you provided the full logs.

-- 
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/20141119/8a3014cc/attachment.html>


[PATCH 11/11] drm/radeon: update the VM after setting BO address v3

2014-11-19 Thread Kai Wasserbäch
6d64134c3a315b77deecc9252) and "git am"-applied your series (no
issues, applied cleanly) on top. Steam games are still entering the defunct
state as soon as the 3D engines are fired up on a kernel built from that source
tree.

This is with (Debian testing as a base):
GPU: Hawaii PRO [Radeon R9 290] (ChipID = 0x67b1)
Mesa: Git:master/b69c7c5dac
libdrm: Git:master/00847fa48b
LLVM: SVN:trunk/r54 (3.6 devel)
X.Org: 2:1.16.1-1
Firmware: <http://people.freedesktop.org/~agd5f/radeon_ucode/>
# 9e05820da42549ce9c89d147cf1f8e19  hawaii_ce.bin
# c8bab593090fc54f239c8d7596c8d846  hawaii_mc.bin
# 3618dbb955d8a84970e262bb2e6d2a16  hawaii_me.bin
# c000b0fc9ff6582145f66504b0ec9597  hawaii_mec.bin
# 0643ad24b3beff2214cce533e094c1b7  hawaii_pfp.bin
# ba6054b7d78184a74602fd81607e1386  hawaii_rlc.bin
# 11288f635737331b69de9ee82fe04898  hawaii_sdma.bin
# 284429675a5560e0fad42aa982965fc2  hawaii_smc.bin
libclc: Git:master/7f6f5bff1f
DDX: 1:7.5.0-1

Let me know, if you need something else; see also the original thread
<http://thread.gmane.org/gmane.comp.video.dri.devel/118415> for further 
information.

Cheers,
Kai

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


[Bug 88501] New: AMD/ATI RS690M Console blanks to white

2014-11-19 Thread bugzilla-dae...@bugzilla.kernel.org
https://bugzilla.kernel.org/show_bug.cgi?id=88501

Bug ID: 88501
   Summary: AMD/ATI RS690M Console blanks to white
   Product: Drivers
   Version: 2.5
Kernel Version: 3.6.0-rc5 to 3.18.0-rc4
  Hardware: x86-64
OS: Linux
  Tree: Mainline
Status: NEW
  Severity: normal
  Priority: P1
 Component: Video(DRI - non Intel)
  Assignee: drivers_video-dri at kernel-bugs.osdl.org
  Reporter: business.kid at gmail.com
Regression: Yes

Created attachment 158181
  --> https://bugzilla.kernel.org/attachment.cgi?id=158181&action=edit
Git Bisect log, & git visualise o/p

Without X running, linux consoles blank after a period adjustable by setterm.
Mine does not. It goes white. If I invert the screen colours, it goes whiter.
Backlight?
I cloned the Linus-stable git and tried it. 3.18.0-rc4 twists this slightly -
The FIRST time the screen blanks, it does so correctly; every other time, it
blanks to white. 
I'm a hardware guy, not a software expert. Git bisect gives the output below.
Details of the box also attached

The box is a HP 6715S, twin core Turion, 3G ram. It's running Slackware-current
as of Sept 30th, 2014. LSPCI output attached. Bios Version: ATI 02/13/08,1.

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


[Bug 88501] AMD/ATI RS690M Console blanks to white

2014-11-19 Thread bugzilla-dae...@bugzilla.kernel.org
https://bugzilla.kernel.org/show_bug.cgi?id=88501

--- Comment #1 from business.kid at gmail.com ---
Created attachment 158191
  --> https://bugzilla.kernel.org/attachment.cgi?id=158191&action=edit
LSPCI -vnn

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


[Bug 88481] Kernel oops leaves system without graphical output [radeon]

2014-11-19 Thread bugzilla-dae...@bugzilla.kernel.org
https://bugzilla.kernel.org/show_bug.cgi?id=88481

Daniel Otero  changed:

   What|Removed |Added

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

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


[Bug 82186] [r600g] BARTS GPU lockup with minecraft shaders

2014-11-19 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=82186

--- Comment #7 from Alex Deucher  ---
possibly related bug 73528.

-- 
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/20141119/76751ce7/attachment.html>


[Bug 88501] AMD/ATI RS690M Console blanks to white

2014-11-19 Thread bugzilla-dae...@bugzilla.kernel.org
https://bugzilla.kernel.org/show_bug.cgi?id=88501

--- Comment #2 from business.kid at gmail.com ---
Created attachment 158201
  --> https://bugzilla.kernel.org/attachment.cgi?id=158201&action=edit
Kernel Config 3.6.0-rc5+

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


[PATCH 11/11] drm/radeon: update the VM after setting BO address v3

2014-11-19 Thread Christian König
] ? _raw_spin_unlock_irqrestore+0xc/0xd
> [  117.820303]  [] ? radeon_drm_ioctl+0x4b/0x7a [radeon]
> [  117.820331]  [] ? do_vfs_ioctl+0x34e/0x404
> [  117.820355]  [] ? vfs_read+0xbc/0xea
> [  117.820377]  [] ? SyS_ioctl+0x51/0x77
> [  117.820398]  [] ? system_call_fastpath+0x12/0x17
> [  117.820423] Code: 00 00 80 ff 77 00 00 48 01 fa 48 0f 42 0d 78 99 6f 00 48 
> 8d
> 04 11 48 ba 00 00 00 00 00 ea ff ff 48 c1 e8 0c 48 6b c0 38 48 01 d0 <48> 8b 
> 10
> 80 e6 80 74 0e 48 8b 50 30 48 8b 08 80 e5 80 48 0f 45
> [  117.820582] RIP  [] virt_to_head_page+0x33/0x4a
> [  117.820608]  RSP 
> [  117.820622] CR2: eae3801564d8
> [  117.838461] ---[ end trace a6e2a6aa1df3196f ]---
>
> I've used Dave Airlie's drm-next as a base (commit
> d0d6c524bf1d72e6d64134c3a315b77deecc9252) and "git am"-applied your series (no
> issues, applied cleanly) on top. Steam games are still entering the defunct
> state as soon as the 3D engines are fired up on a kernel built from that 
> source
> tree.
>
> This is with (Debian testing as a base):
> GPU: Hawaii PRO [Radeon R9 290] (ChipID = 0x67b1)
> Mesa: Git:master/b69c7c5dac
> libdrm: Git:master/00847fa48b
> LLVM: SVN:trunk/r54 (3.6 devel)
> X.Org: 2:1.16.1-1
> Firmware: <http://people.freedesktop.org/~agd5f/radeon_ucode/>
> # 9e05820da42549ce9c89d147cf1f8e19  hawaii_ce.bin
> # c8bab593090fc54f239c8d7596c8d846  hawaii_mc.bin
> # 3618dbb955d8a84970e262bb2e6d2a16  hawaii_me.bin
> # c000b0fc9ff6582145f66504b0ec9597  hawaii_mec.bin
> # 0643ad24b3beff2214cce533e094c1b7  hawaii_pfp.bin
> # ba6054b7d78184a74602fd81607e1386  hawaii_rlc.bin
> # 11288f635737331b69de9ee82fe04898  hawaii_sdma.bin
> # 284429675a5560e0fad42aa982965fc2  hawaii_smc.bin
> libclc: Git:master/7f6f5bff1f
> DDX: 1:7.5.0-1
>
> Let me know, if you need something else; see also the original thread
> <http://thread.gmane.org/gmane.comp.video.dri.devel/118415> for further 
> information.
>
> Cheers,
> Kai
>

-- next part --
A non-text attachment was scrubbed...
Name: 0001-drm-radeon-update-the-VM-after-setting-BO-address-v4.patch
Type: text/x-diff
Size: 2831 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141119/253ea8dc/attachment.patch>


[Bug 88481] Kernel oops leaves system without graphical output [radeon]

2014-11-19 Thread bugzilla-dae...@bugzilla.kernel.org
https://bugzilla.kernel.org/show_bug.cgi?id=88481

Alex Deucher  changed:

   What|Removed |Added

 CC||alexdeucher at gmail.com

--- Comment #7 from Alex Deucher  ---
Should be fixed by
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=83d04c39f9048807a8500e575ae3f1718a3f45bb
which needs to go to stable.

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


[PULL] drm-intel-fixes

2014-11-19 Thread Jani Nikula

Hi Dave, couple of regression fixes, both cc: stable.

BR,
Jani.

The following changes since commit fc14f9c1272f62c3e8d01300f52467c0d9af50f9:

  Linux 3.18-rc5 (2014-11-16 16:36:20 -0800)

are available in the git repository at:

  git://anongit.freedesktop.org/drm-intel tags/drm-intel-fixes-2014-11-19

for you to fetch changes up to 0485c9dc24ec0939b42ca5104c0373297506b555:

  drm/i915: Kick fbdev before vgacon (2014-11-17 10:18:21 +0200)


Daniel Vetter (2):
  drm/i915: drop WaSetupGtModeTdRowDispatch:snb
  drm/i915: Kick fbdev before vgacon

 drivers/gpu/drm/i915/i915_dma.c | 10 ++
 drivers/gpu/drm/i915/intel_pm.c |  5 -
 2 files changed, 6 insertions(+), 9 deletions(-)

-- 
Jani Nikula, Intel Open Source Technology Center


[PATCH 11/11] drm/radeon: update the VM after setting BO address v3

2014-11-19 Thread Kai Wasserbäch
gt;> [  117.820022]  a0602de8 c900061cd000 a060245a
>> 
>> [  117.820055]  c900061ce0a8 8800d21a3d58 8800d4417650
>> 1e7d
>> [  117.820089] Call Trace:
>> [  117.820101]  [] ? kfree+0x2e/0x6d
>> [  117.820137]  [] ? radeon_gem_va_ioctl+0x28c/0x2d3 
>> [radeon]
>> [  117.820176]  [] ? radeon_gem_create_ioctl+0xa4/0xc3 
>> [radeon]
>> [  117.820207]  [] ? drm_ioctl+0x35b/0x3e1
>> [  117.820238]  [] ? radeon_gem_get_tiling_ioctl+0x8e/0x8e
>> [radeon]
>> [  117.820270]  [] ? _raw_spin_unlock_irqrestore+0xc/0xd
>> [  117.820303]  [] ? radeon_drm_ioctl+0x4b/0x7a [radeon]
>> [  117.820331]  [] ? do_vfs_ioctl+0x34e/0x404
>> [  117.820355]  [] ? vfs_read+0xbc/0xea
>> [  117.820377]  [] ? SyS_ioctl+0x51/0x77
>> [  117.820398]  [] ? system_call_fastpath+0x12/0x17
>> [  117.820423] Code: 00 00 80 ff 77 00 00 48 01 fa 48 0f 42 0d 78 99 6f 00 
>> 48 8d
>> 04 11 48 ba 00 00 00 00 00 ea ff ff 48 c1 e8 0c 48 6b c0 38 48 01 d0 <48> 8b 
>> 10
>> 80 e6 80 74 0e 48 8b 50 30 48 8b 08 80 e5 80 48 0f 45
>> [  117.820582] RIP  [] virt_to_head_page+0x33/0x4a
>> [  117.820608]  RSP 
>> [  117.820622] CR2: eae3801564d8
>> [  117.838461] ---[ end trace a6e2a6aa1df3196f ]---
>>
>> I've used Dave Airlie's drm-next as a base (commit
>> d0d6c524bf1d72e6d64134c3a315b77deecc9252) and "git am"-applied your series 
>> (no
>> issues, applied cleanly) on top. Steam games are still entering the defunct
>> state as soon as the 3D engines are fired up on a kernel built from that 
>> source
>> tree.
>>
>> This is with (Debian testing as a base):
>> GPU: Hawaii PRO [Radeon R9 290] (ChipID = 0x67b1)
>> Mesa: Git:master/b69c7c5dac
>> libdrm: Git:master/00847fa48b
>> LLVM: SVN:trunk/r54 (3.6 devel)
>> X.Org: 2:1.16.1-1
>> Firmware: <http://people.freedesktop.org/~agd5f/radeon_ucode/>
>> # 9e05820da42549ce9c89d147cf1f8e19  hawaii_ce.bin
>> # c8bab593090fc54f239c8d7596c8d846  hawaii_mc.bin
>> # 3618dbb955d8a84970e262bb2e6d2a16  hawaii_me.bin
>> # c000b0fc9ff6582145f66504b0ec9597  hawaii_mec.bin
>> # 0643ad24b3beff2214cce533e094c1b7  hawaii_pfp.bin
>> # ba6054b7d78184a74602fd81607e1386  hawaii_rlc.bin
>> # 11288f635737331b69de9ee82fe04898  hawaii_sdma.bin
>> # 284429675a5560e0fad42aa982965fc2  hawaii_smc.bin
>> libclc: Git:master/7f6f5bff1f
>> DDX: 1:7.5.0-1
>>
>> Let me know, if you need something else; see also the original thread
>> <http://thread.gmane.org/gmane.comp.video.dri.devel/118415> for further
>> information.
>>
>> Cheers,
>> Kai
>>
> 

-- 

Kai Wasserbäch (Kai Wasserbaech)

E-Mail: kai at dev.carbon-project.org

-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 648 bytes
Desc: OpenPGP digital signature
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141119/5e6f1370/attachment-0001.sig>


[PATCH 1/6] drm/atomic: Ensure that drm_connector_index is stable

2014-11-19 Thread Daniel Vetter
I've totally forgotten that with DP MST connectors can now be
hotplugged. And failed to adapt Rob's drm_atomic_state code (which
predates connector hotplugging) to the new realities.

The first step is to make sure that the connector indices used to
access the arrays of pointers are stable. The connection mutex gives
us enough guarantees for that, which means we won't unecessarily block
on concurrent modesets or background probing.

So add a locking WARN_ON and shuffle the code slightly to make sure we
always hold the right lock.

Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/drm_atomic.c | 8 
 drivers/gpu/drm/drm_crtc.c   | 5 +
 2 files changed, 9 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index ed22a719440f..90b2d1644bd7 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -295,15 +295,15 @@ drm_atomic_get_connector_state(struct drm_atomic_state 
*state,
struct drm_mode_config *config = &connector->dev->mode_config;
struct drm_connector_state *connector_state;

+   ret = drm_modeset_lock(&config->connection_mutex, state->acquire_ctx);
+   if (ret)
+   return ERR_PTR(ret);
+
index = drm_connector_index(connector);

if (state->connector_states[index])
return state->connector_states[index];

-   ret = drm_modeset_lock(&config->connection_mutex, state->acquire_ctx);
-   if (ret)
-   return ERR_PTR(ret);
-
connector_state = connector->funcs->atomic_duplicate_state(connector);
if (!connector_state)
return ERR_PTR(-ENOMEM);
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 56737e74b59d..5c878f172365 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -867,6 +867,8 @@ int drm_connector_init(struct drm_device *dev,

drm_connector_get_cmdline_mode(connector);

+   /* We should add connectors at the end to avoid upsetting the connector
+* index too much. */
list_add_tail(&connector->head, &dev->mode_config.connector_list);
dev->mode_config.num_connector++;

@@ -930,6 +932,9 @@ unsigned int drm_connector_index(struct drm_connector 
*connector)
 {
unsigned int index = 0;
struct drm_connector *tmp;
+   struct drm_mode_config *config = &connector->dev->mode_config;
+
+   WARN_ON(!drm_modeset_is_locked(&config->connection_mutex));

list_for_each_entry(tmp, &connector->dev->mode_config.connector_list, 
head) {
if (tmp == connector)
-- 
2.1.1



[PATCH 2/6] drm/atomic: Only destroy connector states with connection mutex held

2014-11-19 Thread Daniel Vetter
Otherwise the connector might have been unplugged and destroyed while
we didn't look. Yet another fallout from DP MST hotplugging that I
didn't consider.

To make sure we get this right add an appropriate WARN_ON to
drm_atomic_state_clear (obviously only when we actually have a state
to clear up). And reorder all the state_clear and backoff calls to
make it work out properly.

Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/drm_atomic.c|  9 ++---
 drivers/gpu/drm/drm_atomic_helper.c | 14 +++---
 2 files changed, 13 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index 90b2d1644bd7..67c1dc894bd9 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -112,21 +112,24 @@ EXPORT_SYMBOL(drm_atomic_state_alloc);
 void drm_atomic_state_clear(struct drm_atomic_state *state)
 {
struct drm_device *dev = state->dev;
+   struct drm_mode_config *config = &dev->mode_config;
int i;

DRM_DEBUG_KMS("Clearing atomic state %p\n", state);

-   for (i = 0; i < dev->mode_config.num_connector; i++) {
+   for (i = 0; i < config->num_connector; i++) {
struct drm_connector *connector = state->connectors[i];

if (!connector)
continue;

+   WARN_ON(!drm_modeset_is_locked(&config->connection_mutex));
+
connector->funcs->atomic_destroy_state(connector,
   
state->connector_states[i]);
}

-   for (i = 0; i < dev->mode_config.num_crtc; i++) {
+   for (i = 0; i < config->num_crtc; i++) {
struct drm_crtc *crtc = state->crtcs[i];

if (!crtc)
@@ -136,7 +139,7 @@ void drm_atomic_state_clear(struct drm_atomic_state *state)
  state->crtc_states[i]);
}

-   for (i = 0; i < dev->mode_config.num_total_plane; i++) {
+   for (i = 0; i < config->num_total_plane; i++) {
struct drm_plane *plane = state->planes[i];

if (!plane)
diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
b/drivers/gpu/drm/drm_atomic_helper.c
index fad2b932cf72..0cd054615920 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -1217,8 +1217,8 @@ fail:

return ret;
 backoff:
-   drm_atomic_legacy_backoff(state);
drm_atomic_state_clear(state);
+   drm_atomic_legacy_backoff(state);

/*
 * Someone might have exchanged the framebuffer while we dropped locks
@@ -1285,8 +1285,8 @@ fail:

return ret;
 backoff:
-   drm_atomic_legacy_backoff(state);
drm_atomic_state_clear(state);
+   drm_atomic_legacy_backoff(state);

/*
 * Someone might have exchanged the framebuffer while we dropped locks
@@ -1462,8 +1462,8 @@ fail:

return ret;
 backoff:
-   drm_atomic_legacy_backoff(state);
drm_atomic_state_clear(state);
+   drm_atomic_legacy_backoff(state);

/*
 * Someone might have exchanged the framebuffer while we dropped locks
@@ -1528,8 +1528,8 @@ fail:

return ret;
 backoff:
-   drm_atomic_legacy_backoff(state);
drm_atomic_state_clear(state);
+   drm_atomic_legacy_backoff(state);

goto retry;
 }
@@ -1587,8 +1587,8 @@ fail:

return ret;
 backoff:
-   drm_atomic_legacy_backoff(state);
drm_atomic_state_clear(state);
+   drm_atomic_legacy_backoff(state);

goto retry;
 }
@@ -1646,8 +1646,8 @@ fail:

return ret;
 backoff:
-   drm_atomic_legacy_backoff(state);
drm_atomic_state_clear(state);
+   drm_atomic_legacy_backoff(state);

goto retry;
 }
@@ -1725,8 +1725,8 @@ fail:

return ret;
 backoff:
-   drm_atomic_legacy_backoff(state);
drm_atomic_state_clear(state);
+   drm_atomic_legacy_backoff(state);

/*
 * Someone might have exchanged the framebuffer while we dropped locks
-- 
2.1.1



[PATCH 3/6] drm/atomic: Don't overrun the connector array when hotplugging

2014-11-19 Thread Daniel Vetter
Yet another fallout from not considering DP MST hotplug. With the
previous patches we have stable indices, but it might still happen
that a connector gets added between when we allocate the array and
when we actually add a connector. Especially when we back off due to
ww mutex contention or similar issues.

So store the sizes of the arrays in struct drm_atomic_state and double
check them. We don't really care about races except that we want to
use a consistent value, so ACCESS_ONCE is all we need. And if we
indeed notice that we'd overrun the array then just give up and
restart the entire ioctl.

Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/drm_atomic.c| 26 +-
 drivers/gpu/drm/drm_atomic_helper.c | 23 ---
 include/drm/drm_crtc.h  |  2 ++
 3 files changed, 31 insertions(+), 20 deletions(-)

diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index 67c1dc894bd9..3624632084e2 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -56,6 +56,8 @@ drm_atomic_state_alloc(struct drm_device *dev)
if (!state)
return NULL;

+   state->num_connector = ACCESS_ONCE(dev->mode_config.num_connector);
+
state->crtcs = kcalloc(dev->mode_config.num_crtc,
   sizeof(*state->crtcs), GFP_KERNEL);
if (!state->crtcs)
@@ -72,12 +74,12 @@ drm_atomic_state_alloc(struct drm_device *dev)
  sizeof(*state->plane_states), GFP_KERNEL);
if (!state->plane_states)
goto fail;
-   state->connectors = kcalloc(dev->mode_config.num_connector,
+   state->connectors = kcalloc(state->num_connector,
sizeof(*state->connectors),
GFP_KERNEL);
if (!state->connectors)
goto fail;
-   state->connector_states = kcalloc(dev->mode_config.num_connector,
+   state->connector_states = kcalloc(state->num_connector,
  sizeof(*state->connector_states),
  GFP_KERNEL);
if (!state->connector_states)
@@ -117,7 +119,7 @@ void drm_atomic_state_clear(struct drm_atomic_state *state)

DRM_DEBUG_KMS("Clearing atomic state %p\n", state);

-   for (i = 0; i < config->num_connector; i++) {
+   for (i = 0; i < state->num_connector; i++) {
struct drm_connector *connector = state->connectors[i];

if (!connector)
@@ -304,6 +306,21 @@ drm_atomic_get_connector_state(struct drm_atomic_state 
*state,

index = drm_connector_index(connector);

+   /*
+* Construction of atomic state updates can race with a connector
+* hot-add which might overflow. In this case flip the table and just
+* restart the entire ioctl - no one is fast enough to livelock a cpu
+* with physical hotplug events anyway.
+*
+* Note that we only grab the indexes once we have the right lock to
+* prevent hotplug/unplugging of connectors. So removal is no problem,
+* at most the array is a bit too large.
+*/
+   if (index >= state->num_connector) {
+   DRM_DEBUG_KMS("Hot-added connector would overflow state array, 
restarting\n");
+   return -EAGAIN;
+   }
+
if (state->connector_states[index])
return state->connector_states[index];

@@ -499,10 +516,9 @@ int
 drm_atomic_connectors_for_crtc(struct drm_atomic_state *state,
   struct drm_crtc *crtc)
 {
-   int nconnectors = state->dev->mode_config.num_connector;
int i, num_connected_connectors = 0;

-   for (i = 0; i < nconnectors; i++) {
+   for (i = 0; i < state->num_connector; i++) {
struct drm_connector_state *conn_state;

conn_state = state->connector_states[i];
diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
b/drivers/gpu/drm/drm_atomic_helper.c
index 0cd054615920..99095ef147ef 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -249,7 +249,6 @@ static int
 mode_fixup(struct drm_atomic_state *state)
 {
int ncrtcs = state->dev->mode_config.num_crtc;
-   int nconnectors = state->dev->mode_config.num_connector;
struct drm_crtc_state *crtc_state;
struct drm_connector_state *conn_state;
int i;
@@ -264,7 +263,7 @@ mode_fixup(struct drm_atomic_state *state)
drm_mode_copy(&crtc_state->adjusted_mode, &crtc_state->mode);
}

-   for (i = 0; i < nconnectors; i++) {
+   for (i = 0; i < state->num_connector; i++) {
struct drm_encoder_helper_funcs *funcs;
struct drm_encoder *encoder;

@@ -336,7 +335,6 @@ drm_atomic_helper_check_prepare(struct drm_device *dev,
struct drm_atomic_state *state)
 {
int ncrtc

[PATCH 4/6] drm/crtc: Polish kerneldoc

2014-11-19 Thread Daniel Vetter
- Make it clear that it's a negative errno (more in line with
  everything else).
- Clean up the confusion around get_properties vs. getproperty ioctls:
  One reads per-obj property values, the other reads property
  metadata.

Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/drm_crtc.c | 79 --
 1 file changed, 41 insertions(+), 38 deletions(-)

diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 5c878f172365..8c550302a9ef 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -1490,7 +1490,7 @@ EXPORT_SYMBOL(drm_mode_create_scaling_mode_property);
  * connectors.
  *
  * Returns:
- * Zero on success, errno on failure.
+ * Zero on success, negative errno on failure.
  */
 int drm_mode_create_aspect_ratio_property(struct drm_device *dev)
 {
@@ -1674,7 +1674,7 @@ static void drm_crtc_convert_to_umode(struct 
drm_mode_modeinfo *out,
  * the caller.
  *
  * Returns:
- * Zero on success, errno on failure.
+ * Zero on success, negative errno on failure.
  */
 static int drm_crtc_convert_umode(struct drm_display_mode *out,
  const struct drm_mode_modeinfo *in)
@@ -1717,7 +1717,7 @@ static int drm_crtc_convert_umode(struct drm_display_mode 
*out,
  * Called by the user via ioctl.
  *
  * Returns:
- * Zero on success, errno on failure.
+ * Zero on success, negative errno on failure.
  */
 int drm_mode_getresources(struct drm_device *dev, void *data,
  struct drm_file *file_priv)
@@ -1905,7 +1905,7 @@ out:
  * Called by the user via ioctl.
  *
  * Returns:
- * Zero on success, errno on failure.
+ * Zero on success, negative errno on failure.
  */
 int drm_mode_getcrtc(struct drm_device *dev,
 void *data, struct drm_file *file_priv)
@@ -1966,7 +1966,7 @@ static bool drm_mode_expose_to_userspace(const struct 
drm_display_mode *mode,
  * Called by the user via ioctl.
  *
  * Returns:
- * Zero on success, errno on failure.
+ * Zero on success, negative errno on failure.
  */
 int drm_mode_getconnector(struct drm_device *dev, void *data,
  struct drm_file *file_priv)
@@ -2110,7 +2110,7 @@ out:
  * Called by the user via ioctl.
  *
  * Returns:
- * Zero on success, errno on failure.
+ * Zero on success, negative errno on failure.
  */
 int drm_mode_getencoder(struct drm_device *dev, void *data,
struct drm_file *file_priv)
@@ -2151,7 +2151,7 @@ int drm_mode_getencoder(struct drm_device *dev, void 
*data,
  * Called by the user via ioctl.
  *
  * Returns:
- * Zero on success, errno on failure.
+ * Zero on success, negative errno on failure.
  */
 int drm_mode_getplane_res(struct drm_device *dev, void *data,
  struct drm_file *file_priv)
@@ -2212,7 +2212,7 @@ int drm_mode_getplane_res(struct drm_device *dev, void 
*data,
  * Called by the user via ioctl.
  *
  * Returns:
- * Zero on success, errno on failure.
+ * Zero on success, negative errno on failure.
  */
 int drm_mode_getplane(struct drm_device *dev, void *data,
  struct drm_file *file_priv)
@@ -2386,7 +2386,7 @@ static int setplane_internal(struct drm_plane *plane,
  * valid crtc).
  *
  * Returns:
- * Zero on success, errno on failure.
+ * Zero on success, negative errno on failure.
  */
 int drm_mode_setplane(struct drm_device *dev, void *data,
  struct drm_file *file_priv)
@@ -2461,7 +2461,7 @@ int drm_mode_setplane(struct drm_device *dev, void *data,
  * interface. The only thing it adds is correct refcounting dance.
  * 
  * Returns:
- * Zero on success, errno on failure.
+ * Zero on success, negative errno on failure.
  */
 int drm_mode_set_config_internal(struct drm_mode_set *set)
 {
@@ -2554,7 +2554,7 @@ EXPORT_SYMBOL(drm_crtc_check_viewport);
  * Called by the user via ioctl.
  *
  * Returns:
- * Zero on success, errno on failure.
+ * Zero on success, negative errno on failure.
  */
 int drm_mode_setcrtc(struct drm_device *dev, void *data,
 struct drm_file *file_priv)
@@ -2717,7 +2717,7 @@ out:
  * userspace wants to make use of these capabilities.
  *
  * Returns:
- * Zero on success, errno on failure.
+ * Zero on success, negative errno on failure.
  */
 static int drm_mode_cursor_universal(struct drm_crtc *crtc,
 struct drm_mode_cursor2 *req,
@@ -2865,7 +2865,7 @@ out:
  * Called by the user via ioctl.
  *
  * Returns:
- * Zero on success, errno on failure.
+ * Zero on success, negative errno on failure.
  */
 int drm_mode_cursor_ioctl(struct drm_device *dev,
  void *data, struct drm_file *file_priv)
@@ -2892,7 +2892,7 @@ int drm_mode_cursor_ioctl(struct drm_device *dev,
  * Called by the user via ioctl.
  *
  * Returns:
- * Zero on success, errno on failure.
+ * Zero on success, negative errno on failure.
  */
 int drm_mode_cursor2_ioctl(struct drm_device *dev,
   void *data, str

[PATCH 5/6] drm: s/enum_blob_list/enum_list/ in drm_property

2014-11-19 Thread Daniel Vetter
I guess for hysterical raisins this was meant to be the way to read
blob properties. But that's done with the two-stage approach which
uses separate blob kms object and the special-purpose get_blob ioctl.

Shipping userspace seems to have never relied on this, and the kernel
also never put any blob thing onto that property. And nowadays it
would blow up, e.g. in drm_property_destroy. Also it makes no sense to
return values in an ioctl that only returns metadata about everything.

So let's ditch all the internal code for the blob list, rename the
list to be unambiguous and sprinkle comments all over the place to
explain this peculiar piece of api.

v2: Squash in fixup from Rob to remove now unused variables.

Cc: Rob Clark 
Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/drm_crtc.c  | 53 +++--
 include/drm/drm_crtc.h  |  2 +-
 include/uapi/drm/drm_mode.h |  2 ++
 3 files changed, 20 insertions(+), 37 deletions(-)

diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 8c550302a9ef..589a921d4313 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -3457,7 +3457,7 @@ struct drm_property *drm_property_create(struct 
drm_device *dev, int flags,

property->flags = flags;
property->num_values = num_values;
-   INIT_LIST_HEAD(&property->enum_blob_list);
+   INIT_LIST_HEAD(&property->enum_list);

if (name) {
strncpy(property->name, name, DRM_PROP_NAME_LEN);
@@ -3679,8 +3679,8 @@ int drm_property_add_enum(struct drm_property *property, 
int index,
(value > 63))
return -EINVAL;

-   if (!list_empty(&property->enum_blob_list)) {
-   list_for_each_entry(prop_enum, &property->enum_blob_list, head) 
{
+   if (!list_empty(&property->enum_list)) {
+   list_for_each_entry(prop_enum, &property->enum_list, head) {
if (prop_enum->value == value) {
strncpy(prop_enum->name, name, 
DRM_PROP_NAME_LEN);
prop_enum->name[DRM_PROP_NAME_LEN-1] = '\0';
@@ -3698,7 +3698,7 @@ int drm_property_add_enum(struct drm_property *property, 
int index,
prop_enum->value = value;

property->values[index] = value;
-   list_add_tail(&prop_enum->head, &property->enum_blob_list);
+   list_add_tail(&prop_enum->head, &property->enum_list);
return 0;
 }
 EXPORT_SYMBOL(drm_property_add_enum);
@@ -3715,7 +3715,7 @@ void drm_property_destroy(struct drm_device *dev, struct 
drm_property *property)
 {
struct drm_property_enum *prop_enum, *pt;

-   list_for_each_entry_safe(prop_enum, pt, &property->enum_blob_list, 
head) {
+   list_for_each_entry_safe(prop_enum, pt, &property->enum_list, head) {
list_del(&prop_enum->head);
kfree(prop_enum);
}
@@ -3839,16 +3839,12 @@ int drm_mode_getproperty_ioctl(struct drm_device *dev,
struct drm_mode_get_property *out_resp = data;
struct drm_property *property;
int enum_count = 0;
-   int blob_count = 0;
int value_count = 0;
int ret = 0, i;
int copied;
struct drm_property_enum *prop_enum;
struct drm_mode_property_enum __user *enum_ptr;
-   struct drm_property_blob *prop_blob;
-   uint32_t __user *blob_id_ptr;
uint64_t __user *values_ptr;
-   uint32_t __user *blob_length_ptr;

if (!drm_core_check_feature(dev, DRIVER_MODESET))
return -EINVAL;
@@ -3862,11 +3858,8 @@ int drm_mode_getproperty_ioctl(struct drm_device *dev,

if (drm_property_type_is(property, DRM_MODE_PROP_ENUM) ||
drm_property_type_is(property, DRM_MODE_PROP_BITMASK)) {
-   list_for_each_entry(prop_enum, &property->enum_blob_list, head)
+   list_for_each_entry(prop_enum, &property->enum_list, head)
enum_count++;
-   } else if (drm_property_type_is(property, DRM_MODE_PROP_BLOB)) {
-   list_for_each_entry(prop_blob, &property->enum_blob_list, head)
-   blob_count++;
}

value_count = property->num_values;
@@ -3891,7 +3884,7 @@ int drm_mode_getproperty_ioctl(struct drm_device *dev,
if ((out_resp->count_enum_blobs >= enum_count) && enum_count) {
copied = 0;
enum_ptr = (struct drm_mode_property_enum __user 
*)(unsigned long)out_resp->enum_blob_ptr;
-   list_for_each_entry(prop_enum, 
&property->enum_blob_list, head) {
+   list_for_each_entry(prop_enum, &property->enum_list, 
head) {

if (copy_to_user(&enum_ptr[copied].value, 
&prop_enum->value, sizeof(uint64_t))) {
ret = -EFAULT;
@@ -3909,28 +3902,16 @@ int drm_mode_getproperty_ioctl(struct drm_device *dev,
out_resp

[PATCH 6/6] drm/atomic_helper: Make it clear that commit_planes gets the old state

2014-11-19 Thread Daniel Vetter
Oversight from my kerneldoc cleanup when doing the original atomic
helper series - I've only applied this clarification to the modeset
related helpers, and not the plane update code. Remedy this asap.

Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/drm_atomic_helper.c | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
b/drivers/gpu/drm/drm_atomic_helper.c
index 99095ef147ef..690360038dc1 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -976,18 +976,18 @@ EXPORT_SYMBOL(drm_atomic_helper_prepare_planes);
 /**
  * drm_atomic_helper_commit_planes - commit plane state
  * @dev: DRM device
- * @state: atomic state
+ * @old_state: atomic state object with old state structures
  *
  * This function commits the new plane state using the plane and atomic helper
  * functions for planes and crtcs. It assumes that the atomic state has already
  * been pushed into the relevant object state pointers, since this step can no
  * longer fail.
  *
- * It still requires the global state object @state to know which planes and
+ * It still requires the global state object @old_state to know which planes 
and
  * crtcs need to be updated though.
  */
 void drm_atomic_helper_commit_planes(struct drm_device *dev,
-struct drm_atomic_state *state)
+struct drm_atomic_state *old_state)
 {
int nplanes = dev->mode_config.num_total_plane;
int ncrtcs = dev->mode_config.num_crtc;
@@ -995,7 +995,7 @@ void drm_atomic_helper_commit_planes(struct drm_device *dev,

for (i = 0; i < ncrtcs; i++) {
struct drm_crtc_helper_funcs *funcs;
-   struct drm_crtc *crtc = state->crtcs[i];
+   struct drm_crtc *crtc = old_state->crtcs[i];

if (!crtc)
continue;
@@ -1010,7 +1010,7 @@ void drm_atomic_helper_commit_planes(struct drm_device 
*dev,

for (i = 0; i < nplanes; i++) {
struct drm_plane_helper_funcs *funcs;
-   struct drm_plane *plane = state->planes[i];
+   struct drm_plane *plane = old_state->planes[i];

if (!plane)
continue;
@@ -1025,7 +1025,7 @@ void drm_atomic_helper_commit_planes(struct drm_device 
*dev,

for (i = 0; i < ncrtcs; i++) {
struct drm_crtc_helper_funcs *funcs;
-   struct drm_crtc *crtc = state->crtcs[i];
+   struct drm_crtc *crtc = old_state->crtcs[i];

if (!crtc)
continue;
-- 
2.1.1



[PATCH 01/11] drm/radeon: report disconnected for LVDS/eDP with PX if ddc fails

2014-11-19 Thread Alex Deucher
If ddc fails, presumably the i2c mux (and hopefully the signal
mux) are switched to the other GPU so don't fetch the edid from
the vbios so that the connector reports disconnected.

Signed-off-by: Alex Deucher 
---
 drivers/gpu/drm/radeon/radeon_connectors.c | 19 ++-
 1 file changed, 18 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/radeon/radeon_connectors.c 
b/drivers/gpu/drm/radeon/radeon_connectors.c
index 300c4b3..26baa9c 100644
--- a/drivers/gpu/drm/radeon/radeon_connectors.c
+++ b/drivers/gpu/drm/radeon/radeon_connectors.c
@@ -322,6 +322,12 @@ static void radeon_connector_get_edid(struct drm_connector 
*connector)
}

if (!radeon_connector->edid) {
+   /* don't fetch the edid from the vbios if ddc fails and runpm is
+* enabled so we report disconnected.
+*/
+   if ((rdev->flags & RADEON_IS_PX) && (radeon_runtime_pm != 0))
+   return;
+
if (rdev->is_atom_bios) {
/* some laptops provide a hardcoded edid in rom for 
LCDs */
if (((connector->connector_type == 
DRM_MODE_CONNECTOR_LVDS) ||
@@ -826,6 +832,8 @@ static int radeon_lvds_mode_valid(struct drm_connector 
*connector,
 static enum drm_connector_status
 radeon_lvds_detect(struct drm_connector *connector, bool force)
 {
+   struct drm_device *dev = connector->dev;
+   struct radeon_device *rdev = dev->dev_private;
struct radeon_connector *radeon_connector = 
to_radeon_connector(connector);
struct drm_encoder *encoder = radeon_best_single_encoder(connector);
enum drm_connector_status ret = connector_status_disconnected;
@@ -842,7 +850,11 @@ radeon_lvds_detect(struct drm_connector *connector, bool 
force)
/* check if panel is valid */
if (native_mode->hdisplay >= 320 && native_mode->vdisplay >= 
240)
ret = connector_status_connected;
-
+   /* don't fetch the edid from the vbios if ddc fails and runpm is
+* enabled so we report disconnected.
+*/
+   if ((rdev->flags & RADEON_IS_PX) && (radeon_runtime_pm != 0))
+   ret = connector_status_disconnected;
}

/* check for edid as well */
@@ -1589,6 +1601,11 @@ radeon_dp_detect(struct drm_connector *connector, bool 
force)
/* check if panel is valid */
if (native_mode->hdisplay >= 320 && 
native_mode->vdisplay >= 240)
ret = connector_status_connected;
+   /* don't fetch the edid from the vbios if ddc fails and 
runpm is
+* enabled so we report disconnected.
+*/
+   if ((rdev->flags & RADEON_IS_PX) && (radeon_runtime_pm 
!= 0))
+   ret = connector_status_disconnected;
}
/* eDP is always DP */
radeon_dig_connector->dp_sink_type = 
CONNECTOR_OBJECT_ID_DISPLAYPORT;
-- 
1.8.3.1



[PATCH 02/11] drm/radeon: work around a hw bug in MGCG on CIK

2014-11-19 Thread Alex Deucher
Always need to set bit 0 of RLC_CGTT_MGCG_OVERRIDE
to avoid unreliable doorbell updates in some cases.

Signed-off-by: Alex Deucher 
Cc: stable at vger.kernel.org
---
 drivers/gpu/drm/radeon/cik.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/radeon/cik.c b/drivers/gpu/drm/radeon/cik.c
index 57a359d..20fb1ad 100644
--- a/drivers/gpu/drm/radeon/cik.c
+++ b/drivers/gpu/drm/radeon/cik.c
@@ -6323,6 +6323,7 @@ static void cik_enable_mgcg(struct radeon_device *rdev, 
bool enable)
}

orig = data = RREG32(RLC_CGTT_MGCG_OVERRIDE);
+   data |= 0x0001;
data &= 0xfffd;
if (orig != data)
WREG32(RLC_CGTT_MGCG_OVERRIDE, data);
@@ -6354,7 +6355,7 @@ static void cik_enable_mgcg(struct radeon_device *rdev, 
bool enable)
}
} else {
orig = data = RREG32(RLC_CGTT_MGCG_OVERRIDE);
-   data |= 0x0002;
+   data |= 0x0003;
if (orig != data)
WREG32(RLC_CGTT_MGCG_OVERRIDE, data);

-- 
1.8.3.1



[PATCH 03/11] drm/radeon: fix endian swapping in vbios fetch for tdp table

2014-11-19 Thread Alex Deucher
Value needs to be swapped on BE.

Signed-off-by: Alex Deucher 
Cc: stable at vger.kernel.org
---
 drivers/gpu/drm/radeon/r600_dpm.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/radeon/r600_dpm.c 
b/drivers/gpu/drm/radeon/r600_dpm.c
index f6309bd..b5c73df 100644
--- a/drivers/gpu/drm/radeon/r600_dpm.c
+++ b/drivers/gpu/drm/radeon/r600_dpm.c
@@ -1256,7 +1256,7 @@ int r600_parse_extended_power_table(struct radeon_device 
*rdev)
(mode_info->atom_context->bios + 
data_offset +
 
le16_to_cpu(ext_hdr->usPowerTuneTableOffset));

rdev->pm.dpm.dyn_state.cac_tdp_table->maximum_power_delivery_limit =
-   ppt->usMaximumPowerDeliveryLimit;
+   
le16_to_cpu(ppt->usMaximumPowerDeliveryLimit);
pt = &ppt->power_tune_table;
} else {
ATOM_PPLIB_POWERTUNE_Table *ppt = 
(ATOM_PPLIB_POWERTUNE_Table *)
-- 
1.8.3.1



[PATCH 04/11] drm/radeon/dpm: add smc fan control for SI (v2)

2014-11-19 Thread Alex Deucher
Enable smc fan control for SI boards.  Should
reduce the fan noise on systems with a higher
default fan profile.

v2: disable by default, add rpm controls

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

Signed-off-by: Alex Deucher 
---
 drivers/gpu/drm/radeon/ppsmc.h|   5 +
 drivers/gpu/drm/radeon/r600_dpm.h |   3 +
 drivers/gpu/drm/radeon/si_dpm.c   | 330 +-
 drivers/gpu/drm/radeon/si_dpm.h   |   5 +
 drivers/gpu/drm/radeon/sid.h  |  40 -
 drivers/gpu/drm/radeon/sislands_smc.h |  25 +++
 6 files changed, 401 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/radeon/ppsmc.h b/drivers/gpu/drm/radeon/ppsmc.h
index 11c0e4d..0c4eaa6 100644
--- a/drivers/gpu/drm/radeon/ppsmc.h
+++ b/drivers/gpu/drm/radeon/ppsmc.h
@@ -56,6 +56,9 @@
 #define PPSMC_STATEFLAG_DEEPSLEEP_THROTTLE 0x20
 #define PPSMC_STATEFLAG_DEEPSLEEP_BYPASS   0x40

+#define FDO_MODE_HARDWARE 0
+#define FDO_MODE_PIECE_WISE_LINEAR 1
+
 #define PPSMC_Result_OK ((uint8_t)0x01)
 #define PPSMC_Result_Failed ((uint8_t)0xFF)

@@ -79,6 +82,8 @@ typedef uint8_t PPSMC_Result;
 #define PPSMC_MSG_DisableCac((uint8_t)0x54)
 #define PPSMC_TDPClampingActive ((uint8_t)0x59)
 #define PPSMC_TDPClampingInactive   ((uint8_t)0x5A)
+#define PPSMC_StartFanControl   ((uint8_t)0x5B)
+#define PPSMC_StopFanControl((uint8_t)0x5C)
 #define PPSMC_MSG_NoDisplay ((uint8_t)0x5D)
 #define PPSMC_MSG_HasDisplay((uint8_t)0x5E)
 #define PPSMC_MSG_UVDPowerOFF   ((uint8_t)0x60)
diff --git a/drivers/gpu/drm/radeon/r600_dpm.h 
b/drivers/gpu/drm/radeon/r600_dpm.h
index 46b9d2a..bd499d7 100644
--- a/drivers/gpu/drm/radeon/r600_dpm.h
+++ b/drivers/gpu/drm/radeon/r600_dpm.h
@@ -96,6 +96,9 @@
 #define R600_TEMP_RANGE_MIN (90 * 1000)
 #define R600_TEMP_RANGE_MAX (120 * 1000)

+#define FDO_PWM_MODE_STATIC  1
+#define FDO_PWM_MODE_STATIC_RPM 5
+
 enum r600_power_level {
R600_POWER_LEVEL_LOW = 0,
R600_POWER_LEVEL_MEDIUM = 1,
diff --git a/drivers/gpu/drm/radeon/si_dpm.c b/drivers/gpu/drm/radeon/si_dpm.c
index b59e1d6..cf4c420 100644
--- a/drivers/gpu/drm/radeon/si_dpm.c
+++ b/drivers/gpu/drm/radeon/si_dpm.c
@@ -3398,6 +3398,15 @@ static int si_process_firmware_header(struct 
radeon_device *rdev)

ret = si_read_smc_sram_dword(rdev,
 SISLANDS_SMC_FIRMWARE_HEADER_LOCATION +
+SISLANDS_SMC_FIRMWARE_HEADER_fanTable,
+&tmp, si_pi->sram_end);
+   if (ret)
+   return ret;
+
+   si_pi->fan_table_start = tmp;
+
+   ret = si_read_smc_sram_dword(rdev,
+SISLANDS_SMC_FIRMWARE_HEADER_LOCATION +
 
SISLANDS_SMC_FIRMWARE_HEADER_mcArbDramAutoRefreshTable,
 &tmp, si_pi->sram_end);
if (ret)
@@ -5825,20 +5834,20 @@ static int si_thermal_enable_alert(struct radeon_device 
*rdev,
if (enable) {
PPSMC_Result result;

-   thermal_int |= THERM_INT_MASK_HIGH | THERM_INT_MASK_LOW;
-   rdev->irq.dpm_thermal = true;
+   thermal_int &= ~(THERM_INT_MASK_HIGH | THERM_INT_MASK_LOW);
+   WREG32(CG_THERMAL_INT, thermal_int);
+   rdev->irq.dpm_thermal = false;
result = si_send_msg_to_smc(rdev, 
PPSMC_MSG_EnableThermalInterrupt);
if (result != PPSMC_Result_OK) {
DRM_DEBUG_KMS("Could not enable thermal interrupts.\n");
return -EINVAL;
}
} else {
-   thermal_int &= ~(THERM_INT_MASK_HIGH | THERM_INT_MASK_LOW);
-   rdev->irq.dpm_thermal = false;
+   thermal_int |= THERM_INT_MASK_HIGH | THERM_INT_MASK_LOW;
+   WREG32(CG_THERMAL_INT, thermal_int);
+   rdev->irq.dpm_thermal = true;
}

-   WREG32(CG_THERMAL_INT, thermal_int);
-
return 0;
 }

@@ -5867,6 +5876,309 @@ static int si_thermal_set_temperature_range(struct 
radeon_device *rdev,
return 0;
 }

+static void si_fan_ctrl_set_static_mode(struct radeon_device *rdev, u32 mode)
+{
+   struct si_power_info *si_pi = si_get_pi(rdev);
+   u32 tmp;
+
+   if (si_pi->fan_ctrl_is_in_default_mode) {
+   tmp = (RREG32(CG_FDO_CTRL2) & FDO_PWM_MODE_MASK) >> 
FDO_PWM_MODE_SHIFT;
+   si_pi->fan_ctrl_default_mode = tmp;
+   tmp = (RREG32(CG_FDO_CTRL2) & TMIN_MASK) >> TMIN_SHIFT;
+   si_pi->t_min = tmp;
+   si_pi->fan_ctrl_is_in_default_mode = false;
+   }
+
+   tmp = RREG32(CG_FDO_CTRL2) & ~TMIN_MASK;
+   tmp |= TMIN(0);
+   WREG32(CG_FDO_CTRL2, tmp);
+
+   tmp = RREG32(CG_FDO_CTRL2) & FDO_PWM_MODE_MASK;
+   tmp |= FDO_PWM_MODE(mode);
+   WREG32(CG_FDO_CTRL2, tmp);
+}
+

[PATCH 07/11] drm/radeon: fix PCC debugging message for CI DPM

2014-11-19 Thread Alex Deucher
Add missing newline and print the bad gpio shift.

Signed-off-by: Alex Deucher 
---
 drivers/gpu/drm/radeon/ci_dpm.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/radeon/ci_dpm.c b/drivers/gpu/drm/radeon/ci_dpm.c
index 8312140..c9963b5 100644
--- a/drivers/gpu/drm/radeon/ci_dpm.c
+++ b/drivers/gpu/drm/radeon/ci_dpm.c
@@ -5773,7 +5773,7 @@ int ci_dpm_init(struct radeon_device *rdev)
tmp |= DPM_ENABLED;
break;
default:
-   DRM_ERROR("Invalid PCC GPIO!");
+   DRM_ERROR("Invalid PCC GPIO: %u!\n", gpio.shift);
break;
}
WREG32_SMC(CNB_PWRMGT_CNTL, tmp);
-- 
1.8.3.1



[PATCH 08/11] drm/radeon/ci: apply disp voltage changes before clk changes

2014-11-19 Thread Alex Deucher
Apply voltage changes for displays before changing clocks.

Signed-off-by: Alex Deucher 
---
 drivers/gpu/drm/radeon/ci_dpm.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/radeon/ci_dpm.c b/drivers/gpu/drm/radeon/ci_dpm.c
index c9963b5..e781628 100644
--- a/drivers/gpu/drm/radeon/ci_dpm.c
+++ b/drivers/gpu/drm/radeon/ci_dpm.c
@@ -3752,6 +3752,8 @@ static int ci_upload_dpm_level_enable_mask(struct 
radeon_device *rdev)
struct ci_power_info *pi = ci_get_pi(rdev);
PPSMC_Result result;

+   ci_apply_disp_minimum_voltage_request(rdev);
+
if (!pi->sclk_dpm_key_disabled) {
if (pi->dpm_level_enable_mask.sclk_dpm_enable_mask) {
result = ci_send_msg_to_smc_with_parameter(rdev,
@@ -3782,8 +3784,6 @@ static int ci_upload_dpm_level_enable_mask(struct 
radeon_device *rdev)
}
}

-   ci_apply_disp_minimum_voltage_request(rdev);
-
return 0;
 }

-- 
1.8.3.1



[PATCH 09/11] drm/radeon/ci: use different smc command for pcie dpm

2014-11-19 Thread Alex Deucher
Use unforce levels rather than enable mask instruction.
This is the preferred method.

Signed-off-by: Alex Deucher 
---
 drivers/gpu/drm/radeon/ci_dpm.c | 12 ++--
 1 file changed, 10 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/radeon/ci_dpm.c b/drivers/gpu/drm/radeon/ci_dpm.c
index e781628..73f8c4b 100644
--- a/drivers/gpu/drm/radeon/ci_dpm.c
+++ b/drivers/gpu/drm/radeon/ci_dpm.c
@@ -3773,7 +3773,7 @@ static int ci_upload_dpm_level_enable_mask(struct 
radeon_device *rdev)
return -EINVAL;
}
}
-
+#if 0
if (!pi->pcie_dpm_key_disabled) {
if (pi->dpm_level_enable_mask.pcie_dpm_enable_mask) {
result = ci_send_msg_to_smc_with_parameter(rdev,
@@ -3783,7 +3783,7 @@ static int ci_upload_dpm_level_enable_mask(struct 
radeon_device *rdev)
return -EINVAL;
}
}
-
+#endif
return 0;
 }

@@ -4247,6 +4247,14 @@ int ci_dpm_force_performance_level(struct radeon_device 
*rdev,
}
}
} else if (level == RADEON_DPM_FORCED_LEVEL_AUTO) {
+   if (!pi->pcie_dpm_key_disabled) {
+   PPSMC_Result smc_result;
+
+   smc_result = ci_send_msg_to_smc(rdev,
+   
PPSMC_MSG_PCIeDPM_UnForceLevel);
+   if (smc_result != PPSMC_Result_OK)
+   return -EINVAL;
+   }
ret = ci_upload_dpm_level_enable_mask(rdev);
if (ret)
return ret;
-- 
1.8.3.1



[PATCH 10/11] drm/radeon/ci: force pcie level before sclk and mclk

2014-11-19 Thread Alex Deucher
Preferred ordering.

Signed-off-by: Alex Deucher 
---
 drivers/gpu/drm/radeon/ci_dpm.c | 34 +-
 1 file changed, 17 insertions(+), 17 deletions(-)

diff --git a/drivers/gpu/drm/radeon/ci_dpm.c b/drivers/gpu/drm/radeon/ci_dpm.c
index 73f8c4b..630434c 100644
--- a/drivers/gpu/drm/radeon/ci_dpm.c
+++ b/drivers/gpu/drm/radeon/ci_dpm.c
@@ -4143,57 +4143,57 @@ int ci_dpm_force_performance_level(struct radeon_device 
*rdev,
int ret;

if (level == RADEON_DPM_FORCED_LEVEL_HIGH) {
-   if ((!pi->sclk_dpm_key_disabled) &&
-   pi->dpm_level_enable_mask.sclk_dpm_enable_mask) {
+   if ((!pi->pcie_dpm_key_disabled) &&
+   pi->dpm_level_enable_mask.pcie_dpm_enable_mask) {
levels = 0;
-   tmp = pi->dpm_level_enable_mask.sclk_dpm_enable_mask;
+   tmp = pi->dpm_level_enable_mask.pcie_dpm_enable_mask;
while (tmp >>= 1)
levels++;
if (levels) {
-   ret = ci_dpm_force_state_sclk(rdev, levels);
+   ret = ci_dpm_force_state_pcie(rdev, level);
if (ret)
return ret;
for (i = 0; i < rdev->usec_timeout; i++) {
-   tmp = 
(RREG32_SMC(TARGET_AND_CURRENT_PROFILE_INDEX) &
-  CURR_SCLK_INDEX_MASK) >> 
CURR_SCLK_INDEX_SHIFT;
+   tmp = 
(RREG32_SMC(TARGET_AND_CURRENT_PROFILE_INDEX_1) &
+  CURR_PCIE_INDEX_MASK) >> 
CURR_PCIE_INDEX_SHIFT;
if (tmp == levels)
break;
udelay(1);
}
}
}
-   if ((!pi->mclk_dpm_key_disabled) &&
-   pi->dpm_level_enable_mask.mclk_dpm_enable_mask) {
+   if ((!pi->sclk_dpm_key_disabled) &&
+   pi->dpm_level_enable_mask.sclk_dpm_enable_mask) {
levels = 0;
-   tmp = pi->dpm_level_enable_mask.mclk_dpm_enable_mask;
+   tmp = pi->dpm_level_enable_mask.sclk_dpm_enable_mask;
while (tmp >>= 1)
levels++;
if (levels) {
-   ret = ci_dpm_force_state_mclk(rdev, levels);
+   ret = ci_dpm_force_state_sclk(rdev, levels);
if (ret)
return ret;
for (i = 0; i < rdev->usec_timeout; i++) {
tmp = 
(RREG32_SMC(TARGET_AND_CURRENT_PROFILE_INDEX) &
-  CURR_MCLK_INDEX_MASK) >> 
CURR_MCLK_INDEX_SHIFT;
+  CURR_SCLK_INDEX_MASK) >> 
CURR_SCLK_INDEX_SHIFT;
if (tmp == levels)
break;
udelay(1);
}
}
}
-   if ((!pi->pcie_dpm_key_disabled) &&
-   pi->dpm_level_enable_mask.pcie_dpm_enable_mask) {
+   if ((!pi->mclk_dpm_key_disabled) &&
+   pi->dpm_level_enable_mask.mclk_dpm_enable_mask) {
levels = 0;
-   tmp = pi->dpm_level_enable_mask.pcie_dpm_enable_mask;
+   tmp = pi->dpm_level_enable_mask.mclk_dpm_enable_mask;
while (tmp >>= 1)
levels++;
if (levels) {
-   ret = ci_dpm_force_state_pcie(rdev, level);
+   ret = ci_dpm_force_state_mclk(rdev, levels);
if (ret)
return ret;
for (i = 0; i < rdev->usec_timeout; i++) {
-   tmp = 
(RREG32_SMC(TARGET_AND_CURRENT_PROFILE_INDEX_1) &
-  CURR_PCIE_INDEX_MASK) >> 
CURR_PCIE_INDEX_SHIFT;
+   tmp = 
(RREG32_SMC(TARGET_AND_CURRENT_PROFILE_INDEX) &
+  CURR_MCLK_INDEX_MASK) >> 
CURR_MCLK_INDEX_SHIFT;
if (tmp == levels)
break;
udelay(1);
-- 
1.8.3.1



[PATCH 11/11] drm/radeon/ci: disable needless sclk changes

2014-11-19 Thread Alex Deucher
The current code always reprogrammed the sclk levels,
but we don't currently handle disp sclk requirements
so just skip it.

Signed-off-by: Alex Deucher 
---
 drivers/gpu/drm/radeon/ci_dpm.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/radeon/ci_dpm.c b/drivers/gpu/drm/radeon/ci_dpm.c
index 630434c..3f898d0 100644
--- a/drivers/gpu/drm/radeon/ci_dpm.c
+++ b/drivers/gpu/drm/radeon/ci_dpm.c
@@ -3809,7 +3809,7 @@ static void ci_find_dpm_states_clocks_in_dpm_table(struct 
radeon_device *rdev,
pi->need_update_smu7_dpm_table |= DPMTABLE_OD_UPDATE_SCLK;
} else {
/* XXX check display min clock requirements */
-   if (0 != CISLAND_MINIMUM_ENGINE_CLOCK)
+   if (CISLAND_MINIMUM_ENGINE_CLOCK != 
CISLAND_MINIMUM_ENGINE_CLOCK)
pi->need_update_smu7_dpm_table |= DPMTABLE_UPDATE_SCLK;
}

-- 
1.8.3.1



[PATCH 05/11] drm/radeon/dpm: add smc fan control for CI (v2)

2014-11-19 Thread Alex Deucher
Enable smc fan control for CI boards.  Should
reduce the fan noise on systems with a higher
default fan profile.

v2: disable by default, add additional fan setup, rpm control

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

Signed-off-by: Alex Deucher 
---
 drivers/gpu/drm/radeon/ci_dpm.c| 345 -
 drivers/gpu/drm/radeon/ci_dpm.h|   5 +
 drivers/gpu/drm/radeon/cikd.h  |  40 +++-
 drivers/gpu/drm/radeon/ppsmc.h |   6 +
 drivers/gpu/drm/radeon/pptable.h   |   8 +
 drivers/gpu/drm/radeon/r600_dpm.c  |   9 +
 drivers/gpu/drm/radeon/radeon.h|   4 +
 drivers/gpu/drm/radeon/smu7_discrete.h |  30 ++-
 8 files changed, 443 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/radeon/ci_dpm.c b/drivers/gpu/drm/radeon/ci_dpm.c
index 9dbc52f..4581d6c 100644
--- a/drivers/gpu/drm/radeon/ci_dpm.c
+++ b/drivers/gpu/drm/radeon/ci_dpm.c
@@ -184,6 +184,9 @@ static int ci_set_overdrive_target_tdp(struct radeon_device 
*rdev,
   u32 target_tdp);
 static int ci_update_uvd_dpm(struct radeon_device *rdev, bool gate);

+static PPSMC_Result ci_send_msg_to_smc_with_parameter(struct radeon_device 
*rdev,
+ PPSMC_Msg msg, u32 
parameter);
+
 static struct ci_power_info *ci_get_pi(struct radeon_device *rdev)
 {
 struct ci_power_info *pi = rdev->pm.dpm.priv;
@@ -355,6 +358,21 @@ static int ci_populate_dw8(struct radeon_device *rdev)
return 0;
 }

+static int ci_populate_fuzzy_fan(struct radeon_device *rdev)
+{
+   struct ci_power_info *pi = ci_get_pi(rdev);
+
+   if ((rdev->pm.dpm.fan.fan_output_sensitivity & (1 << 15)) ||
+   (rdev->pm.dpm.fan.fan_output_sensitivity == 0))
+   rdev->pm.dpm.fan.fan_output_sensitivity =
+   rdev->pm.dpm.fan.default_fan_output_sensitivity;
+
+   pi->smc_powertune_table.FuzzyFan_PwmSetDelta =
+   cpu_to_be16(rdev->pm.dpm.fan.fan_output_sensitivity);
+
+   return 0;
+}
+
 static int ci_min_max_v_gnbl_pm_lid_from_bapm_vddc(struct radeon_device *rdev)
 {
struct ci_power_info *pi = ci_get_pi(rdev);
@@ -480,6 +498,9 @@ static int ci_populate_pm_base(struct radeon_device *rdev)
ret = ci_populate_dw8(rdev);
if (ret)
return ret;
+   ret = ci_populate_fuzzy_fan(rdev);
+   if (ret)
+   return ret;
ret = ci_min_max_v_gnbl_pm_lid_from_bapm_vddc(rdev);
if (ret)
return ret;
@@ -859,6 +880,7 @@ static int ci_thermal_enable_alert(struct radeon_device 
*rdev,

if (enable) {
thermal_int &= ~(THERM_INT_MASK_HIGH | THERM_INT_MASK_LOW);
+   WREG32_SMC(CG_THERMAL_INT, thermal_int);
rdev->irq.dpm_thermal = false;
result = ci_send_msg_to_smc(rdev, 
PPSMC_MSG_Thermal_Cntl_Enable);
if (result != PPSMC_Result_OK) {
@@ -867,6 +889,7 @@ static int ci_thermal_enable_alert(struct radeon_device 
*rdev,
}
} else {
thermal_int |= THERM_INT_MASK_HIGH | THERM_INT_MASK_LOW;
+   WREG32_SMC(CG_THERMAL_INT, thermal_int);
rdev->irq.dpm_thermal = true;
result = ci_send_msg_to_smc(rdev, 
PPSMC_MSG_Thermal_Cntl_Disable);
if (result != PPSMC_Result_OK) {
@@ -875,12 +898,325 @@ static int ci_thermal_enable_alert(struct radeon_device 
*rdev,
}
}

-   WREG32_SMC(CG_THERMAL_INT, thermal_int);
+   return 0;
+}
+
+static void ci_fan_ctrl_set_static_mode(struct radeon_device *rdev, u32 mode)
+{
+   struct ci_power_info *pi = ci_get_pi(rdev);
+   u32 tmp;
+
+   if (pi->fan_ctrl_is_in_default_mode) {
+   tmp = (RREG32_SMC(CG_FDO_CTRL2) & FDO_PWM_MODE_MASK) >> 
FDO_PWM_MODE_SHIFT;
+   pi->fan_ctrl_default_mode = tmp;
+   tmp = (RREG32_SMC(CG_FDO_CTRL2) & TMIN_MASK) >> TMIN_SHIFT;
+   pi->t_min = tmp;
+   pi->fan_ctrl_is_in_default_mode = false;
+   }
+
+   tmp = RREG32_SMC(CG_FDO_CTRL2) & ~TMIN_MASK;
+   tmp |= TMIN(0);
+   WREG32_SMC(CG_FDO_CTRL2, tmp);
+
+   tmp = RREG32_SMC(CG_FDO_CTRL2) & FDO_PWM_MODE_MASK;
+   tmp |= FDO_PWM_MODE(mode);
+   WREG32_SMC(CG_FDO_CTRL2, tmp);
+}
+
+static int ci_thermal_setup_fan_table(struct radeon_device *rdev)
+{
+   struct ci_power_info *pi = ci_get_pi(rdev);
+   SMU7_Discrete_FanTable fan_table = { FDO_MODE_HARDWARE };
+   u32 duty100;
+   u32 t_diff1, t_diff2, pwm_diff1, pwm_diff2;
+   u16 fdo_min, slope1, slope2;
+   u32 reference_clock, tmp;
+   int ret;
+   u64 tmp64;
+
+   if (!pi->fan_table_start) {
+   rdev->pm.dpm.fan.ucode_fan_control = false;
+   return 0;
+   }
+
+   duty100 = (RREG32_SMC(CG_FDO_CTRL1) & FMAX_DU

[PATCH 06/11] drm/radeon/dpm: add thermal dpm support for CI

2014-11-19 Thread Alex Deucher
Not currently used.

Signed-off-by: Alex Deucher 
---
 drivers/gpu/drm/radeon/ci_dpm.c | 27 +++
 drivers/gpu/drm/radeon/ci_dpm.h |  1 +
 drivers/gpu/drm/radeon/ppsmc.h  |  3 +++
 3 files changed, 31 insertions(+)

diff --git a/drivers/gpu/drm/radeon/ci_dpm.c b/drivers/gpu/drm/radeon/ci_dpm.c
index 4581d6c..8312140 100644
--- a/drivers/gpu/drm/radeon/ci_dpm.c
+++ b/drivers/gpu/drm/radeon/ci_dpm.c
@@ -714,6 +714,25 @@ static int ci_enable_smc_cac(struct radeon_device *rdev, 
bool enable)
return ret;
 }

+static int ci_enable_thermal_based_sclk_dpm(struct radeon_device *rdev,
+   bool enable)
+{
+   struct ci_power_info *pi = ci_get_pi(rdev);
+   PPSMC_Result smc_result = PPSMC_Result_OK;
+
+   if (pi->thermal_sclk_dpm_enabled) {
+   if (enable)
+   smc_result = ci_send_msg_to_smc(rdev, 
PPSMC_MSG_ENABLE_THERMAL_DPM);
+   else
+   smc_result = ci_send_msg_to_smc(rdev, 
PPSMC_MSG_DISABLE_THERMAL_DPM);
+   }
+
+   if (smc_result == PPSMC_Result_OK)
+   return 0;
+   else
+   return -EINVAL;
+}
+
 static int ci_power_control_set_level(struct radeon_device *rdev)
 {
struct ci_power_info *pi = ci_get_pi(rdev);
@@ -5177,6 +5196,12 @@ int ci_dpm_enable(struct radeon_device *rdev)

ci_enable_auto_throttle_source(rdev, 
RADEON_DPM_AUTO_THROTTLE_SRC_THERMAL, true);

+   ret = ci_enable_thermal_based_sclk_dpm(rdev, true);
+   if (ret) {
+   DRM_ERROR("ci_enable_thermal_based_sclk_dpm failed\n");
+   return ret;
+   }
+
ci_thermal_start_thermal_controller(rdev);

ci_update_current_ps(rdev, boot_ps);
@@ -5240,6 +5265,7 @@ void ci_dpm_disable(struct radeon_device *rdev)
ci_reset_to_default(rdev);
ci_dpm_stop_smc(rdev);
ci_force_switch_to_arb_f0(rdev);
+   ci_enable_thermal_based_sclk_dpm(rdev, false);

ci_update_current_ps(rdev, boot_ps);
 }
@@ -5639,6 +5665,7 @@ int ci_dpm_init(struct radeon_device *rdev)
pi->sclk_dpm_key_disabled = 0;
pi->mclk_dpm_key_disabled = 0;
pi->pcie_dpm_key_disabled = 0;
+   pi->thermal_sclk_dpm_enabled = 0;

/* mclk dpm is unstable on some R7 260X cards with the old mc ucode */
if ((rdev->pdev->device == 0x6658) &&
diff --git a/drivers/gpu/drm/radeon/ci_dpm.h b/drivers/gpu/drm/radeon/ci_dpm.h
index bb19fbf..84e3d3b 100644
--- a/drivers/gpu/drm/radeon/ci_dpm.h
+++ b/drivers/gpu/drm/radeon/ci_dpm.h
@@ -239,6 +239,7 @@ struct ci_power_info {
u32 sclk_dpm_key_disabled;
u32 mclk_dpm_key_disabled;
u32 pcie_dpm_key_disabled;
+   u32 thermal_sclk_dpm_enabled;
struct ci_pcie_perf_range pcie_gen_performance;
struct ci_pcie_perf_range pcie_lane_performance;
struct ci_pcie_perf_range pcie_gen_powersaving;
diff --git a/drivers/gpu/drm/radeon/ppsmc.h b/drivers/gpu/drm/radeon/ppsmc.h
index ff698b0..7e5724a 100644
--- a/drivers/gpu/drm/radeon/ppsmc.h
+++ b/drivers/gpu/drm/radeon/ppsmc.h
@@ -162,6 +162,9 @@ typedef uint8_t PPSMC_Result;
 #define PPSMC_MSG_Remove_DC_Clamp ((uint16_t) 0x191)
 #define PPSMC_MSG_SetFanPwmMax((uint16_t) 0x19A)

+#define PPSMC_MSG_ENABLE_THERMAL_DPM  ((uint16_t) 0x19C)
+#define PPSMC_MSG_DISABLE_THERMAL_DPM ((uint16_t) 0x19D)
+
 #define PPSMC_MSG_API_GetSclkFrequency((uint16_t) 0x200)
 #define PPSMC_MSG_API_GetMclkFrequency((uint16_t) 0x201)

-- 
1.8.3.1



[Bug 86471] Unreal Engine 4.6 Editor dont start

2014-11-19 Thread bugzilla-dae...@freedesktop.org
age=@0x7fff4ea0: 0x0,
InOutName=..., Create=true, Throw=true) at
/home/linuxdonald/UnrealEngine/Engine/Source/Runtime/CoreUObject/Private/UObject/UObjectGlobals.cpp:601
#25 0x768023c6 in StaticLoadObject (ObjectClass=0xacfb80, InOuter=0x0,
InName=0x7c4d300 L"/Engine/EditorMeshes/EditorSphere.EditorSphere",
Filename=0x0, LoadFlags=0, Sandbox=0x0, bAllowObjectReconciliation=true)
at
/home/linuxdonald/UnrealEngine/Engine/Source/Runtime/CoreUObject/Private/UObject/UObjectGlobals.cpp:687
#26 0x71fef3d6 in LoadObject (Outer=0x0, Name=0x7c4d300
L"/Engine/EditorMeshes/EditorSphere.EditorSphere", Filename=0x0, LoadFlags=0,
Sandbox=0x0)
at
/home/linuxdonald/UnrealEngine/Engine/Source/Runtime/CoreUObject/Public/UObject/UObjectGlobals.h:1106
#27 0x71fef32c in
ConstructorHelpersInternal::FindOrLoadObject (PathName=...) at
/home/linuxdonald/UnrealEngine/Engine/Source/Runtime/CoreUObject/Public/UObject/ConstructorHelpers.h:31
#28 0x71fee0f7 in
ConstructorHelpers::FObjectFinder::FObjectFinder
(this=0x7fffecce38e8 , 
ObjectToFind=0x7fffec3e2678 L"/Engine/EditorMeshes/EditorSphere") at
/home/linuxdonald/UnrealEngine/Engine/Source/Runtime/CoreUObject/Public/UObject/ConstructorHelpers.h:91
#29 0x7fffea6597bc in UEditorEngine::UEditorEngine(FObjectInitializer
const&)::FConstructorStatics::FConstructorStatics() (this=0x7fffecce38c8
)
at
/home/linuxdonald/UnrealEngine/Engine/Source/Editor/UnrealEd/Private/Editor.cpp:211
#30 0x7fffea659195 in UEditorEngine::UEditorEngine (this=0x5754000,
ObjectInitializer=...) at
/home/linuxdonald/UnrealEngine/Engine/Source/Editor/UnrealEd/Private/Editor.cpp:214
#31 0x7fffebe9dde1 in UEditorEngine::__DefaultConstructor (X=...) at
/home/linuxdonald/UnrealEngine/Engine/Source/Editor/UnrealEd/Classes/Editor/EditorEngine.h:208
#32 0x7fffebe9dd75 in InternalConstructor (X=...) at
/home/linuxdonald/UnrealEngine/Engine/Source/Runtime/CoreUObject/Public/UObject/Class.h:2206
#33 0x7654bd0e in UClass::CreateDefaultObject (this=0xaeed40) at
/home/linuxdonald/UnrealEngine/Engine/Source/Runtime/CoreUObject/Private/UObject/Class.cpp:2512
#34 0x00472507 in UClass::GetDefaultObject (this=0xaeed40,
bCreateIfNeeded=true) at Runtime/CoreUObject/Public/UObject/Class.h:1946
#35 0x767fcab5 in UObjectLoadAllCompiledInDefaultProperties () at
/home/linuxdonald/UnrealEngine/Engine/Source/Runtime/CoreUObject/Private/UObject/UObjectBase.cpp:737
#36 0x767fbd2a in ProcessNewlyLoadedUObjects () at
/home/linuxdonald/UnrealEngine/Engine/Source/Runtime/CoreUObject/Private/UObject/UObjectBase.cpp:812
#37 0x0042a933 in FEngineLoop::PreInit (this=0x6b0568 ,
CmdLine=0x491318 L"") at
/home/linuxdonald/UnrealEngine/Engine/Source/Runtime/Launch/Private/LaunchEngineLoop.cpp:1277
#38 0x0041d5d2 in EnginePreInit (CmdLine=0x491318 L"") at
/home/linuxdonald/UnrealEngine/Engine/Source/Runtime/Launch/Private/Launch.cpp:31
#39 0x0044dd74 in GuardedMain (CmdLine=0x491318 L"") at
/home/linuxdonald/UnrealEngine/Engine/Source/Runtime/Launch/Private/Launch.cpp:110
#40 0x00466d66 in main (argc=1, argv=0x7fffe708) at
/home/linuxdonald/UnrealEngine/Engine/Source/Runtime/Launch/Private/Linux/LaunchLinux.cpp:193
(gdb) [2014.11.19-17.15.00:176][  0]LogGenericPlatformMisc:
FPlatformMisc::RequestExit(0)
[2014.11.19-17.15.00:186][  0]LogExit: Preparing to exit.
[2014.11.19-17.15.00:192][  0]LogExit: Exiting.
[2014.11.19-17.15.00:299][  0]LogGenericPlatformMisc:
FPlatformMisc::RequestExit(0)
[2014.11.19-17.15.00:309][  0]LogExit: Preparing to exit.
[2014.11.19-17.15.00:315][  0]LogExit: Exiting.
[2014.11.19-17.15.00:836][  0]LogGenericPlatformMisc:
FPlatformMisc::RequestExit(0)
[2014.11.19-17.15.00:846][  0]LogExit: Preparing to exit.
[2014.11.19-17.15.00:852][  0]LogExit: Exiting.

-- 
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/20141119/0b98624e/attachment-0001.html>


[PATCH] drm/radeon: update the VM after setting BO address v4

2014-11-19 Thread Christian König
From: Christian König 

This way the necessary VM update is kicked off immediately
if all BOs involved are in GPU accessible memory.

v2: fix vm lock
v3: immediately update unmaps as well
v4: use drm_free_large instead of kfree

Signed-off-by: Christian König 
Tested-by: Kai Wasserbäch 
---
 drivers/gpu/drm/radeon/radeon_gem.c | 64 +
 1 file changed, 64 insertions(+)

diff --git a/drivers/gpu/drm/radeon/radeon_gem.c 
b/drivers/gpu/drm/radeon/radeon_gem.c
index f752c7f..a748a64 100644
--- a/drivers/gpu/drm/radeon/radeon_gem.c
+++ b/drivers/gpu/drm/radeon/radeon_gem.c
@@ -518,6 +518,68 @@ out:
return r;
 }

+/**
+ * radeon_gem_va_update_vm -update the bo_va in its VM
+ *
+ * @rdev: radeon_device pointer
+ * @bo_va: bo_va to update
+ *
+ * Update the bo_va directly after setting it's address. Errors are not
+ * vital here, so they are not reported back to userspace.
+ */
+static void radeon_gem_va_update_vm(struct radeon_device *rdev,
+   struct radeon_bo_va *bo_va)
+{
+   struct ttm_validate_buffer tv, *entry;
+   struct radeon_cs_reloc *vm_bos;
+   struct ww_acquire_ctx ticket;
+   struct list_head list;
+   unsigned domain;
+   int r;
+
+   INIT_LIST_HEAD(&list);
+
+   tv.bo = &bo_va->bo->tbo;
+   tv.shared = true;
+   list_add(&tv.head, &list);
+
+   vm_bos = radeon_vm_get_bos(rdev, bo_va->vm, &list);
+   if (!vm_bos)
+   return;
+
+   r = ttm_eu_reserve_buffers(&ticket, &list, true);
+   if (r)
+   goto error_free;
+
+   list_for_each_entry(entry, &list, head) {
+   domain = radeon_mem_type_to_domain(entry->bo->mem.mem_type);
+   /* if anything is swapped out don't swap it in here,
+  just abort and wait for the next CS */
+   if (domain == RADEON_GEM_DOMAIN_CPU)
+   goto error_unreserve;
+   }
+
+   mutex_lock(&bo_va->vm->mutex);
+   r = radeon_vm_clear_freed(rdev, bo_va->vm);
+   if (r)
+   goto error_unlock;
+
+   if (bo_va->it.start)
+   r = radeon_vm_bo_update(rdev, bo_va, &bo_va->bo->tbo.mem);
+
+error_unlock:
+   mutex_unlock(&bo_va->vm->mutex);
+
+error_unreserve:
+   ttm_eu_backoff_reservation(&ticket, &list);
+
+error_free:
+   drm_free_large(vm_bos);
+
+   if (r)
+   DRM_ERROR("Couldn't update BO_VA (%d)\n", r);
+}
+
 int radeon_gem_va_ioctl(struct drm_device *dev, void *data,
  struct drm_file *filp)
 {
@@ -612,6 +674,8 @@ int radeon_gem_va_ioctl(struct drm_device *dev, void *data,
default:
break;
}
+   if (!r)
+   radeon_gem_va_update_vm(rdev, bo_va);
args->operation = RADEON_VA_RESULT_OK;
if (r) {
args->operation = RADEON_VA_RESULT_ERROR;
-- 
1.9.1



[Bug 88501] AMD/ATI RS690M Console blanks to white

2014-11-19 Thread bugzilla-dae...@bugzilla.kernel.org
https://bugzilla.kernel.org/show_bug.cgi?id=88501

Alex Deucher  changed:

   What|Removed |Added

 CC||alexdeucher at gmail.com

--- Comment #3 from Alex Deucher  ---
Does booting a recent kernel with radeon.backlight=0 fix the issue?

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


[PATCH] drm/tegra: Select root window for event dispatch

2014-11-19 Thread Sean Paul
In finish pageflip, the driver was not selecting the root
window when dispatching events. This exposed a race where
a plane update would change the window selection and cause
tegra_dc_finish_page_flip to check the wrong base address.

This patch also protects access to the window selection register
as well as the registers affected by it.

Signed-off-by: Sean Paul 
---
 drivers/gpu/drm/tegra/dc.c | 20 +---
 1 file changed, 17 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/tegra/dc.c b/drivers/gpu/drm/tegra/dc.c
index b957908..a3b41ea 100644
--- a/drivers/gpu/drm/tegra/dc.c
+++ b/drivers/gpu/drm/tegra/dc.c
@@ -168,7 +168,7 @@ static int tegra_dc_setup_window(struct tegra_dc *dc, 
unsigned int index,
 const struct tegra_dc_window *window)
 {
unsigned h_offset, v_offset, h_size, v_size, h_dda, v_dda, bpp;
-   unsigned long value;
+   unsigned long value, flags;
bool yuv, planar;

/*
@@ -181,6 +181,8 @@ static int tegra_dc_setup_window(struct tegra_dc *dc, 
unsigned int index,
else
bpp = planar ? 1 : 2;

+   spin_lock_irqsave(&dc->lock, flags);
+
value = WINDOW_A_SELECT << index;
tegra_dc_writel(dc, value, DC_CMD_DISPLAY_WINDOW_HEADER);

@@ -273,6 +275,7 @@ static int tegra_dc_setup_window(struct tegra_dc *dc, 
unsigned int index,

case TEGRA_BO_TILING_MODE_BLOCK:
DRM_ERROR("hardware doesn't support block linear 
mode\n");
+   spin_unlock_irqrestore(&dc->lock, flags);
return -EINVAL;
}

@@ -330,6 +333,7 @@ static int tegra_dc_setup_window(struct tegra_dc *dc, 
unsigned int index,
}

tegra_dc_window_commit(dc, index);
+   spin_unlock_irqrestore(&dc->lock, flags);

return 0;
 }
@@ -339,10 +343,12 @@ static int tegra_window_plane_disable(struct drm_plane 
*plane)
struct tegra_dc *dc = to_tegra_dc(plane->crtc);
struct tegra_plane *p = to_tegra_plane(plane);
u32 value;
+   unsigned long flags;

if (!plane->crtc)
return 0;

+   spin_lock_irqsave(&dc->lock, flags);
value = WINDOW_A_SELECT << p->index;
tegra_dc_writel(dc, value, DC_CMD_DISPLAY_WINDOW_HEADER);

@@ -351,6 +357,7 @@ static int tegra_window_plane_disable(struct drm_plane 
*plane)
tegra_dc_writel(dc, value, DC_WIN_WIN_OPTIONS);

tegra_dc_window_commit(dc, p->index);
+   spin_unlock_irqrestore(&dc->lock, flags);

return 0;
 }
@@ -700,13 +707,14 @@ static int tegra_dc_set_base(struct tegra_dc *dc, int x, 
int y,
unsigned int h_offset = 0, v_offset = 0;
struct tegra_bo_tiling tiling;
unsigned int format, swap;
-   unsigned long value;
+   unsigned long value, flags;
int err;

err = tegra_fb_get_tiling(fb, &tiling);
if (err < 0)
return err;

+   spin_lock_irqsave(&dc->lock, flags);
tegra_dc_writel(dc, WINDOW_A_SELECT, DC_CMD_DISPLAY_WINDOW_HEADER);

value = fb->offsets[0] + y * fb->pitches[0] +
@@ -752,6 +760,7 @@ static int tegra_dc_set_base(struct tegra_dc *dc, int x, 
int y,

case TEGRA_BO_TILING_MODE_BLOCK:
DRM_ERROR("hardware doesn't support block linear 
mode\n");
+   spin_unlock_irqrestore(&dc->lock, flags);
return -EINVAL;
}

@@ -777,6 +786,7 @@ static int tegra_dc_set_base(struct tegra_dc *dc, int x, 
int y,
value = GENERAL_ACT_REQ | WIN_A_ACT_REQ;
tegra_dc_writel(dc, value << 8, DC_CMD_STATE_CONTROL);
tegra_dc_writel(dc, value, DC_CMD_STATE_CONTROL);
+   spin_unlock_irqrestore(&dc->lock, flags);

return 0;
 }
@@ -790,7 +800,6 @@ void tegra_dc_enable_vblank(struct tegra_dc *dc)
value = tegra_dc_readl(dc, DC_CMD_INT_MASK);
value |= VBLANK_INT;
tegra_dc_writel(dc, value, DC_CMD_INT_MASK);
-
spin_unlock_irqrestore(&dc->lock, flags);
 }

@@ -819,11 +828,16 @@ static void tegra_dc_finish_page_flip(struct tegra_dc *dc)

bo = tegra_fb_get_plane(crtc->primary->fb, 0);

+   spin_lock_irqsave(&dc->lock, flags);
+
/* check if new start address has been latched */
+   tegra_dc_writel(dc, WINDOW_A_SELECT, DC_CMD_DISPLAY_WINDOW_HEADER);
tegra_dc_writel(dc, READ_MUX, DC_CMD_STATE_ACCESS);
base = tegra_dc_readl(dc, DC_WINBUF_START_ADDR);
tegra_dc_writel(dc, 0, DC_CMD_STATE_ACCESS);

+   spin_unlock_irqrestore(&dc->lock, flags);
+
if (base == bo->paddr + crtc->primary->fb->offsets[0]) {
spin_lock_irqsave(&drm->event_lock, flags);
drm_send_vblank_event(drm, dc->pipe, dc->event);
-- 
2.1.1



[Bug 88501] AMD/ATI RS690M Console blanks to white

2014-11-19 Thread bugzilla-dae...@bugzilla.kernel.org
https://bugzilla.kernel.org/show_bug.cgi?id=88501

--- Comment #4 from Alex Deucher  ---
Created attachment 158211
  --> https://bugzilla.kernel.org/attachment.cgi?id=158211&action=edit
possible fix

Does this patch fix the issue (against 3.17 or newer kernel)?

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


[PATCH 01/11] drm/radeon: rework vm_flush parameters

2014-11-19 Thread Alex Deucher
On Wed, Nov 19, 2014 at 8:01 AM, Christian König
 wrote:
> From: Christian König 
>
> Use ring structure instead of index and provide vm_id and pd_addr separately.
>
> Signed-off-by: Christian König 

Pushed to my 3.19-wip tree.  I'll send out a new radeon drm-next pull
request later today or tomorrow.

Alex

> ---
>  drivers/gpu/drm/radeon/cik.c | 23 ++-
>  drivers/gpu/drm/radeon/cik_sdma.c| 22 +-
>  drivers/gpu/drm/radeon/ni.c  | 14 +-
>  drivers/gpu/drm/radeon/ni_dma.c  | 14 +-
>  drivers/gpu/drm/radeon/radeon.h  |  5 +++--
>  drivers/gpu/drm/radeon/radeon_asic.h | 18 --
>  drivers/gpu/drm/radeon/radeon_vm.c   |  3 ++-
>  drivers/gpu/drm/radeon/si.c  | 18 +++---
>  drivers/gpu/drm/radeon/si_dma.c  | 19 ---
>  9 files changed, 61 insertions(+), 75 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeon/cik.c b/drivers/gpu/drm/radeon/cik.c
> index 57a359d..d52ead9 100644
> --- a/drivers/gpu/drm/radeon/cik.c
> +++ b/drivers/gpu/drm/radeon/cik.c
> @@ -5967,26 +5967,23 @@ static void cik_vm_decode_fault(struct radeon_device 
> *rdev,
>   * Update the page table base and flush the VM TLB
>   * using the CP (CIK).
>   */
> -void cik_vm_flush(struct radeon_device *rdev, int ridx, struct radeon_vm *vm)
> +void cik_vm_flush(struct radeon_device *rdev, struct radeon_ring *ring,
> + unsigned vm_id, uint64_t pd_addr)
>  {
> -   struct radeon_ring *ring = &rdev->ring[ridx];
> -   int usepfp = (ridx == RADEON_RING_TYPE_GFX_INDEX);
> -
> -   if (vm == NULL)
> -   return;
> +   int usepfp = (ring->idx == RADEON_RING_TYPE_GFX_INDEX);
>
> radeon_ring_write(ring, PACKET3(PACKET3_WRITE_DATA, 3));
> radeon_ring_write(ring, (WRITE_DATA_ENGINE_SEL(usepfp) |
>  WRITE_DATA_DST_SEL(0)));
> -   if (vm->id < 8) {
> +   if (vm_id < 8) {
> radeon_ring_write(ring,
> - (VM_CONTEXT0_PAGE_TABLE_BASE_ADDR + (vm->id 
> << 2)) >> 2);
> + (VM_CONTEXT0_PAGE_TABLE_BASE_ADDR + (vm_id 
> << 2)) >> 2);
> } else {
> radeon_ring_write(ring,
> - (VM_CONTEXT8_PAGE_TABLE_BASE_ADDR + 
> ((vm->id - 8) << 2)) >> 2);
> + (VM_CONTEXT8_PAGE_TABLE_BASE_ADDR + ((vm_id 
> - 8) << 2)) >> 2);
> }
> radeon_ring_write(ring, 0);
> -   radeon_ring_write(ring, vm->pd_gpu_addr >> 12);
> +   radeon_ring_write(ring, pd_addr >> 12);
>
> /* update SH_MEM_* regs */
> radeon_ring_write(ring, PACKET3(PACKET3_WRITE_DATA, 3));
> @@ -5994,7 +5991,7 @@ void cik_vm_flush(struct radeon_device *rdev, int ridx, 
> struct radeon_vm *vm)
>  WRITE_DATA_DST_SEL(0)));
> radeon_ring_write(ring, SRBM_GFX_CNTL >> 2);
> radeon_ring_write(ring, 0);
> -   radeon_ring_write(ring, VMID(vm->id));
> +   radeon_ring_write(ring, VMID(vm_id));
>
> radeon_ring_write(ring, PACKET3(PACKET3_WRITE_DATA, 6));
> radeon_ring_write(ring, (WRITE_DATA_ENGINE_SEL(usepfp) |
> @@ -6015,7 +6012,7 @@ void cik_vm_flush(struct radeon_device *rdev, int ridx, 
> struct radeon_vm *vm)
> radeon_ring_write(ring, VMID(0));
>
> /* HDP flush */
> -   cik_hdp_flush_cp_ring_emit(rdev, ridx);
> +   cik_hdp_flush_cp_ring_emit(rdev, ring->idx);
>
> /* bits 0-15 are the VM contexts0-15 */
> radeon_ring_write(ring, PACKET3(PACKET3_WRITE_DATA, 3));
> @@ -6023,7 +6020,7 @@ void cik_vm_flush(struct radeon_device *rdev, int ridx, 
> struct radeon_vm *vm)
>  WRITE_DATA_DST_SEL(0)));
> radeon_ring_write(ring, VM_INVALIDATE_REQUEST >> 2);
> radeon_ring_write(ring, 0);
> -   radeon_ring_write(ring, 1 << vm->id);
> +   radeon_ring_write(ring, 1 << vm_id);
>
> /* compute doesn't have PFP */
> if (usepfp) {
> diff --git a/drivers/gpu/drm/radeon/cik_sdma.c 
> b/drivers/gpu/drm/radeon/cik_sdma.c
> index 4e8432d..7470a2e 100644
> --- a/drivers/gpu/drm/radeon/cik_sdma.c
> +++ b/drivers/gpu/drm/radeon/cik_sdma.c
> @@ -901,25 +901,21 @@ void cik_sdma_vm_pad_ib(struct radeon_ib *ib)
>   * Update the page table base and flush the VM TLB
>   * using sDMA (CIK).
>   */
> -void cik_dma_vm_flush(struct radeon_device *rdev, int ridx, struct radeon_vm 
> *vm)
> +void cik_dma_vm_flush(struct radeon_device *rdev, struct radeon_ring *ring,
> + unsigned vm_id, uint64_t pd_addr)
>  {
> -   struct radeon_ring *ring = &rdev->ring[ridx];
> -
> -   if (vm == NULL)
> -   return;
> -
> radeon_ring_write(ring, SDMA_PACKET(SDMA_OPCODE_SRBM_WRITE, 0, 
> 0xf000));
> -   if (vm->id < 8) {
> -   radeon_ring_write(ring, (VM_CONTEXT0_PAGE_TABLE_BASE_ADDR + 
> (vm->id << 2)) >> 2);
> + 

[Bug 61941] Random GPU lockups/resets on Mobility Radeon HD 3650 with radeon.dpm=1

2014-11-19 Thread bugzilla-dae...@bugzilla.kernel.org
https://bugzilla.kernel.org/show_bug.cgi?id=61941

Pavol Klačanský  changed:

   What|Removed |Added

 CC||pavol at klacansky.com

--- Comment #23 from Pavol Klačanský  ---
It occurs at least once a day on 3.18.0-031800rc4-generic.

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


[PATCH 01/11] drm/radeon: rework vm_flush parameters

2014-11-19 Thread Christian König
Am 19.11.2014 um 19:28 schrieb Alex Deucher:
> On Wed, Nov 19, 2014 at 8:01 AM, Christian König
>  wrote:
>> From: Christian König 
>>
>> Use ring structure instead of index and provide vm_id and pd_addr separately.
>>
>> Signed-off-by: Christian König 
> Pushed to my 3.19-wip tree.  I'll send out a new radeon drm-next pull
> request later today or tomorrow.

Please note that I had to fix another bug in the last patch pointed out 
by Kai Wasserbäch.

The updated patch should already be in your inbox.

Christian.

>
> Alex
>
>> ---
>>   drivers/gpu/drm/radeon/cik.c | 23 ++-
>>   drivers/gpu/drm/radeon/cik_sdma.c| 22 +-
>>   drivers/gpu/drm/radeon/ni.c  | 14 +-
>>   drivers/gpu/drm/radeon/ni_dma.c  | 14 +-
>>   drivers/gpu/drm/radeon/radeon.h  |  5 +++--
>>   drivers/gpu/drm/radeon/radeon_asic.h | 18 --
>>   drivers/gpu/drm/radeon/radeon_vm.c   |  3 ++-
>>   drivers/gpu/drm/radeon/si.c  | 18 +++---
>>   drivers/gpu/drm/radeon/si_dma.c  | 19 ---
>>   9 files changed, 61 insertions(+), 75 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/radeon/cik.c b/drivers/gpu/drm/radeon/cik.c
>> index 57a359d..d52ead9 100644
>> --- a/drivers/gpu/drm/radeon/cik.c
>> +++ b/drivers/gpu/drm/radeon/cik.c
>> @@ -5967,26 +5967,23 @@ static void cik_vm_decode_fault(struct radeon_device 
>> *rdev,
>>* Update the page table base and flush the VM TLB
>>* using the CP (CIK).
>>*/
>> -void cik_vm_flush(struct radeon_device *rdev, int ridx, struct radeon_vm 
>> *vm)
>> +void cik_vm_flush(struct radeon_device *rdev, struct radeon_ring *ring,
>> + unsigned vm_id, uint64_t pd_addr)
>>   {
>> -   struct radeon_ring *ring = &rdev->ring[ridx];
>> -   int usepfp = (ridx == RADEON_RING_TYPE_GFX_INDEX);
>> -
>> -   if (vm == NULL)
>> -   return;
>> +   int usepfp = (ring->idx == RADEON_RING_TYPE_GFX_INDEX);
>>
>>  radeon_ring_write(ring, PACKET3(PACKET3_WRITE_DATA, 3));
>>  radeon_ring_write(ring, (WRITE_DATA_ENGINE_SEL(usepfp) |
>>   WRITE_DATA_DST_SEL(0)));
>> -   if (vm->id < 8) {
>> +   if (vm_id < 8) {
>>  radeon_ring_write(ring,
>> - (VM_CONTEXT0_PAGE_TABLE_BASE_ADDR + 
>> (vm->id << 2)) >> 2);
>> + (VM_CONTEXT0_PAGE_TABLE_BASE_ADDR + (vm_id 
>> << 2)) >> 2);
>>  } else {
>>  radeon_ring_write(ring,
>> - (VM_CONTEXT8_PAGE_TABLE_BASE_ADDR + 
>> ((vm->id - 8) << 2)) >> 2);
>> + (VM_CONTEXT8_PAGE_TABLE_BASE_ADDR + 
>> ((vm_id - 8) << 2)) >> 2);
>>  }
>>  radeon_ring_write(ring, 0);
>> -   radeon_ring_write(ring, vm->pd_gpu_addr >> 12);
>> +   radeon_ring_write(ring, pd_addr >> 12);
>>
>>  /* update SH_MEM_* regs */
>>  radeon_ring_write(ring, PACKET3(PACKET3_WRITE_DATA, 3));
>> @@ -5994,7 +5991,7 @@ void cik_vm_flush(struct radeon_device *rdev, int 
>> ridx, struct radeon_vm *vm)
>>   WRITE_DATA_DST_SEL(0)));
>>  radeon_ring_write(ring, SRBM_GFX_CNTL >> 2);
>>  radeon_ring_write(ring, 0);
>> -   radeon_ring_write(ring, VMID(vm->id));
>> +   radeon_ring_write(ring, VMID(vm_id));
>>
>>  radeon_ring_write(ring, PACKET3(PACKET3_WRITE_DATA, 6));
>>  radeon_ring_write(ring, (WRITE_DATA_ENGINE_SEL(usepfp) |
>> @@ -6015,7 +6012,7 @@ void cik_vm_flush(struct radeon_device *rdev, int 
>> ridx, struct radeon_vm *vm)
>>  radeon_ring_write(ring, VMID(0));
>>
>>  /* HDP flush */
>> -   cik_hdp_flush_cp_ring_emit(rdev, ridx);
>> +   cik_hdp_flush_cp_ring_emit(rdev, ring->idx);
>>
>>  /* bits 0-15 are the VM contexts0-15 */
>>  radeon_ring_write(ring, PACKET3(PACKET3_WRITE_DATA, 3));
>> @@ -6023,7 +6020,7 @@ void cik_vm_flush(struct radeon_device *rdev, int 
>> ridx, struct radeon_vm *vm)
>>   WRITE_DATA_DST_SEL(0)));
>>  radeon_ring_write(ring, VM_INVALIDATE_REQUEST >> 2);
>>  radeon_ring_write(ring, 0);
>> -   radeon_ring_write(ring, 1 << vm->id);
>> +   radeon_ring_write(ring, 1 << vm_id);
>>
>>  /* compute doesn't have PFP */
>>  if (usepfp) {
>> diff --git a/drivers/gpu/drm/radeon/cik_sdma.c 
>> b/drivers/gpu/drm/radeon/cik_sdma.c
>> index 4e8432d..7470a2e 100644
>> --- a/drivers/gpu/drm/radeon/cik_sdma.c
>> +++ b/drivers/gpu/drm/radeon/cik_sdma.c
>> @@ -901,25 +901,21 @@ void cik_sdma_vm_pad_ib(struct radeon_ib *ib)
>>* Update the page table base and flush the VM TLB
>>* using sDMA (CIK).
>>*/
>> -void cik_dma_vm_flush(struct radeon_device *rdev, int ridx, struct 
>> radeon_vm *vm)
>> +void cik_dma_vm_flush(struct radeon_device *rdev, struct radeon_ring *ring,
>> + unsigned vm_i

[RFC 0/7+1] Add in-kernel vblank delaying mechanism

2014-11-19 Thread Paulo Zanoni
From: Paulo Zanoni 

Hi

---
TL;DR summary:
I wrote patches. Help me choose the best implementation and interface.
---

So the i915.ko driver could use some mechanism to run functions after a given
number of vblanks. Implementations for this mechanism were already proposed in
the past (by Chris Wilson and others), but they were i915-specific instead of a
generic drm.ko implementation. We even had patches that make use of this new
mechanism.

Since this is very similar to the vblank IOCTL we currently have, but with the
caller being a Kernel module instead of user space, I decided to write an
implementation that tries to reuse the current IOCTL infrastructure.

In the first patch we add all the necessary code to allow the modules to call
the vblank ioctl from Kernel space: they provide a callback function that is
going to be called instead of the traditional send_vblank_event(), which means
the Kernel callers don't have to deal with the file descriptors and DRM events.

In the second patch we add a simple extension of the feature, to allow the
drivers to have their callbacks called in a non-atomic context.

In all the other subsequent patches we rework the underlying code so that
the common aspects between the user space vblank IOCTL and the Kernel interface
are all stored in a single structure (struct drm_vblank_wait_item), and then
anything that is specific to the different users is stored in a structure that
contains struct drm_vblank_wait_item. This way, most of the drm.ko code only
needs to deal with struct drm_vblank_wait_item, not really knowing how it is
wrapped. The advantage of this rework is that it reduces the number of memory
allocations needed in some cases (from 2 to 1) and it also reduces the amount of
memory used on each allocation.

But while this all sounds nice in the above description, I had the feeling that
this adds a lot of complexity and makes the code not-so-beautiful. If we ever
need more extensions/options to this feature, we're going to have to untangle
the code even more from the IOCTL part. We also have a small "abstraction break"
in change introduced in patch 6. And there's the risk that some of the reworks
may have added a regression somewhere.

Based on that, I decided to also provide an alternative implementation. In this
implementation we add a new dev->vblank_kernel_list instead of reusing
dev->vblank_event_list, and add new code to handle that this. This new code is
completely based on the code that handles dev->vblank_kernel_list, so there's
some duplication here. On the other hand, since the in-Kernel infrastructure is
not tied to the IOCTL structure, we can very easily grow and adapt the Kernel
code without having to fight against the IOCTL code. And the risk of regressions
is greatly reduced.

The second difference of this alternative implementation is the signature of the
drm_wait_vblank_kernel() function. While it could be exactly the same as the one
used in the other series, I decided to make it different so we can also choose
which one to use. In the 7-patch series implementation, all the user needs to do
is to allocate the structure, and call the function, properly setting all its
arguments. Then the function is responsible for parsing the arguments and
populating the structure based on that. On the alternative implementation, the
user has to fill the structure with the appropriate arguments, and then call
drm_wait_vblank_kernel() passing just the allocated structure as an argument.

If you notice, you will see that these patches add a new debugfs file to
i915.ko. This file is just a very simple example user of the new interface,
which I used while developing. If you have difficulty understanding the new
interface, please also look at the i915/i915_debugfs.c diff. Of course, I plan
to exclude this debugfs interface from the final to-be-merged patches.

So, in summary, we have a few things we need to discuss:

 1. Which implementation to use?

   a. Just the 2 first patches of the 7-patch series?
  Pros:
- the Kernel users basically call the vblank IOCTL
- the code changes are minimal
 Cons:
- The amount of memory allocations and memory space consumed is not
  optimal

   b. The full 7-patch series?
  Pros:
- The same backend is used for both the Kernel and IOCTL.
  Cons:
- The code gets more complex.
- Extending the Kernel interface can get complicated due to the fact
  that it shares code with the IOCTL interface.
- I didn't really like this solution.

   c. The alternative implementation I wrote?
  Pros:
- It's independent from the IOCTL code, making further patches easier.
  Cons:
- There is some duplicated code.

   d. Something totally different from these alternatives?

 2. How should the driver interface look like?

   a. All the possibilities are passed through the function call, so the drm.ko
  code needs to set the struct members itself.

[RFC] drm: add a mechanism for drivers to schedule vblank callbacks

2014-11-19 Thread Paulo Zanoni
From: Paulo Zanoni 

The drivers need a way to schedule functions to be ran after a certain
number of vblanks. The i915.ko driver has plenty of examples where
this could be used, such as for unpinning buffers after a modeset.
Since the vblank wait IOCTL does basically what we want, but for the
user space, in this patch we add a new list of vblank events
(dev->vblank_kernel_list) and handle it exactly like we handle the
user space events.

Signed-off-by: Paulo Zanoni 
---
 drivers/gpu/drm/drm_drv.c   |   1 +
 drivers/gpu/drm/drm_irq.c   | 106 ++--
 drivers/gpu/drm/i915/i915_debugfs.c |  81 +++
 include/drm/drmP.h  |  22 
 4 files changed, 206 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
index 2e5c7d9..b5ae6c8 100644
--- a/drivers/gpu/drm/drm_drv.c
+++ b/drivers/gpu/drm/drm_drv.c
@@ -557,6 +557,7 @@ struct drm_device *drm_dev_alloc(struct drm_driver *driver,
INIT_LIST_HEAD(&dev->vmalist);
INIT_LIST_HEAD(&dev->maplist);
INIT_LIST_HEAD(&dev->vblank_event_list);
+   INIT_LIST_HEAD(&dev->vblank_kernel_list);

spin_lock_init(&dev->buf_lock);
spin_lock_init(&dev->event_lock);
diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
index 0e47df4..6e04035 100644
--- a/drivers/gpu/drm/drm_irq.c
+++ b/drivers/gpu/drm/drm_irq.c
@@ -1107,6 +1107,13 @@ void drm_crtc_wait_one_vblank(struct drm_crtc *crtc)
 }
 EXPORT_SYMBOL(drm_crtc_wait_one_vblank);

+static void send_kernel_vblank_event(struct drm_kernel_vblank_item *item)
+{
+   if (item->callback_from_work)
+   schedule_work(&item->work);
+   else
+   item->callback(item);
+}
 /**
  * drm_vblank_off - disable vblank events on a CRTC
  * @dev: DRM device
@@ -1124,7 +1131,8 @@ EXPORT_SYMBOL(drm_crtc_wait_one_vblank);
 void drm_vblank_off(struct drm_device *dev, int crtc)
 {
struct drm_vblank_crtc *vblank = &dev->vblank[crtc];
-   struct drm_pending_vblank_event *e, *t;
+   struct drm_pending_vblank_event *e, *et;
+   struct drm_kernel_vblank_item *i, *it;
struct timeval now;
unsigned long irqflags;
unsigned int seq;
@@ -1151,7 +1159,7 @@ void drm_vblank_off(struct drm_device *dev, int crtc)
/* Send any queued vblank events, lest the natives grow disquiet */
seq = drm_vblank_count_and_time(dev, crtc, &now);

-   list_for_each_entry_safe(e, t, &dev->vblank_event_list, base.link) {
+   list_for_each_entry_safe(e, et, &dev->vblank_event_list, base.link) {
if (e->pipe != crtc)
continue;
DRM_DEBUG("Sending premature vblank event on disable: \
@@ -1161,6 +1169,21 @@ void drm_vblank_off(struct drm_device *dev, int crtc)
drm_vblank_put(dev, e->pipe);
send_vblank_event(dev, e, seq, &now);
}
+
+   list_for_each_entry_safe(i, it, &dev->vblank_kernel_list, link) {
+   int pipe = drm_crtc_index(i->crtc);
+
+   if (pipe != crtc)
+   continue;
+
+   DRM_DEBUG("Sending premature kernel vblank event on disable: \
+ wanted %d, current %d\n",
+ i->target_seq, seq);
+   i->premature = true;
+   list_del(&i->link);
+   drm_vblank_put(dev, pipe);
+   send_kernel_vblank_event(i);
+   }
spin_unlock_irqrestore(&dev->event_lock, irqflags);
 }
 EXPORT_SYMBOL(drm_vblank_off);
@@ -1560,9 +1583,68 @@ done:
return ret;
 }

+static void drm_kernel_vblank_work_func(struct work_struct *work)
+{
+   struct drm_kernel_vblank_item *item =
+   container_of(work, struct drm_kernel_vblank_item, work);
+
+   item->callback(item);
+}
+
+int drm_wait_vblank_kernel(struct drm_kernel_vblank_item *item)
+{
+   struct drm_crtc *crtc = item->crtc;
+   struct drm_device *dev = crtc->dev;
+   int pipe = drm_crtc_index(crtc);
+   struct drm_vblank_crtc *vblank = &dev->vblank[pipe];
+   unsigned int seq;
+   unsigned long irqflags;
+   int ret = 0;
+
+   if (!dev->irq_enabled)
+   return -EINVAL;
+
+   if (item->callback_from_work)
+   INIT_WORK(&item->work, drm_kernel_vblank_work_func);
+
+   ret = drm_vblank_get(dev, pipe);
+   if (ret) {
+   DRM_DEBUG("failed to acquire vblank counter, %d\n", ret);
+   return ret;
+   }
+
+   seq = drm_vblank_count(dev, pipe);
+   if (!item->absolute)
+   item->target_seq += seq;
+
+   spin_lock_irqsave(&dev->event_lock, irqflags);
+
+   if (!vblank->enabled) {
+   ret = -EINVAL;
+   goto out;
+   }
+
+   if (seq - item->target_seq <= (1 << 23)) {
+   drm_vblank_put(dev, pipe);
+   send_kernel_vblank_event(item);
+   } el

  1   2   >