[Bug 90997] [apitrace] GPU lockup with Dishonored and Gallium Nine

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

Nick Sarnie  changed:

   What|Removed |Added

 Resolution|--- |WORKSFORME
 Status|NEW |RESOLVED

--- Comment #4 from Nick Sarnie  ---
Hi,

I cannot reproduce this anymore.

Thanks,
sarnex

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


[PATCH 20/20] drm/gma500: use DRM_FB_HELPER_DEFAULT_OPS for fb_ops

2016-09-29 Thread Stefan Christ
This refactoring leads to real functional changes in the driver.

Now the struct psbfb_ops implements two additional members:

   .fb_setcmap = drm_fb_helper_setcmap,
   .fb_pan_display = drm_fb_helper_pan_display,

and the struct psbfb_roll_ops implements one additional member:

   .fb_setcmap = drm_fb_helper_setcmap,

and the struct psbfb_unaccel_ops implements two additional members:

   .fb_setcmap = drm_fb_helper_setcmap,
   .fb_pan_display = drm_fb_helper_pan_display,

These changes are not tested.

Cc: Patrik Jakobsson 
Signed-off-by: Stefan Christ 
---
 drivers/gpu/drm/gma500/framebuffer.c | 12 +++-
 1 file changed, 3 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/gma500/framebuffer.c 
b/drivers/gpu/drm/gma500/framebuffer.c
index 0fcdce0..24aa16b 100644
--- a/drivers/gpu/drm/gma500/framebuffer.c
+++ b/drivers/gpu/drm/gma500/framebuffer.c
@@ -186,9 +186,7 @@ static int psbfb_mmap(struct fb_info *info, struct 
vm_area_struct *vma)

 static struct fb_ops psbfb_ops = {
.owner = THIS_MODULE,
-   .fb_check_var = drm_fb_helper_check_var,
-   .fb_set_par = drm_fb_helper_set_par,
-   .fb_blank = drm_fb_helper_blank,
+   DRM_FB_HELPER_DEFAULT_OPS,
.fb_setcolreg = psbfb_setcolreg,
.fb_fillrect = drm_fb_helper_cfb_fillrect,
.fb_copyarea = psbfb_copyarea,
@@ -199,9 +197,7 @@ static struct fb_ops psbfb_ops = {

 static struct fb_ops psbfb_roll_ops = {
.owner = THIS_MODULE,
-   .fb_check_var = drm_fb_helper_check_var,
-   .fb_set_par = drm_fb_helper_set_par,
-   .fb_blank = drm_fb_helper_blank,
+   DRM_FB_HELPER_DEFAULT_OPS,
.fb_setcolreg = psbfb_setcolreg,
.fb_fillrect = drm_fb_helper_cfb_fillrect,
.fb_copyarea = drm_fb_helper_cfb_copyarea,
@@ -212,9 +208,7 @@ static struct fb_ops psbfb_roll_ops = {

 static struct fb_ops psbfb_unaccel_ops = {
.owner = THIS_MODULE,
-   .fb_check_var = drm_fb_helper_check_var,
-   .fb_set_par = drm_fb_helper_set_par,
-   .fb_blank = drm_fb_helper_blank,
+   DRM_FB_HELPER_DEFAULT_OPS,
.fb_setcolreg = psbfb_setcolreg,
.fb_fillrect = drm_fb_helper_cfb_fillrect,
.fb_copyarea = drm_fb_helper_cfb_copyarea,
-- 
2.7.3



[PATCH 19/20] drm/i915: use DRM_FB_HELPER_DEFAULT_OPS for fb_ops

2016-09-29 Thread Stefan Christ
Cc: Daniel Vetter 
Cc: Jani Nikula 
Signed-off-by: Stefan Christ 
---
 drivers/gpu/drm/i915/intel_fbdev.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_fbdev.c 
b/drivers/gpu/drm/i915/intel_fbdev.c
index 3e3632c..cf589ab 100644
--- a/drivers/gpu/drm/i915/intel_fbdev.c
+++ b/drivers/gpu/drm/i915/intel_fbdev.c
@@ -102,14 +102,13 @@ static int intel_fbdev_pan_display(struct 
fb_var_screeninfo *var,

 static struct fb_ops intelfb_ops = {
.owner = THIS_MODULE,
-   .fb_check_var = drm_fb_helper_check_var,
+   DRM_FB_HELPER_DEFAULT_OPS,
.fb_set_par = intel_fbdev_set_par,
.fb_fillrect = drm_fb_helper_cfb_fillrect,
.fb_copyarea = drm_fb_helper_cfb_copyarea,
.fb_imageblit = drm_fb_helper_cfb_imageblit,
.fb_pan_display = intel_fbdev_pan_display,
.fb_blank = intel_fbdev_blank,
-   .fb_setcmap = drm_fb_helper_setcmap,
.fb_debug_enter = drm_fb_helper_debug_enter,
.fb_debug_leave = drm_fb_helper_debug_leave,
 };
-- 
2.7.3



[PATCH 18/20] drm/omapdrm: use DRM_FB_HELPER_DEFAULT_OPS for fb_ops

2016-09-29 Thread Stefan Christ
Cc: Tomi Valkeinen 
Signed-off-by: Stefan Christ 
---
 drivers/gpu/drm/omapdrm/omap_fbdev.c | 5 +
 1 file changed, 1 insertion(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/omapdrm/omap_fbdev.c 
b/drivers/gpu/drm/omapdrm/omap_fbdev.c
index adb10fb..8d8ac17 100644
--- a/drivers/gpu/drm/omapdrm/omap_fbdev.c
+++ b/drivers/gpu/drm/omapdrm/omap_fbdev.c
@@ -82,6 +82,7 @@ fallback:

 static struct fb_ops omap_fb_ops = {
.owner = THIS_MODULE,
+   DRM_FB_HELPER_DEFAULT_OPS,

/* Note: to properly handle manual update displays, we wrap the
 * basic fbdev ops which write to the framebuffer
@@ -92,11 +93,7 @@ static struct fb_ops omap_fb_ops = {
.fb_copyarea = drm_fb_helper_sys_copyarea,
.fb_imageblit = drm_fb_helper_sys_imageblit,

-   .fb_check_var = drm_fb_helper_check_var,
-   .fb_set_par = drm_fb_helper_set_par,
.fb_pan_display = omap_fbdev_pan_display,
-   .fb_blank = drm_fb_helper_blank,
-   .fb_setcmap = drm_fb_helper_setcmap,
 };

 static int omap_fbdev_create(struct drm_fb_helper *helper,
-- 
2.7.3



[PATCH 17/20] drm/virtio: use DRM_FB_HELPER_DEFAULT_OPS for fb_ops

2016-09-29 Thread Stefan Christ
This patch removes a TODO comment in the code. I do not know whether it
is still relevant.

Cc: David Airlie 
Cc: Gerd Hoffmann 
Signed-off-by: Stefan Christ 
---
 drivers/gpu/drm/virtio/virtgpu_fb.c | 6 +-
 1 file changed, 1 insertion(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/virtio/virtgpu_fb.c 
b/drivers/gpu/drm/virtio/virtgpu_fb.c
index 2242a80..138dbcf 100644
--- a/drivers/gpu/drm/virtio/virtgpu_fb.c
+++ b/drivers/gpu/drm/virtio/virtgpu_fb.c
@@ -200,14 +200,10 @@ static void virtio_gpu_3d_imageblit(struct fb_info *info,

 static struct fb_ops virtio_gpufb_ops = {
.owner = THIS_MODULE,
-   .fb_check_var = drm_fb_helper_check_var,
-   .fb_set_par = drm_fb_helper_set_par, /* TODO: copy vmwgfx */
+   DRM_FB_HELPER_DEFAULT_OPS,
.fb_fillrect = virtio_gpu_3d_fillrect,
.fb_copyarea = virtio_gpu_3d_copyarea,
.fb_imageblit = virtio_gpu_3d_imageblit,
-   .fb_pan_display = drm_fb_helper_pan_display,
-   .fb_blank = drm_fb_helper_blank,
-   .fb_setcmap = drm_fb_helper_setcmap,
.fb_debug_enter = drm_fb_helper_debug_enter,
.fb_debug_leave = drm_fb_helper_debug_leave,
 };
-- 
2.7.3



[PATCH 16/20] drm/msm: use DRM_FB_HELPER_DEFAULT_OPS for fb_ops

2016-09-29 Thread Stefan Christ
Cc: Rob Clark 
Signed-off-by: Stefan Christ 
---
 drivers/gpu/drm/msm/msm_fbdev.c | 7 +--
 1 file changed, 1 insertion(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/msm/msm_fbdev.c b/drivers/gpu/drm/msm/msm_fbdev.c
index ffd4a33..d29f5e8 100644
--- a/drivers/gpu/drm/msm/msm_fbdev.c
+++ b/drivers/gpu/drm/msm/msm_fbdev.c
@@ -39,6 +39,7 @@ struct msm_fbdev {

 static struct fb_ops msm_fb_ops = {
.owner = THIS_MODULE,
+   DRM_FB_HELPER_DEFAULT_OPS,

/* Note: to properly handle manual update displays, we wrap the
 * basic fbdev ops which write to the framebuffer
@@ -49,12 +50,6 @@ static struct fb_ops msm_fb_ops = {
.fb_copyarea = drm_fb_helper_sys_copyarea,
.fb_imageblit = drm_fb_helper_sys_imageblit,
.fb_mmap = msm_fbdev_mmap,
-
-   .fb_check_var = drm_fb_helper_check_var,
-   .fb_set_par = drm_fb_helper_set_par,
-   .fb_pan_display = drm_fb_helper_pan_display,
-   .fb_blank = drm_fb_helper_blank,
-   .fb_setcmap = drm_fb_helper_setcmap,
 };

 static int msm_fbdev_mmap(struct fb_info *info, struct vm_area_struct *vma)
-- 
2.7.3



[PATCH 15/20] drm/udl: use DRM_FB_HELPER_DEFAULT_OPS for fb_ops

2016-09-29 Thread Stefan Christ
Cc: Dave Airlie 
Signed-off-by: Stefan Christ 
---
 drivers/gpu/drm/udl/udl_fb.c | 6 +-
 1 file changed, 1 insertion(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/udl/udl_fb.c b/drivers/gpu/drm/udl/udl_fb.c
index 9688bfa..2137a4f 100644
--- a/drivers/gpu/drm/udl/udl_fb.c
+++ b/drivers/gpu/drm/udl/udl_fb.c
@@ -254,14 +254,10 @@ static int udl_fb_release(struct fb_info *info, int user)

 static struct fb_ops udlfb_ops = {
.owner = THIS_MODULE,
-   .fb_check_var = drm_fb_helper_check_var,
-   .fb_set_par = drm_fb_helper_set_par,
+   DRM_FB_HELPER_DEFAULT_OPS,
.fb_fillrect = drm_fb_helper_sys_fillrect,
.fb_copyarea = drm_fb_helper_sys_copyarea,
.fb_imageblit = drm_fb_helper_sys_imageblit,
-   .fb_pan_display = drm_fb_helper_pan_display,
-   .fb_blank = drm_fb_helper_blank,
-   .fb_setcmap = drm_fb_helper_setcmap,
.fb_debug_enter = drm_fb_helper_debug_enter,
.fb_debug_leave = drm_fb_helper_debug_leave,
.fb_mmap = udl_fb_mmap,
-- 
2.7.3



[PATCH 14/20] drm/tegra: use DRM_FB_HELPER_DEFAULT_OPS for fb_ops

2016-09-29 Thread Stefan Christ
Cc: Thierry Reding 
Signed-off-by: Stefan Christ 
---
 drivers/gpu/drm/tegra/fb.c | 6 +-
 1 file changed, 1 insertion(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/tegra/fb.c b/drivers/gpu/drm/tegra/fb.c
index e6d71fa..e4a5ab0 100644
--- a/drivers/gpu/drm/tegra/fb.c
+++ b/drivers/gpu/drm/tegra/fb.c
@@ -186,14 +186,10 @@ unreference:
 #ifdef CONFIG_DRM_FBDEV_EMULATION
 static struct fb_ops tegra_fb_ops = {
.owner = THIS_MODULE,
+   DRM_FB_HELPER_DEFAULT_OPS,
.fb_fillrect = drm_fb_helper_sys_fillrect,
.fb_copyarea = drm_fb_helper_sys_copyarea,
.fb_imageblit = drm_fb_helper_sys_imageblit,
-   .fb_check_var = drm_fb_helper_check_var,
-   .fb_set_par = drm_fb_helper_set_par,
-   .fb_blank = drm_fb_helper_blank,
-   .fb_pan_display = drm_fb_helper_pan_display,
-   .fb_setcmap = drm_fb_helper_setcmap,
 };

 static int tegra_fbdev_probe(struct drm_fb_helper *helper,
-- 
2.7.3



[PATCH 13/20] drm/radeon: use DRM_FB_HELPER_DEFAULT_OPS for fb_ops

2016-09-29 Thread Stefan Christ
Cc: Alex Deucher 
Signed-off-by: Stefan Christ 
---
 drivers/gpu/drm/radeon/radeon_fb.c | 6 +-
 1 file changed, 1 insertion(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/radeon/radeon_fb.c 
b/drivers/gpu/drm/radeon/radeon_fb.c
index 0e3143a..12c6fe1 100644
--- a/drivers/gpu/drm/radeon/radeon_fb.c
+++ b/drivers/gpu/drm/radeon/radeon_fb.c
@@ -49,14 +49,10 @@ struct radeon_fbdev {

 static struct fb_ops radeonfb_ops = {
.owner = THIS_MODULE,
-   .fb_check_var = drm_fb_helper_check_var,
-   .fb_set_par = drm_fb_helper_set_par,
+   DRM_FB_HELPER_DEFAULT_OPS,
.fb_fillrect = drm_fb_helper_cfb_fillrect,
.fb_copyarea = drm_fb_helper_cfb_copyarea,
.fb_imageblit = drm_fb_helper_cfb_imageblit,
-   .fb_pan_display = drm_fb_helper_pan_display,
-   .fb_blank = drm_fb_helper_blank,
-   .fb_setcmap = drm_fb_helper_setcmap,
.fb_debug_enter = drm_fb_helper_debug_enter,
.fb_debug_leave = drm_fb_helper_debug_leave,
 };
-- 
2.7.3



[PATCH 12/20] drm/rockchip: use DRM_FB_HELPER_DEFAULT_OPS for fb_ops

2016-09-29 Thread Stefan Christ
Cc: Mark Yao 
Signed-off-by: Stefan Christ 
---
 drivers/gpu/drm/rockchip/rockchip_drm_fbdev.c | 6 +-
 1 file changed, 1 insertion(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_fbdev.c 
b/drivers/gpu/drm/rockchip/rockchip_drm_fbdev.c
index 207e01d..46eaa3e 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_fbdev.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_fbdev.c
@@ -36,15 +36,11 @@ static int rockchip_fbdev_mmap(struct fb_info *info,

 static struct fb_ops rockchip_drm_fbdev_ops = {
.owner  = THIS_MODULE,
+   DRM_FB_HELPER_DEFAULT_OPS,
.fb_mmap= rockchip_fbdev_mmap,
.fb_fillrect= drm_fb_helper_cfb_fillrect,
.fb_copyarea= drm_fb_helper_cfb_copyarea,
.fb_imageblit   = drm_fb_helper_cfb_imageblit,
-   .fb_check_var   = drm_fb_helper_check_var,
-   .fb_set_par = drm_fb_helper_set_par,
-   .fb_blank   = drm_fb_helper_blank,
-   .fb_pan_display = drm_fb_helper_pan_display,
-   .fb_setcmap = drm_fb_helper_setcmap,
 };

 static int rockchip_drm_fbdev_create(struct drm_fb_helper *helper,
-- 
2.7.3



[PATCH 11/20] drm/qxl: use DRM_FB_HELPER_DEFAULT_OPS for fb_ops

2016-09-29 Thread Stefan Christ
Cc: Dave Airlie 
Signed-off-by: Stefan Christ 
---
 drivers/gpu/drm/qxl/qxl_fb.c | 6 +-
 1 file changed, 1 insertion(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/qxl/qxl_fb.c b/drivers/gpu/drm/qxl/qxl_fb.c
index 28c1423..114f4cb 100644
--- a/drivers/gpu/drm/qxl/qxl_fb.c
+++ b/drivers/gpu/drm/qxl/qxl_fb.c
@@ -82,14 +82,10 @@ static struct fb_deferred_io qxl_defio = {

 static struct fb_ops qxlfb_ops = {
.owner = THIS_MODULE,
-   .fb_check_var = drm_fb_helper_check_var,
-   .fb_set_par = drm_fb_helper_set_par, /* TODO: copy vmwgfx */
+   DRM_FB_HELPER_DEFAULT_OPS,
.fb_fillrect = drm_fb_helper_sys_fillrect,
.fb_copyarea = drm_fb_helper_sys_copyarea,
.fb_imageblit = drm_fb_helper_sys_imageblit,
-   .fb_pan_display = drm_fb_helper_pan_display,
-   .fb_blank = drm_fb_helper_blank,
-   .fb_setcmap = drm_fb_helper_setcmap,
.fb_debug_enter = drm_fb_helper_debug_enter,
.fb_debug_leave = drm_fb_helper_debug_leave,
 };
-- 
2.7.3



[PATCH 10/20] drm/nouveau: use DRM_FB_HELPER_DEFAULT_OPS for fb_ops

2016-09-29 Thread Stefan Christ
Cc: Ben Skeggs 
Signed-off-by: Stefan Christ 
---
 drivers/gpu/drm/nouveau/nouveau_fbcon.c | 12 ++--
 1 file changed, 2 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/nouveau_fbcon.c 
b/drivers/gpu/drm/nouveau/nouveau_fbcon.c
index d1f248f..2373796 100644
--- a/drivers/gpu/drm/nouveau/nouveau_fbcon.c
+++ b/drivers/gpu/drm/nouveau/nouveau_fbcon.c
@@ -200,33 +200,25 @@ nouveau_fbcon_release(struct fb_info *info, int user)

 static struct fb_ops nouveau_fbcon_ops = {
.owner = THIS_MODULE,
+   DRM_FB_HELPER_DEFAULT_OPS,
.fb_open = nouveau_fbcon_open,
.fb_release = nouveau_fbcon_release,
-   .fb_check_var = drm_fb_helper_check_var,
-   .fb_set_par = drm_fb_helper_set_par,
.fb_fillrect = nouveau_fbcon_fillrect,
.fb_copyarea = nouveau_fbcon_copyarea,
.fb_imageblit = nouveau_fbcon_imageblit,
.fb_sync = nouveau_fbcon_sync,
-   .fb_pan_display = drm_fb_helper_pan_display,
-   .fb_blank = drm_fb_helper_blank,
-   .fb_setcmap = drm_fb_helper_setcmap,
.fb_debug_enter = drm_fb_helper_debug_enter,
.fb_debug_leave = drm_fb_helper_debug_leave,
 };

 static struct fb_ops nouveau_fbcon_sw_ops = {
.owner = THIS_MODULE,
+   DRM_FB_HELPER_DEFAULT_OPS,
.fb_open = nouveau_fbcon_open,
.fb_release = nouveau_fbcon_release,
-   .fb_check_var = drm_fb_helper_check_var,
-   .fb_set_par = drm_fb_helper_set_par,
.fb_fillrect = drm_fb_helper_cfb_fillrect,
.fb_copyarea = drm_fb_helper_cfb_copyarea,
.fb_imageblit = drm_fb_helper_cfb_imageblit,
-   .fb_pan_display = drm_fb_helper_pan_display,
-   .fb_blank = drm_fb_helper_blank,
-   .fb_setcmap = drm_fb_helper_setcmap,
.fb_debug_enter = drm_fb_helper_debug_enter,
.fb_debug_leave = drm_fb_helper_debug_leave,
 };
-- 
2.7.3



[PATCH 09/20] drm/mgag200: use DRM_FB_HELPER_DEFAULT_OPS for fb_ops

2016-09-29 Thread Stefan Christ
Cc: Dave Airlie 
Signed-off-by: Stefan Christ 
---
 drivers/gpu/drm/mgag200/mgag200_fb.c | 6 +-
 1 file changed, 1 insertion(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/mgag200/mgag200_fb.c 
b/drivers/gpu/drm/mgag200/mgag200_fb.c
index d9b04b0..a41aa19 100644
--- a/drivers/gpu/drm/mgag200/mgag200_fb.c
+++ b/drivers/gpu/drm/mgag200/mgag200_fb.c
@@ -127,14 +127,10 @@ static void mga_imageblit(struct fb_info *info,

 static struct fb_ops mgag200fb_ops = {
.owner = THIS_MODULE,
-   .fb_check_var = drm_fb_helper_check_var,
-   .fb_set_par = drm_fb_helper_set_par,
+   DRM_FB_HELPER_DEFAULT_OPS,
.fb_fillrect = mga_fillrect,
.fb_copyarea = mga_copyarea,
.fb_imageblit = mga_imageblit,
-   .fb_pan_display = drm_fb_helper_pan_display,
-   .fb_blank = drm_fb_helper_blank,
-   .fb_setcmap = drm_fb_helper_setcmap,
 };

 static int mgag200fb_create_object(struct mga_fbdev *afbdev,
-- 
2.7.3



[PATCH 08/20] drm/exynos: use DRM_FB_HELPER_DEFAULT_OPS for fb_ops

2016-09-29 Thread Stefan Christ
Cc: Inki Dae 
Cc: Joonyoung Shim 
Cc: Seung-Woo Kim 
Cc: Kyungmin Park 
Signed-off-by: Stefan Christ 
---
 drivers/gpu/drm/exynos/exynos_drm_fbdev.c | 6 +-
 1 file changed, 1 insertion(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_fbdev.c 
b/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
index 4cfb39d..9f35deb 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
@@ -63,15 +63,11 @@ static int exynos_drm_fb_mmap(struct fb_info *info,

 static struct fb_ops exynos_drm_fb_ops = {
.owner  = THIS_MODULE,
+   DRM_FB_HELPER_DEFAULT_OPS,
.fb_mmap= exynos_drm_fb_mmap,
.fb_fillrect= drm_fb_helper_cfb_fillrect,
.fb_copyarea= drm_fb_helper_cfb_copyarea,
.fb_imageblit   = drm_fb_helper_cfb_imageblit,
-   .fb_check_var   = drm_fb_helper_check_var,
-   .fb_set_par = drm_fb_helper_set_par,
-   .fb_blank   = drm_fb_helper_blank,
-   .fb_pan_display = drm_fb_helper_pan_display,
-   .fb_setcmap = drm_fb_helper_setcmap,
 };

 static int exynos_drm_fbdev_update(struct drm_fb_helper *helper,
-- 
2.7.3



[PATCH 07/20] drm/fb_cma_helper: use DRM_FB_HELPER_DEFAULT_OPS for fb_ops

2016-09-29 Thread Stefan Christ
Cc: David Airlie 
Signed-off-by: Stefan Christ 
---
 drivers/gpu/drm/drm_fb_cma_helper.c | 6 +-
 1 file changed, 1 insertion(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/drm_fb_cma_helper.c 
b/drivers/gpu/drm/drm_fb_cma_helper.c
index 1fd6eac..71551fd 100644
--- a/drivers/gpu/drm/drm_fb_cma_helper.c
+++ b/drivers/gpu/drm/drm_fb_cma_helper.c
@@ -311,14 +311,10 @@ static int drm_fb_cma_mmap(struct fb_info *info, struct 
vm_area_struct *vma)

 static struct fb_ops drm_fbdev_cma_ops = {
.owner  = THIS_MODULE,
+   DRM_FB_HELPER_DEFAULT_OPS,
.fb_fillrect= drm_fb_helper_sys_fillrect,
.fb_copyarea= drm_fb_helper_sys_copyarea,
.fb_imageblit   = drm_fb_helper_sys_imageblit,
-   .fb_check_var   = drm_fb_helper_check_var,
-   .fb_set_par = drm_fb_helper_set_par,
-   .fb_blank   = drm_fb_helper_blank,
-   .fb_pan_display = drm_fb_helper_pan_display,
-   .fb_setcmap = drm_fb_helper_setcmap,
.fb_mmap= drm_fb_cma_mmap,
 };

-- 
2.7.3



[PATCH 06/20] drm/cirrus: use DRM_FB_HELPER_DEFAULT_OPS for fb_ops

2016-09-29 Thread Stefan Christ
Cc: Dave Airlie 
Signed-off-by: Stefan Christ 
---
 drivers/gpu/drm/cirrus/cirrus_fbdev.c | 6 +-
 1 file changed, 1 insertion(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/cirrus/cirrus_fbdev.c 
b/drivers/gpu/drm/cirrus/cirrus_fbdev.c
index 3b5be72..4f8d42b 100644
--- a/drivers/gpu/drm/cirrus/cirrus_fbdev.c
+++ b/drivers/gpu/drm/cirrus/cirrus_fbdev.c
@@ -124,14 +124,10 @@ static void cirrus_imageblit(struct fb_info *info,

 static struct fb_ops cirrusfb_ops = {
.owner = THIS_MODULE,
-   .fb_check_var = drm_fb_helper_check_var,
-   .fb_set_par = drm_fb_helper_set_par,
+   DRM_FB_HELPER_DEFAULT_OPS,
.fb_fillrect = cirrus_fillrect,
.fb_copyarea = cirrus_copyarea,
.fb_imageblit = cirrus_imageblit,
-   .fb_pan_display = drm_fb_helper_pan_display,
-   .fb_blank = drm_fb_helper_blank,
-   .fb_setcmap = drm_fb_helper_setcmap,
 };

 static int cirrusfb_create_object(struct cirrus_fbdev *afbdev,
-- 
2.7.3



[PATCH 05/20] drm/bochs: use DRM_FB_HELPER_DEFAULT_OPS for fb_ops

2016-09-29 Thread Stefan Christ
Cc: Gerd Hoffmann 
Signed-off-by: Stefan Christ 
---
 drivers/gpu/drm/bochs/bochs_fbdev.c | 6 +-
 1 file changed, 1 insertion(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/bochs/bochs_fbdev.c 
b/drivers/gpu/drm/bochs/bochs_fbdev.c
index e1ec498..da790a1 100644
--- a/drivers/gpu/drm/bochs/bochs_fbdev.c
+++ b/drivers/gpu/drm/bochs/bochs_fbdev.c
@@ -22,14 +22,10 @@ static int bochsfb_mmap(struct fb_info *info,

 static struct fb_ops bochsfb_ops = {
.owner = THIS_MODULE,
-   .fb_check_var = drm_fb_helper_check_var,
-   .fb_set_par = drm_fb_helper_set_par,
+   DRM_FB_HELPER_DEFAULT_OPS,
.fb_fillrect = drm_fb_helper_sys_fillrect,
.fb_copyarea = drm_fb_helper_sys_copyarea,
.fb_imageblit = drm_fb_helper_sys_imageblit,
-   .fb_pan_display = drm_fb_helper_pan_display,
-   .fb_blank = drm_fb_helper_blank,
-   .fb_setcmap = drm_fb_helper_setcmap,
.fb_mmap = bochsfb_mmap,
 };

-- 
2.7.3



[PATCH 04/20] drm/ast: use DRM_FB_HELPER_DEFAULT_OPS for fb_ops

2016-09-29 Thread Stefan Christ
Cc: Dave Airlie 
Signed-off-by: Stefan Christ 
---
 drivers/gpu/drm/ast/ast_fb.c | 6 +-
 1 file changed, 1 insertion(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/ast/ast_fb.c b/drivers/gpu/drm/ast/ast_fb.c
index c017a93..b604fdd 100644
--- a/drivers/gpu/drm/ast/ast_fb.c
+++ b/drivers/gpu/drm/ast/ast_fb.c
@@ -150,14 +150,10 @@ static void ast_imageblit(struct fb_info *info,

 static struct fb_ops astfb_ops = {
.owner = THIS_MODULE,
-   .fb_check_var = drm_fb_helper_check_var,
-   .fb_set_par = drm_fb_helper_set_par,
+   DRM_FB_HELPER_DEFAULT_OPS,
.fb_fillrect = ast_fillrect,
.fb_copyarea = ast_copyarea,
.fb_imageblit = ast_imageblit,
-   .fb_pan_display = drm_fb_helper_pan_display,
-   .fb_blank = drm_fb_helper_blank,
-   .fb_setcmap = drm_fb_helper_setcmap,
.fb_debug_enter = drm_fb_helper_debug_enter,
.fb_debug_leave = drm_fb_helper_debug_leave,
 };
-- 
2.7.3



[PATCH 03/20] drm/armada: use DRM_FB_HELPER_DEFAULT_OPS for fb_ops

2016-09-29 Thread Stefan Christ
Cc: Russell King 
Signed-off-by: Stefan Christ 
---
 drivers/gpu/drm/armada/armada_fbdev.c | 6 +-
 1 file changed, 1 insertion(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/armada/armada_fbdev.c 
b/drivers/gpu/drm/armada/armada_fbdev.c
index 7d03c51..0322bb0 100644
--- a/drivers/gpu/drm/armada/armada_fbdev.c
+++ b/drivers/gpu/drm/armada/armada_fbdev.c
@@ -20,14 +20,10 @@

 static /*const*/ struct fb_ops armada_fb_ops = {
.owner  = THIS_MODULE,
-   .fb_check_var   = drm_fb_helper_check_var,
-   .fb_set_par = drm_fb_helper_set_par,
+   DRM_FB_HELPER_DEFAULT_OPS,
.fb_fillrect= drm_fb_helper_cfb_fillrect,
.fb_copyarea= drm_fb_helper_cfb_copyarea,
.fb_imageblit   = drm_fb_helper_cfb_imageblit,
-   .fb_pan_display = drm_fb_helper_pan_display,
-   .fb_blank   = drm_fb_helper_blank,
-   .fb_setcmap = drm_fb_helper_setcmap,
.fb_debug_enter = drm_fb_helper_debug_enter,
.fb_debug_leave = drm_fb_helper_debug_leave,
 };
-- 
2.7.3



[PATCH 02/20] drm/amdgpu: use DRM_FB_HELPER_DEFAULT_OPS for fb_ops

2016-09-29 Thread Stefan Christ
Cc: Alex Deucher 
Cc: Christian König 
Signed-off-by: Stefan Christ 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c | 6 +-
 1 file changed, 1 insertion(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c
index 9191467..6b80982 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c
@@ -50,14 +50,10 @@ struct amdgpu_fbdev {

 static struct fb_ops amdgpufb_ops = {
.owner = THIS_MODULE,
-   .fb_check_var = drm_fb_helper_check_var,
-   .fb_set_par = drm_fb_helper_set_par,
+   DRM_FB_HELPER_DEFAULT_OPS,
.fb_fillrect = drm_fb_helper_cfb_fillrect,
.fb_copyarea = drm_fb_helper_cfb_copyarea,
.fb_imageblit = drm_fb_helper_cfb_imageblit,
-   .fb_pan_display = drm_fb_helper_pan_display,
-   .fb_blank = drm_fb_helper_blank,
-   .fb_setcmap = drm_fb_helper_setcmap,
.fb_debug_enter = drm_fb_helper_debug_enter,
.fb_debug_leave = drm_fb_helper_debug_leave,
 };
-- 
2.7.3



[PATCH 01/20] drm/fb-helper: add DRM_FB_HELPER_DEFAULT_OPS for fb_ops

2016-09-29 Thread Stefan Christ
The define DRM_FB_HELPER_DEFAULT_OPS provides the drm_fb_helper default
implementations for functions in struct fb_ops. A drm driver can use it
like:

static struct fb_ops drm_fbdev_cma_ops = {
.owner  = THIS_MODULE,
DRM_FB_HELPER_DEFAULT_OPS,
/* driver specific implementations */
};

Suggested-by: Daniel Vetter 
Signed-off-by: Stefan Christ 
---
 include/drm/drm_fb_helper.h | 13 +
 1 file changed, 13 insertions(+)

diff --git a/include/drm/drm_fb_helper.h b/include/drm/drm_fb_helper.h
index db8d478..b76f5c7 100644
--- a/include/drm/drm_fb_helper.h
+++ b/include/drm/drm_fb_helper.h
@@ -214,6 +214,19 @@ struct drm_fb_helper {
bool delayed_hotplug;
 };

+/**
+ * @DRM_FB_HELPER_DEFAULT_OPS:
+ *
+ * Helper define to register default implementations of drm_fb_helper
+ * functions. To be used in struct fb_ops of drm drivers.
+ */
+#define DRM_FB_HELPER_DEFAULT_OPS \
+   .fb_check_var   = drm_fb_helper_check_var, \
+   .fb_set_par = drm_fb_helper_set_par, \
+   .fb_setcmap = drm_fb_helper_setcmap, \
+   .fb_blank   = drm_fb_helper_blank, \
+   .fb_pan_display = drm_fb_helper_pan_display
+
 #ifdef CONFIG_DRM_FBDEV_EMULATION
 int drm_fb_helper_modinit(void);
 void drm_fb_helper_prepare(struct drm_device *dev, struct drm_fb_helper 
*helper,
-- 
2.7.3



[PATCH 00/20] Introduce DRM_FB_HELPER_DEFAULT_OPS for struct fb_ops

2016-09-29 Thread Stefan Christ
Hi,

this series is refactoring work suggested by Daniel Vetter in the email:

   https://lists.freedesktop.org/archives/dri-devel/2016-July/113237.html

The define DRM_FB_HELPER_DEFAULT_OPS provides the drm_fb_helper default
implementations for functions in struct fb_ops. A drm driver can use it like:

static struct fb_ops drm_fbdev_cma_ops = {
.owner  = THIS_MODULE,
DRM_FB_HELPER_DEFAULT_OPS,
/* driver specific implementations */
};

The patches do not make any functional change to the kernel binary except
driver 'drm/gma500'. The patch for gma500 enables two new functions (fb_setcmap
and fb_pan_display) in fb_ops.  If this is not appropriate, the driver may
reassign the struct members to null.

There is no refactoring patch for driver 'vmwgfx'. It reimplements nearly all
fb_ops with driver specific functions anyways. 

This series is based on tag v4.8-rc8. If rebased onto 'drm-next' there are two
small conflicts.

Kind regards,
Stefan Christ

Stefan Christ (20):
  drm/fb-helper: add DRM_FB_HELPER_DEFAULT_OPS for fb_ops
  drm/amdgpu: use DRM_FB_HELPER_DEFAULT_OPS for fb_ops
  drm/armada: use DRM_FB_HELPER_DEFAULT_OPS for fb_ops
  drm/ast: use DRM_FB_HELPER_DEFAULT_OPS for fb_ops
  drm/bochs: use DRM_FB_HELPER_DEFAULT_OPS for fb_ops
  drm/cirrus: use DRM_FB_HELPER_DEFAULT_OPS for fb_ops
  drm/fb_cma_helper: use DRM_FB_HELPER_DEFAULT_OPS for fb_ops
  drm/exynos: use DRM_FB_HELPER_DEFAULT_OPS for fb_ops
  drm/mgag200: use DRM_FB_HELPER_DEFAULT_OPS for fb_ops
  drm/nouveau: use DRM_FB_HELPER_DEFAULT_OPS for fb_ops
  drm/qxl: use DRM_FB_HELPER_DEFAULT_OPS for fb_ops
  drm/rockchip: use DRM_FB_HELPER_DEFAULT_OPS for fb_ops
  drm/radeon: use DRM_FB_HELPER_DEFAULT_OPS for fb_ops
  drm/tegra: use DRM_FB_HELPER_DEFAULT_OPS for fb_ops
  drm/udl: use DRM_FB_HELPER_DEFAULT_OPS for fb_ops
  drm/msm: use DRM_FB_HELPER_DEFAULT_OPS for fb_ops
  drm/virtio: use DRM_FB_HELPER_DEFAULT_OPS for fb_ops
  drm/omapdrm: use DRM_FB_HELPER_DEFAULT_OPS for fb_ops
  drm/i915: use DRM_FB_HELPER_DEFAULT_OPS for fb_ops
  drm/gma500: use DRM_FB_HELPER_DEFAULT_OPS for fb_ops

 drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c|  6 +-
 drivers/gpu/drm/armada/armada_fbdev.c |  6 +-
 drivers/gpu/drm/ast/ast_fb.c  |  6 +-
 drivers/gpu/drm/bochs/bochs_fbdev.c   |  6 +-
 drivers/gpu/drm/cirrus/cirrus_fbdev.c |  6 +-
 drivers/gpu/drm/drm_fb_cma_helper.c   |  6 +-
 drivers/gpu/drm/exynos/exynos_drm_fbdev.c |  6 +-
 drivers/gpu/drm/gma500/framebuffer.c  | 12 +++-
 drivers/gpu/drm/i915/intel_fbdev.c|  3 +--
 drivers/gpu/drm/mgag200/mgag200_fb.c  |  6 +-
 drivers/gpu/drm/msm/msm_fbdev.c   |  7 +--
 drivers/gpu/drm/nouveau/nouveau_fbcon.c   | 12 ++--
 drivers/gpu/drm/omapdrm/omap_fbdev.c  |  5 +
 drivers/gpu/drm/qxl/qxl_fb.c  |  6 +-
 drivers/gpu/drm/radeon/radeon_fb.c|  6 +-
 drivers/gpu/drm/rockchip/rockchip_drm_fbdev.c |  6 +-
 drivers/gpu/drm/tegra/fb.c|  6 +-
 drivers/gpu/drm/udl/udl_fb.c  |  6 +-
 drivers/gpu/drm/virtio/virtgpu_fb.c   |  6 +-
 include/drm/drm_fb_helper.h   | 13 +
 20 files changed, 35 insertions(+), 101 deletions(-)

-- 
2.7.3



[PATCH v1 4/4] drm: bridge/analogix: switch Main-link and eDP PHY when enable/disable psr

2016-09-29 Thread zain wang
turn off Main-link and power down eDP PHY when enable psr,
turn on Main-link and power up eDP PHY when disable psr.

Signed-off-by: zain wang 

---

 drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 105 ++---
 1 file changed, 52 insertions(+), 53 deletions(-)

diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c 
b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
index 7177f5f..1bc98ab 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
@@ -98,56 +98,6 @@ static int analogix_dp_detect_hpd(struct analogix_dp_device 
*dp)
return 0;
 }

-int analogix_dp_enable_psr(struct device *dev)
-{
-   struct analogix_dp_device *dp = dev_get_drvdata(dev);
-   struct edp_vsc_psr psr_vsc;
-
-   if (!dp->psr_support)
-   return -EINVAL;
-
-   if (dp->dpms_mode != DRM_MODE_DPMS_ON)
-   return -EBUSY;
-
-   /* Prepare VSC packet as per EDP 1.4 spec, Table 6.9 */
-   memset(_vsc, 0, sizeof(psr_vsc));
-   psr_vsc.sdp_header.HB0 = 0;
-   psr_vsc.sdp_header.HB1 = 0x7;
-   psr_vsc.sdp_header.HB2 = 0x2;
-   psr_vsc.sdp_header.HB3 = 0x8;
-
-   psr_vsc.DB0 = 0;
-   psr_vsc.DB1 = EDP_VSC_PSR_STATE_ACTIVE | EDP_VSC_PSR_CRC_VALUES_VALID;
-
-   return analogix_dp_send_psr_spd(dp, _vsc);
-}
-EXPORT_SYMBOL_GPL(analogix_dp_enable_psr);
-
-int analogix_dp_disable_psr(struct device *dev)
-{
-   struct analogix_dp_device *dp = dev_get_drvdata(dev);
-   struct edp_vsc_psr psr_vsc;
-
-   if (!dp->psr_support)
-   return -EINVAL;
-
-   if (dp->dpms_mode != DRM_MODE_DPMS_ON)
-   return -EBUSY;
-
-   /* Prepare VSC packet as per EDP 1.4 spec, Table 6.9 */
-   memset(_vsc, 0, sizeof(psr_vsc));
-   psr_vsc.sdp_header.HB0 = 0;
-   psr_vsc.sdp_header.HB1 = 0x7;
-   psr_vsc.sdp_header.HB2 = 0x2;
-   psr_vsc.sdp_header.HB3 = 0x8;
-
-   psr_vsc.DB0 = 0;
-   psr_vsc.DB1 = 0;
-
-   return analogix_dp_send_psr_spd(dp, _vsc);
-}
-EXPORT_SYMBOL_GPL(analogix_dp_disable_psr);
-
 static bool analogix_dp_detect_sink_psr(struct analogix_dp_device *dp)
 {
unsigned char psr_version;
@@ -168,12 +118,11 @@ static void analogix_dp_enable_sink_psr(struct 
analogix_dp_device *dp)
drm_dp_dpcd_writeb(>aux, DP_PSR_EN_CFG, psr_en);

/* Main-Link transmitter remains active during PSR active states */
-   psr_en = DP_PSR_MAIN_LINK_ACTIVE | DP_PSR_CRC_VERIFICATION;
+   psr_en = DP_PSR_CRC_VERIFICATION;
drm_dp_dpcd_writeb(>aux, DP_PSR_EN_CFG, psr_en);

/* Enable psr function */
-   psr_en = DP_PSR_ENABLE | DP_PSR_MAIN_LINK_ACTIVE |
-DP_PSR_CRC_VERIFICATION;
+   psr_en = DP_PSR_ENABLE | DP_PSR_CRC_VERIFICATION;
drm_dp_dpcd_writeb(>aux, DP_PSR_EN_CFG, psr_en);

analogix_dp_enable_psr_crc(dp);
@@ -876,6 +825,56 @@ static void analogix_dp_commit(struct analogix_dp_device 
*dp)
analogix_dp_enable_sink_psr(dp);
 }

+int analogix_dp_enable_psr(struct device *dev)
+{
+   struct analogix_dp_device *dp = dev_get_drvdata(dev);
+   struct edp_vsc_psr psr_vsc;
+
+   if (!dp->psr_support)
+   return -EINVAL;
+
+   if (dp->dpms_mode != DRM_MODE_DPMS_ON)
+   return -EBUSY;
+
+   /* Prepare VSC packet as per EDP 1.4 spec, Table 6.9 */
+   memset(_vsc, 0, sizeof(psr_vsc));
+   psr_vsc.sdp_header.HB0 = 0;
+   psr_vsc.sdp_header.HB1 = 0x7;
+   psr_vsc.sdp_header.HB2 = 0x2;
+   psr_vsc.sdp_header.HB3 = 0x8;
+
+   psr_vsc.DB0 = 0;
+   psr_vsc.DB1 = EDP_VSC_PSR_STATE_ACTIVE | EDP_VSC_PSR_CRC_VALUES_VALID;
+
+   return analogix_dp_send_psr_spd(dp, _vsc);
+}
+EXPORT_SYMBOL_GPL(analogix_dp_enable_psr);
+
+int analogix_dp_disable_psr(struct device *dev)
+{
+   struct analogix_dp_device *dp = dev_get_drvdata(dev);
+   struct edp_vsc_psr psr_vsc;
+
+   if (!dp->psr_support)
+   return -EINVAL;
+
+   if (dp->dpms_mode != DRM_MODE_DPMS_ON)
+   return -EBUSY;
+
+   /* Prepare VSC packet as per EDP 1.4 spec, Table 6.9 */
+   memset(_vsc, 0, sizeof(psr_vsc));
+   psr_vsc.sdp_header.HB0 = 0;
+   psr_vsc.sdp_header.HB1 = 0x7;
+   psr_vsc.sdp_header.HB2 = 0x2;
+   psr_vsc.sdp_header.HB3 = 0x8;
+
+   psr_vsc.DB0 = 0;
+   psr_vsc.DB1 = 0;
+
+   return analogix_dp_send_psr_spd(dp, _vsc);
+}
+EXPORT_SYMBOL_GPL(analogix_dp_disable_psr);
+
 /*
  * This function is a bit of a catch-all for panel preparation, hopefully
  * simplifying the logic of functions that need to prepare/unprepare the panel
-- 
1.9.1




[PATCH v1 3/4] drm/bridge: analogix_dp: detect Sink PSR state after configuring the PSR

2016-09-29 Thread zain wang
From: Yakir Yang 

Make sure the request PSR state takes effect in analogix_dp_send_psr_spd()
function, or print the sink PSR error state if we failed to apply the
requested PSR setting.

Signed-off-by: Yakir Yang 
Signed-off-by: Zain Wang 

---

 drivers/gpu/drm/bridge/analogix/analogix_dp_core.c |  6 ++
 drivers/gpu/drm/bridge/analogix/analogix_dp_core.h |  6 --
 drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c  | 25 --
 drivers/gpu/drm/rockchip/analogix_dp-rockchip.c|  8 ---
 4 files changed, 34 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c 
b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
index 026ec91..7177f5f 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
@@ -119,8 +119,7 @@ int analogix_dp_enable_psr(struct device *dev)
psr_vsc.DB0 = 0;
psr_vsc.DB1 = EDP_VSC_PSR_STATE_ACTIVE | EDP_VSC_PSR_CRC_VALUES_VALID;

-   analogix_dp_send_psr_spd(dp, _vsc);
-   return 0;
+   return analogix_dp_send_psr_spd(dp, _vsc);
 }
 EXPORT_SYMBOL_GPL(analogix_dp_enable_psr);

@@ -145,8 +144,7 @@ int analogix_dp_disable_psr(struct device *dev)
psr_vsc.DB0 = 0;
psr_vsc.DB1 = 0;

-   analogix_dp_send_psr_spd(dp, _vsc);
-   return 0;
+   return analogix_dp_send_psr_spd(dp, _vsc);
 }
 EXPORT_SYMBOL_GPL(analogix_dp_disable_psr);

diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h 
b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h
index 5c6a288..cdc0535 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h
@@ -20,6 +20,8 @@
 #define MAX_CR_LOOP 5
 #define MAX_EQ_LOOP 5

+#define DP_TIMEOUT_PSR_LOOP_MS msecs_to_jiffies(300)
+
 /* DP_MAX_LANE_COUNT */
 #define DPCD_ENHANCED_FRAME_CAP(x) (((x) >> 7) & 0x1)
 #define DPCD_MAX_LANE_COUNT(x) ((x) & 0x1f)
@@ -247,8 +249,8 @@ void analogix_dp_config_video_slave_mode(struct 
analogix_dp_device *dp);
 void analogix_dp_enable_scrambling(struct analogix_dp_device *dp);
 void analogix_dp_disable_scrambling(struct analogix_dp_device *dp);
 void analogix_dp_enable_psr_crc(struct analogix_dp_device *dp);
-void analogix_dp_send_psr_spd(struct analogix_dp_device *dp,
- struct edp_vsc_psr *vsc);
+int analogix_dp_send_psr_spd(struct analogix_dp_device *dp,
+struct edp_vsc_psr *vsc);
 ssize_t analogix_dp_transfer(struct analogix_dp_device *dp,
 struct drm_dp_aux_msg *msg);

diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c 
b/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
index cd37ac0..9e1177c 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
@@ -992,10 +992,12 @@ void analogix_dp_enable_psr_crc(struct analogix_dp_device 
*dp)
writel(PSR_VID_CRC_ENABLE, dp->reg_base + ANALOGIX_DP_CRC_CON);
 }

-void analogix_dp_send_psr_spd(struct analogix_dp_device *dp,
- struct edp_vsc_psr *vsc)
+int analogix_dp_send_psr_spd(struct analogix_dp_device *dp,
+struct edp_vsc_psr *vsc)
 {
+   unsigned long timeout;
unsigned int val;
+   u8 sink;

/* don't send info frame */
val = readl(dp->reg_base + ANALOGIX_DP_PKT_SEND_CTL);
@@ -1036,6 +1038,25 @@ void analogix_dp_send_psr_spd(struct analogix_dp_device 
*dp,
val = readl(dp->reg_base + ANALOGIX_DP_PKT_SEND_CTL);
val |= IF_EN;
writel(val, dp->reg_base + ANALOGIX_DP_PKT_SEND_CTL);
+
+   timeout = jiffies + DP_TIMEOUT_PSR_LOOP_MS;
+   while (time_before(jiffies, timeout)) {
+   val = drm_dp_dpcd_readb(>aux, DP_PSR_STATUS, );
+   if (val != 1) {
+   dev_err(dp->dev, "PSR_STATUS read failed ret=%d", val);
+   return -EBUSY;
+   }
+
+   if ((vsc->DB1 && sink == DP_PSR_SINK_ACTIVE_RFB) ||
+   (!vsc->DB1 && sink == DP_PSR_SINK_INACTIVE))
+   return 0;
+
+   usleep_range(1000, 1500);
+   }
+
+   dev_warn(dp->dev, "Failed to apply PSR, sink state was [%x]", sink);
+
+   return -ETIMEDOUT;
 }

 ssize_t analogix_dp_transfer(struct analogix_dp_device *dp,
diff --git a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c 
b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
index e83be15..dc106d0 100644
--- a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
+++ b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
@@ -102,10 +102,10 @@ static void analogix_dp_psr_work(struct work_struct *work)
struct rockchip_dp_device *dp =
container_of(work, typeof(*dp), psr_work);
struct drm_crtc *crtc = dp->encoder.crtc;
-   int psr_state = dp->psr_state;
+ 

[PATCH v1 2/4] drm/bridge: analogix_dp: get sync PM when init eDP

2016-09-29 Thread zain wang
Signed-off-by: zain wang 

---

 drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c 
b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
index 206529a..026ec91 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
@@ -1386,10 +1386,12 @@ int analogix_dp_bind(struct device *dev, struct 
drm_device *drm_dev,
}

pm_runtime_enable(dev);
+   pm_runtime_get_sync(dev);

phy_power_on(dp->phy);

analogix_dp_init_dp(dp);
+   pm_runtime_put_sync(dev);

ret = devm_request_threaded_irq(>dev, dp->irq,
analogix_dp_hardirq,
-- 
1.9.1




[PATCH v1 1/4] drm/bridge: analogix_dp: prevent runing enable_psr when disabled bridge.

2016-09-29 Thread zain wang
When disabled bridge, analogix_dp_enable_psr() may run due to timer was set
by rockchip_drm_do_flush(), in this case we should return -EBUSY.

Signed-off-by: zain wang 

---

 drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 10 --
 1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c 
b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
index 0f2e423..206529a 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
@@ -106,6 +106,9 @@ int analogix_dp_enable_psr(struct device *dev)
if (!dp->psr_support)
return -EINVAL;

+   if (dp->dpms_mode != DRM_MODE_DPMS_ON)
+   return -EBUSY;
+
/* Prepare VSC packet as per EDP 1.4 spec, Table 6.9 */
memset(_vsc, 0, sizeof(psr_vsc));
psr_vsc.sdp_header.HB0 = 0;
@@ -129,6 +132,9 @@ int analogix_dp_disable_psr(struct device *dev)
if (!dp->psr_support)
return -EINVAL;

+   if (dp->dpms_mode != DRM_MODE_DPMS_ON)
+   return -EBUSY;
+
/* Prepare VSC packet as per EDP 1.4 spec, Table 6.9 */
memset(_vsc, 0, sizeof(psr_vsc));
psr_vsc.sdp_header.HB0 = 0;
@@ -1097,6 +1103,8 @@ static void analogix_dp_bridge_disable(struct drm_bridge 
*bridge)
if (dp->dpms_mode != DRM_MODE_DPMS_ON)
return;

+   dp->dpms_mode = DRM_MODE_DPMS_OFF;
+
if (dp->plat_data->panel) {
if (drm_panel_disable(dp->plat_data->panel)) {
DRM_ERROR("failed to disable the panel\n");
@@ -1115,8 +1123,6 @@ static void analogix_dp_bridge_disable(struct drm_bridge 
*bridge)
ret = analogix_dp_prepare_panel(dp, false, true);
if (ret)
DRM_ERROR("failed to setup the panel ret = %d\n", ret);
-
-   dp->dpms_mode = DRM_MODE_DPMS_OFF;
 }

 static void analogix_dp_bridge_mode_set(struct drm_bridge *bridge,
-- 
1.9.1




[PATCH v1 0/4] Misc changes to Rockchip PSR drivers

2016-09-29 Thread zain wang

1. prevent runing enable_psr when disabled bridge
2. get sync PM when init eDP
3. detect Sink PSR state after configuring the PSR
4. switch Main-Link and eDP phy when enable/disable psr

BR,
- Zain


Yakir Yang (1):
  drm/bridge: analogix_dp: detect Sink PSR state after configuring the
PSR

zain wang (3):
  drm/bridge: analogix_dp: prevent runing enable_psr when disabled
bridge.
  drm/bridge: analogix_dp: get sync PM when init eDP
  drm: bridge/analogix: switch Main-link and eDP PHY when enable/disable
psr

 drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 107 +++--
 drivers/gpu/drm/bridge/analogix/analogix_dp_core.h |   6 +-
 drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c  |  25 -
 drivers/gpu/drm/rockchip/analogix_dp-rockchip.c|   8 +-
 4 files changed, 88 insertions(+), 58 deletions(-)

-- 
1.9.1




[Bug 97969] [radeonsi, bisected: fb827c0] Video decoding shows green artifacts

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

--- Comment #3 from Alexandre Demers  ---
With the patch, when playing problematic videos, I get a black screen instead
of a partial display with green artifacts.

Also, with and without the patch, dmesg catches the following when playing the
problematic videos (I should have had a look previously):
[76261.125581] [drm:radeon_uvd_cs_parse [radeon]] *ERROR* Handle 0x8fd80001
already in use!
[76261.125594] [drm:radeon_cs_ioctl [radeon]] *ERROR* Invalid command stream !
[76261.126059] [drm:radeon_uvd_cs_parse [radeon]] *ERROR* Handle 0x8fd80001
already in use!
[76261.126072] [drm:radeon_cs_ioctl [radeon]] *ERROR* Invalid command stream !
[76261.126441] [drm:radeon_uvd_cs_parse [radeon]] *ERROR* Handle 0x8fd80001
already in use!
[76261.126452] [drm:radeon_cs_ioctl [radeon]] *ERROR* Invalid command stream !

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


[Bug 97980] [amdgpu] New kernel warning during shutdown

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

--- Comment #4 from Mike Lothian  ---
Sorry I spoke too soon, the issue is still there, it's just more difficult to
see as the reboot is so quick now

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


[Bug 97980] [amdgpu] New kernel warning during shutdown

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

--- Comment #3 from Alex Deucher  ---
(In reply to Mike Lothian from comment #2)
> Yes that fixes it
> 
> I've been having a more and more difficult time testing stuff of late,
> there's been quite a few regressions and I've been carrying more and more
> patches amongst various branches - lets hope the next cycle will be better
> 

Well, bug fixes go to -fixes and new features go to -next.  If you want
everything, you'd need to merge -fixes into -next.

> What's your handle on IRC?

agd5f

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


[Bug 97980] [amdgpu] New kernel warning during shutdown

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

Mike Lothian  changed:

   What|Removed |Added

 CC||mike at fireburn.co.uk

--- Comment #2 from Mike Lothian  ---
Yes that fixes it

I've been having a more and more difficult time testing stuff of late, there's
been quite a few regressions and I've been carrying more and more patches
amongst various branches - lets hope the next cycle will be better

What's your handle on IRC?

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


[PATCH v3] drm: tilcdc: add a workaround for failed clk_set_rate()

2016-09-29 Thread Bartosz Golaszewski
Some architectures don't use the common clock framework and don't
implement all the clk interfaces for every clock. This is the case
for da850-lcdk where clk_set_rate() only works for PLL0 and PLL1.

Trying to set the clock rate for the LCDC clock results in -EINVAL
being returned.

As a workaround for that: if the call to clk_set_rate() fails, fall
back to adjusting the clock divider instead. Proper divider value is
calculated by dividing the current clock rate by the required pixel
clock rate in HZ.

This code is based on a hack initially developed internally for
baylibre by Karl Beldan .

Tested with a da850-lcdk with an LCD display connected over VGA.

Signed-off-by: Bartosz Golaszewski 
---
v1 -> v2:
- rebased on top of current drm-next
- removed unnecessary error messages
- removed an extra newline
- added a warning if the effective pixel clock rate differs much from
  the requested rate

v2 -> v3:
- removed WARN_ONCE() in favor of dev_warn()
- added the real and calculated clock rates to the warning message
- tweaked the variable names
- used a local variable to remove redundant 'crtc->mode.clock * 1000'

Retested with

  modetest -M tilcdc -s 26:800x600 at RG16
  modetest -M tilcdc -s 26:1024x768 at RG16

using some additional work-in-progress changes on top of this patch.

 drivers/gpu/drm/tilcdc/tilcdc_crtc.c | 57 
 1 file changed, 51 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/tilcdc/tilcdc_crtc.c 
b/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
index 52ebe8f..87cfde9 100644
--- a/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
+++ b/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
@@ -320,23 +320,68 @@ static bool tilcdc_crtc_mode_fixup(struct drm_crtc *crtc,
return true;
 }

+/*
+ * Calculate the percentage difference between the requested pixel clock rate
+ * and the effective rate resulting from calculating the clock divider value.
+ */
+static unsigned int tilcdc_pclk_diff(unsigned long rate,
+unsigned long real_rate)
+{
+   int r = rate / 100, rr = real_rate / 100;
+
+   return (unsigned int)(abs(((rr - r) * 100) / r));
+}
+
 static void tilcdc_crtc_set_clk(struct drm_crtc *crtc)
 {
struct drm_device *dev = crtc->dev;
struct tilcdc_drm_private *priv = dev->dev_private;
struct tilcdc_crtc *tilcdc_crtc = to_tilcdc_crtc(crtc);
-   const unsigned clkdiv = 2; /* using a fixed divider of 2 */
+   unsigned long clk_rate, real_rate, req_rate;
+   unsigned int clkdiv;
int ret;

+   clkdiv = 2; /* first try using a standard divider of 2 */
+
/* mode.clock is in KHz, set_rate wants parameter in Hz */
-   ret = clk_set_rate(priv->clk, crtc->mode.clock * 1000 * clkdiv);
+   req_rate = crtc->mode.clock * 1000;
+
+   ret = clk_set_rate(priv->clk, req_rate * clkdiv);
+   clk_rate = clk_get_rate(priv->clk);
if (ret < 0) {
-   dev_err(dev->dev, "failed to set display clock rate to: %d\n",
-   crtc->mode.clock);
-   return;
+   /*
+* If we fail to set the clock rate (some architectures don't
+* use the common clock framework yet and may not implement
+* all the clk API calls for every clock), try the next best
+* thing: adjusting the clock divider, unless clk_get_rate()
+* failed as well.
+*/
+   if (!clk_rate) {
+   /* Nothing more we can do. Just bail out. */
+   dev_err(dev->dev,
+   "failed to set the pixel clock - unable to read 
current lcdc clock rate\n");
+   return;
+   }
+
+   clkdiv = DIV_ROUND_CLOSEST(clk_rate, req_rate);
+
+   /*
+* Emit a warning if the real clock rate resulting from the
+* calculated divider differs much from the requested rate.
+*
+* 5% is an arbitrary value - LCDs are usually quite tolerant
+* about pixel clock rates.
+*/
+   real_rate = clkdiv * req_rate;
+
+   if (tilcdc_pclk_diff(clk_rate, real_rate) > 5) {
+   dev_warn(dev->dev,
+"effective pixel clock rate (%luHz) differs 
from the calculated rate (%luHz)\n",
+clk_rate, real_rate);
+   }
}

-   tilcdc_crtc->lcd_fck_rate = clk_get_rate(priv->clk);
+   tilcdc_crtc->lcd_fck_rate = clk_rate;

DBG("lcd_clk=%u, mode clock=%d, div=%u",
tilcdc_crtc->lcd_fck_rate, crtc->mode.clock, clkdiv);
-- 
2.7.4



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

2016-09-29 Thread Shawn Guo
Hi Sean,

On Tue, Sep 27, 2016 at 11:48:37AM -0400, Sean Paul wrote:
> On Sat, Sep 24, 2016 at 10:26 AM, Shawn Guo  wrote:
> > It adds the initial ZTE VOU display controller DRM driver.  There are
> > still some features to be added, like overlay plane, scaling, and more
> > output devices support.  But it's already useful with dual CRTCs and
> > HDMI monitor working.
> >
> > It's been tested on Debian Jessie LXDE desktop with modesetting driver.
> >
> > Signed-off-by: Shawn Guo 
> 
> Hi Shawn,
> I think overall this is very well done! A couple of things stuck out
> to me, I've pointed them out below, hopefully you can use some of
> them.

Thanks for reviewing the patch.  The comments are helpful, and I will
try to address them immediately once I get back from the business
travel.

> > diff --git a/drivers/gpu/drm/zte/Makefile b/drivers/gpu/drm/zte/Makefile
> > new file mode 100644
> > index ..b40968dc749f
> > --- /dev/null
> > +++ b/drivers/gpu/drm/zte/Makefile
> > @@ -0,0 +1,8 @@
> > +zxdrm-y := \
> > +   zx_drm_drv.o \
> > +   zx_crtc.o \
> > +   zx_plane.o \
> > +   zx_hdmi.o
> > +
> > +obj-$(CONFIG_DRM_ZTE) += zxdrm.o
> > +
> > diff --git a/drivers/gpu/drm/zte/zx_crtc.c b/drivers/gpu/drm/zte/zx_crtc.c
> 
> I was a little tripped up when I first read this file since I assumed
> there was one instance of this driver per-crtc. However, there's
> really N crtcs per driver. Might it be less confusing to call it
> zx_vou.c instead?

Okay, will rename it.

> > +static void zx_crtc_enable(struct drm_crtc *crtc)
> > +{
> > +   struct drm_display_mode *mode = >state->adjusted_mode;
> > +   struct zx_crtc *zcrtc = to_zx_crtc(crtc);
> > +   struct zx_vou_hw *vou = dev_get_drvdata(zcrtc->dev);
> 
> IMO, it would be better to store a pointer to vou in each zx_crtc
> rather than reaching into drvdata.

Yeah, agree on that.

> > +   bool is_main = is_main_crtc(crtc);
> > +   struct videomode vm;
> > +   u32 pol = 0;
> > +   u32 val;
> > +
> > +   drm_display_mode_to_videomode(mode, );
> 
> Why do this conversion? You should be able to get everything you need
> from drm_display_mode

It's a helper function, and the calculation of front_porch, back_porch
and sync_len helps me.

> > +
> > +   /* Set up timing parameters */
> > +   val = (vm.vactive - 1) << 16;
> > +   val |= (vm.hactive - 1) & 0x;
> > +   writel(val, vou->timing + (is_main ? FIR_MAIN_ACTIVE : 
> > FIR_AUX_ACTIVE));
> > +
> > +   val = ((vm.hsync_len - 1) << SYNC_WIDE_SHIFT) & SYNC_WIDE_MASK;
> > +   val |= ((vm.hback_porch - 1) << BACK_PORCH_SHIFT) & BACK_PORCH_MASK;
> > +   val |= ((vm.hfront_porch - 1) << FRONT_PORCH_SHIFT) & 
> > FRONT_PORCH_MASK;
> > +   writel(val, vou->timing + (is_main ? FIR_MAIN_H_TIMING :
> > +FIR_AUX_H_TIMING));
> > +
> > +   val = ((vm.vsync_len - 1) << SYNC_WIDE_SHIFT) & SYNC_WIDE_MASK;
> > +   val |= ((vm.vback_porch - 1) << BACK_PORCH_SHIFT) & BACK_PORCH_MASK;
> > +   val |= ((vm.vfront_porch - 1) << FRONT_PORCH_SHIFT) & 
> > FRONT_PORCH_MASK;
> > +   writel(val, vou->timing + (is_main ? FIR_MAIN_V_TIMING :
> > +FIR_AUX_V_TIMING));
> 
> It would be nice to figure out a better way of handing the main/aux
> switch as opposed to sprinkling all of these inline conditionals
> around. Perhaps you could introduce a struct which stores the
> addresses per-crtc and then reference the struct in the driver as
> opposed to the #defines.
> 
> ie:
> 
> writel(val, vou->timing + zcrtc->regs->v_timing);

Yeah, good suggestion.

> > +static void zx_crtc_atomic_begin(struct drm_crtc *crtc,
> > +struct drm_crtc_state *state)
> > +{
> > +   struct drm_pending_vblank_event *event = crtc->state->event;
> > +
> > +   if (event) {
> 
> nit: you can save yourself a level of indentation by exiting early on
> !event instead of scoping the entire function on event.

Aha, right!

> 
> > +   crtc->state->event = NULL;
> > +
> > +   spin_lock_irq(>dev->event_lock);
> > +   if (drm_crtc_vblank_get(crtc) == 0)
> > +   drm_crtc_arm_vblank_event(crtc, event);
> > +   else
> > +   drm_crtc_send_vblank_event(crtc, event);
> > +   spin_unlock_irq(>dev->event_lock);
> > +   }
> > +}



> > +static struct zx_crtc *zx_crtc_init(struct drm_device *drm,
> > +   enum vou_chn_type chn_type)
> > +{
> > +   struct zx_drm_private *priv = drm->dev_private;
> > +   struct zx_vou_hw *vou = priv->vou;
> > +   struct device *dev = vou->dev;
> > +   struct zx_layer_data data;
> > +   struct zx_crtc *zcrtc;
> > +   int ret;
> > +
> > +   zcrtc = devm_kzalloc(dev, sizeof(*zcrtc), GFP_KERNEL);
> > +   if (!zcrtc)
> > +   return ERR_PTR(-ENOMEM);
> > +
> > +   

[Bug 97980] [amdgpu] New kernel warning during shutdown

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

--- Comment #1 from Alex Deucher  ---
Does cherry-picking this patch over help?
https://cgit.freedesktop.org/~airlied/linux/commit/?h=drm-fixes=a951ed85abd4615e98e36b536e3b3b07b22a88ac

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


[Bug 97980] [amdgpu] New kernel warning during shutdown

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

Bug ID: 97980
   Summary: [amdgpu] New kernel warning during shutdown
   Product: DRI
   Version: XOrg git
  Hardware: Other
OS: All
Status: NEW
  Severity: normal
  Priority: medium
 Component: DRM/AMDgpu
  Assignee: dri-devel at lists.freedesktop.org
  Reporter: mike at fireburn.co.uk

Created attachment 126886
  --> https://bugs.freedesktop.org/attachment.cgi?id=126886=edit
Screenshot

I might have spoke too soon with the memory manager patches, I'm seeing a stack
trace just as the machine is just about to switch off.

Also it takes about 30 seconds to switch off my laptop now, I think it's amdgpu
related, it seems to wait then fire up the card then switch off - it could also
be hard disk or even systemd related though.

I'm attaching the screen shot but it looks like an issue with
ttm_bo_force_list_clean

Sorry about the bad quality but I had to record a video in slowmo to capture
it, then screenshot that

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


-next trees

2016-09-29 Thread Thierry Reding
On Wed, Sep 28, 2016 at 01:31:36PM +1000, Dave Airlie wrote:
> Hey all,
> 
> Back from a week off, I've hoovered up everything and backmerged -rc8 on top.
> 
> If I've missed anything please let me know, I haven't seen next trees
> for exynos or nouveau, as possibly a few others, but those are the
> main two I noticed.

Bad timing with my vacation this time. I just sent out a single fix pull
request for Tegra that I had wanted to send out before the vacation but
forgot.

I also sent out a drm/panel pull request earlier. Nothing major there,
just updates and one new driver, all cooked in linux-next for two weeks.

Thierry
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160929/ffaa23c1/attachment-0001.sig>


[GIT PULL] drm/tegra: Changes for v4.9-rc1

2016-09-29 Thread Thierry Reding
Hi Dave,

The following changes since commit 87904c3e82319cf2bad8d656d79c5030dab9490e:

  drm/tegra: dsi: Enhance runtime power management (2016-08-24 15:58:57 +0200)

are available in the git repository at:

  git://anongit.freedesktop.org/tegra/linux tags/drm/tegra/for-4.9-rc1

for you to fetch changes up to 08ee01789eebf433c27e8b3eecc3ddbb5f7c4d51:

  drm/tegra: Fix window[0] base address corruption (2016-08-24 16:15:09 +0200)

Thanks,
Thierry


drm/tegra: Changes for v4.9-rc1

One bugfix that avoids overwriting the Y plane base address when
displaying buffers with one of the YUV/YVU formats.


Dmitry Osipenko (1):
  drm/tegra: Fix window[0] base address corruption

 drivers/gpu/drm/tegra/dc.c | 9 -
 1 file changed, 8 insertions(+), 1 deletion(-)


[PATCH] drm: Document caveats around atomic event handling

2016-09-29 Thread Daniel Vetter
It's not that obvious how a driver can all race the atomic commit with
handling the completion event. And there's unfortunately a pile of
drivers with rather bad event handling which misdirect people into the
wrong direction.

Try to remedy this by documenting everything better.

v2: Type fixes Alex spotted.

Cc: Andrzej Hajda 
Cc: Alex Deucher 
Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/drm_irq.c | 32 +--
 include/drm/drm_crtc.h| 56 ---
 2 files changed, 73 insertions(+), 15 deletions(-)

diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
index 10611a936059..dd59c0d8b652 100644
--- a/drivers/gpu/drm/drm_irq.c
+++ b/drivers/gpu/drm/drm_irq.c
@@ -1008,6 +1008,31 @@ static void send_vblank_event(struct drm_device *dev,
  * period. This helper function implements exactly the required vblank arming
  * behaviour.
  *
+ * NOTE: Drivers using this to send out the event in struct _crtc_state
+ * as part of an atomic commit must ensure that the next vblank happens at
+ * exactly the same time as the atomic commit is committed to the hardware. 
This
+ * function itself does **not** protect again the next vblank interrupt racing
+ * with either this function call or the atomic commit operation. A possible
+ * sequence could be:
+ *
+ * 1. Driver commits new hardware state into vblank-synchronized registers.
+ * 2. A vblank happens, committing the hardware state. Also the corresponding
+ *vblank interrupt is fired off and fully processed by the interrupt
+ *handler.
+ * 3. The atomic commit operation proceeds to call drm_crtc_arm_vblank_event().
+ * 4. The event is only send out for the next vblank, which is wrong.
+ *
+ * An equivalent race can happen when the driver calls
+ * drm_crtc_arm_vblank_event() before writing out the new hardware state.
+ *
+ * The only way to make this work savely is to prevent the vblank from firing
+ * (and the hardware from committig anything else) until the entire atomic
+ * commit sequence has run to completion. If the hardware does not have such a
+ * feature (e.g. using a "go" bit), then it is unsafe to use this functions.
+ * Instead drivers need to manually send out the event from their interrupt
+ * handler by calling drm_crtc_send_vblank_event() and make sure that there's 
no
+ * possible race with the hardware committing the atomic update.
+ *
  * Caller must hold event lock. Caller must also hold a vblank reference for
  * the event @e, which will be dropped when the next vblank arrives.
  */
@@ -1030,8 +1055,11 @@ EXPORT_SYMBOL(drm_crtc_arm_vblank_event);
  * @crtc: the source CRTC of the vblank event
  * @e: the event to send
  *
- * Updates sequence # and timestamp on event, and sends it to userspace.
- * Caller must hold event lock.
+ * Updates sequence # and timestamp on event for the most recently processed
+ * vblank, and sends it to userspace.  Caller must hold event lock.
+ *
+ * See drm_crtc_arm_vblank_event() for a helper which can be used in certain
+ * situation, especially to send out events for atomic commit operations.
  */
 void drm_crtc_send_vblank_event(struct drm_crtc *crtc,
struct drm_pending_vblank_event *e)
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index f88f9a2d05c1..eac3e4067fe5 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -109,8 +109,6 @@ struct drm_plane_helper_funcs;
  * @ctm: Transformation matrix
  * @gamma_lut: Lookup table for converting pixel data after the
  * conversion matrix
- * @event: optional pointer to a DRM event to signal upon completion of the
- * state update
  * @state: backpointer to global drm_atomic_state
  *
  * Note that the distinction between @enable and @active is rather subtile:
@@ -159,6 +157,46 @@ struct drm_crtc_state {
struct drm_property_blob *ctm;
struct drm_property_blob *gamma_lut;

+   /**
+* @event:
+*
+* Optional pointer to a DRM event to signal upon completion of the
+* state update. The driver must send out the event when the atomic
+* commit operation completes. There are two cases:
+*
+*  - The event is for a CRTC which is being disabled through this
+*atomic commit. In that case the event can be send out any time
+*after the hardware has stopped scanning out the current
+*framebuffers. It should contain the timestamp and counter for the
+*last vblank before the display pipeline was shut off.
+*
+*  - For a CRTC which is enabled at the end of the commit (even when it
+*undergoes an full modeset) the vblank timestamp and counter must
+*be for the vblank right before the first frame that scans out the
+*new set of buffers. Again the event can only be sent out after the
+*hardware has stopped scanning out the old buffers.
+*
+

[GIT PULL] drm/panel: Changes for v4.9-rc1

2016-09-29 Thread Thierry Reding
Hi Dave,

The following changes since commit 29b4817d4018df78086157ea3a55c1d9424a7cfc:

  Linux 4.8-rc1 (2016-08-07 18:18:00 -0700)

are available in the git repository at:

  git://anongit.freedesktop.org/tegra/linux tags/drm/panel/for-4.9-rc1

for you to fetch changes up to c96f566273bf086fe18a294ac37edf2d451ff024:

  drm/panel: Add JDI LT070ME05000 WUXGA DSI Panel (2016-09-16 17:32:48 +0200)

I'm terribly late with this because I was on vacation last week and have
been catching up since. On the upside, it's a very small set of changes,
and it's been cooking in linux-next for two weeks now without any issues
so I don't think there's going to be any surprises.

Thanks,
Thierry


drm/panel: Changes for v4.9-rc1

Adds support for one more panel to the simple-panel driver, fixes up a
couple of delays and flags for existing panels and finally adds a new
driver for the DSI panel found on Nexus 7 devices.


Brian Norris (1):
  drm/panel: simple-panel: Add delay timings for Starry KR122EA0SRA

Jonathan Liu (1):
  drm/panel: simple: Fix bus_format for the Olimex LCD-OLinuXino-4.3TS

Marek Vasut (1):
  drm/panel: simple: Fix bus flags for Ortustech com43h4m85ulc

Michael Olbrich (1):
  drm/panel: simple: Add Innolux G101ICE-L01 panel

Thierry Reding (1):
  drm/dsi: Order DCS helpers by command code

Vinay Simha BN (3):
  drm/dsi: Implement DCS set/get display brightness
  dt-bindings: Add JDI LT070ME05000 panel bindings
  drm/panel: Add JDI LT070ME05000 WUXGA DSI Panel

Yakir Yang (1):
  drm/panel: simple: Add delay timing for Sharp LQ123P1JX31

 .../bindings/display/panel/innolux,g101ice-l01.txt |   7 +
 .../bindings/display/panel/jdi,lt070me05000.txt|  31 ++
 drivers/gpu/drm/drm_mipi_dsi.c |  63 ++-
 drivers/gpu/drm/panel/Kconfig  |  11 +
 drivers/gpu/drm/panel/Makefile |   1 +
 drivers/gpu/drm/panel/panel-jdi-lt070me05000.c | 532 +
 drivers/gpu/drm/panel/panel-simple.c   |  44 +-
 include/drm/drm_mipi_dsi.h |   6 +-
 8 files changed, 686 insertions(+), 9 deletions(-)
 create mode 100644 
Documentation/devicetree/bindings/display/panel/innolux,g101ice-l01.txt
 create mode 100644 
Documentation/devicetree/bindings/display/panel/jdi,lt070me05000.txt
 create mode 100644 drivers/gpu/drm/panel/panel-jdi-lt070me05000.c


EDID reading failed when using DVI-to-VGA connector in valleyview(device id: 0x0f31)

2016-09-29 Thread 杨波
reported bug https://bugs.freedesktop.org/show_bug.cgi?id=97971

If need more info, pls let me know





--

武汉深之度科技有限公司
Wuhan Deepin Technology Co., Ltd.

  杨波  

手机:18523158905


武汉:武汉市光谷大道77号光谷金融港B18栋6楼 
北京:北京市海淀区知春路锦秋国际大厦B座501室
上海:上海市长宁区愚园路1258号15A01室


官网:www.deepin.org  官博:深度操作系统








-- Original --
From:  "Jani Nikula"<jani.nik...@linux.intel.com>;
Date:  Thu, Sep 29, 2016 03:11 PM
To:  "杨波"; "daniel.vetter"; 
Cc:  "dri-devel"; 
Subject:  Re: EDID reading failed when using DVI-to-VGA connector in 
valleyview(device id: 0x0f31)


On Thu, 29 Sep 2016, 杨波  wrote:
> Hi, everyone:
> Reading EDID failed when using DVI-to-VGA connector in valleyview(device 
> id: 0x0f31). 
> It is not G4X device,but still need to probe digital port. 

I don't think the patch is acceptable, at least not without a proper
explanation and debugging of the problem. Please file a bug at [1], add
drm.debug=14 module parameter and attach dmesg on the bug.

BR,
Jani.

[1] https://bugs.freedesktop.org/enter_bug.cgi?product=DRI=DRM/Intel



>
>
>
>
>
> --
>
> 武汉深之度科技有限公司
> Wuhan Deepin Technology Co., Ltd.
>
>   杨波  
>
> 手机:18523158905
>
>
> 武汉:武汉市光谷大道77号光谷金融港B18栋6楼 
> 北京:北京市海淀区知春路锦秋国际大厦B座501室
> 上海:上海市长宁区愚园路1258号15A01室
>
>
> 官网:www.deepin.org  官博:深度操作系统
> From e2dbb517239b5f03da7578e9e350013f8e9c2b3a Mon Sep 17 00:00:00 2001
> From: Yang Bo 
> Date: Thu, 29 Sep 2016 14:48:32 +0800
> Subject: [PATCH] EDID reading failure in 0x0f31
>
> EDID reading failure is observed in valleyview(device id: 0x0f31)
> when using DVI-to-VGA connector.
>
> Signed-off-by: Yang Bo 
> ---
>  drivers/gpu/drm/i915/intel_crt.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_crt.c 
> b/drivers/gpu/drm/i915/intel_crt.c
> index 827b6ef..83662fa 100644
> --- a/drivers/gpu/drm/i915/intel_crt.c
> +++ b/drivers/gpu/drm/i915/intel_crt.c
> @@ -715,7 +715,7 @@ static int intel_crt_get_modes(struct drm_connector 
> *connector)
>  
>   i2c = intel_gmbus_get_adapter(dev_priv, dev_priv->vbt.crt_ddc_pin);
>   ret = intel_crt_ddc_get_modes(connector, i2c);
> - if (ret || !IS_G4X(dev))
> + if (ret || !(IS_G4X(dev) || (dev->pdev->device == 0x0f31)))
>   goto out;
>  
>   /* Try to probe digital port for output in DVI-I -> VGA mode. */

-- 
Jani Nikula, Intel Open Source Technology Center
-- next part --
An HTML attachment was scrubbed...
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160929/349f7d44/attachment.html>


[PATCH] drm: Document caveats around atomic event handling

2016-09-29 Thread Daniel Vetter
It's not that obvious how a driver can all race the atomic commit with
handling the completion event. And there's unfortunately a pile of
drivers with rather bad event handling which misdirect people into the
wrong direction.

Try to remedy this by documenting everything better.

Cc: Andrzej Hajda 
Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/drm_irq.c | 32 +--
 include/drm/drm_crtc.h| 56 ---
 2 files changed, 73 insertions(+), 15 deletions(-)

diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
index 10611a936059..8874b564ec76 100644
--- a/drivers/gpu/drm/drm_irq.c
+++ b/drivers/gpu/drm/drm_irq.c
@@ -1008,6 +1008,31 @@ static void send_vblank_event(struct drm_device *dev,
  * period. This helper function implements exactly the required vblank arming
  * behaviour.
  *
+ * NOTE: Drivers using this to send out the even in struct _crtc_state
+ * as part of an atomic commit must ensure that the next vblank happens at
+ * exactly the same time as the atomic commit is committed to the hardware. 
This
+ * function itself does **not** protect again the next vblank interrupt racing
+ * with either this function call or the atomic commit operation. A possible
+ * sequence could be:
+ *
+ * 1. Driver commits new hardware state into vblank-synchronized registes.
+ * 2. A vblank happes, committing the hardware state. Also the corresponding
+ *vblank interrupt is fired off and fully processed by the interrupt
+ *handler.
+ * 3. The atomic commit operation proceeds to call drm_crtc_arm_vblank_event().
+ * 4. The event is only send out for the next vblank, which is wrong.
+ *
+ * An equivalent race can happen when the driver calls
+ * drm_crtc_arm_vblank_event() before writing out the new hardware state.
+ *
+ * The only way to make this work savely is to prevent the vblank from firing
+ * (and the hardware from committig anything else) until the entire atomic
+ * commit sequence has run to completion. If the hardware does not have such a
+ * feature (e.g. using a "go" bit), then it is unsafe to use this functions.
+ * Instead drivers need to manually send out the event from their interrupt
+ * handler by calling drm_crtc_send_vblank_event() and make sure that there's 
no
+ * possible race with the hardware committing the atomic update.
+ *
  * Caller must hold event lock. Caller must also hold a vblank reference for
  * the event @e, which will be dropped when the next vblank arrives.
  */
@@ -1030,8 +1055,11 @@ EXPORT_SYMBOL(drm_crtc_arm_vblank_event);
  * @crtc: the source CRTC of the vblank event
  * @e: the event to send
  *
- * Updates sequence # and timestamp on event, and sends it to userspace.
- * Caller must hold event lock.
+ * Updates sequence # and timestamp on event for the most recently processed
+ * vblank, and sends it to userspace.  Caller must hold event lock.
+ *
+ * See drm_crtc_arm_vblank_event() for a helper which can be used in certain
+ * situation, especially to send out events for atomic commit operations.
  */
 void drm_crtc_send_vblank_event(struct drm_crtc *crtc,
struct drm_pending_vblank_event *e)
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index f88f9a2d05c1..b381be639fd8 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -109,8 +109,6 @@ struct drm_plane_helper_funcs;
  * @ctm: Transformation matrix
  * @gamma_lut: Lookup table for converting pixel data after the
  * conversion matrix
- * @event: optional pointer to a DRM event to signal upon completion of the
- * state update
  * @state: backpointer to global drm_atomic_state
  *
  * Note that the distinction between @enable and @active is rather subtile:
@@ -159,6 +157,46 @@ struct drm_crtc_state {
struct drm_property_blob *ctm;
struct drm_property_blob *gamma_lut;

+   /**
+* @event:
+*
+* Optional pointer to a DRM event to signal upon completion of the
+* state update. The driver must send out the event when the atomic
+* commit operation completes. There are two cases:
+*
+*  - The event is for a CRTC which is being disabled through this
+*atomic commit. In that case the event can be send out any time
+*after the hardware has stopped out scanning out the current
+*framebuffers. It should contain the timestampe and counter for the
+*last vblank before the display pipeline was shut off.
+*
+*  - For a CRTC which is enabled at the end of the commit (even when it
+*undergoes an full modeset) the vblank timestampe and counter must
+*be for the vblank right before the first frame that scans out the
+*new set of buffers. Again the event can only be sent out after the
+*hardware has stopped scanning out the old buffers.
+*
+*  - Events for disabled CRTCs are not 

[Bug 97976] VCE regression BO to small for addr since winsys/amdgpu: enable buffer allocation from slabs

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

--- Comment #5 from Andy Furniss  ---
(In reply to Nicolai Hähnle from comment #4)
> Created attachment 126880 [details] [review]
> candidate fix
> 
> Should be fixed by the attached patch.

Yes, working OK with that.

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


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

2016-09-29 Thread Shawn Guo
On Sun, Sep 25, 2016 at 10:58:09PM +0200, Daniel Vetter wrote:
> On Sat, Sep 24, 2016 at 10:26:25PM +0800, Shawn Guo wrote:
> > It adds the initial ZTE VOU display controller DRM driver.  There are
> > still some features to be added, like overlay plane, scaling, and more
> > output devices support.  But it's already useful with dual CRTCs and
> > HDMI monitor working.
> > 
> > It's been tested on Debian Jessie LXDE desktop with modesetting driver.
> > 
> > Signed-off-by: Shawn Guo 
> 
> I've done a very quick read-through, looks real pretty. A few comments
> below and in-line.

Thanks much for looking at it.

> For testing, have you tried to run i-g-t validation tests per our
> documentation? See 
> https://dri.freedesktop.org/docs/drm/gpu/drm-uapi.html#validating-changes-with-igt

Sorry for my ignorance on that.  I'm on business travel right now, and
will give it a try once I get back to the hardware.

> >  drivers/gpu/drm/Kconfig  |   2 +
> >  drivers/gpu/drm/Makefile |   1 +
> >  drivers/gpu/drm/zte/Kconfig  |   8 +
> >  drivers/gpu/drm/zte/Makefile |   8 +
> >  drivers/gpu/drm/zte/zx_crtc.c| 691 
> > +++
> >  drivers/gpu/drm/zte/zx_crtc.h|  47 +++
> >  drivers/gpu/drm/zte/zx_drm_drv.c | 258 +++
> >  drivers/gpu/drm/zte/zx_drm_drv.h |  22 ++
> >  drivers/gpu/drm/zte/zx_hdmi.c| 540 ++
> >  drivers/gpu/drm/zte/zx_plane.c   | 362 
> >  drivers/gpu/drm/zte/zx_plane.h   |  26 ++
> >  11 files changed, 1965 insertions(+)
> >  create mode 100644 drivers/gpu/drm/zte/Kconfig
> >  create mode 100644 drivers/gpu/drm/zte/Makefile
> >  create mode 100644 drivers/gpu/drm/zte/zx_crtc.c
> >  create mode 100644 drivers/gpu/drm/zte/zx_crtc.h
> >  create mode 100644 drivers/gpu/drm/zte/zx_drm_drv.c
> >  create mode 100644 drivers/gpu/drm/zte/zx_drm_drv.h
> >  create mode 100644 drivers/gpu/drm/zte/zx_hdmi.c
> >  create mode 100644 drivers/gpu/drm/zte/zx_plane.c
> >  create mode 100644 drivers/gpu/drm/zte/zx_plane.h
> 
> New entry in MAINTAINERS listening you (and probably dri-devel as the m-l)
> is missing.

Okay.  I will add a patch to do that in the next version.

> > +static int zx_drm_bind(struct device *dev)
> > +{
> > +   struct drm_device *drm;
> > +   struct zx_drm_private *priv;
> > +   int ret;
> > +
> > +   priv = devm_kzalloc(dev, sizeof(*priv), GFP_KERNEL);
> > +   if (!priv)
> > +   return -ENOMEM;
> > +
> > +   drm = drm_dev_alloc(_drm_driver, dev);
> > +   if (!drm)
> > +   return -ENOMEM;
> > +
> > +   drm->dev_private = priv;
> > +   dev_set_drvdata(dev, drm);
> > +
> > +   drm_mode_config_init(drm);
> > +   drm->mode_config.min_width = 16;
> > +   drm->mode_config.min_height = 16;
> > +   drm->mode_config.max_width = 4096;
> > +   drm->mode_config.max_height = 4096;
> > +   drm->mode_config.funcs = _drm_mode_config_funcs;
> > +
> > +   ret = drm_dev_register(drm, 0);
> 
> drm_dev_register should be the last function call in your bind function.
> Similar for unbind, drm_dev_register should be called first.
> 
> As a consequence of that you can remove the drm_connector_(un)register
> calls, those are only needed for hotplugged connectors like dp mst. But
> with correct ordering of drm_dev_(un)register that function will also take
> care of connector registration and unregistration.

Aha, that's the trick to save the call to drm_connector_register() from
connector driver.  Thanks for the info.

> > +static int zx_hdmi_get_edid_block(void *data, u8 *buf, unsigned int block,
> > + size_t len)
> > +{
> > +   struct zx_hdmi *hdmi = data;
> > +   int retry = 0;
> > +   int ret = 0;
> > +   int i = 0;
> > +   u8 val;
> > +
> > +   /* Enable DDC master access */
> > +   val = hdmi_readb(hdmi, TPI_DDC_MASTER_EN);
> > +   val |= HW_DDC_MASTER;
> > +   hdmi_writeb(hdmi, TPI_DDC_MASTER_EN, val);
> > +
> > +   hdmi_writeb(hdmi, ZX_DDC_ADDR, 0xa0);
> > +   hdmi_writeb(hdmi, ZX_DDC_OFFSET, block * EDID_LENGTH);
> > +   /* Bits [9:8] of bytes */
> > +   hdmi_writeb(hdmi, ZX_DDC_DIN_CNT2, (len >> 8) & 0xff);
> > +   /* Bits [7:0] of bytes */
> > +   hdmi_writeb(hdmi, ZX_DDC_DIN_CNT1, len & 0xff);
> > +
> > +   /* Clear FIFO */
> > +   val = hdmi_readb(hdmi, ZX_DDC_CMD);
> > +   val &= ~DDC_CMD_MASK;
> > +   val |= DDC_CMD_CLEAR_FIFO;
> > +   hdmi_writeb(hdmi, ZX_DDC_CMD, val);
> > +
> > +   /* Kick off the read */
> > +   val = hdmi_readb(hdmi, ZX_DDC_CMD);
> > +   val &= ~DDC_CMD_MASK;
> > +   val |= DDC_CMD_SEQUENTIAL_READ;
> > +   hdmi_writeb(hdmi, ZX_DDC_CMD, val);
> 
> It looks like the ZX_DDC register range implements a hw i2c engine (since
> you specifiy port and offsets and everything). Please implement it as an
> i2c_adapter driver and use the normal drm_get_edid function.

Okay.  I will give it a try to see if it works.

> > +static int zx_gl_plane_atomic_check(struct drm_plane *plane,
> > +   struct 

[Bug 97976] VCE regression BO to small for addr since winsys/amdgpu: enable buffer allocation from slabs

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

--- Comment #4 from Nicolai Hähnle  ---
Created attachment 126880
  --> https://bugs.freedesktop.org/attachment.cgi?id=126880=edit
candidate fix

Should be fixed by the attached patch.

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


[RFC PATCH 1/6] drm: add helper for arming crtc completion event

2016-09-29 Thread Daniel Vetter
On Thu, Sep 29, 2016 at 3:39 PM, Andrzej Hajda  wrote:
>
>>> +drm_crtc_arm_vblank_event(crtc, event);
>>> +else
>>> +drm_crtc_send_vblank_event(crtc, event);
>>> +spin_unlock_irq(>dev->event_lock);
>>> +}
>>> +}
>>> +EXPORT_SYMBOL(drm_crtc_arm_completion_event);
>> Maybe we need an EXPORT_SYMBOL_BROKEN for this  btw the kerneldoc of
>> the functions you're called do explain that this is not as easy as it
>> seems. That's also something you throw under the rug here.
>> -Daniel
>
> After quick look I have not found these kerneldocs, where can read about it.

Oops, it's indeed not there. It should be right next to
arm_vblank_event as a real big warning, but looks like I only put that
in some commit message and not into the docs itself :( Will fix asap.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch


drm/mediatek: fixed the calc method of data rate per lane

2016-09-29 Thread CK Hu
Hi, Jitao:

Sorry for late reply.
Some comments inline.

On Fri, 2016-08-26 at 14:10 +0800, Jitao Shi wrote:
> Tune dsi frame rate by pixel clock, dsi add some extra signal (i.e. Tlpx,
> Ths-prepare, Ths-zero, Ths-trail,Ths-exit) when enter and exit LP mode, this
> signal will cause h-time larger than normal and reduce FPS.
> Need to multiply a coefficient to offset the extra signal's effect.
> coefficient = ((htotal*bpp/lane_number)+Tlpx+Ths_prep+Ths_zero+Ths_trail+
> Ths_exit)/(htotal*bpp/lane_number))
> 
> Signed-off-by: Jitao Shi 
> ---
>  drivers/gpu/drm/mediatek/mtk_dsi.c |  111 
> ++--
>  1 file changed, 67 insertions(+), 44 deletions(-)
> 
> diff --git a/drivers/gpu/drm/mediatek/mtk_dsi.c 
> b/drivers/gpu/drm/mediatek/mtk_dsi.c
> index 28b2044..506aa22 100644

[snip...]

>  
> -static void dsi_phy_timconfig(struct mtk_dsi *dsi)
> +static void dsi_phy_timconfig(struct mtk_dsi *dsi, u32 phy_timing0,
> +   u32 phy_timing1, u32 phy_timing2,
> +   u32 phy_timing3)
>  {
> - u32 timcon0, timcon1, timcon2, timcon3;
> - unsigned int ui, cycle_time;
> - unsigned int lpx;
> -
> - ui = 1000 / dsi->data_rate + 0x01;
> - cycle_time = 8000 / dsi->data_rate + 0x01;
> - lpx = 5;
> -
> - timcon0 = (8 << 24) | (0xa << 16) | (0x6 << 8) | lpx;
> - timcon1 = (7 << 24) | (5 * lpx << 16) | ((3 * lpx) / 2) << 8 |
> -   (4 * lpx);
> - timcon2 = ((NS_TO_CYCLE(0x64, cycle_time) + 0xa) << 24) |
> -   (NS_TO_CYCLE(0x150, cycle_time) << 16);
> - timcon3 = (2 * lpx) << 16 | NS_TO_CYCLE(80 + 52 * ui, cycle_time) << 8 |
> -NS_TO_CYCLE(0x40, cycle_time);
> -
> - writel(timcon0, dsi->regs + DSI_PHY_TIMECON0);
> - writel(timcon1, dsi->regs + DSI_PHY_TIMECON1);
> - writel(timcon2, dsi->regs + DSI_PHY_TIMECON2);
> - writel(timcon3, dsi->regs + DSI_PHY_TIMECON3);
> + writel(phy_timing0, dsi->regs + DSI_PHY_TIMECON0);
> + writel(phy_timing1, dsi->regs + DSI_PHY_TIMECON1);
> + writel(phy_timing2, dsi->regs + DSI_PHY_TIMECON2);
> + writel(phy_timing3, dsi->regs + DSI_PHY_TIMECON3);
>  }
>  
>  static void mtk_dsi_enable(struct mtk_dsi *dsi)
> @@ -202,19 +186,57 @@ static int mtk_dsi_poweron(struct mtk_dsi *dsi)
>  {
>   struct device *dev = dsi->dev;
>   int ret;
> + u64 bit_clock, total_bits;
> + u32 htotal, htotal_bits, bit_per_pixel, overhead_cycles, overhead_bits;
> + u32 phy_timing0, phy_timing1, phy_timing2, phy_timing3;
>  
>   if (++dsi->refcount != 1)
>   return 0;
>  
> + phy_timing0 = LPX(5) | HS_PRPR(6) | HS_ZERO(10) | HS_TRAIL(8);
> + phy_timing1 = TA_GO(20) | TA_SURE(7) | TA_GET(25) | DA_HS_EXIT(7);
> + phy_timing2 = CLK_ZERO(38) | CLK_TRAIL(22);
> + phy_timing3 = CLK_HS_PRPR(8) | CLK_HS_POST(21) | CLK_HS_EXIT(10);

The original phy_timing2 and phy_timing3 is defined as

timcon2 = ((NS_TO_CYCLE(0x64, cycle_time) + 0xa) << 24) |
  (NS_TO_CYCLE(0x150, cycle_time) << 16);
timcon3 = (2 * lpx) << 16 | NS_TO_CYCLE(80 + 52 * ui, cycle_time) << 8
|
   NS_TO_CYCLE(0x40, cycle_time);

They are varied by cycle_time. I think you should not use a fixed value
for them.

> +
> + switch (dsi->format) {
> + case MIPI_DSI_FMT_RGB565:
> + bit_per_pixel = 16;
> + break;
> + case MIPI_DSI_FMT_RGB666_PACKED:
> + bit_per_pixel = 18;
> + break;
> + case MIPI_DSI_FMT_RGB666:
> + case MIPI_DSI_FMT_RGB888:
> + default:
> + bit_per_pixel = 24;
> + break;
> + }
>   /**
> -  * data_rate = (pixel_clock / 1000) * pixel_dipth * mipi_ratio;
> -  * pixel_clock unit is Khz, data_rata unit is MHz, so need divide 1000.
> -  * mipi_ratio is mipi clk coefficient for balance the pixel clk in mipi.
> -  * we set mipi_ratio is 1.05.
> +  * data_rate = (pixel_clock) * bit_per_pixel * mipi_ratio / lane_num;
> +  * vm.pixelclock is Khz, data_rata unit is Hz, so need to multiply 1000
> +  * mipi_ratio is (htotal * byte_per_pixel / lane_num + Tlpx + Ths_prep
> +  *+ Thstrail + Ths_exit + Ths_zero) /
> +  *   (htotal * byte_per_pixel /lane_number)
>*/
> - dsi->data_rate = dsi->vm.pixelclock * 3 * 21 / (1 * 1000 * 10);
> + bit_clock = dsi->vm.pixelclock * 1000 * bit_per_pixel;
> + htotal = dsi->vm.hactive + dsi->vm.hback_porch + dsi->vm.hfront_porch +
> +  dsi->vm.hsync_len;
> + htotal_bits = htotal * bit_per_pixel;
> +
> + /**
> +  * overhead = lpx + hs_prepare + hs_zero + hs_trail + hs_exit
> +  */
> + overhead_cycles = (phy_timing0 & 0xff) + (phy_timing0 >> 8 & 0xff) +
> +   (phy_timing0 >> 16 & 0xff) +
> +   (phy_timing0 >> 24 & 0xff) +
> +   (phy_timing1 >> 24 & 0xff);

I think phy_timing0 and 

[RFC PATCH 1/6] drm: add helper for arming crtc completion event

2016-09-29 Thread Andrzej Hajda
Hi Daniel,


On 29.09.2016 11:44, Daniel Vetter wrote:
> On Tue, Sep 27, 2016 at 03:36:14PM +0200, Andrzej Hajda wrote:
>> A lot of drivers need to fire pageflip completion event at very next vblank
>> interrupt. The patch adds helper to perform this operation.
>> drm_crtc_arm_completion_event checks if there is an event to handle,
>> if vblank reference get succeeds it arms the event, otherwise it sends the
>> event immediately.
>>
>> Signed-off-by: Andrzej Hajda 
>> ---
>>  drivers/gpu/drm/drm_irq.c | 25 +
>>  include/drm/drm_irq.h |  1 +
>>  2 files changed, 26 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
>> index 77f357b..313d323 100644
>> --- a/drivers/gpu/drm/drm_irq.c
>> +++ b/drivers/gpu/drm/drm_irq.c
>> @@ -1053,6 +1053,31 @@ void drm_crtc_send_vblank_event(struct drm_crtc *crtc,
>>  EXPORT_SYMBOL(drm_crtc_send_vblank_event);
>>  
>>  /**
>> + * drm_crtc_arm_completion_event - conditionally arm crtc completion event
>> + * @crtc: the source CRTC of the completion event
>> + *
>> + * A lot of drivers need to fire pageflip completion event at very next 
>> vblank
>> + * interrupt. This helper tries to arm the event in case of successful 
>> vblank
>> + * get otherwise it sends the event immediately.
> This function is copypasted tons of times over all drivers because they
> were broken, and this hack at least got the events working. But in general
> this here is racy, and if Mario ever runs on your hw he'll get upset about
> the wrong timings.

Could you explain what is racy here? I am not vblank expert, but the code
for me looked more or less OK.

>
> If we go with this (and I'm really not convinced it's a good idea) then it
> should have real big warning that you should never use this in a new
> driver.

It looked to me as an easy copy/paste cleaning :)
Anyway I would like to have correct solution, at least in case of exynos.

>
>> + */
>> +void drm_crtc_arm_completion_event(struct drm_crtc *crtc)
>> +{
>> +struct drm_pending_vblank_event *event = crtc->state->event;
>> +
>> +if (event) {
>> +crtc->state->event = NULL;
>> +
>> +spin_lock_irq(>dev->event_lock);
>> +if (drm_crtc_vblank_get(crtc) == 0)
> This check here completely torpedoes the design principle of atomic
> helpers that drivers always know the state of the crtc. Again I only did
> this because I didn't want to buy hw it for all the drivers which got
> this wrong.

If you mean driver should know that getting vblank should be possible
or not this code could be probably parametrized, for example:

drm_crtc_handle_completion_event(struct drm_crtc *crtc, bool send_immediately)


>> +drm_crtc_arm_vblank_event(crtc, event);
>> +else
>> +drm_crtc_send_vblank_event(crtc, event);
>> +spin_unlock_irq(>dev->event_lock);
>> +}
>> +}
>> +EXPORT_SYMBOL(drm_crtc_arm_completion_event);
> Maybe we need an EXPORT_SYMBOL_BROKEN for this  btw the kerneldoc of
> the functions you're called do explain that this is not as easy as it
> seems. That's also something you throw under the rug here.
> -Daniel

After quick look I have not found these kerneldocs, where can read about it.

Regards
Andrzej



[PATCH 2/2] drm/vc4: Add support for double-clocked modes.

2016-09-29 Thread Eric Anholt
Now that we have infoframes to report the pixel repeat flag, we can
start using it.  Fixes locking the 720x480i and 720x576i modes on my
Dell 2408WFP.  Like the 1920x1080i case, they don't fit properly on
the screen, though.

Signed-off-by: Eric Anholt 
---
 drivers/gpu/drm/vc4/vc4_crtc.c | 17 +++--
 drivers/gpu/drm/vc4/vc4_hdmi.c | 16 +++-
 drivers/gpu/drm/vc4/vc4_regs.h |  2 ++
 3 files changed, 24 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/vc4/vc4_crtc.c b/drivers/gpu/drm/vc4/vc4_crtc.c
index 83cafea03eff..7f08d681a74b 100644
--- a/drivers/gpu/drm/vc4/vc4_crtc.c
+++ b/drivers/gpu/drm/vc4/vc4_crtc.c
@@ -378,6 +378,7 @@ static void vc4_crtc_mode_set_nofb(struct drm_crtc *crtc)
struct drm_crtc_state *state = crtc->state;
struct drm_display_mode *mode = >adjusted_mode;
bool interlace = mode->flags & DRM_MODE_FLAG_INTERLACE;
+   u32 pixel_rep = (mode->flags & DRM_MODE_FLAG_DBLCLK) ? 2 : 1;
u32 format = PV_CONTROL_FORMAT_24;
bool debug_dump_regs = false;
int clock_select = vc4_get_clock_select(crtc);
@@ -393,14 +394,17 @@ static void vc4_crtc_mode_set_nofb(struct drm_crtc *crtc)
CRTC_WRITE(PV_CONTROL, 0);

CRTC_WRITE(PV_HORZA,
-  VC4_SET_FIELD(mode->htotal - mode->hsync_end,
+  VC4_SET_FIELD((mode->htotal -
+ mode->hsync_end) * pixel_rep,
 PV_HORZA_HBP) |
-  VC4_SET_FIELD(mode->hsync_end - mode->hsync_start,
+  VC4_SET_FIELD((mode->hsync_end -
+ mode->hsync_start) * pixel_rep,
 PV_HORZA_HSYNC));
CRTC_WRITE(PV_HORZB,
-  VC4_SET_FIELD(mode->hsync_start - mode->hdisplay,
+  VC4_SET_FIELD((mode->hsync_start -
+ mode->hdisplay) * pixel_rep,
 PV_HORZB_HFP) |
-  VC4_SET_FIELD(mode->hdisplay, PV_HORZB_HACTIVE));
+  VC4_SET_FIELD(mode->hdisplay * pixel_rep, PV_HORZB_HACTIVE));

CRTC_WRITE(PV_VERTA,
   VC4_SET_FIELD(mode->crtc_vtotal - mode->crtc_vsync_end,
@@ -434,20 +438,21 @@ static void vc4_crtc_mode_set_nofb(struct drm_crtc *crtc)
CRTC_WRITE(PV_V_CONTROL,
   PV_VCONTROL_CONTINUOUS |
   PV_VCONTROL_INTERLACE |
-  VC4_SET_FIELD(mode->htotal / 2,
+  VC4_SET_FIELD(mode->htotal * pixel_rep / 2,
 PV_VCONTROL_ODD_DELAY));
CRTC_WRITE(PV_VSYNCD_EVEN, 0);
} else {
CRTC_WRITE(PV_V_CONTROL, PV_VCONTROL_CONTINUOUS);
}

-   CRTC_WRITE(PV_HACT_ACT, mode->hdisplay);
+   CRTC_WRITE(PV_HACT_ACT, mode->hdisplay * pixel_rep);


CRTC_WRITE(PV_CONTROL,
   VC4_SET_FIELD(format, PV_CONTROL_FORMAT) |
   VC4_SET_FIELD(vc4_get_fifo_full_level(format),
 PV_CONTROL_FIFO_LEVEL) |
+  VC4_SET_FIELD(pixel_rep - 1, PV_CONTROL_PIXEL_REP) |
   PV_CONTROL_CLR_AT_START |
   PV_CONTROL_TRIGGER_UNDERFLOW |
   PV_CONTROL_WAIT_HSTART |
diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c b/drivers/gpu/drm/vc4/vc4_hdmi.c
index d6b54b905bee..c4cb2e26de32 100644
--- a/drivers/gpu/drm/vc4/vc4_hdmi.c
+++ b/drivers/gpu/drm/vc4/vc4_hdmi.c
@@ -402,6 +402,7 @@ static void vc4_hdmi_encoder_mode_set(struct drm_encoder 
*encoder,
bool hsync_pos = mode->flags & DRM_MODE_FLAG_PHSYNC;
bool vsync_pos = mode->flags & DRM_MODE_FLAG_PVSYNC;
bool interlaced = mode->flags & DRM_MODE_FLAG_INTERLACE;
+   u32 pixel_rep = (mode->flags & DRM_MODE_FLAG_DBLCLK) ? 2 : 1;
u32 verta = (VC4_SET_FIELD(mode->crtc_vsync_end - 
mode->crtc_vsync_start,
   VC4_HDMI_VERTA_VSP) |
 VC4_SET_FIELD(mode->crtc_vsync_start - mode->crtc_vdisplay,
@@ -424,7 +425,8 @@ static void vc4_hdmi_encoder_mode_set(struct drm_encoder 
*encoder,

HD_WRITE(VC4_HD_VID_CTL, 0);

-   clk_set_rate(vc4->hdmi->pixel_clock, mode->clock * 1000);
+   clk_set_rate(vc4->hdmi->pixel_clock, mode->clock * 1000 *
+((mode->flags & DRM_MODE_FLAG_DBLCLK) ? 2 : 1));

HDMI_WRITE(VC4_HDMI_SCHEDULER_CONTROL,
   HDMI_READ(VC4_HDMI_SCHEDULER_CONTROL) |
@@ -434,14 +436,18 @@ static void vc4_hdmi_encoder_mode_set(struct drm_encoder 
*encoder,
HDMI_WRITE(VC4_HDMI_HORZA,
   (vsync_pos ? VC4_HDMI_HORZA_VPOS : 0) |
   (hsync_pos ? VC4_HDMI_HORZA_HPOS : 0) |
-  VC4_SET_FIELD(mode->hdisplay, VC4_HDMI_HORZA_HAP));
+  VC4_SET_FIELD(mode->hdisplay * pixel_rep,
+VC4_HDMI_HORZA_HAP));

HDMI_WRITE(VC4_HDMI_HORZB,
- 

[PATCH 1/2] drm/vc4: Set up the AVI and SPD infoframes.

2016-09-29 Thread Eric Anholt
Fixes a purple bar on the left side of the screen with my Dell
2408WFP.  It will also be required for supporting the double-clocked
video modes.

Signed-off-by: Eric Anholt 
---
 drivers/gpu/drm/vc4/vc4_hdmi.c | 136 +++--
 drivers/gpu/drm/vc4/vc4_regs.h |   5 ++
 2 files changed, 136 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c b/drivers/gpu/drm/vc4/vc4_hdmi.c
index d94108ca961d..d6b54b905bee 100644
--- a/drivers/gpu/drm/vc4/vc4_hdmi.c
+++ b/drivers/gpu/drm/vc4/vc4_hdmi.c
@@ -62,6 +62,8 @@ struct vc4_hdmi {
 struct vc4_hdmi_encoder {
struct vc4_encoder base;
bool hdmi_monitor;
+   bool limited_rgb_range;
+   bool rgb_range_selectable;
 };

 static inline struct vc4_hdmi_encoder *
@@ -205,6 +207,12 @@ static int vc4_hdmi_connector_get_modes(struct 
drm_connector *connector)
return -ENODEV;

vc4_encoder->hdmi_monitor = drm_detect_hdmi_monitor(edid);
+
+   if (edid && edid->input & DRM_EDID_INPUT_DIGITAL) {
+   vc4_encoder->rgb_range_selectable =
+   drm_rgb_quant_range_selectable(edid);
+   }
+
drm_mode_connector_update_edid_property(connector, edid);
ret = drm_add_edid_modes(connector, edid);

@@ -272,6 +280,117 @@ static const struct drm_encoder_funcs 
vc4_hdmi_encoder_funcs = {
.destroy = vc4_hdmi_encoder_destroy,
 };

+static int vc4_hdmi_stop_packet(struct drm_encoder *encoder,
+   enum hdmi_infoframe_type type)
+{
+   struct drm_device *dev = encoder->dev;
+   struct vc4_dev *vc4 = to_vc4_dev(dev);
+   u32 packet_id = type - 0x80;
+
+   HDMI_WRITE(VC4_HDMI_RAM_PACKET_CONFIG,
+  HDMI_READ(VC4_HDMI_RAM_PACKET_CONFIG) & ~BIT(packet_id));
+
+   return wait_for(!(HDMI_READ(VC4_HDMI_RAM_PACKET_STATUS) &
+ BIT(packet_id)), 100);
+}
+
+static void vc4_hdmi_write_infoframe(struct drm_encoder *encoder,
+union hdmi_infoframe *frame)
+{
+   struct drm_device *dev = encoder->dev;
+   struct vc4_dev *vc4 = to_vc4_dev(dev);
+   u32 packet_id = frame->any.type - 0x80;
+   u32 packet_reg = VC4_HDMI_GCP_0 + VC4_HDMI_PACKET_STRIDE * packet_id;
+   uint8_t buffer[VC4_HDMI_PACKET_STRIDE];
+   ssize_t len, i;
+   int ret;
+
+   WARN_ONCE(!(HDMI_READ(VC4_HDMI_RAM_PACKET_CONFIG) &
+   VC4_HDMI_RAM_PACKET_ENABLE),
+ "Packet RAM has to be on to store the packet.");
+
+   len = hdmi_infoframe_pack(frame, buffer, sizeof(buffer));
+   if (len < 0)
+   return;
+
+   ret = vc4_hdmi_stop_packet(encoder, frame->any.type);
+   if (ret) {
+   DRM_ERROR("Failed to wait for infoframe to go idle: %d\n", ret);
+   return;
+   }
+
+   for (i = 0; i < len; i += 7) {
+   HDMI_WRITE(packet_reg,
+  buffer[i + 0] << 0 |
+  buffer[i + 1] << 8 |
+  buffer[i + 2] << 16);
+   packet_reg += 4;
+
+   HDMI_WRITE(packet_reg,
+  buffer[i + 3] << 0 |
+  buffer[i + 4] << 8 |
+  buffer[i + 5] << 16 |
+  buffer[i + 6] << 24);
+   packet_reg += 4;
+   }
+
+   HDMI_WRITE(VC4_HDMI_RAM_PACKET_CONFIG,
+  HDMI_READ(VC4_HDMI_RAM_PACKET_CONFIG) | BIT(packet_id));
+   ret = wait_for((HDMI_READ(VC4_HDMI_RAM_PACKET_STATUS) &
+   BIT(packet_id)), 100);
+   if (ret)
+   DRM_ERROR("Failed to wait for infoframe to start: %d\n", ret);
+}
+
+static void vc4_hdmi_set_avi_infoframe(struct drm_encoder *encoder)
+{
+   struct vc4_hdmi_encoder *vc4_encoder = to_vc4_hdmi_encoder(encoder);
+   struct drm_crtc *crtc = encoder->crtc;
+   const struct drm_display_mode *mode = >state->adjusted_mode;
+   union hdmi_infoframe frame;
+   int ret;
+
+   ret = drm_hdmi_avi_infoframe_from_display_mode(, mode);
+   if (ret < 0) {
+   DRM_ERROR("couldn't fill AVI infoframe\n");
+   return;
+   }
+
+   if (vc4_encoder->rgb_range_selectable) {
+   if (vc4_encoder->limited_rgb_range) {
+   frame.avi.quantization_range =
+   HDMI_QUANTIZATION_RANGE_LIMITED;
+   } else {
+   frame.avi.quantization_range =
+   HDMI_QUANTIZATION_RANGE_FULL;
+   }
+   }
+
+   vc4_hdmi_write_infoframe(encoder, );
+}
+
+static void vc4_hdmi_set_spd_infoframe(struct drm_encoder *encoder)
+{
+   union hdmi_infoframe frame;
+   int ret;
+
+   ret = hdmi_spd_infoframe_init(, "Broadcom", "Videocore");
+   if (ret < 0) {
+   DRM_ERROR("couldn't fill SPD infoframe\n");
+   return;
+   }
+
+  

[PATCH 2/2 v2] drm/vc4: Fix support for interlaced modes on HDMI.

2016-09-29 Thread Eric Anholt
We really do need to be using the halved V fields.  I had been
confused by the code I was using as a reference because it stored
halved vsync fields but not halved vdisplay, so it looked like I only
needed to divide vdisplay by 2.

This reverts part of Mario's timestamping fixes that prevented
CRTC_HALVE_V from applying, and instead adjusts the timestamping code
to not use the crtc field in that case.

Fixes locking of 1920x1080x60i on my Dell 2408WFP.  There are black
bars on the top and bottom, but I suspect that might be an
under/overscan flags problem as opposed to video timings.

Signed-off-by: Eric Anholt 
---

After noting that we only used the one halved field last night and
spending some more of today debugging interlaced modes, I went and
looked and apparently the PV and HDMI *do* want CRTC_INTERLACE_HALVE_V
behavior.  This doesn't fix the problems I had, but it should correct
our timings, and also simplifies things and makes us look more like
other drivers.

 drivers/gpu/drm/vc4/vc4_crtc.c | 49 ++
 drivers/gpu/drm/vc4/vc4_hdmi.c | 45 +++---
 drivers/gpu/drm/vc4/vc4_regs.h |  3 +++
 3 files changed, 41 insertions(+), 56 deletions(-)

diff --git a/drivers/gpu/drm/vc4/vc4_crtc.c b/drivers/gpu/drm/vc4/vc4_crtc.c
index 2682f07d8f1e..83cafea03eff 100644
--- a/drivers/gpu/drm/vc4/vc4_crtc.c
+++ b/drivers/gpu/drm/vc4/vc4_crtc.c
@@ -229,7 +229,7 @@ int vc4_crtc_get_scanoutpos(struct drm_device *dev, 
unsigned int crtc_id,
 * and need to make things up in a approximative but consistent way.
 */
ret |= DRM_SCANOUTPOS_IN_VBLANK;
-   vblank_lines = mode->crtc_vtotal - mode->crtc_vdisplay;
+   vblank_lines = mode->vtotal - mode->vdisplay;

if (flags & DRM_CALLED_FROM_VBLIRQ) {
/*
@@ -378,7 +378,6 @@ static void vc4_crtc_mode_set_nofb(struct drm_crtc *crtc)
struct drm_crtc_state *state = crtc->state;
struct drm_display_mode *mode = >adjusted_mode;
bool interlace = mode->flags & DRM_MODE_FLAG_INTERLACE;
-   u32 vactive = (mode->vdisplay >> (interlace ? 1 : 0));
u32 format = PV_CONTROL_FORMAT_24;
bool debug_dump_regs = false;
int clock_select = vc4_get_clock_select(crtc);
@@ -404,32 +403,46 @@ static void vc4_crtc_mode_set_nofb(struct drm_crtc *crtc)
   VC4_SET_FIELD(mode->hdisplay, PV_HORZB_HACTIVE));

CRTC_WRITE(PV_VERTA,
-  VC4_SET_FIELD(mode->vtotal - mode->vsync_end,
+  VC4_SET_FIELD(mode->crtc_vtotal - mode->crtc_vsync_end,
 PV_VERTA_VBP) |
-  VC4_SET_FIELD(mode->vsync_end - mode->vsync_start,
+  VC4_SET_FIELD(mode->crtc_vsync_end - mode->crtc_vsync_start,
 PV_VERTA_VSYNC));
CRTC_WRITE(PV_VERTB,
-  VC4_SET_FIELD(mode->vsync_start - mode->vdisplay,
+  VC4_SET_FIELD(mode->crtc_vsync_start - mode->crtc_vdisplay,
 PV_VERTB_VFP) |
-  VC4_SET_FIELD(vactive, PV_VERTB_VACTIVE));
+  VC4_SET_FIELD(mode->crtc_vdisplay, PV_VERTB_VACTIVE));

if (interlace) {
CRTC_WRITE(PV_VERTA_EVEN,
-  VC4_SET_FIELD(mode->vtotal - mode->vsync_end - 1,
+  VC4_SET_FIELD(mode->crtc_vtotal -
+mode->crtc_vsync_end - 1,
 PV_VERTA_VBP) |
-  VC4_SET_FIELD(mode->vsync_end - mode->vsync_start,
+  VC4_SET_FIELD(mode->crtc_vsync_end -
+mode->crtc_vsync_start,
 PV_VERTA_VSYNC));
CRTC_WRITE(PV_VERTB_EVEN,
-  VC4_SET_FIELD(mode->vsync_start - mode->vdisplay,
+  VC4_SET_FIELD(mode->crtc_vsync_start -
+mode->crtc_vdisplay,
 PV_VERTB_VFP) |
-  VC4_SET_FIELD(vactive, PV_VERTB_VACTIVE));
+  VC4_SET_FIELD(mode->crtc_vdisplay, 
PV_VERTB_VACTIVE));
+
+   /* We set up first field even mode for HDMI.  VEC's
+* NTSC mode would want first field odd instead, once
+* we support it (to do so, set ODD_FIRST and put the
+* delay in VSYNCD_EVEN instead).
+*/
+   CRTC_WRITE(PV_V_CONTROL,
+  PV_VCONTROL_CONTINUOUS |
+  PV_VCONTROL_INTERLACE |
+  VC4_SET_FIELD(mode->htotal / 2,
+PV_VCONTROL_ODD_DELAY));
+   CRTC_WRITE(PV_VSYNCD_EVEN, 0);
+   } else {
+   CRTC_WRITE(PV_V_CONTROL, PV_VCONTROL_CONTINUOUS);
}

CRTC_WRITE(PV_HACT_ACT, 

[PATCH v2] drm: tilcdc: add a workaround for failed clk_set_rate()

2016-09-29 Thread Bartosz Golaszewski
2016-09-29 9:55 GMT+02:00 Jyri Sarha :
> On 09/28/16 15:41, Bartosz Golaszewski wrote:
>> Some architectures don't use the common clock framework and don't
>> implement all the clk interfaces for every clock. This is the case
>> for da850-lcdk where clk_set_rate() only works for PLL0 and PLL1.
>>
>> Trying to set the clock rate for the LCDC clock results in -EINVAL
>> being returned.
>>
>> As a workaround for that: if the call to clk_set_rate() fails, fall
>> back to adjusting the clock divider instead. Proper divider value is
>> calculated by dividing the current clock rate by the required pixel
>> clock rate in HZ.
>>
>> This code is based on a hack initially developed internally for
>> baylibre by Karl Beldan .
>>
>> Tested with a da850-lcdk with an LCD display connected over VGA.
>>
>> Signed-off-by: Bartosz Golaszewski 
>
> I'd say that a warn with backtrace over kill here (we know quite well
> how we end up here). And it would be helpful to know in actual numbers
> what the clock should have been and how close to it did we get.
>
> Otherwise the patch appears to work fine at least on am335x.
>

Actually there's one more issue - the requested clock rate is in
crtc->mode.clock, not in the rate variable, so that needs fixing too
for the message to be correct.

Best regards,
Bartosz Golaszewski


EDID reading failed when using DVI-to-VGA connector in valleyview(device id: 0x0f31)

2016-09-29 Thread 杨波
Hi, everyone:
Reading EDID failed when using DVI-to-VGA connector in valleyview(device 
id: 0x0f31). 
It is not G4X device,but still need to probe digital port. 





--

武汉深之度科技有限公司
Wuhan Deepin Technology Co., Ltd.

  杨波  

手机:18523158905


武汉:武汉市光谷大道77号光谷金融港B18栋6楼 
北京:北京市海淀区知春路锦秋国际大厦B座501室
上海:上海市长宁区愚园路1258号15A01室


官网:www.deepin.org  官博:深度操作系统
-- next part --
An HTML attachment was scrubbed...
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160929/99ea2890/attachment.html>
-- next part --
A non-text attachment was scrubbed...
Name: EDID-reading-failure-in-0x0f31.patch
Type: application/octet-stream
Size: 1004 bytes
Desc: not available
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160929/99ea2890/attachment.obj>


[Bug 97969] [radeonsi, bisected: fb827c0] Video decoding shows green artifacts

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

--- Comment #2 from Nicolai Hähnle  ---
Created attachment 126871
  --> https://bugs.freedesktop.org/attachment.cgi?id=126871=edit
possible fix

Does the attached patch fix the problem for you?

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


[PATCH v2 00/23] drm/omap: Convert to use videomode from omap_video_timings

2016-09-29 Thread Tomi Valkeinen
On 22/09/16 14:06, Peter Ujfalusi wrote:
> Hi,
> 
> Changes since v1:
> - separated the patches from the sync drive edge selection series [1]
> - commit messages updated as per Tomi's comments
> - other comments from Tomi for patch 10 (was 13) and 11 (was 14) addressed 
> also
> 
> The following series will convert the omapdrm stack to use the generic 
> videmode
> instead of the private omap_video_timings struct for the panel information.
> It depends on the 'video: of: Drive edge selection for sync' series [1] as it 
> is
> using the flags introduced by the sync drive edge selection support.
> 
> The patches are most mechanical ones. I have decided to split it up to small
> chunks and did one change at the time to finally remove the omap_video_timings
> from omapdrm.
> 
> generated on top of 4.8-rc7 + [1]
> 
> Regards,
> Peter
> 
> [1] http://marc.info/?l=linux-fbdev=147454058512738=2

For the series:

Reviewed-by: Tomi Valkeinen 

 Tomi

-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160929/b6692cfa/attachment.sig>


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

2016-09-29 Thread Maxime Ripard
Hi,

On Tue, Sep 27, 2016 at 10:42:09AM -0400, Sean Paul wrote:
> As an aside, it seems like (from the diff, I haven't looked at the
> code) the bridge_pre_enable and bridge_post_disable calls are missing,
> and the enable/disable calls are in the wrong place.

Actually, I don't even think that's necessary. The atomic helpers
already call drm_bridge_pre_enable and drm_bridge_enable at the right
time. So I guess the proper fix would be to just remove the driver's
call to drm_bridge_enable.

Thanks!
Maxime

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


[Bug 97976] VCE regression BO to small for addr since winsys/amdgpu: enable buffer allocation from slabs

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

--- Comment #3 from Nicolai Hähnle  ---
Thanks for the report, I can reproduce this and will investigate.

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


[PATCH v2 3/3] video: of: display_timing: Add support for syncclk-active property

2016-09-29 Thread Tomi Valkeinen
On 22/09/16 13:35, Peter Ujfalusi wrote:
> Configure the DISPLAY_FLAGS_SYNC_POSEDGE/NEGEDGE flags according to the
> binding document.
> If the syncclk-active is present in DT, configure the flags accordingly, if
> it is omitted it means that the SYNC edge is following the pixdata
> configuration.
> 
> Signed-off-by: Peter Ujfalusi 
> CC: Rob Herring <robh+dt at kernel.org>
> CC: Mark Rutland 
> CC: devicetree at vger.kernel.org
> ---
>  drivers/video/of_display_timing.c | 9 +
>  1 file changed, 9 insertions(+)
> 
> diff --git a/drivers/video/of_display_timing.c 
> b/drivers/video/of_display_timing.c
> index 8a1076beecd3..db992c684f09 100644
> --- a/drivers/video/of_display_timing.c
> +++ b/drivers/video/of_display_timing.c
> @@ -88,6 +88,15 @@ static int of_parse_display_timing(const struct 
> device_node *np,
>   dt->flags |= val ? DISPLAY_FLAGS_PIXDATA_POSEDGE :
>   DISPLAY_FLAGS_PIXDATA_NEGEDGE;
>  
> + if (!of_property_read_u32(np, "syncclk-active", ))
> + dt->flags |= val ? DISPLAY_FLAGS_SYNC_POSEDGE :
> + DISPLAY_FLAGS_SYNC_NEGEDGE;
> + else if (dt->flags & (DISPLAY_FLAGS_PIXDATA_POSEDGE |
> +   DISPLAY_FLAGS_PIXDATA_NEGEDGE))
> + dt->flags |= dt->flags & DISPLAY_FLAGS_PIXDATA_POSEDGE ?
> + DISPLAY_FLAGS_SYNC_POSEDGE :
> + DISPLAY_FLAGS_SYNC_NEGEDGE;
> +
>   if (of_property_read_bool(np, "interlaced"))
>   dt->flags |= DISPLAY_FLAGS_INTERLACED;
>   if (of_property_read_bool(np, "doublescan"))
> 

Reviewed-by: Tomi Valkeinen 

 Tomi

-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160929/1f741446/attachment.sig>


[PATCH v2 2/3] video: display_timing: Add flags to select the edge when the sync is driven

2016-09-29 Thread Tomi Valkeinen
On 22/09/16 13:35, Peter Ujfalusi wrote:
> The sync can be - and for some panels it must be - driven on different edge
> then the data.

Well, the "can be" depends on the display controller =).

> Signed-off-by: Peter Ujfalusi 
> CC: Rob Herring <robh+dt at kernel.org>
> CC: Mark Rutland 
> CC: devicetree at vger.kernel.org
> ---
>  include/video/display_timing.h | 4 
>  1 file changed, 4 insertions(+)
> 
> diff --git a/include/video/display_timing.h b/include/video/display_timing.h
> index 28d9d0d566ca..3d289e990aca 100644
> --- a/include/video/display_timing.h
> +++ b/include/video/display_timing.h
> @@ -28,6 +28,10 @@ enum display_flags {
>   DISPLAY_FLAGS_INTERLACED= BIT(8),
>   DISPLAY_FLAGS_DOUBLESCAN= BIT(9),
>   DISPLAY_FLAGS_DOUBLECLK = BIT(10),
> + /* drive sync on pos. edge */
> + DISPLAY_FLAGS_SYNC_POSEDGE  = BIT(11),
> + /* drive sync on neg. edge */
> + DISPLAY_FLAGS_SYNC_NEGEDGE  = BIT(12),
>  };
>  
>  /*
> 

Reviewed-by: Tomi Valkeinen 

 Tomi

-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160929/51bec99d/attachment.sig>


[PATCH v2 1/3] dt-bindings: display: display-timing: Add property to configure sync drive edge

2016-09-29 Thread Tomi Valkeinen
On 22/09/16 13:35, Peter Ujfalusi wrote:
> There are display panels which demands that the sync signal is driven on
> different edge than the pixel data.
> With the syncclk-active property we can specify the clk edge to be used to
> drive the sync signal. When the property is missing it indicates that the
> sync is driven on the same edge as the pixel data.
> 
> Signed-off-by: Peter Ujfalusi 
> CC: Rob Herring <robh+dt at kernel.org>
> CC: Mark Rutland 
> CC: devicetree at vger.kernel.org
> ---
>  .../devicetree/bindings/display/panel/display-timing.txt  | 8 
> 
>  1 file changed, 8 insertions(+)
> 
> diff --git 
> a/Documentation/devicetree/bindings/display/panel/display-timing.txt 
> b/Documentation/devicetree/bindings/display/panel/display-timing.txt
> index e1d4a0b59612..81a75893d1b8 100644
> --- a/Documentation/devicetree/bindings/display/panel/display-timing.txt
> +++ b/Documentation/devicetree/bindings/display/panel/display-timing.txt
> @@ -32,6 +32,14 @@ optional properties:
>   - active low  = drive pixel data on falling edge/
>   sample data on rising edge
>   - ignored = ignored
> + - syncclk-active: with
> + - active high = drive sync on rising edge/
> + sample sync on falling edge of pixel
> + clock
> + - active low  = drive sync on falling edge/
> + sample sync on rising edge of pixel
> + clock
> + - omitted = same configuration as pixelclk-active

I wonder if the "sample sync on..." should be left out here. It makes
sense for the pixel data, but for sync... Do the panels "sample" it, or
do they trigger on rising/falling edge?

Well, maybe that's a bit on the nitpick side, so:

Reviewed-by: Tomi Valkeinen 

 Tomi

-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160929/6e591225/attachment.sig>


[Bug 141741] drm:radeon_get_bios [radeon]] *ERROR* Unable to locate a BIOS ROM

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

David Martos  changed:

   What|Removed |Added

 CC||dri-devel at lists.freedesktop
   ||.org

-- 
You are receiving this mail because:
You are on the CC list for the bug.
You are watching the assignee of the bug.


[Bug 97976] VCE regression BO to small for addr since winsys/amdgpu: enable buffer allocation from slabs

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

--- Comment #2 from Alex Deucher  ---
Still probably a duplicate, but different winsys.

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


[Bug 97976] VCE regression BO to small for addr since winsys/amdgpu: enable buffer allocation from slabs

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

Alex Deucher  changed:

   What|Removed |Added

 Resolution|DUPLICATE   |---
 Status|RESOLVED|REOPENED

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


[Bug 97976] VCE regression BO to small for addr since winsys/amdgpu: enable buffer allocation from slabs

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

Alex Deucher  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #1 from Alex Deucher  ---


*** This bug has been marked as a duplicate of bug 97969 ***

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


[Bug 97969] [radeonsi, bisected: fb827c0] Video decoding shows green artifacts

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

Alex Deucher  changed:

   What|Removed |Added

 CC||adf.lists at gmail.com

--- Comment #1 from Alex Deucher  ---
*** Bug 97976 has been marked as a duplicate of this bug. ***

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


[Bug 97976] VCE regression BO to small for addr since winsys/amdgpu: enable buffer allocation from slabs

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

Bug ID: 97976
   Summary: VCE regression BO to small for addr since
winsys/amdgpu: enable buffer allocation from slabs
   Product: Mesa
   Version: git
  Hardware: Other
OS: All
Status: NEW
  Severity: normal
  Priority: medium
 Component: Drivers/Gallium/radeonsi
  Assignee: dri-devel at lists.freedesktop.org
  Reporter: adf.lists at gmail.com
QA Contact: dri-devel at lists.freedesktop.org

R9 285 tonga, git llvm, drm-next-4.9-wip.

Since Mesa commit -

commit ffa1c669ddb48c25bab3457b8b2bfcd255acc674
Author: Nicolai Hähnle 
Date:   Wed Sep 7 10:50:59 2016 +0200

winsys/amdgpu: enable buffer allocation from slabs

Using VCE encode fails (but not instantly) with 

[drm:amdgpu_vce_cs_reloc [amdgpu]] *ERROR* BO to small for addr 0x010005fe00
139 138

If you have gstreamer + vce you may be able to reproduce with -

gst-launch-1.0 -f ximagesrc use-damage=0 startx=0 starty=0 endx=1919 endy=1079
! queue ! videoconvert ! video/x-raw,framerate=60/1,format=NV12  ! queue !
vaapih264enc ! video/x-h264,profile=baseline ! fakesink

Which will run forever, it takes a few seconds to trigger for me. It assumes
your screen is 1080p so may need tweaking and I guess may luck out of
triggering at smaller sizes.

Other tests not involving gstreamer/screen grabbing = avconv reading 1080p
rawvid from tmpfs are also affected.

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


[PATCH 2/2] drm/mediatek: clear IRQ status before enable OVL interrupt

2016-09-29 Thread CK Hu
Acked-by: CK Hu 

On Thu, 2016-09-29 at 11:29 +0800, Bibby Hsieh wrote:
> To make sure that the first vblank IRQ after enabling
> vblank isn't too short or immediate, we have to clear
> the IRQ status before enable OVL interrupt.
> 
> Signed-off-by: Bibby Hsieh 
> ---
>  drivers/gpu/drm/mediatek/mtk_disp_ovl.c |1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c 
> b/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
> index 019b7ca..f75c5b5 100644
> --- a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
> +++ b/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
> @@ -80,6 +80,7 @@ static void mtk_ovl_enable_vblank(struct mtk_ddp_comp *comp,
>ddp_comp);
>  
>   priv->crtc = crtc;
> + writel(0x0, comp->regs + DISP_REG_OVL_INTSTA);
>   writel_relaxed(OVL_FME_CPL_INT, comp->regs + DISP_REG_OVL_INTEN);
>  }
>  




[PATCH 1/2] drm/mediatek: set vblank_disable_allowed to true

2016-09-29 Thread CK Hu
Acked-by: CK Hu 

On Thu, 2016-09-29 at 11:29 +0800, Bibby Hsieh wrote:
> MTK DRM driver didn't set the vblank_disable_allowed to
> true, it cause that the irq_handler is called every
> 16.6 ms (every vblank) when the display didn't be updated.
> 
> Signed-off-by: Bibby Hsieh 
> ---
>  drivers/gpu/drm/mediatek/mtk_drm_drv.c |1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_drv.c 
> b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
> index eebb7d8..941ec5f 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_drv.c
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
> @@ -200,6 +200,7 @@ static int mtk_drm_kms_init(struct drm_device *drm)
>   if (ret < 0)
>   goto err_component_unbind;
>  
> + drm->vblank_disable_allowed = true;
>   drm_kms_helper_poll_init(drm);
>   drm_mode_config_reset(drm);
>  




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

2016-09-29 Thread Sean Paul
On Thu, Sep 29, 2016 at 8:04 AM, Maxime Ripard
 wrote:
> Hi,
>
> On Tue, Sep 27, 2016 at 10:42:09AM -0400, Sean Paul wrote:
>> As an aside, it seems like (from the diff, I haven't looked at the
>> code) the bridge_pre_enable and bridge_post_disable calls are missing,
>> and the enable/disable calls are in the wrong place.
>
> Actually, I don't even think that's necessary. The atomic helpers
> already call drm_bridge_pre_enable and drm_bridge_enable at the right
> time. So I guess the proper fix would be to just remove the driver's
> call to drm_bridge_enable.
>

Yeah, that sounds good to me. I suppose this is one of the wonderful
ways that drm_bridge and drm_panel differ :-)

Sean


> Thanks!
> Maxime
>
> --
> Maxime Ripard, Free Electrons
> Embedded Linux and Kernel engineering
> http://free-electrons.com


[PATCH v3] drm/exynos: mixer: configure layers once in mixer_atomic_flush()

2016-09-29 Thread Inki Dae


2016년 09월 29일 01:28에 Tobias Jakobi 이(가) 쓴 글:
> Inki Dae wrote:
>> 2016-09-28 18:06 GMT+09:00 Tobias Jakobi :
>>> Hello Inki,
>>>
>>>
>>> Inki Dae wrote:


 2016년 09월 28일 09:03에 Tobias Jakobi 이(가) 쓴 글:
> Hey Inki,
>
>
> Inki Dae wrote:
>>
>>
>> 2016년 09월 28일 01:52에 Tobias Jakobi 이(가) 쓴 글:
>>> Hello Andrzej,
>>>
>>>
>>> Andrzej Hajda wrote:
 On 27.09.2016 13:22, Tobias Jakobi wrote:
> Hello Inki,
>
>
> Inki Dae wrote:
>> 2016년 09월 26일 20:36에 Tobias Jakobi 이(가) 쓴 글:
>>> Only manipulate the MXR_CFG and MXR_LAYER_CFG registers once
>>> in mixer_cfg_layer().
>>> Trigger this via atomic flush.
>>>
>>> Changes in v2:
>>> - issue mixer_cfg_layer() in mixer_disable()
>>> - rename fields as suggested by Andrzej
>>> - added docu to mixer context struct
>>> - simplify mixer_win_reset() as well
>>>
>>> Changes in v3:
>>> - simplify some conditions as suggested by Inki
>>> - add docu to mixer_cfg_layer()
>>> - fold switch statements into a single one
>>>
>>> Signed-off-by: Tobias Jakobi 
>>> ---
>>>  drivers/gpu/drm/exynos/exynos_mixer.c | 135 
>>> ++
>>>  drivers/gpu/drm/exynos/regs-mixer.h   |   2 +
>>>  2 files changed, 92 insertions(+), 45 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c 
>>> b/drivers/gpu/drm/exynos/exynos_mixer.c
>>> index 1e78d57..4f06f4d 100644
>>> --- a/drivers/gpu/drm/exynos/exynos_mixer.c
>>> +++ b/drivers/gpu/drm/exynos/exynos_mixer.c
>>> @@ -93,12 +93,25 @@ static const uint32_t vp_formats[] = {
>>>DRM_FORMAT_NV21,
>>>  };
>>>
>>> +/*
>>> + * Mixer context structure.
>>> + *
>>> + * @crtc: The HDMI CRTC attached to the mixer.
>>> + * @planes: Array of plane objects for each of the mixer windows.
>>> + * @active_windows: Cache of the mixer's hardware state.
>>> + *   Tracks which mixer windows are active/inactive.
>>> + * @pipe: The CRTC index.
>>> + * @flags: Bitfield build from the mixer_flag_bits enumerator.
>>> + * @mixer_resources: A struct containing registers, clocks, etc.
>>> + * @mxr_ver: The hardware revision/version of the mixer.
>>> + */
>>>  struct mixer_context {
>>>struct platform_device *pdev;
>>>struct device   *dev;
>>>struct drm_device   *drm_dev;
>>>struct exynos_drm_crtc  *crtc;
>>>struct exynos_drm_plane planes[MIXER_WIN_NR];
>>> +  unsigned long   active_windows;
>>>int pipe;
>>>unsigned long   flags;
>>>
>>> @@ -418,37 +431,70 @@ static void mixer_cfg_rgb_fmt(struct 
>>> mixer_context *ctx, unsigned int height)
>>>mixer_reg_writemask(res, MXR_CFG, val, MXR_CFG_RGB_FMT_MASK);
>>>  }
>>>
>>> -static void mixer_cfg_layer(struct mixer_context *ctx, unsigned 
>>> int win,
>>> -  unsigned int priority, bool enable)
>>> +/**
>>> + * mixer_cfg_layer - apply layer configuration to hardware
>>> + * @ctx: mixer context
>>> + *
>>> + * This configures the MXR_CFG and MXR_LAYER_CFG hardware registers
>>> + * using the 'active_windows' field of the the mixer content, and
>>> + * the pixel format of the framebuffers associated with the enabled
>>> + * windows.
>>> + *
>>> + * Has to be called under mixer lock.
>>> + */
>>> +static void mixer_cfg_layer(struct mixer_context *ctx)
>>>  {
>>>struct mixer_resources *res = >mixer_res;
>>> -  u32 val = enable ? ~0 : 0;
>>> -
>>> -  switch (win) {
>>> -  case 0:
>>> -  mixer_reg_writemask(res, MXR_CFG, val, 
>>> MXR_CFG_GRP0_ENABLE);
>>> -  mixer_reg_writemask(res, MXR_LAYER_CFG,
>>> -  MXR_LAYER_CFG_GRP0_VAL(priority),
>>> -  MXR_LAYER_CFG_GRP0_MASK);
>>> -  break;
>>> -  case 1:
>>> -  mixer_reg_writemask(res, MXR_CFG, val, 
>>> MXR_CFG_GRP1_ENABLE);
>>> -  mixer_reg_writemask(res, MXR_LAYER_CFG,
>>> -  MXR_LAYER_CFG_GRP1_VAL(priority),
>>> -  MXR_LAYER_CFG_GRP1_MASK);
>>> +  unsigned int win;
>>>
>>> -  

[PATCH] drm/mediatek: fix a typo

2016-09-29 Thread CK Hu
Acked-by: CK Hu 

On Thu, 2016-09-29 at 11:22 +0800, Bibby Hsieh wrote:
> Fix the typo: OD_RELAYMODE->OD_CFG
> 
> Signed-off-by: Bibby Hsieh 
> ---
>  drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c |2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c 
> b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
> index df33b3c..aa5f20f 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
> @@ -123,7 +123,7 @@ static void mtk_od_config(struct mtk_ddp_comp *comp, 
> unsigned int w,
> unsigned int bpc)
>  {
>   writel(w << 16 | h, comp->regs + DISP_OD_SIZE);
> - writel(OD_RELAYMODE, comp->regs + OD_RELAYMODE);
> + writel(OD_RELAYMODE, comp->regs + OD_CFG);
>   mtk_dither_set(comp, bpc, DISP_OD_CFG);
>  }
>  




[PATCH] drm: Document caveats around atomic event handling

2016-09-29 Thread Alex Deucher
On Thu, Sep 29, 2016 at 11:50 AM, Daniel Vetter  
wrote:
> It's not that obvious how a driver can all race the atomic commit with
> handling the completion event. And there's unfortunately a pile of
> drivers with rather bad event handling which misdirect people into the
> wrong direction.
>
> Try to remedy this by documenting everything better.
>
> v2: Type fixes Alex spotted.

Missed a few noted below.  With those fixed:
Reviewed-by: Alex Deucher 

>
> Cc: Andrzej Hajda 
> Cc: Alex Deucher 
> Signed-off-by: Daniel Vetter 
> ---
>  drivers/gpu/drm/drm_irq.c | 32 +--
>  include/drm/drm_crtc.h| 56 
> ---
>  2 files changed, 73 insertions(+), 15 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
> index 10611a936059..dd59c0d8b652 100644
> --- a/drivers/gpu/drm/drm_irq.c
> +++ b/drivers/gpu/drm/drm_irq.c
> @@ -1008,6 +1008,31 @@ static void send_vblank_event(struct drm_device *dev,
>   * period. This helper function implements exactly the required vblank arming
>   * behaviour.
>   *
> + * NOTE: Drivers using this to send out the event in struct _crtc_state
> + * as part of an atomic commit must ensure that the next vblank happens at
> + * exactly the same time as the atomic commit is committed to the hardware. 
> This
> + * function itself does **not** protect again the next vblank interrupt 
> racing
> + * with either this function call or the atomic commit operation. A possible
> + * sequence could be:
> + *
> + * 1. Driver commits new hardware state into vblank-synchronized registers.
> + * 2. A vblank happens, committing the hardware state. Also the corresponding
> + *vblank interrupt is fired off and fully processed by the interrupt
> + *handler.
> + * 3. The atomic commit operation proceeds to call 
> drm_crtc_arm_vblank_event().
> + * 4. The event is only send out for the next vblank, which is wrong.
> + *
> + * An equivalent race can happen when the driver calls
> + * drm_crtc_arm_vblank_event() before writing out the new hardware state.
> + *
> + * The only way to make this work savely is to prevent the vblank from firing

safely

> + * (and the hardware from committig anything else) until the entire atomic


committing

> + * commit sequence has run to completion. If the hardware does not have such 
> a
> + * feature (e.g. using a "go" bit), then it is unsafe to use this functions.
> + * Instead drivers need to manually send out the event from their interrupt
> + * handler by calling drm_crtc_send_vblank_event() and make sure that 
> there's no
> + * possible race with the hardware committing the atomic update.
> + *
>   * Caller must hold event lock. Caller must also hold a vblank reference for
>   * the event @e, which will be dropped when the next vblank arrives.
>   */
> @@ -1030,8 +1055,11 @@ EXPORT_SYMBOL(drm_crtc_arm_vblank_event);
>   * @crtc: the source CRTC of the vblank event
>   * @e: the event to send
>   *
> - * Updates sequence # and timestamp on event, and sends it to userspace.
> - * Caller must hold event lock.
> + * Updates sequence # and timestamp on event for the most recently processed
> + * vblank, and sends it to userspace.  Caller must hold event lock.
> + *
> + * See drm_crtc_arm_vblank_event() for a helper which can be used in certain
> + * situation, especially to send out events for atomic commit operations.
>   */
>  void drm_crtc_send_vblank_event(struct drm_crtc *crtc,
> struct drm_pending_vblank_event *e)
> diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
> index f88f9a2d05c1..eac3e4067fe5 100644
> --- a/include/drm/drm_crtc.h
> +++ b/include/drm/drm_crtc.h
> @@ -109,8 +109,6 @@ struct drm_plane_helper_funcs;
>   * @ctm: Transformation matrix
>   * @gamma_lut: Lookup table for converting pixel data after the
>   * conversion matrix
> - * @event: optional pointer to a DRM event to signal upon completion of the
> - * state update
>   * @state: backpointer to global drm_atomic_state
>   *
>   * Note that the distinction between @enable and @active is rather subtile:
> @@ -159,6 +157,46 @@ struct drm_crtc_state {
> struct drm_property_blob *ctm;
> struct drm_property_blob *gamma_lut;
>
> +   /**
> +* @event:
> +*
> +* Optional pointer to a DRM event to signal upon completion of the
> +* state update. The driver must send out the event when the atomic
> +* commit operation completes. There are two cases:
> +*
> +*  - The event is for a CRTC which is being disabled through this
> +*atomic commit. In that case the event can be send out any time
> +*after the hardware has stopped scanning out the current
> +*framebuffers. It should contain the timestamp and counter for 
> the
> +*last vblank before the display pipeline was shut off.
> +*
> +*  - For a CRTC which is enabled 

-next trees

2016-09-29 Thread Daniel Vetter
On Wed, Sep 28, 2016 at 05:07:04PM -0400, Alex Deucher wrote:
> On Tue, Sep 27, 2016 at 11:31 PM, Dave Airlie  wrote:
> > Hey all,
> >
> > Back from a week off, I've hoovered up everything and backmerged -rc8 on 
> > top.
> >
> > If I've missed anything please let me know, I haven't seen next trees
> > for exynos or nouveau, as possibly a few others, but those are the
> > main two I noticed.
> 
> Just one last set of bug fixes I sent out a few minutes ago.

I realized that I've forgotten the generic pipe crc work from Tomeu. One
more -misc pull for that I guess.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch


[RFC PATCH 6/6] drm/sun4i: use helper for arming crtc completion event

2016-09-29 Thread Daniel Vetter
On Tue, Sep 27, 2016 at 11:09:53AM -0400, Alex Deucher wrote:
> On Tue, Sep 27, 2016 at 9:36 AM, Andrzej Hajda  wrote:
> > Replace custom code with core helper.
> >
> > Signed-off-by: Andrzej Hajda 
> 
> Nice cleanup.  Series is:
> Reviewed-by: Alex Deucher 

Replied to the helper patch with the reasons, but as-is nack.
-Daniel

> 
> > ---
> >  drivers/gpu/drm/sun4i/sun4i_crtc.c | 12 +---
> >  1 file changed, 1 insertion(+), 11 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/sun4i/sun4i_crtc.c 
> > b/drivers/gpu/drm/sun4i/sun4i_crtc.c
> > index 4a19221..238c08c 100644
> > --- a/drivers/gpu/drm/sun4i/sun4i_crtc.c
> > +++ b/drivers/gpu/drm/sun4i/sun4i_crtc.c
> > @@ -51,22 +51,12 @@ static void sun4i_crtc_atomic_flush(struct drm_crtc 
> > *crtc,
> >  {
> > struct sun4i_crtc *scrtc = drm_crtc_to_sun4i_crtc(crtc);
> > struct sun4i_drv *drv = scrtc->drv;
> > -   struct drm_pending_vblank_event *event = crtc->state->event;
> >
> > DRM_DEBUG_DRIVER("Committing plane changes\n");
> >
> > sun4i_backend_commit(drv->backend);
> >
> > -   if (event) {
> > -   crtc->state->event = NULL;
> > -
> > -   spin_lock_irq(>dev->event_lock);
> > -   if (drm_crtc_vblank_get(crtc) == 0)
> > -   drm_crtc_arm_vblank_event(crtc, event);
> > -   else
> > -   drm_crtc_send_vblank_event(crtc, event);
> > -   spin_unlock_irq(>dev->event_lock);
> > -   }
> > +   drm_crtc_arm_completion_event(crtc);
> >  }
> >
> >  static void sun4i_crtc_disable(struct drm_crtc *crtc)
> > --
> > 2.7.4
> >
> > ___
> > dri-devel mailing list
> > dri-devel at lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/dri-devel

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


[RFC PATCH 1/6] drm: add helper for arming crtc completion event

2016-09-29 Thread Daniel Vetter
On Tue, Sep 27, 2016 at 03:36:14PM +0200, Andrzej Hajda wrote:
> A lot of drivers need to fire pageflip completion event at very next vblank
> interrupt. The patch adds helper to perform this operation.
> drm_crtc_arm_completion_event checks if there is an event to handle,
> if vblank reference get succeeds it arms the event, otherwise it sends the
> event immediately.
> 
> Signed-off-by: Andrzej Hajda 
> ---
>  drivers/gpu/drm/drm_irq.c | 25 +
>  include/drm/drm_irq.h |  1 +
>  2 files changed, 26 insertions(+)
> 
> diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
> index 77f357b..313d323 100644
> --- a/drivers/gpu/drm/drm_irq.c
> +++ b/drivers/gpu/drm/drm_irq.c
> @@ -1053,6 +1053,31 @@ void drm_crtc_send_vblank_event(struct drm_crtc *crtc,
>  EXPORT_SYMBOL(drm_crtc_send_vblank_event);
>  
>  /**
> + * drm_crtc_arm_completion_event - conditionally arm crtc completion event
> + * @crtc: the source CRTC of the completion event
> + *
> + * A lot of drivers need to fire pageflip completion event at very next 
> vblank
> + * interrupt. This helper tries to arm the event in case of successful vblank
> + * get otherwise it sends the event immediately.

This function is copypasted tons of times over all drivers because they
were broken, and this hack at least got the events working. But in general
this here is racy, and if Mario ever runs on your hw he'll get upset about
the wrong timings.

If we go with this (and I'm really not convinced it's a good idea) then it
should have real big warning that you should never use this in a new
driver.

> + */
> +void drm_crtc_arm_completion_event(struct drm_crtc *crtc)
> +{
> + struct drm_pending_vblank_event *event = crtc->state->event;
> +
> + if (event) {
> + crtc->state->event = NULL;
> +
> + spin_lock_irq(>dev->event_lock);
> + if (drm_crtc_vblank_get(crtc) == 0)

This check here completely torpedoes the design principle of atomic
helpers that drivers always know the state of the crtc. Again I only did
this because I didn't want to buy hw it for all the drivers which got
this wrong.

> + drm_crtc_arm_vblank_event(crtc, event);
> + else
> + drm_crtc_send_vblank_event(crtc, event);
> + spin_unlock_irq(>dev->event_lock);
> + }
> +}
> +EXPORT_SYMBOL(drm_crtc_arm_completion_event);

Maybe we need an EXPORT_SYMBOL_BROKEN for this  btw the kerneldoc of
the functions you're called do explain that this is not as easy as it
seems. That's also something you throw under the rug here.
-Daniel

> +
> +/**
>   * drm_vblank_enable - enable the vblank interrupt on a CRTC
>   * @dev: DRM device
>   * @pipe: CRTC index
> diff --git a/include/drm/drm_irq.h b/include/drm/drm_irq.h
> index 2401b14..7bd9690 100644
> --- a/include/drm/drm_irq.h
> +++ b/include/drm/drm_irq.h
> @@ -144,6 +144,7 @@ extern void drm_crtc_send_vblank_event(struct drm_crtc 
> *crtc,
>  struct drm_pending_vblank_event *e);
>  extern void drm_crtc_arm_vblank_event(struct drm_crtc *crtc,
> struct drm_pending_vblank_event *e);
> +extern void drm_crtc_arm_completion_event(struct drm_crtc *crtc);
>  extern bool drm_handle_vblank(struct drm_device *dev, unsigned int pipe);
>  extern bool drm_crtc_handle_vblank(struct drm_crtc *crtc);
>  extern int drm_crtc_vblank_get(struct drm_crtc *crtc);
> -- 
> 2.7.4
> 

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


[PATCH] drm: simple_kms_helper: Add prepare_fb and cleanup_fb hooks

2016-09-29 Thread Daniel Vetter
On Mon, Sep 26, 2016 at 03:01:52PM +0200, Marek Vasut wrote:
> Add .prepare_fb and .cleanup_fb plane hooks into the drm_simple_kms.
> These can be used by drivers to call ie. the drm_fb_cma_setup_fence()
> helper.
> 
> Signed-off-by: Marek Vasut 
> Cc: Noralf Trønnes 
> Cc: Daniel Vetter 
> Cc: David Airlie 
> ---
>  drivers/gpu/drm/drm_simple_kms_helper.c | 26 ++
>  include/drm/drm_simple_kms_helper.h | 18 ++
>  2 files changed, 44 insertions(+)
> 
> diff --git a/drivers/gpu/drm/drm_simple_kms_helper.c 
> b/drivers/gpu/drm/drm_simple_kms_helper.c
> index 7b6d26e..7bae08c 100644
> --- a/drivers/gpu/drm/drm_simple_kms_helper.c
> +++ b/drivers/gpu/drm/drm_simple_kms_helper.c
> @@ -125,7 +125,33 @@ static void drm_simple_kms_plane_atomic_update(struct 
> drm_plane *plane,
>   pipe->funcs->update(pipe, pstate);
>  }
>  
> +static int drm_simple_kms_plane_prepare_fb(struct drm_plane *plane,
> +struct drm_plane_state *state)
> +{
> + struct drm_simple_display_pipe *pipe;
> +
> + pipe = container_of(plane, struct drm_simple_display_pipe, plane);
> + if (!pipe->funcs || !pipe->funcs->prepare_fb)
> + return 0;
> +
> + return pipe->funcs->prepare_fb(pipe, state);
> +}
> +
> +static void drm_simple_kms_plane_cleanup_fb(struct drm_plane *plane,
> + struct drm_plane_state *state)
> +{
> + struct drm_simple_display_pipe *pipe;
> +
> + pipe = container_of(plane, struct drm_simple_display_pipe, plane);
> + if (!pipe->funcs || !pipe->funcs->cleanup_fb)
> + return;
> +
> + pipe->funcs->cleanup_fb(pipe, state);
> +}
> +
>  static const struct drm_plane_helper_funcs drm_simple_kms_plane_helper_funcs 
> = {
> + .prepare_fb = drm_simple_kms_plane_prepare_fb,
> + .cleanup_fb = drm_simple_kms_plane_cleanup_fb,
>   .atomic_check = drm_simple_kms_plane_atomic_check,
>   .atomic_update = drm_simple_kms_plane_atomic_update,
>  };
> diff --git a/include/drm/drm_simple_kms_helper.h 
> b/include/drm/drm_simple_kms_helper.h
> index 5d112f7..1f55488 100644
> --- a/include/drm/drm_simple_kms_helper.h
> +++ b/include/drm/drm_simple_kms_helper.h
> @@ -69,6 +69,24 @@ struct drm_simple_display_pipe_funcs {
>*/
>   void (*update)(struct drm_simple_display_pipe *pipe,
>  struct drm_plane_state *plane_state);
> +
> + /**
> +  * @prepare_fb:
> +  *
> +  * Optional, calls drm_plane_helper_funcs->prepare_fb , refer to

s/calls/called by/.

> +  * the documentation in drm_modeset_helper_vtables.h .

Please insert a direct link to the right structure using "struct
_plane_helper_funcs". Please run

$ make htmldocs

to make sure it's all pretty and the links work.

Code itself lgtm.
-Daniel

> +  */
> + int (*prepare_fb)(struct drm_simple_display_pipe *pipe,
> +   struct drm_plane_state *plane_state);
> +
> + /**
> +  * @cleanup_fb:
> +  *
> +  * Optional, calls drm_plane_helper_funcs->cleanup_fb , refer to
> +  * the documentation in drm_modeset_helper_vtables.h .
> +  */
> + void (*cleanup_fb)(struct drm_simple_display_pipe *pipe,
> +struct drm_plane_state *plane_state);
>  };
>  
>  /**
> -- 
> 2.9.3
> 

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


[PATCH 2/2] drm/imx: Switch to drm_fb_cma_setup_fence() helper

2016-09-29 Thread Daniel Vetter
On Mon, Sep 26, 2016 at 03:01:04PM +0200, Marek Vasut wrote:
> Remove the common code from the driver and use the drm_fb_cma_setup_fence()
> helper instead. Moveover, call the helper from prepare_fb() plane hook .
> 
> Signed-off-by: Marek Vasut 
> Cc: Daniel Vetter 
> Cc: Lucas Stach 
> ---
>  drivers/gpu/drm/imx/imx-drm-core.c | 30 +-
>  drivers/gpu/drm/imx/ipuv3-plane.c  |  8 
>  2 files changed, 9 insertions(+), 29 deletions(-)
> 
> diff --git a/drivers/gpu/drm/imx/imx-drm-core.c 
> b/drivers/gpu/drm/imx/imx-drm-core.c
> index 98df09c..c7faa1f 100644
> --- a/drivers/gpu/drm/imx/imx-drm-core.c
> +++ b/drivers/gpu/drm/imx/imx-drm-core.c
> @@ -18,7 +18,6 @@
>  #include 
>  #include 
>  #include 
> -#include 
>  #include 
>  #include 
>  #include 
> @@ -151,38 +150,11 @@ static int imx_drm_atomic_check(struct drm_device *dev,
>   return ret;
>  }
>  
> -static int imx_drm_atomic_commit(struct drm_device *dev,
> -  struct drm_atomic_state *state,
> -  bool nonblock)
> -{
> - struct drm_plane_state *plane_state;
> - struct drm_plane *plane;
> - struct dma_buf *dma_buf;
> - int i;
> -
> - /*
> -  * If the plane fb has an dma-buf attached, fish out the exclusive
> -  * fence for the atomic helper to wait on.
> -  */
> - for_each_plane_in_state(state, plane, plane_state, i) {
> - if ((plane->state->fb != plane_state->fb) && plane_state->fb) {
> - dma_buf = drm_fb_cma_get_gem_obj(plane_state->fb,
> -  0)->base.dma_buf;
> - if (!dma_buf)
> - continue;
> - plane_state->fence =
> - reservation_object_get_excl_rcu(dma_buf->resv);
> - }
> - }
> -
> - return drm_atomic_helper_commit(dev, state, nonblock);
> -}
> -
>  static const struct drm_mode_config_funcs imx_drm_mode_config_funcs = {
>   .fb_create = drm_fb_cma_create,
>   .output_poll_changed = imx_drm_output_poll_changed,
>   .atomic_check = imx_drm_atomic_check,
> - .atomic_commit = imx_drm_atomic_commit,
> + .atomic_commit = drm_atomic_helper_commit,
>  };
>  
>  static void imx_drm_atomic_commit_tail(struct drm_atomic_state *state)
> diff --git a/drivers/gpu/drm/imx/ipuv3-plane.c 
> b/drivers/gpu/drm/imx/ipuv3-plane.c
> index ce22d0a..50615e3 100644
> --- a/drivers/gpu/drm/imx/ipuv3-plane.c
> +++ b/drivers/gpu/drm/imx/ipuv3-plane.c
> @@ -250,6 +250,13 @@ static const struct drm_plane_funcs ipu_plane_funcs = {
>   .atomic_destroy_state   = drm_atomic_helper_plane_destroy_state,
>  };
>  
> +static int ipu_plane_prepare_fb(struct drm_plane *plane,
> + struct drm_plane_state *state)
> +{
> + drm_fb_cma_setup_fence(plane, state);
> + return 0;
> +}
> +
>  static int ipu_plane_atomic_check(struct drm_plane *plane,
> struct drm_plane_state *state)
>  {
> @@ -442,6 +449,7 @@ static void ipu_plane_atomic_update(struct drm_plane 
> *plane,
>  }
>  
>  static const struct drm_plane_helper_funcs ipu_plane_helper_funcs = {
> + .prepare_fb = ipu_plane_prepare_fb,

See my coment about the function naming, but imo drm_fb_cma_prepare_fb
should have a function type matching prepare_fb. Otherwise every driver
needs a dummy wrapper function like ipu_plane_prepare_fb, which imo would
be pointless.
-Daniel

>   .atomic_check = ipu_plane_atomic_check,
>   .atomic_disable = ipu_plane_atomic_disable,
>   .atomic_update = ipu_plane_atomic_update,
> -- 
> 2.9.3
> 

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


[PATCH 1/2] drm/fb_cma_helper: Add drm_fb_cma_setup_fence() helper

2016-09-29 Thread Daniel Vetter
On Wed, Sep 28, 2016 at 10:08:21PM +0200, Marek Vasut wrote:
> On 09/28/2016 03:55 PM, Lucas Stach wrote:
> > Hi Marek,
> > 
> > Am Montag, den 26.09.2016, 15:01 +0200 schrieb Marek Vasut:
> >> Add new drm_fb_cma_setup_fence() helper function extracted from the
> >> imx-drm driver. This function checks if the plane has DMABUF attached
> >> to it and if so, sets up the fence on which the atomic helper can wait.
> >>
> >> Signed-off-by: Marek Vasut 
> >> Cc: Daniel Vetter 
> >> Cc: Lucas Stach 
> >> ---
> >>  drivers/gpu/drm/drm_fb_cma_helper.c | 26 ++
> >>  include/drm/drm_fb_cma_helper.h |  3 +++
> >>  2 files changed, 29 insertions(+)
> >>
> >> diff --git a/drivers/gpu/drm/drm_fb_cma_helper.c 
> >> b/drivers/gpu/drm/drm_fb_cma_helper.c
> >> index 1fd6eac..2441707 100644
> >> --- a/drivers/gpu/drm/drm_fb_cma_helper.c
> >> +++ b/drivers/gpu/drm/drm_fb_cma_helper.c
> >> @@ -23,8 +23,10 @@
> >>  #include 
> >>  #include 
> >>  #include 
> >> +#include 
> >>  #include 
> >>  #include 
> >> +#include 
> >>  
> >>  #define DEFAULT_FBDEFIO_DELAY_MS 50
> >>  
> >> @@ -265,6 +267,30 @@ struct drm_gem_cma_object 
> >> *drm_fb_cma_get_gem_obj(struct drm_framebuffer *fb,
> >>  }
> >>  EXPORT_SYMBOL_GPL(drm_fb_cma_get_gem_obj);
> >>  
> >> +/**
> >> + * drm_fb_cma_setup_fence() - Set up the fence for atomic helper to wait 
> >> on
> > 
> > I don't really like the naming of the helper. It's not setting up any
> > fence, it's either extracting it from the plane and/or attaching it to
> > the planestate, so I would have expected the name to include extract or
> > attach.

Imo for helpers that should be put into a specific vhook like this here,
it'd go with that vhooks name. So here drm_fb_cma_prepare_fb.

And then in the kerneldoc also mention where it should be put (both for
drivers using atomic helpers, and those using simple pipe helpers), e.g.
"This should be put into the prepare_fb hook of struct
_plane_helper_funcs."

Please run $ make htmldocs to make sure the docs look pretty and the
generated links are correct.
-Daniel

> > 
> >> + * @plane: Which plane
> >> + * @state: Plane state to check
> > 
> > s/check/attach fence to
> 
> Both fixed in V2, thanks.
> 
> >> + *
> >> + * If the plane fb has an dma-buf attached, fish out the exclusive
> >> + * fence for the atomic helper to wait on.
> >> + */
> >> +void drm_fb_cma_setup_fence(struct drm_plane *plane,
> >> +  struct drm_plane_state *state)
> >> +{
> >> +  struct dma_buf *dma_buf;
> >> +
> >> +  if ((plane->state->fb == state->fb) || !state->fb)
> >> +  return;
> >> +
> >> +  dma_buf = drm_fb_cma_get_gem_obj(state->fb, 0)->base.dma_buf;
> >> +  if (!dma_buf)
> >> +  return;
> >> +
> >> +  state->fence = reservation_object_get_excl_rcu(dma_buf->resv);
> >> +}
> >> +EXPORT_SYMBOL_GPL(drm_fb_cma_setup_fence);
> >> +
> >>  #ifdef CONFIG_DEBUG_FS
> >>  static void drm_fb_cma_describe(struct drm_framebuffer *fb, struct 
> >> seq_file *m)
> >>  {
> >> diff --git a/include/drm/drm_fb_cma_helper.h 
> >> b/include/drm/drm_fb_cma_helper.h
> >> index f313211..fc122d3 100644
> >> --- a/include/drm/drm_fb_cma_helper.h
> >> +++ b/include/drm/drm_fb_cma_helper.h
> >> @@ -41,6 +41,9 @@ struct drm_framebuffer *drm_fb_cma_create(struct 
> >> drm_device *dev,
> >>  struct drm_gem_cma_object *drm_fb_cma_get_gem_obj(struct drm_framebuffer 
> >> *fb,
> >>unsigned int plane);
> >>  
> >> +void drm_fb_cma_setup_fence(struct drm_plane *plane,
> >> +  struct drm_plane_state *state);
> >> +
> >>  #ifdef CONFIG_DEBUG_FS
> >>  struct seq_file;
> >>  
> > 
> > 
> 
> 
> -- 
> Best regards,
> Marek Vasut

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


[PATCH] drm: Document caveats around atomic event handling

2016-09-29 Thread Alex Deucher
On Thu, Sep 29, 2016 at 11:20 AM, Daniel Vetter  
wrote:
> It's not that obvious how a driver can all race the atomic commit with
> handling the completion event. And there's unfortunately a pile of
> drivers with rather bad event handling which misdirect people into the
> wrong direction.

Thanks for filling in these details.  A few spelling typos noted below.

>
> Try to remedy this by documenting everything better.
>
> Cc: Andrzej Hajda 
> Signed-off-by: Daniel Vetter 
> ---
>  drivers/gpu/drm/drm_irq.c | 32 +--
>  include/drm/drm_crtc.h| 56 
> ---
>  2 files changed, 73 insertions(+), 15 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
> index 10611a936059..8874b564ec76 100644
> --- a/drivers/gpu/drm/drm_irq.c
> +++ b/drivers/gpu/drm/drm_irq.c
> @@ -1008,6 +1008,31 @@ static void send_vblank_event(struct drm_device *dev,
>   * period. This helper function implements exactly the required vblank arming
>   * behaviour.
>   *
> + * NOTE: Drivers using this to send out the even in struct _crtc_state

event

> + * as part of an atomic commit must ensure that the next vblank happens at
> + * exactly the same time as the atomic commit is committed to the hardware. 
> This
> + * function itself does **not** protect again the next vblank interrupt 
> racing
> + * with either this function call or the atomic commit operation. A possible
> + * sequence could be:
> + *
> + * 1. Driver commits new hardware state into vblank-synchronized registes.

registers

> + * 2. A vblank happes, committing the hardware state. Also the corresponding

happens

> + *vblank interrupt is fired off and fully processed by the interrupt
> + *handler.
> + * 3. The atomic commit operation proceeds to call 
> drm_crtc_arm_vblank_event().
> + * 4. The event is only send out for the next vblank, which is wrong.
> + *
> + * An equivalent race can happen when the driver calls
> + * drm_crtc_arm_vblank_event() before writing out the new hardware state.
> + *
> + * The only way to make this work savely is to prevent the vblank from firing

safely

> + * (and the hardware from committig anything else) until the entire atomic

committing

> + * commit sequence has run to completion. If the hardware does not have such 
> a
> + * feature (e.g. using a "go" bit), then it is unsafe to use this functions.
> + * Instead drivers need to manually send out the event from their interrupt
> + * handler by calling drm_crtc_send_vblank_event() and make sure that 
> there's no
> + * possible race with the hardware committing the atomic update.
> + *
>   * Caller must hold event lock. Caller must also hold a vblank reference for
>   * the event @e, which will be dropped when the next vblank arrives.
>   */
> @@ -1030,8 +1055,11 @@ EXPORT_SYMBOL(drm_crtc_arm_vblank_event);
>   * @crtc: the source CRTC of the vblank event
>   * @e: the event to send
>   *
> - * Updates sequence # and timestamp on event, and sends it to userspace.
> - * Caller must hold event lock.
> + * Updates sequence # and timestamp on event for the most recently processed
> + * vblank, and sends it to userspace.  Caller must hold event lock.
> + *
> + * See drm_crtc_arm_vblank_event() for a helper which can be used in certain
> + * situation, especially to send out events for atomic commit operations.
>   */
>  void drm_crtc_send_vblank_event(struct drm_crtc *crtc,
> struct drm_pending_vblank_event *e)
> diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
> index f88f9a2d05c1..b381be639fd8 100644
> --- a/include/drm/drm_crtc.h
> +++ b/include/drm/drm_crtc.h
> @@ -109,8 +109,6 @@ struct drm_plane_helper_funcs;
>   * @ctm: Transformation matrix
>   * @gamma_lut: Lookup table for converting pixel data after the
>   * conversion matrix
> - * @event: optional pointer to a DRM event to signal upon completion of the
> - * state update
>   * @state: backpointer to global drm_atomic_state
>   *
>   * Note that the distinction between @enable and @active is rather subtile:
> @@ -159,6 +157,46 @@ struct drm_crtc_state {
> struct drm_property_blob *ctm;
> struct drm_property_blob *gamma_lut;
>
> +   /**
> +* @event:
> +*
> +* Optional pointer to a DRM event to signal upon completion of the
> +* state update. The driver must send out the event when the atomic
> +* commit operation completes. There are two cases:
> +*
> +*  - The event is for a CRTC which is being disabled through this
> +*atomic commit. In that case the event can be send out any time

sent

> +*after the hardware has stopped out scanning out the current

stopped scanning out

> +*framebuffers. It should contain the timestampe and counter for 
> the

timestamp

> +*last vblank before the display pipeline was shut off.
> +*
> +*  - For a 

[PATCH 2/2] drm/mediatek: clear IRQ status before enable OVL interrupt

2016-09-29 Thread Bibby Hsieh
To make sure that the first vblank IRQ after enabling
vblank isn't too short or immediate, we have to clear
the IRQ status before enable OVL interrupt.

Signed-off-by: Bibby Hsieh 
---
 drivers/gpu/drm/mediatek/mtk_disp_ovl.c |1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c 
b/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
index 019b7ca..f75c5b5 100644
--- a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
+++ b/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
@@ -80,6 +80,7 @@ static void mtk_ovl_enable_vblank(struct mtk_ddp_comp *comp,
 ddp_comp);

priv->crtc = crtc;
+   writel(0x0, comp->regs + DISP_REG_OVL_INTSTA);
writel_relaxed(OVL_FME_CPL_INT, comp->regs + DISP_REG_OVL_INTEN);
 }

-- 
1.7.9.5



[PATCH 1/2] drm/mediatek: set vblank_disable_allowed to true

2016-09-29 Thread Bibby Hsieh
MTK DRM driver didn't set the vblank_disable_allowed to
true, it cause that the irq_handler is called every
16.6 ms (every vblank) when the display didn't be updated.

Signed-off-by: Bibby Hsieh 
---
 drivers/gpu/drm/mediatek/mtk_drm_drv.c |1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/mediatek/mtk_drm_drv.c 
b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
index eebb7d8..941ec5f 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_drv.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
@@ -200,6 +200,7 @@ static int mtk_drm_kms_init(struct drm_device *drm)
if (ret < 0)
goto err_component_unbind;

+   drm->vblank_disable_allowed = true;
drm_kms_helper_poll_init(drm);
drm_mode_config_reset(drm);

-- 
1.7.9.5



[PATCH 0/2] fix issue: vblank interrupts are never disabled

2016-09-29 Thread Bibby Hsieh
Clean the interrupt status before enable interrupt
and set the vblank_disable_allowed to fix the issue.

Bibby Hsieh (2):
  drm/mediatek: set vblank_disable_allowed to true
  drm/mediatek: clear IRQ status before enable OVL interrupt

 drivers/gpu/drm/mediatek/mtk_disp_ovl.c |1 +
 drivers/gpu/drm/mediatek/mtk_drm_drv.c  |1 +
 2 files changed, 2 insertions(+)

-- 
1.7.9.5



[PATCH] drm: simple_kms_helper: Handle the vblank events

2016-09-29 Thread Daniel Vetter
On Tue, Sep 27, 2016 at 02:20:49PM +0200, Marek Vasut wrote:
> On 09/27/2016 02:16 PM, Noralf Trønnes wrote:
> > 
> > Den 27.09.2016 12:29, skrev Marek Vasut:
> >> On 09/27/2016 09:49 AM, Daniel Vetter wrote:
> >>> On Mon, Sep 26, 2016 at 2:59 PM, Marek Vasut  wrote:
>  On 09/26/2016 11:41 AM, Marek Vasut wrote:
> > On 09/25/2016 11:00 PM, Daniel Vetter wrote:
> >> On Sun, Sep 25, 2016 at 09:41:58PM +0200, Marek Vasut wrote:
> >>> Handle the vblank events in the simple_kms_helper driver, otherwise
> >>> the drm_atomic_helper flip_done event never happens.
> >>>
> >>> Signed-off-by: Marek Vasut 
> >>> Cc: Noralf Trønnes 
> >>> Cc: Daniel Vetter 
> >>> Cc: David Airlie 
> >>> ---
> >>>   drivers/gpu/drm/drm_simple_kms_helper.c | 18 ++
> >>>   1 file changed, 18 insertions(+)
> >>>
> >>> diff --git a/drivers/gpu/drm/drm_simple_kms_helper.c
> >>> b/drivers/gpu/drm/drm_simple_kms_helper.c
> >>> index 7b6d26e..3345b40 100644
> >>> --- a/drivers/gpu/drm/drm_simple_kms_helper.c
> >>> +++ b/drivers/gpu/drm/drm_simple_kms_helper.c
> >>> @@ -34,6 +34,23 @@ static const struct drm_encoder_funcs
> >>> drm_simple_kms_encoder_funcs = {
> >>>  .destroy = drm_encoder_cleanup,
> >>>   };
> >>>
> >>> +static void drm_simple_kms_crtc_begin(struct drm_crtc *crtc,
> >>> + struct drm_crtc_state *state)
> >>> +{
> >>> +   struct drm_pending_vblank_event *event = crtc->state->event;
> >>> +
> >>> +   if (event) {
> >>> +   crtc->state->event = NULL;
> >>> +
> >>> +   spin_lock_irq(>dev->event_lock);
> >>> +   if (drm_crtc_vblank_get(crtc) == 0)
> >>> +   drm_crtc_arm_vblank_event(crtc, event);
> >>> +   else
> >>> +   drm_crtc_send_vblank_event(crtc, event);
> >>> +   spin_unlock_irq(>dev->event_lock);
> >>> +   }
> >>> +}
> >> This should be done by drivers, in the ->update hook. At least if
> >> we want
> >> to pretend that it's semi-accurate and not racy (which the above is).
> >> -Daniel
> > Got it and wrapped into mxsfb, thanks.
>  Hrm, while this works most of the time, I managed to get a page_flip
>  timeout when terminating the kmscube OpenGL demo (see below). I'm not
>  getting this splat with this patch applied. Any idea what this could
>  mean ?
> >>> Are you on latest drm-next?
> >> No, I'm on next/master from 20160927 . Is this the right tree?
> >> https://cgit.freedesktop.org/~airlied/linux/log/?h=drm-next
> >>
> >>> There was a bug fixed for 4.9 which
> >>> resulted in the primary plane not always being added to the state,
> >>> which means that the ->update hook would not get called when the plane
> >>> is getting disabled.
> >> Ah, which patch ?
> > 
> > I believe this is the one:
> > 
> > drm/simple-helpers: Always add planes to the state update
> > https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/commit/drivers/gpu/drm/drm_simple_kms_helper.c?id=6dcf0de7ef10244b17442f47956a1d9fabe2abe1
> 
> Thanks. I have that one in my tree already.

Can you pls check that for the case where you hit the WARN the simple
pipe's ->update function is called, and that you're indeed handling the
event in all cases?
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch


[Intel-gfx] [PATCH] drm: Add frame CRC debugfs files only for drivers that have CRTC

2016-09-29 Thread Emil Velikov
On 29 September 2016 at 09:59, Daniel Vetter  wrote:
> On Thu, Sep 29, 2016 at 10:25:09AM +0200, Tomeu Vizoso wrote:
>> On 29 September 2016 at 05:42, Dhinakaran Pandiyan
>>  wrote:
>> > vgem does not do modeset, looping through non-existent CRTC's while
>> > registering drm_minor in
>> >
>> > 'commit 48c787899882 ("drm: Add API for capturing frame CRCs")'
>> >
>> > caused kernel oops. So, let's add CRC debugfs files
>> > only for those drivers that do modeset.
>> >
>> > Signed-off-by: Dhinakaran Pandiyan 
>> > Cc: Tomeu Vizoso 
>> > Cc: Daniel Vetter 
>> > Cc: Emil Velikov 
>>
>> Reviewed-by: Tomeu Vizoso 
>
> Applied to drm-misc, thanks.
>
>> But I would prefer if drm_for_each_crtc was safe to call in any device
>> regardless of the features that its driver supports.
>
> Imo explicit checks are much better, especially in userspace-facing code
> like this (well it's debugfs and not an ioctl, but still). Unrelated rant:
> I think we should throw away the concept of having per-minor debugfs (with
> a symlink for backwards compat). Then we could have put the crc code into
> drm_modeset_register_all, and there would not have been any bug.
Fwiw I agree that explicit checks are better.

I keep forgetting that we create a card# node even if the device does not
feature DRIVER_MODESET. IMHO if we drop that assumption, we can simplify
core DRM and/or some drivers. If userspace is not new enough to know about
render nodes it's simply not capable of using new drivers/devices properly
and there will be no regressions afaict. Not to mention it the dubious auth
requirement even if the device is render only. Alternatively if we can have
add a comment why the card# is required that'll be greatly appreciated.

That said, the patch is a good fix and is
Reviewed-by: Emil Velikov 

Regards,
Emil

P.S. Some of the links on your blog have gone crazy [2]

[1] https://dri.freedesktop.org/docs/drm/gpu/drm-uapi.html#render-nodes
[2] http://blog.ffwll.ch/2016/01/better-markup-for-kernel-gpu-docbook.html
-- next part --
An HTML attachment was scrubbed...
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160929/de967404/attachment-0001.html>


[PATCH] drm/sti: mark symbols static where possible

2016-09-29 Thread Daniel Vetter
On Wed, Sep 28, 2016 at 09:27:13AM +0200, Vincent ABRIOU wrote:
> Yes true, patch from Ville
> https://lists.freedesktop.org/archives/dri-devel/2016-September/118631.html;
> already fix patches sent by Baoyou.

Yeah, I resolved those conflicts by simply taking the code from the sti
tree. I'll send a pull request for drm-misc with that merge to Dave this
week still because I've totally forgotten about Tomeu's work.
-Daniel

> 
> Vincent
> 
> On 09/27/2016 09:07 PM, Benjamin Gaignard wrote:
> > I think that create conflicts with what is already in Vincent pull
> > request where we have fix the problem reported by coccicheck and
> > sparse.
> >
> > https://lists.freedesktop.org/archives/dri-devel/2016-September/118892.html
> >
> > Benjamin
> >
> > 2016-09-27 18:35 GMT+02:00 Sean Paul :
> >> On Sun, Sep 25, 2016 at 3:57 AM, Baoyou Xie  
> >> wrote:
> >>> We get 6 warnings when building kernel with W=1:
> >>> drivers/gpu/drm/sti/sti_mixer.c:361:6: warning: no previous prototype for 
> >>> 'sti_mixer_set_matrix' [-Wmissing-prototypes]
> >>> drivers/gpu/drm/sti/sti_dvo.c:109:5: warning: no previous prototype for 
> >>> 'dvo_awg_generate_code' [-Wmissing-prototypes]
> >>> drivers/gpu/drm/sti/sti_gdp.c:476:5: warning: no previous prototype for 
> >>> 'sti_gdp_field_cb' [-Wmissing-prototypes]
> >>> drivers/gpu/drm/sti/sti_hqvdp.c:786:5: warning: no previous prototype for 
> >>> 'sti_hqvdp_vtg_cb' [-Wmissing-prototypes]
> >>> drivers/gpu/drm/sti/sti_hqvdp.c:1292:5: warning: no previous prototype 
> >>> for 'sti_hqvdp_bind' [-Wmissing-prototypes]
> >>> drivers/gpu/drm/sti/sti_drv.c:143:6: warning: no previous prototype for 
> >>> 'sti_drm_dbg_cleanup' [-Wmissing-prototypes]
> >>>
> >>> In fact, these functions are only used in the file in which they are
> >>> declared and don't need a declaration, but can be made static.
> >>> So this patch marks these functions with 'static'.
> >>>
> >>> Signed-off-by: Baoyou Xie 
> >>
> >> Applied to -misc, thanks.
> >>
> >> Sean
> >>
> >>> ---
> >>>  drivers/gpu/drm/sti/sti_drv.c   | 2 +-
> >>>  drivers/gpu/drm/sti/sti_dvo.c   | 3 ++-
> >>>  drivers/gpu/drm/sti/sti_gdp.c   | 2 +-
> >>>  drivers/gpu/drm/sti/sti_hqvdp.c | 5 +++--
> >>>  drivers/gpu/drm/sti/sti_mixer.c | 2 +-
> >>>  5 files changed, 8 insertions(+), 6 deletions(-)
> >>>
> >>> diff --git a/drivers/gpu/drm/sti/sti_drv.c b/drivers/gpu/drm/sti/sti_drv.c
> >>> index 7cd3804..e6f0706 100644
> >>> --- a/drivers/gpu/drm/sti/sti_drv.c
> >>> +++ b/drivers/gpu/drm/sti/sti_drv.c
> >>> @@ -140,7 +140,7 @@ static int sti_drm_dbg_init(struct drm_minor *minor)
> >>> return ret;
> >>>  }
> >>>
> >>> -void sti_drm_dbg_cleanup(struct drm_minor *minor)
> >>> +static void sti_drm_dbg_cleanup(struct drm_minor *minor)
> >>>  {
> >>> drm_debugfs_remove_files(sti_drm_dbg_list,
> >>>  ARRAY_SIZE(sti_drm_dbg_list), minor);
> >>> diff --git a/drivers/gpu/drm/sti/sti_dvo.c b/drivers/gpu/drm/sti/sti_dvo.c
> >>> index 00881eb..4545ad0 100644
> >>> --- a/drivers/gpu/drm/sti/sti_dvo.c
> >>> +++ b/drivers/gpu/drm/sti/sti_dvo.c
> >>> @@ -106,7 +106,8 @@ struct sti_dvo_connector {
> >>> container_of(x, struct sti_dvo_connector, drm_connector)
> >>>
> >>>  #define BLANKING_LEVEL 16
> >>> -int dvo_awg_generate_code(struct sti_dvo *dvo, u8 *ram_size, u32 
> >>> *ram_code)
> >>> +static int
> >>> +dvo_awg_generate_code(struct sti_dvo *dvo, u8 *ram_size, u32 *ram_code)
> >>>  {
> >>> struct drm_display_mode *mode = >mode;
> >>> struct dvo_config *config = dvo->config;
> >>> diff --git a/drivers/gpu/drm/sti/sti_gdp.c b/drivers/gpu/drm/sti/sti_gdp.c
> >>> index b8d942c..4648d1b 100644
> >>> --- a/drivers/gpu/drm/sti/sti_gdp.c
> >>> +++ b/drivers/gpu/drm/sti/sti_gdp.c
> >>> @@ -473,7 +473,7 @@ static void sti_gdp_disable(struct sti_gdp *gdp)
> >>>   * RETURNS:
> >>>   * 0 on success.
> >>>   */
> >>> -int sti_gdp_field_cb(struct notifier_block *nb,
> >>> +static int sti_gdp_field_cb(struct notifier_block *nb,
> >>> unsigned long event, void *data)
> >>>  {
> >>> struct sti_gdp *gdp = container_of(nb, struct sti_gdp, 
> >>> vtg_field_nb);
> >>> diff --git a/drivers/gpu/drm/sti/sti_hqvdp.c 
> >>> b/drivers/gpu/drm/sti/sti_hqvdp.c
> >>> index b5ee783..7f0dea8 100644
> >>> --- a/drivers/gpu/drm/sti/sti_hqvdp.c
> >>> +++ b/drivers/gpu/drm/sti/sti_hqvdp.c
> >>> @@ -783,7 +783,8 @@ static void sti_hqvdp_disable(struct sti_hqvdp *hqvdp)
> >>>   * RETURNS:
> >>>   * 0 on success.
> >>>   */
> >>> -int sti_hqvdp_vtg_cb(struct notifier_block *nb, unsigned long evt, void 
> >>> *data)
> >>> +static int
> >>> +sti_hqvdp_vtg_cb(struct notifier_block *nb, unsigned long evt, void 
> >>> *data)
> >>>  {
> >>> struct sti_hqvdp *hqvdp = container_of(nb, struct sti_hqvdp, 
> >>> vtg_nb);
> >>> int btm_cmd_offset, top_cmd_offest;
> >>> @@ -1289,7 +1290,7 @@ static struct drm_plane *sti_hqvdp_create(struct 
> >>> drm_device *drm_dev,
> >>> return >plane.drm_plane;

[PATCH] drm/mediatek: fix a typo

2016-09-29 Thread Bibby Hsieh
Fix the typo: OD_RELAYMODE->OD_CFG

Signed-off-by: Bibby Hsieh 
---
 drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c 
b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
index df33b3c..aa5f20f 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
@@ -123,7 +123,7 @@ static void mtk_od_config(struct mtk_ddp_comp *comp, 
unsigned int w,
  unsigned int bpc)
 {
writel(w << 16 | h, comp->regs + DISP_OD_SIZE);
-   writel(OD_RELAYMODE, comp->regs + OD_RELAYMODE);
+   writel(OD_RELAYMODE, comp->regs + OD_CFG);
mtk_dither_set(comp, bpc, DISP_OD_CFG);
 }

-- 
1.7.9.5



[PATCH] drm: Convert prime dma-buf <-> handle to rbtree

2016-09-29 Thread Daniel Vetter
On Tue, Sep 27, 2016 at 12:18:13PM -0400, Sean Paul wrote:
> On Tue, Sep 27, 2016 at 2:36 AM, David Herrmann  
> wrote:
> > Hi Chris
> >
> > On Mon, Sep 26, 2016 at 10:44 PM, Chris Wilson  > chris-wilson.co.uk> wrote:
> >> Currently we use a linear walk to lookup a handle and return a dma-buf,
> >> and vice versa. A long overdue TODO task is to convert that to a
> >> hashtable. Since the initial implementation of dma-buf/prime, we now
> >> have resizeable hashtables we can use (and now a future task is to RCU
> >> enable the lookup!). However, this patch opts to use an rbtree instead
> >> to provide O(lgN) lookups (and insertion, deletion). rbtrees were chosen
> >> over using the RCU backed resizable hashtable to firstly avoid the
> >> reallocations (rbtrees can be embedded entirely within the parent
> >> struct) and to favour simpler code with predictable worst case
> >> behaviour. In simple testing, the difference between using the constant
> >> lookup and insertion of the rhashtable and the rbtree was less than 10%
> >> of the wall time (igt/benchmarks/prime_lookup) - both are dramatic
> >> improvements over the existing linear lists.
> >>
> >> v2: Favour rbtree over rhashtable
> >>
> >> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=94631
> >> Signed-off-by: Chris Wilson 
> >> Cc: Sean Paul 
> >> Cc: David Herrmann 
> >> ---
> >>  drivers/gpu/drm/drm_prime.c | 85 
> >> +++--
> >>  include/drm/drmP.h  |  5 +--
> >>  2 files changed, 77 insertions(+), 13 deletions(-)
> >
> > Thanks for doing the benchmark and rewriting it with rb-trees. I think
> > the lack of error-handling is a big plus here. Anyway, this is:
> >
> > Reviewed-by: David Herrmann 
> 
> 
> Agreed, it's also nice be able to keep the WARN_ON in
> drm_prime_destroy_file_private
> 
> Reviewed-by: Sean Paul 

Applied to drm-misc, thanks.
-Daniel

> 
> >
> > Your tree-traversals are a bit inconsistent in how you order your
> > iterator against the element to lookup in your conditions, but.. meh.
> > A big WARN_ON on conflicts might not hurt either. But looks all good.
> >
> > Thanks
> > David
> >
> >> diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c
> >> index 780589b420a4..57201d68cf61 100644
> >> --- a/drivers/gpu/drm/drm_prime.c
> >> +++ b/drivers/gpu/drm/drm_prime.c
> >> @@ -28,6 +28,7 @@
> >>
> >>  #include 
> >>  #include 
> >> +#include 
> >>  #include 
> >>  #include 
> >>
> >> @@ -61,9 +62,11 @@
> >>   */
> >>
> >>  struct drm_prime_member {
> >> -   struct list_head entry;
> >> struct dma_buf *dma_buf;
> >> uint32_t handle;
> >> +
> >> +   struct rb_node dmabuf_rb;
> >> +   struct rb_node handle_rb;
> >>  };
> >>
> >>  struct drm_prime_attachment {
> >> @@ -75,6 +78,7 @@ static int drm_prime_add_buf_handle(struct 
> >> drm_prime_file_private *prime_fpriv,
> >> struct dma_buf *dma_buf, uint32_t 
> >> handle)
> >>  {
> >> struct drm_prime_member *member;
> >> +   struct rb_node **p, *rb;
> >>
> >> member = kmalloc(sizeof(*member), GFP_KERNEL);
> >> if (!member)
> >> @@ -83,18 +87,56 @@ static int drm_prime_add_buf_handle(struct 
> >> drm_prime_file_private *prime_fpriv,
> >> get_dma_buf(dma_buf);
> >> member->dma_buf = dma_buf;
> >> member->handle = handle;
> >> -   list_add(>entry, _fpriv->head);
> >> +
> >> +   rb = NULL;
> >> +   p = _fpriv->dmabufs.rb_node;
> >> +   while (*p) {
> >> +   struct drm_prime_member *pos;
> >> +
> >> +   rb = *p;
> >> +   pos = rb_entry(rb, struct drm_prime_member, dmabuf_rb);
> >> +   if (dma_buf > pos->dma_buf)
> >> +   p = >rb_right;
> >> +   else
> >> +   p = >rb_left;
> >> +   }
> >> +   rb_link_node(>dmabuf_rb, rb, p);
> >> +   rb_insert_color(>dmabuf_rb, _fpriv->dmabufs);
> >> +
> >> +   rb = NULL;
> >> +   p = _fpriv->handles.rb_node;
> >> +   while (*p) {
> >> +   struct drm_prime_member *pos;
> >> +
> >> +   rb = *p;
> >> +   pos = rb_entry(rb, struct drm_prime_member, handle_rb);
> >> +   if (handle > pos->handle)
> >> +   p = >rb_right;
> >> +   else
> >> +   p = >rb_left;
> >> +   }
> >> +   rb_link_node(>handle_rb, rb, p);
> >> +   rb_insert_color(>handle_rb, _fpriv->handles);
> >> +
> >> return 0;
> >>  }
> >>
> >>  static struct dma_buf *drm_prime_lookup_buf_by_handle(struct 
> >> drm_prime_file_private *prime_fpriv,
> >>   uint32_t handle)
> >>  {
> >> -   struct drm_prime_member *member;
> >> +   struct rb_node *rb;
> >> +
> >> +   rb = prime_fpriv->handles.rb_node;
> >> +   while (rb) {
> >> +   struct drm_prime_member *member;
> >>
> >> -   

[PATCH 10/10] drm/i915: Account for sink max TMDS clock when checking the port clock

2016-09-29 Thread Ander Conselvan De Oliveira
On Wed, 2016-09-28 at 16:51 +0300, ville.syrjala at linux.intel.com wrote:
> From: Ville Syrjälä 
> 
> It's perfectly legal for the sink to support 12bpc only for
> some lower resolution modes, while the higher resolution modes
> can only be used with 8bpc. So let's take the sink's max TMDS clock
> into account before we go and decide that a particular mode can
> be used with 12bpc.

Reviewed-by: Ander Conselvan de Oliveira 

> 
> Signed-off-by: Ville Syrjälä 
> ---
>  drivers/gpu/drm/i915/intel_hdmi.c | 9 -
>  1 file changed, 8 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_hdmi.c
> b/drivers/gpu/drm/i915/intel_hdmi.c
> index 8d49800064df..8d46f5836746 100644
> --- a/drivers/gpu/drm/i915/intel_hdmi.c
> +++ b/drivers/gpu/drm/i915/intel_hdmi.c
> @@ -1220,10 +1220,17 @@ static int hdmi_port_clock_limit(struct intel_hdmi
> *hdmi,
>  int max_tmds_clock = intel_hdmi_source_max_tmds_clock(to_i915(dev));
>  
>  if (respect_downstream_limits) {
> + struct intel_connector *connector = hdmi->attached_connector;
> + const struct drm_display_info *info = 
> >base.display_info;
> +
>  if (hdmi->dp_dual_mode.max_tmds_clock)
>  max_tmds_clock = min(max_tmds_clock,
>       hdmi-
> >dp_dual_mode.max_tmds_clock);
> - if (!hdmi->has_hdmi_sink)
> +
> + if (info->max_tmds_clock)
> + max_tmds_clock = min(max_tmds_clock,
> +      info->max_tmds_clock);
> + else if (!hdmi->has_hdmi_sink)
>  max_tmds_clock = min(max_tmds_clock, 165000);
>  }
>  


[PATCH 09/10] drm/i915: Replace a bunch of connector->base.display_info with a local variable

2016-09-29 Thread Ander Conselvan De Oliveira
On Wed, 2016-09-28 at 16:51 +0300, ville.syrjala at linux.intel.com wrote:
> From: Ville Syrjälä 
> 
> Reduce the eyesore with a local variable.
> 
> Signed-off-by: Ville Syrjälä 

Reviewed-by: Ander Conselvan de Oliveira 

> ---
>  drivers/gpu/drm/i915/intel_display.c | 14 +++---
>  1 file changed, 7 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index 8e464e089794..34ca03e621ba 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -12657,22 +12657,22 @@ static void
>  connected_sink_compute_bpp(struct intel_connector *connector,
>     struct intel_crtc_state *pipe_config)
>  {
> + const struct drm_display_info *info = >base.display_info;
>  int bpp = pipe_config->pipe_bpp;
>  
>  DRM_DEBUG_KMS("[CONNECTOR:%d:%s] checking for sink bpp constrains\n",
> - connector->base.base.id,
> - connector->base.name);
> +       connector->base.base.id,
> +       connector->base.name);
>  
>  /* Don't use an invalid EDID bpc value */
> - if (connector->base.display_info.bpc &&
> -     connector->base.display_info.bpc * 3 < bpp) {
> + if (info->bpc != 0 && info->bpc * 3 < bpp) {
>  DRM_DEBUG_KMS("clamping display bpp (was %d) to EDID reported
> max of %d\n",
> -       bpp, connector->base.display_info.bpc*3);
> - pipe_config->pipe_bpp = connector->base.display_info.bpc*3;
> +       bpp, info->bpc * 3);
> + pipe_config->pipe_bpp = info->bpc * 3;
>  }
>  
>  /* Clamp bpp to 8 on screens without EDID 1.4 */
> - if (connector->base.display_info.bpc == 0 && bpp > 24) {
> + if (info->bpc == 0 && bpp > 24) {
>  DRM_DEBUG_KMS("clamping display bpp (was %d) to default limit
> of 24\n",
>        bpp);
>  pipe_config->pipe_bpp = 24;


[PATCH v5 3/3] drm/mediatek: modify the factor to make the pll_rate set in the 1G-2G range

2016-09-29 Thread Bibby Hsieh
From: Junzhi Zhao 

Currently, the code sets the "pll" to the desired multiple
of the pixel clock manully(4*3m 8*3,etc).  The valid range
of the pll is 1G-2G, however, when the pixel clock is bigger
than 167MHz,  the "pll" will be set to a invalid value( > 2G),
then the "pll" will be 2GHz, thus the pixel clock will be in
correct. Change the factor to make the "pll" be set in the
(1G, 2G) range.

Signed-off-by: Junzhi Zhao 
Signed-off-by: Bibby Hsieh 
---
 drivers/gpu/drm/mediatek/mtk_dpi.c |9 +++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/mediatek/mtk_dpi.c 
b/drivers/gpu/drm/mediatek/mtk_dpi.c
index 0186e50..90fb831 100644
--- a/drivers/gpu/drm/mediatek/mtk_dpi.c
+++ b/drivers/gpu/drm/mediatek/mtk_dpi.c
@@ -432,11 +432,16 @@ static int mtk_dpi_set_display_mode(struct mtk_dpi *dpi,
unsigned long pll_rate;
unsigned int factor;

+   /* let pll_rate can fix the valid range of tvdpll (1G~2GHz) */
pix_rate = 1000UL * mode->clock;
-   if (mode->clock <= 74000)
+   if (mode->clock <= 27000)
+   factor = 16 * 3;
+   else if (mode->clock <= 84000)
factor = 8 * 3;
-   else
+   else if (mode->clock <= 167000)
factor = 4 * 3;
+   else
+   factor = 2 * 3;
pll_rate = pix_rate * factor;

dev_dbg(dpi->dev, "Want PLL %lu Hz, pixel clock %lu Hz\n",
-- 
1.7.9.5



[PATCH v5 2/3] drm/mediatek: enhance the HDMI driving current

2016-09-29 Thread Bibby Hsieh
From: Junzhi Zhao 

In order to improve 4K resolution performance,
we have to enhance the HDMI driving current
when clock rate is greater than 165MHz.

Signed-off-by: Junzhi Zhao 
Signed-off-by: Bibby Hsieh 
---
 drivers/gpu/drm/mediatek/mtk_mt8173_hdmi_phy.c |   42 +---
 1 file changed, 30 insertions(+), 12 deletions(-)

diff --git a/drivers/gpu/drm/mediatek/mtk_mt8173_hdmi_phy.c 
b/drivers/gpu/drm/mediatek/mtk_mt8173_hdmi_phy.c
index 8a24754..51cb9cf 100644
--- a/drivers/gpu/drm/mediatek/mtk_mt8173_hdmi_phy.c
+++ b/drivers/gpu/drm/mediatek/mtk_mt8173_hdmi_phy.c
@@ -265,6 +265,9 @@ static int mtk_hdmi_pll_set_rate(struct clk_hw *hw, 
unsigned long rate,
struct mtk_hdmi_phy *hdmi_phy = to_mtk_hdmi_phy(hw);
unsigned int pre_div;
unsigned int div;
+   unsigned int pre_ibias;
+   unsigned int hdmi_ibias;
+   unsigned int imp_en;

dev_dbg(hdmi_phy->dev, "%s: %lu Hz, parent: %lu Hz\n", __func__,
rate, parent_rate);
@@ -298,18 +301,31 @@ static int mtk_hdmi_pll_set_rate(struct clk_hw *hw, 
unsigned long rate,
  (0x1 << PLL_BR_SHIFT),
  RG_HDMITX_PLL_BP | RG_HDMITX_PLL_BC |
  RG_HDMITX_PLL_BR);
-   mtk_hdmi_phy_clear_bits(hdmi_phy, HDMI_CON3, RG_HDMITX_PRD_IMP_EN);
+   if (rate < 16500) {
+   mtk_hdmi_phy_clear_bits(hdmi_phy, HDMI_CON3,
+   RG_HDMITX_PRD_IMP_EN);
+   pre_ibias = 0x3;
+   imp_en = 0x0;
+   hdmi_ibias = hdmi_phy->ibias;
+   } else {
+   mtk_hdmi_phy_set_bits(hdmi_phy, HDMI_CON3,
+ RG_HDMITX_PRD_IMP_EN);
+   pre_ibias = 0x6;
+   imp_en = 0xf;
+   hdmi_ibias = hdmi_phy->ibias_up;
+   }
mtk_hdmi_phy_mask(hdmi_phy, HDMI_CON4,
- (0x3 << PRD_IBIAS_CLK_SHIFT) |
- (0x3 << PRD_IBIAS_D2_SHIFT) |
- (0x3 << PRD_IBIAS_D1_SHIFT) |
- (0x3 << PRD_IBIAS_D0_SHIFT),
+ (pre_ibias << PRD_IBIAS_CLK_SHIFT) |
+ (pre_ibias << PRD_IBIAS_D2_SHIFT) |
+ (pre_ibias << PRD_IBIAS_D1_SHIFT) |
+ (pre_ibias << PRD_IBIAS_D0_SHIFT),
  RG_HDMITX_PRD_IBIAS_CLK |
  RG_HDMITX_PRD_IBIAS_D2 |
  RG_HDMITX_PRD_IBIAS_D1 |
  RG_HDMITX_PRD_IBIAS_D0);
mtk_hdmi_phy_mask(hdmi_phy, HDMI_CON3,
- (0x0 << DRV_IMP_EN_SHIFT), RG_HDMITX_DRV_IMP_EN);
+ (imp_en << DRV_IMP_EN_SHIFT),
+ RG_HDMITX_DRV_IMP_EN);
mtk_hdmi_phy_mask(hdmi_phy, HDMI_CON6,
  (hdmi_phy->drv_imp_clk << DRV_IMP_CLK_SHIFT) |
  (hdmi_phy->drv_imp_d2 << DRV_IMP_D2_SHIFT) |
@@ -318,12 +334,14 @@ static int mtk_hdmi_pll_set_rate(struct clk_hw *hw, 
unsigned long rate,
  RG_HDMITX_DRV_IMP_CLK | RG_HDMITX_DRV_IMP_D2 |
  RG_HDMITX_DRV_IMP_D1 | RG_HDMITX_DRV_IMP_D0);
mtk_hdmi_phy_mask(hdmi_phy, HDMI_CON5,
- (hdmi_phy->ibias << DRV_IBIAS_CLK_SHIFT) |
- (hdmi_phy->ibias << DRV_IBIAS_D2_SHIFT) |
- (hdmi_phy->ibias << DRV_IBIAS_D1_SHIFT) |
- (hdmi_phy->ibias << DRV_IBIAS_D0_SHIFT),
- RG_HDMITX_DRV_IBIAS_CLK | RG_HDMITX_DRV_IBIAS_D2 |
- RG_HDMITX_DRV_IBIAS_D1 | RG_HDMITX_DRV_IBIAS_D0);
+ (hdmi_ibias << DRV_IBIAS_CLK_SHIFT) |
+ (hdmi_ibias << DRV_IBIAS_D2_SHIFT) |
+ (hdmi_ibias << DRV_IBIAS_D1_SHIFT) |
+ (hdmi_ibias << DRV_IBIAS_D0_SHIFT),
+ RG_HDMITX_DRV_IBIAS_CLK |
+ RG_HDMITX_DRV_IBIAS_D2 |
+ RG_HDMITX_DRV_IBIAS_D1 |
+ RG_HDMITX_DRV_IBIAS_D0);
return 0;
 }

-- 
1.7.9.5



[PATCH v5 1/3] drm/mediatek: do mtk_hdmi_send_infoframe after HDMI clock enable

2016-09-29 Thread Bibby Hsieh
From: Junzhi Zhao 

The mtk_hdmi_send_infoframe have to
be run after PLL and PIXEL clock of HDMI enable.
Make sure that HDMI inforframes can be sent
successfully.

Signed-off-by: Junzhi Zhao 
Signed-off-by: Bibby Hsieh 
---
 drivers/gpu/drm/mediatek/mtk_hdmi.c |   17 +++--
 1 file changed, 11 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/mediatek/mtk_hdmi.c 
b/drivers/gpu/drm/mediatek/mtk_hdmi.c
index 334562d..875b045 100644
--- a/drivers/gpu/drm/mediatek/mtk_hdmi.c
+++ b/drivers/gpu/drm/mediatek/mtk_hdmi.c
@@ -1133,12 +1133,6 @@ static int mtk_hdmi_output_set_display_mode(struct 
mtk_hdmi *hdmi,
phy_power_on(hdmi->phy);
mtk_hdmi_aud_output_config(hdmi, mode);

-   mtk_hdmi_setup_audio_infoframe(hdmi);
-   mtk_hdmi_setup_avi_infoframe(hdmi, mode);
-   mtk_hdmi_setup_spd_infoframe(hdmi, "mediatek", "On-chip HDMI");
-   if (mode->flags & DRM_MODE_FLAG_3D_MASK)
-   mtk_hdmi_setup_vendor_specific_infoframe(hdmi, mode);
-
mtk_hdmi_hw_vid_black(hdmi, false);
mtk_hdmi_hw_aud_unmute(hdmi);
mtk_hdmi_hw_send_av_unmute(hdmi);
@@ -1401,6 +1395,16 @@ static void mtk_hdmi_bridge_pre_enable(struct drm_bridge 
*bridge)
hdmi->powered = true;
 }

+static void mtk_hdmi_send_infoframe(struct mtk_hdmi *hdmi,
+   struct drm_display_mode *mode)
+{
+   mtk_hdmi_setup_audio_infoframe(hdmi);
+   mtk_hdmi_setup_avi_infoframe(hdmi, mode);
+   mtk_hdmi_setup_spd_infoframe(hdmi, "mediatek", "On-chip HDMI");
+   if (mode->flags & DRM_MODE_FLAG_3D_MASK)
+   mtk_hdmi_setup_vendor_specific_infoframe(hdmi, mode);
+}
+
 static void mtk_hdmi_bridge_enable(struct drm_bridge *bridge)
 {
struct mtk_hdmi *hdmi = hdmi_ctx_from_bridge(bridge);
@@ -1409,6 +1413,7 @@ static void mtk_hdmi_bridge_enable(struct drm_bridge 
*bridge)
clk_prepare_enable(hdmi->clk[MTK_HDMI_CLK_HDMI_PLL]);
clk_prepare_enable(hdmi->clk[MTK_HDMI_CLK_HDMI_PIXEL]);
phy_power_on(hdmi->phy);
+   mtk_hdmi_send_infoframe(hdmi, >mode);

hdmi->enabled = true;
 }
-- 
1.7.9.5



[PATCH v5 0/3] MT8173 HDMI 4K support

2016-09-29 Thread Bibby Hsieh
This is MT8173 HDMI 4K support PATCH v5, based on 4.8-rc1.

In order to support HDMI 4K on MT8173,
we have to make some modifications.
1) Make sure that mtk_hdmi_send_infoframe is sent successfully.
2) Enhance the HDMI driving current to improve performance.
3) Make sure that pixel clock is 297MHz when resolution is 4K.

Changes since v4:
 - Update commit message and patch title.

Changes since v3:
 - Rebase to 4.8-rc1.
 - The valid range of tvdpll is 1G to 2G Hz, so, we Change the
   if statement of mode->clock to fit that and add a comment.

Changes since v2:
 - Remove the change about preparation for MT2701 support.

Changes since v1:
 - According to the suggestion from philipp, We use the new
   dpi0_sel rate set method.
 - calls clk_set_rate to set the dpi0_sel according to the
   pixel clock.
 - Remove the direct access to all the intermediate clock part.
 - Remove the intermediate tvdpll_d* clocks in dts.
 - According to suggestion from CK, we rename the clock parse
   function and remove it from mtk_dpi_conf struct.
 - Merges the hdmi Pll set rate for pixel clock greater than
   165MHz and smaller parts.

The PATCH depends on the following patch:
https://patchwork.kernel.org/patch/9262575/
(arm64: dts: mt8173: add mmsel clocks for 4K support)

Junzhi Zhao (3):
  drm/mediatek: do mtk_hdmi_send_infoframe after HDMI clock enable
  drm/mediatek: enhance the HDMI driving current
  drm/mediatek: modify the factor to make the pll_rate set in the 1G-2G
range

 drivers/gpu/drm/mediatek/mtk_dpi.c |9 +++--
 drivers/gpu/drm/mediatek/mtk_hdmi.c|   17 ++
 drivers/gpu/drm/mediatek/mtk_mt8173_hdmi_phy.c |   42 +---
 3 files changed, 48 insertions(+), 20 deletions(-)

-- 
1.7.9.5



[Intel-gfx] [PATCH] drm: Restore lost drm_framebuffer_unreference in drm_mode_page_flip_ioctl

2016-09-29 Thread Daniel Vetter
On Wed, Sep 28, 2016 at 11:25:00PM +0100, Chris Wilson wrote:
> Commit 43968d7b806d ("drm: Extract drm_plane.[hc]") was not the simple
> cut'n'paste we presumed, somehow it introduced a leak of the page flip
> target's framebuffer.
> 
> Fixes: 43968d7b806d ("drm: Extract drm_plane.[hc]")
> Signed-off-by: Chris Wilson 
> Cc: Daniel Vetter 
> Cc: Sean Paul 

Oops, thanks for catching this, applied to drm-misc.
-Daniel

> ---
>  drivers/gpu/drm/drm_plane.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/drivers/gpu/drm/drm_plane.c b/drivers/gpu/drm/drm_plane.c
> index cd0d475bf3c3..783aef8acab7 100644
> --- a/drivers/gpu/drm/drm_plane.c
> +++ b/drivers/gpu/drm/drm_plane.c
> @@ -898,6 +898,8 @@ int drm_mode_page_flip_ioctl(struct drm_device *dev,
>  out:
>   if (ret && crtc->funcs->page_flip_target)
>   drm_crtc_vblank_put(crtc);
> + if (fb)
> + drm_framebuffer_unreference(fb);
>   if (crtc->primary->old_fb)
>   drm_framebuffer_unreference(crtc->primary->old_fb);
>   crtc->primary->old_fb = NULL;
> -- 
> 2.9.3
> 
> ___
> Intel-gfx mailing list
> Intel-gfx at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

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


[Intel-gfx] [PATCH] drm: Add frame CRC debugfs files only for drivers that have CRTC

2016-09-29 Thread Daniel Vetter
On Thu, Sep 29, 2016 at 10:25:09AM +0200, Tomeu Vizoso wrote:
> On 29 September 2016 at 05:42, Dhinakaran Pandiyan
>  wrote:
> > vgem does not do modeset, looping through non-existent CRTC's while
> > registering drm_minor in
> >
> > 'commit 48c787899882 ("drm: Add API for capturing frame CRCs")'
> >
> > caused kernel oops. So, let's add CRC debugfs files
> > only for those drivers that do modeset.
> >
> > Signed-off-by: Dhinakaran Pandiyan 
> > Cc: Tomeu Vizoso 
> > Cc: Daniel Vetter 
> > Cc: Emil Velikov 
> 
> Reviewed-by: Tomeu Vizoso 

Applied to drm-misc, thanks.

> But I would prefer if drm_for_each_crtc was safe to call in any device
> regardless of the features that its driver supports.

Imo explicit checks are much better, especially in userspace-facing code
like this (well it's debugfs and not an ioctl, but still). Unrelated rant:
I think we should throw away the concept of having per-minor debugfs (with
a symlink for backwards compat). Then we could have put the crc code into
drm_modeset_register_all, and there would not have been any bug.
-Daniel

> 
> Regards,
> 
> Tomeu
> 
> > ---
> >  drivers/gpu/drm/drm_drv.c | 8 ++--
> >  1 file changed, 6 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
> > index 70d2543..294404f 100644
> > --- a/drivers/gpu/drm/drm_drv.c
> > +++ b/drivers/gpu/drm/drm_drv.c
> > @@ -208,6 +208,7 @@ static int drm_minor_register(struct drm_device *dev, 
> > unsigned int type)
> > struct drm_crtc *crtc;
> > unsigned long flags;
> > int ret;
> > +   bool is_modeset;
> >
> > DRM_DEBUG("\n");
> >
> > @@ -221,7 +222,8 @@ static int drm_minor_register(struct drm_device *dev, 
> > unsigned int type)
> > return ret;
> > }
> >
> > -   if (type == DRM_MINOR_PRIMARY) {
> > +   is_modeset = drm_core_check_feature(dev, DRIVER_MODESET);
> > +   if (type == DRM_MINOR_PRIMARY && is_modeset) {
> > drm_for_each_crtc(crtc, dev) {
> > ret = drm_debugfs_crtc_add(crtc);
> > if (ret)
> > @@ -255,12 +257,14 @@ static void drm_minor_unregister(struct drm_device 
> > *dev, unsigned int type)
> > struct drm_minor *minor;
> > struct drm_crtc *crtc;
> > unsigned long flags;
> > +   bool is_modeset;
> >
> > minor = *drm_minor_get_slot(dev, type);
> > if (!minor || !device_is_registered(minor->kdev))
> > return;
> >
> > -   if (type == DRM_MINOR_PRIMARY) {
> > +   is_modeset = drm_core_check_feature(dev, DRIVER_MODESET);
> > +   if (type == DRM_MINOR_PRIMARY && is_modeset) {
> > drm_for_each_crtc(crtc, dev)
> > drm_debugfs_crtc_remove(crtc);
> > }
> > --
> > 2.7.4
> >
> > ___
> > Intel-gfx mailing list
> > Intel-gfx at lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/intel-gfx

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


[PATCH v2] drm: tilcdc: add a workaround for failed clk_set_rate()

2016-09-29 Thread Jyri Sarha
On 09/28/16 15:41, Bartosz Golaszewski wrote:
> Some architectures don't use the common clock framework and don't
> implement all the clk interfaces for every clock. This is the case
> for da850-lcdk where clk_set_rate() only works for PLL0 and PLL1.
> 
> Trying to set the clock rate for the LCDC clock results in -EINVAL
> being returned.
> 
> As a workaround for that: if the call to clk_set_rate() fails, fall
> back to adjusting the clock divider instead. Proper divider value is
> calculated by dividing the current clock rate by the required pixel
> clock rate in HZ.
> 
> This code is based on a hack initially developed internally for
> baylibre by Karl Beldan .
> 
> Tested with a da850-lcdk with an LCD display connected over VGA.
> 
> Signed-off-by: Bartosz Golaszewski 
> ---
> v1 -> v2:
> - rebased on top of current drm-next
> - removed unnecessary error messages
> - removed an extra newline
> - added a warning if the effective pixel clock rate differs much from
>   the requested rate
> 
> Retested with modetest -M tilcdc -s 26:800x600 at RG16 using some
> additional work-in-progress changes on top of this patch.
> 
>  drivers/gpu/drm/tilcdc/tilcdc_crtc.c | 50 
> 
>  1 file changed, 45 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/gpu/drm/tilcdc/tilcdc_crtc.c 
> b/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
> index 52ebe8f..7346f300b 100644
> --- a/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
> +++ b/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
> @@ -320,23 +320,63 @@ static bool tilcdc_crtc_mode_fixup(struct drm_crtc 
> *crtc,
>   return true;
>  }
>  
> +/*
> + * Calculate the percentage difference between the requested pixel clock rate
> + * and the effective rate resulting from calculating the clock divider value.
> + */
> +static unsigned int tilcdc_pclk_diff(unsigned long rate,
> +  unsigned long real_rate)
> +{
> + int r = rate / 100, rr = real_rate / 100;
> +
> + return (unsigned int)(abs(((rr - r) * 100) / r));
> +}
> +
>  static void tilcdc_crtc_set_clk(struct drm_crtc *crtc)
>  {
>   struct drm_device *dev = crtc->dev;
>   struct tilcdc_drm_private *priv = dev->dev_private;
>   struct tilcdc_crtc *tilcdc_crtc = to_tilcdc_crtc(crtc);
> - const unsigned clkdiv = 2; /* using a fixed divider of 2 */
> + unsigned long rate, real_rate;
> + unsigned int clkdiv;
>   int ret;
>  
> + clkdiv = 2; /* first try using a standard divider of 2 */
> +
>   /* mode.clock is in KHz, set_rate wants parameter in Hz */
>   ret = clk_set_rate(priv->clk, crtc->mode.clock * 1000 * clkdiv);
> + rate = clk_get_rate(priv->clk);
>   if (ret < 0) {
> - dev_err(dev->dev, "failed to set display clock rate to: %d\n",
> - crtc->mode.clock);
> - return;
> + /*
> +  * If we fail to set the clock rate (some architectures don't
> +  * use the common clock framework yet and may not implement
> +  * all the clk API calls for every clock), try the next best
> +  * thing: adjusting the clock divider, unless clk_get_rate()
> +  * failed as well.
> +  */
> + if (!rate) {
> + /* Nothing more we can do. Just bail out. */
> + dev_err(dev->dev,
> + "failed to set the pixel clock - unable to read 
> current lcdc clock rate\n");
> + return;
> + }
> +
> + clkdiv = DIV_ROUND_CLOSEST(rate, (crtc->mode.clock * 1000));
> +
> + /*
> +  * Emit a warning if the real clock rate resulting from the
> +  * calculated divider differs much from the requested rate.
> +  *
> +  * 5% is an arbitrary value - LCDs are usually quite tolerant
> +  * about pixel clock rates.
> +  */
> + real_rate = clkdiv * crtc->mode.clock * 1000;
> +
> + WARN_ONCE(tilcdc_pclk_diff(rate, real_rate) > 5,
> +   "real pixel clock rate diverged from the requested 
> rate more than 5%%\n");

I'd say that a warn with backtrace over kill here (we know quite well
how we end up here). And it would be helpful to know in actual numbers
what the clock should have been and how close to it did we get.

Otherwise the patch appears to work fine at least on am335x.

BR,
Jyri

>   }
>  
> - tilcdc_crtc->lcd_fck_rate = clk_get_rate(priv->clk);
> + tilcdc_crtc->lcd_fck_rate = rate;
>  
>   DBG("lcd_clk=%u, mode clock=%d, div=%u",
>   tilcdc_crtc->lcd_fck_rate, crtc->mode.clock, clkdiv);
> 



[Intel-gfx] [PATCH] drm: Add frame CRC debugfs files only for drivers that have CRTC

2016-09-29 Thread Jani Nikula
On Thu, 29 Sep 2016, Dhinakaran Pandiyan  
wrote:
> vgem does not do modeset, looping through non-existent CRTC's while
> registering drm_minor in
>
>   'commit 48c787899882 ("drm: Add API for capturing frame CRCs")'
>
> caused kernel oops. So, let's add CRC debugfs files
> only for those drivers that do modeset.
>
> Signed-off-by: Dhinakaran Pandiyan 
> Cc: Tomeu Vizoso 
> Cc: Daniel Vetter 
> Cc: Emil Velikov 

Fixes: 48c787899882 ("drm: Add API for capturing frame CRCs")

Dhinakaran, for future reference, please add the kernel oops to the
commit messages. It'll help reviewing the patch and matching other bug
reports to the fix.

Tomeu, Emil, please review ASAP. This started oopsing all over the place
in our CI... we'll need to start running pre-merge testing on patches on
dri-devel too, like we do on intel-gfx. (Hint, for now, Cc'ing intel-gfx
on drm patches will run our CI on it.)

Thanks,
Jani.


> ---
>  drivers/gpu/drm/drm_drv.c | 8 ++--
>  1 file changed, 6 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
> index 70d2543..294404f 100644
> --- a/drivers/gpu/drm/drm_drv.c
> +++ b/drivers/gpu/drm/drm_drv.c
> @@ -208,6 +208,7 @@ static int drm_minor_register(struct drm_device *dev, 
> unsigned int type)
>   struct drm_crtc *crtc;
>   unsigned long flags;
>   int ret;
> + bool is_modeset;
>  
>   DRM_DEBUG("\n");
>  
> @@ -221,7 +222,8 @@ static int drm_minor_register(struct drm_device *dev, 
> unsigned int type)
>   return ret;
>   }
>  
> - if (type == DRM_MINOR_PRIMARY) {
> + is_modeset = drm_core_check_feature(dev, DRIVER_MODESET);
> + if (type == DRM_MINOR_PRIMARY && is_modeset) {
>   drm_for_each_crtc(crtc, dev) {
>   ret = drm_debugfs_crtc_add(crtc);
>   if (ret)
> @@ -255,12 +257,14 @@ static void drm_minor_unregister(struct drm_device 
> *dev, unsigned int type)
>   struct drm_minor *minor;
>   struct drm_crtc *crtc;
>   unsigned long flags;
> + bool is_modeset;
>  
>   minor = *drm_minor_get_slot(dev, type);
>   if (!minor || !device_is_registered(minor->kdev))
>   return;
>  
> - if (type == DRM_MINOR_PRIMARY) {
> + is_modeset = drm_core_check_feature(dev, DRIVER_MODESET);
> + if (type == DRM_MINOR_PRIMARY && is_modeset) {
>   drm_for_each_crtc(crtc, dev)
>   drm_debugfs_crtc_remove(crtc);
>   }

-- 
Jani Nikula, Intel Open Source Technology Center


[PATCH] drm/mediatek: fix a typo

2016-09-29 Thread Matthias Brugger


On 29/09/16 06:01, CK Hu wrote:
> Acked-by: CK Hu 
>
> On Thu, 2016-09-29 at 11:22 +0800, Bibby Hsieh wrote:
>> Fix the typo: OD_RELAYMODE->OD_CFG
>>

Although it is quite clear what the patch does, could you write one 
sentence to explain what it does. Maybe explain even which effect it 
has, which error get fixed etc.

As we are getting public available boards now, we should take more care 
about fixes. If you have a fix for a commit introduced in an earlier 
version of linux and it should be fixed for this version as well (e.g. 
v4.6 does have the feature but it does not work correctly) then please 
add these two lines before your Signed-off-by:

Fixes:  ("")
Cc: stable at vger.kernel.org # v4.6+

Where v4.6+ stands for the oldest version where this should get fixed.

Thanks a lot,
Matthias

>> Signed-off-by: Bibby Hsieh 
>> ---
>>  drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c |2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c 
>> b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
>> index df33b3c..aa5f20f 100644
>> --- a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
>> +++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
>> @@ -123,7 +123,7 @@ static void mtk_od_config(struct mtk_ddp_comp *comp, 
>> unsigned int w,
>>unsigned int bpc)
>>  {
>>  writel(w << 16 | h, comp->regs + DISP_OD_SIZE);
>> -writel(OD_RELAYMODE, comp->regs + OD_RELAYMODE);
>> +writel(OD_RELAYMODE, comp->regs + OD_CFG);
>>  mtk_dither_set(comp, bpc, DISP_OD_CFG);
>>  }
>>
>
>


[PATCH 2/2] drm/vc4: Add support for interlaced modes on HDMI.

2016-09-29 Thread Mark yao
On 2016年09月29日 10:20, Eric Anholt wrote:
> We just needed to initialize a few more fields.
>
> Signed-off-by: Eric Anholt 
> ---
>   drivers/gpu/drm/vc4/vc4_crtc.c | 17 ++---
>   drivers/gpu/drm/vc4/vc4_hdmi.c | 12 
>   drivers/gpu/drm/vc4/vc4_regs.h |  3 +++
>   3 files changed, 25 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/vc4/vc4_crtc.c b/drivers/gpu/drm/vc4/vc4_crtc.c
> index 8fc2b731b59a..d575f8aa3273 100644
> --- a/drivers/gpu/drm/vc4/vc4_crtc.c
> +++ b/drivers/gpu/drm/vc4/vc4_crtc.c
> @@ -428,13 +428,24 @@ static void vc4_crtc_mode_set_nofb(struct drm_crtc 
> *crtc)
>  VC4_SET_FIELD(mode->vsync_start - mode->vdisplay,
>PV_VERTB_VFP) |
>  VC4_SET_FIELD(vactive, PV_VERTB_VACTIVE));
> +
> + /* We set up first field even mode for HDMI.  VEC's
> +  * NTSC mode would want first field odd instead, once
> +  * we support it (to do so, set ODD_FIRST and put the
> +  * delay in VSYNCD_EVEN instead).
> +  */
> + CRTC_WRITE(PV_V_CONTROL,
> +PV_VCONTROL_CONTINUOUS |
> +PV_VCONTROL_INTERLACE |
> +VC4_SET_FIELD(mode->htotal / 2,
> +  PV_VCONTROL_ODD_DELAY));
> + CRTC_WRITE(PV_VSYNCD_EVEN, 0);
> + } else {
> + CRTC_WRITE(PV_V_CONTROL, PV_VCONTROL_CONTINUOUS);
>   }
>   
>   CRTC_WRITE(PV_HACT_ACT, mode->hdisplay);
>   
> - CRTC_WRITE(PV_V_CONTROL,
> -PV_VCONTROL_CONTINUOUS |
> -(interlace ? PV_VCONTROL_INTERLACE : 0));
>   
>   CRTC_WRITE(PV_CONTROL,
>  VC4_SET_FIELD(format, PV_CONTROL_FORMAT) |
> diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c b/drivers/gpu/drm/vc4/vc4_hdmi.c
> index 5770d6704f4b..6095e48fcf46 100644
> --- a/drivers/gpu/drm/vc4/vc4_hdmi.c
> +++ b/drivers/gpu/drm/vc4/vc4_hdmi.c
> @@ -246,7 +246,7 @@ static struct drm_connector 
> *vc4_hdmi_connector_init(struct drm_device *dev,
>   connector->polled = (DRM_CONNECTOR_POLL_CONNECT |
>DRM_CONNECTOR_POLL_DISCONNECT);
>   
> - connector->interlace_allowed = 0;
> + connector->interlace_allowed = true;
>   connector->doublescan_allowed = 0;
>   
>   drm_mode_connector_attach_encoder(connector, encoder);
> @@ -278,8 +278,8 @@ static void vc4_hdmi_encoder_mode_set(struct drm_encoder 
> *encoder,
>   bool debug_dump_regs = false;
>   bool hsync_pos = mode->flags & DRM_MODE_FLAG_PHSYNC;
>   bool vsync_pos = mode->flags & DRM_MODE_FLAG_PVSYNC;
> - u32 vactive = (mode->vdisplay >>
> -((mode->flags & DRM_MODE_FLAG_INTERLACE) ? 1 : 0));
> + bool interlaced = mode->flags & DRM_MODE_FLAG_INTERLACE;
> + u32 vactive = mode->vdisplay >> interlaced;

How about use mode->crtc_vdisplay:

see this:
drm_mode_set_crtcinfo()

 if (p->flags & DRM_MODE_FLAG_INTERLACE) {
 if (adjust_flags & CRTC_INTERLACE_HALVE_V) {
 p->crtc_vdisplay /= 2;
 p->crtc_vsync_start /= 2;
 p->crtc_vsync_end /= 2;
 p->crtc_vtotal /= 2;
 }
 }

Thanks

>   u32 verta = (VC4_SET_FIELD(mode->vsync_end - mode->vsync_start,
>  VC4_HDMI_VERTA_VSP) |
>VC4_SET_FIELD(mode->vsync_start - mode->vdisplay,
> @@ -288,6 +288,10 @@ static void vc4_hdmi_encoder_mode_set(struct drm_encoder 
> *encoder,
>   u32 vertb = (VC4_SET_FIELD(0, VC4_HDMI_VERTB_VSPO) |
>VC4_SET_FIELD(mode->vtotal - mode->vsync_end,
>  VC4_HDMI_VERTB_VBP));
> + u32 vertb_even = (VC4_SET_FIELD(0, VC4_HDMI_VERTB_VSPO) |
> +   VC4_SET_FIELD(mode->vtotal - mode->vsync_end -
> + interlaced,
> + VC4_HDMI_VERTB_VBP));
>   
>   if (debug_dump_regs) {
>   DRM_INFO("HDMI regs before:\n");
> @@ -319,7 +323,7 @@ static void vc4_hdmi_encoder_mode_set(struct drm_encoder 
> *encoder,
>   HDMI_WRITE(VC4_HDMI_VERTA0, verta);
>   HDMI_WRITE(VC4_HDMI_VERTA1, verta);
>   
> - HDMI_WRITE(VC4_HDMI_VERTB0, vertb);
> + HDMI_WRITE(VC4_HDMI_VERTB0, vertb_even);
>   HDMI_WRITE(VC4_HDMI_VERTB1, vertb);
>   
>   HD_WRITE(VC4_HD_VID_CTL,
> diff --git a/drivers/gpu/drm/vc4/vc4_regs.h b/drivers/gpu/drm/vc4/vc4_regs.h
> index 160942a9180e..fec7b5ef058b 100644
> --- a/drivers/gpu/drm/vc4/vc4_regs.h
> +++ b/drivers/gpu/drm/vc4/vc4_regs.h
> @@ -183,6 +183,9 @@
>   # define PV_CONTROL_EN  BIT(0)
>   
>   #define PV_V_CONTROL0x04
> +# define PV_VCONTROL_ODD_DELAY_MASK  VC4_MASK(22, 6)
> +# define PV_VCONTROL_ODD_DELAY_SHIFT 6
> +# define PV_VCONTROL_ODD_FIRST   BIT(5)
>   # define 

[Intel-gfx] [PATCH] drm: Add frame CRC debugfs files only for drivers that have CRTC

2016-09-29 Thread Tomeu Vizoso
On 29 September 2016 at 05:42, Dhinakaran Pandiyan
 wrote:
> vgem does not do modeset, looping through non-existent CRTC's while
> registering drm_minor in
>
> 'commit 48c787899882 ("drm: Add API for capturing frame CRCs")'
>
> caused kernel oops. So, let's add CRC debugfs files
> only for those drivers that do modeset.
>
> Signed-off-by: Dhinakaran Pandiyan 
> Cc: Tomeu Vizoso 
> Cc: Daniel Vetter 
> Cc: Emil Velikov 

Reviewed-by: Tomeu Vizoso 

But I would prefer if drm_for_each_crtc was safe to call in any device
regardless of the features that its driver supports.

Regards,

Tomeu

> ---
>  drivers/gpu/drm/drm_drv.c | 8 ++--
>  1 file changed, 6 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
> index 70d2543..294404f 100644
> --- a/drivers/gpu/drm/drm_drv.c
> +++ b/drivers/gpu/drm/drm_drv.c
> @@ -208,6 +208,7 @@ static int drm_minor_register(struct drm_device *dev, 
> unsigned int type)
> struct drm_crtc *crtc;
> unsigned long flags;
> int ret;
> +   bool is_modeset;
>
> DRM_DEBUG("\n");
>
> @@ -221,7 +222,8 @@ static int drm_minor_register(struct drm_device *dev, 
> unsigned int type)
> return ret;
> }
>
> -   if (type == DRM_MINOR_PRIMARY) {
> +   is_modeset = drm_core_check_feature(dev, DRIVER_MODESET);
> +   if (type == DRM_MINOR_PRIMARY && is_modeset) {
> drm_for_each_crtc(crtc, dev) {
> ret = drm_debugfs_crtc_add(crtc);
> if (ret)
> @@ -255,12 +257,14 @@ static void drm_minor_unregister(struct drm_device 
> *dev, unsigned int type)
> struct drm_minor *minor;
> struct drm_crtc *crtc;
> unsigned long flags;
> +   bool is_modeset;
>
> minor = *drm_minor_get_slot(dev, type);
> if (!minor || !device_is_registered(minor->kdev))
> return;
>
> -   if (type == DRM_MINOR_PRIMARY) {
> +   is_modeset = drm_core_check_feature(dev, DRIVER_MODESET);
> +   if (type == DRM_MINOR_PRIMARY && is_modeset) {
> drm_for_each_crtc(crtc, dev)
> drm_debugfs_crtc_remove(crtc);
> }
> --
> 2.7.4
>
> ___
> Intel-gfx mailing list
> Intel-gfx at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx


EDID reading failed when using DVI-to-VGA connector in valleyview(device id: 0x0f31)

2016-09-29 Thread Jani Nikula
On Thu, 29 Sep 2016, 杨波  wrote:
> Hi, everyone:
> Reading EDID failed when using DVI-to-VGA connector in valleyview(device 
> id: 0x0f31). 
> It is not G4X device,but still need to probe digital port. 

I don't think the patch is acceptable, at least not without a proper
explanation and debugging of the problem. Please file a bug at [1], add
drm.debug=14 module parameter and attach dmesg on the bug.

BR,
Jani.

[1] https://bugs.freedesktop.org/enter_bug.cgi?product=DRI=DRM/Intel



>
>
>
>
>
> --
>
> 武汉深之度科技有限公司
> Wuhan Deepin Technology Co., Ltd.
>
>   杨波  
>
> 手机:18523158905
>
>
> 武汉:武汉市光谷大道77号光谷金融港B18栋6楼 
> 北京:北京市海淀区知春路锦秋国际大厦B座501室
> 上海:上海市长宁区愚园路1258号15A01室
>
>
> 官网:www.deepin.org  官博:深度操作系统
> From e2dbb517239b5f03da7578e9e350013f8e9c2b3a Mon Sep 17 00:00:00 2001
> From: Yang Bo 
> Date: Thu, 29 Sep 2016 14:48:32 +0800
> Subject: [PATCH] EDID reading failure in 0x0f31
>
> EDID reading failure is observed in valleyview(device id: 0x0f31)
> when using DVI-to-VGA connector.
>
> Signed-off-by: Yang Bo 
> ---
>  drivers/gpu/drm/i915/intel_crt.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_crt.c 
> b/drivers/gpu/drm/i915/intel_crt.c
> index 827b6ef..83662fa 100644
> --- a/drivers/gpu/drm/i915/intel_crt.c
> +++ b/drivers/gpu/drm/i915/intel_crt.c
> @@ -715,7 +715,7 @@ static int intel_crt_get_modes(struct drm_connector 
> *connector)
>  
>   i2c = intel_gmbus_get_adapter(dev_priv, dev_priv->vbt.crt_ddc_pin);
>   ret = intel_crt_ddc_get_modes(connector, i2c);
> - if (ret || !IS_G4X(dev))
> + if (ret || !(IS_G4X(dev) || (dev->pdev->device == 0x0f31)))
>   goto out;
>  
>   /* Try to probe digital port for output in DVI-I -> VGA mode. */

-- 
Jani Nikula, Intel Open Source Technology Center


  1   2   >