[PATCH] drm/exynos: constify exynos_drm_crtc_ops structures

[Bhumika Goyal]

Declare exynos_drm_crtc_ops structures as const as they are only passed
as an argument to the function exynos_drm_crtc_create. This argument is
of type const struct exynos_drm_crtc_ops *, so exynos_drm_crtc_ops
structures having this property can be declared const.
Done using Coccinelle:

@r disable optional_qualifier@
identifier i;
position p;
@@
static struct exynos_drm_crtc_ops i at p={...};

@ok@
position p;
identifier r.i;
@@
exynos_drm_crtc_create(..., at p,...)

@bad@
position p!={r.p,ok.p};
identifier r.i;
@@
i at p

@depends on !bad disable optional_qualifier@
identifier r.i;
@@
+const
struct exynos_drm_crtc_ops i;

File size before:
   textdata bss dec hex filename
   5008 280   0528814a8 exynos/exynos5433_drm_decon.o

File size after:
   textdata bss dec hex filename
   5120 176   0529614b0 exynos/exynos5433_drm_decon.o

Signed-off-by: Bhumika Goyal 
---
 drivers/gpu/drm/exynos/exynos5433_drm_decon.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c 
b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
index 6ca1f31..12b9bf0 100644
--- a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
+++ b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
@@ -470,7 +470,7 @@ static void decon_clear_channels(struct exynos_drm_crtc 
*crtc)
clk_disable_unprepare(ctx->clks[i]);
 }

-static struct exynos_drm_crtc_ops decon_crtc_ops = {
+static const struct exynos_drm_crtc_ops decon_crtc_ops = {
.enable = decon_enable,
.disable= decon_disable,
.enable_vblank  = decon_enable_vblank,
-- 
1.9.1

[Bug 99078] Desktop icons oversaturated with red after December 11 2016 update

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

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

calexil at yahoo.com changed:

   What|Removed |Added

 CC||calexil at yahoo.com

--- Comment #21 from calexil at yahoo.com ---
Same problem using the stable mesa padoka ppa, as of the most recent build

llvm-toolchain-3.9  1:3.9.1-1~gd~x  Oibaf (2017-01-08)

mesa1:13.0.3-3~x~padoka0Paulo Dias (2017-01-08)

https://launchpad.net/~paulo-miguel-dias/+archive/ubuntu/pkppa

-- 
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/20170109/042c0dfd/attachment.html>

[Bug 98984] Hexagonal shapes around lights in Cities: Skylines

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

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

--- Comment #4 from randomsalad at gmail.com ---
OpenGL renderer string: Gallium 0.4 on AMD HAWAII (DRM 3.8.0 / 4.9.0, LLVM
3.9.1)
OpenGL version string: 3.0 Mesa 17.0.0-devel (git-8bc39e251b)

Bug is still there as of git-8bc39e251b.

-- 
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/20170109/12153f43/attachment.html>

[PATCH v4 3/3] drm: zte: add overlay plane support

[Shawn Guo]

From: Shawn Guo 

It enables VOU VL (Video Layer) to support overlay plane with scaling
function.  VL0 has some quirks on scaling support.  We choose to skip it
and only adds VL1 and VL2 into DRM core for now.

Function zx_plane_atomic_disable() gets moved around with no changes to
save a forward declaration.

Signed-off-by: Shawn Guo 
---
 drivers/gpu/drm/zte/zx_plane.c  | 301 +---
 drivers/gpu/drm/zte/zx_plane.h  |   1 +
 drivers/gpu/drm/zte/zx_plane_regs.h |  51 ++
 drivers/gpu/drm/zte/zx_vou.c|  84 +-
 drivers/gpu/drm/zte/zx_vou_regs.h   |  18 +++
 5 files changed, 426 insertions(+), 29 deletions(-)

diff --git a/drivers/gpu/drm/zte/zx_plane.c b/drivers/gpu/drm/zte/zx_plane.c
index 5445eebf830f..24426c2b4b8f 100644
--- a/drivers/gpu/drm/zte/zx_plane.c
+++ b/drivers/gpu/drm/zte/zx_plane.c
@@ -30,6 +30,261 @@
DRM_FORMAT_ARGB,
 };

+static const uint32_t vl_formats[] = {
+   DRM_FORMAT_NV12,/* Semi-planar YUV420 */
+   DRM_FORMAT_YUV420,  /* Planar YUV420 */
+   DRM_FORMAT_YUYV,/* Packed YUV422 */
+   DRM_FORMAT_YVYU,
+   DRM_FORMAT_UYVY,
+   DRM_FORMAT_VYUY,
+   DRM_FORMAT_YUV444,  /* YUV444 8bit */
+   /*
+* TODO: add formats below that HW supports:
+*  - YUV420 P010
+*  - YUV420 Hantro
+*  - YUV444 10bit
+*/
+};
+
+#define FRAC_16_16(mult, div)(((mult) << 16) / (div))
+
+static int zx_vl_plane_atomic_check(struct drm_plane *plane,
+   struct drm_plane_state *plane_state)
+{
+   struct drm_framebuffer *fb = plane_state->fb;
+   struct drm_crtc *crtc = plane_state->crtc;
+   struct drm_crtc_state *crtc_state;
+   struct drm_rect clip;
+   int min_scale = FRAC_16_16(1, 8);
+   int max_scale = FRAC_16_16(8, 1);
+
+   if (!crtc || !fb)
+   return 0;
+
+   crtc_state = drm_atomic_get_existing_crtc_state(plane_state->state,
+   crtc);
+   if (WARN_ON(!crtc_state))
+   return -EINVAL;
+
+   /* nothing to check when disabling or disabled */
+   if (!crtc_state->enable)
+   return 0;
+
+   /* plane must be enabled */
+   if (!plane_state->crtc)
+   return -EINVAL;
+
+   clip.x1 = 0;
+   clip.y1 = 0;
+   clip.x2 = crtc_state->adjusted_mode.hdisplay;
+   clip.y2 = crtc_state->adjusted_mode.vdisplay;
+
+   return drm_plane_helper_check_state(plane_state, ,
+   min_scale, max_scale,
+   true, true);
+}
+
+static int zx_vl_get_fmt(uint32_t format)
+{
+   switch (format) {
+   case DRM_FORMAT_NV12:
+   return VL_FMT_YUV420;
+   case DRM_FORMAT_YUV420:
+   return VL_YUV420_PLANAR | VL_FMT_YUV420;
+   case DRM_FORMAT_YUYV:
+   return VL_YUV422_YUYV | VL_FMT_YUV422;
+   case DRM_FORMAT_YVYU:
+   return VL_YUV422_YVYU | VL_FMT_YUV422;
+   case DRM_FORMAT_UYVY:
+   return VL_YUV422_UYVY | VL_FMT_YUV422;
+   case DRM_FORMAT_VYUY:
+   return VL_YUV422_VYUY | VL_FMT_YUV422;
+   case DRM_FORMAT_YUV444:
+   return VL_FMT_YUV444_8BIT;
+   default:
+   WARN_ONCE(1, "invalid pixel format %d\n", format);
+   return -EINVAL;
+   }
+}
+
+static inline void zx_vl_set_update(struct zx_plane *zplane)
+{
+   void __iomem *layer = zplane->layer;
+
+   zx_writel_mask(layer + VL_CTRL0, VL_UPDATE, VL_UPDATE);
+}
+
+static inline void zx_vl_rsz_set_update(struct zx_plane *zplane)
+{
+   zx_writel(zplane->rsz + RSZ_VL_ENABLE_CFG, 1);
+}
+
+static int zx_vl_rsz_get_fmt(uint32_t format)
+{
+   switch (format) {
+   case DRM_FORMAT_NV12:
+   case DRM_FORMAT_YUV420:
+   return RSZ_VL_FMT_YCBCR420;
+   case DRM_FORMAT_YUYV:
+   case DRM_FORMAT_YVYU:
+   case DRM_FORMAT_UYVY:
+   case DRM_FORMAT_VYUY:
+   return RSZ_VL_FMT_YCBCR422;
+   case DRM_FORMAT_YUV444:
+   return RSZ_VL_FMT_YCBCR444;
+   default:
+   WARN_ONCE(1, "invalid pixel format %d\n", format);
+   return -EINVAL;
+   }
+}
+
+static inline u32 rsz_step_value(u32 src, u32 dst)
+{
+   u32 val = 0;
+
+   if (src == dst)
+   val = 0;
+   else if (src < dst)
+   val = RSZ_PARA_STEP((src << 16) / dst);
+   else if (src > dst)
+   val = RSZ_DATA_STEP(src / dst) |
+ RSZ_PARA_STEP(((src << 16) / dst) & 0x);
+
+   return val;
+}
+
+static void zx_vl_rsz_setup(struct zx_plane *zplane, uint32_t format,
+   u32 src_w, u32 src_h, u32 dst_w, u32 dst_h)
+{
+   void __iomem *rsz = zplane->rsz;
+   u32 src_chroma_w = src_w;
+   u32 src_chroma_h = src_h;
+   u32 

[PATCH v4 2/3] drm: zte: add .atomic_disable hook to disable graphic layer

[Shawn Guo]

From: Shawn Guo 

There are a few hardware bits for each graphic layer to control main/aux
channel and clock selection, as well as the layer enabling.  These bits
sit outside the layer block itself, but in VOU control glue block.  We
currently set these bits up at CRTC initialization for once, and do not
support disabling the layer.

This patch creates a pair of functions zx_vou_layer_enable[disable] to
be invoked from plane hooks .atomic_update and .atomic_disable to set up
and tear down the layer.  This is generic for both graphic and video
layers, so it will make the overlay plane support to be added later much
easier.

Signed-off-by: Shawn Guo 
Reviewed-by: Sean Paul 
---
 drivers/gpu/drm/zte/zx_plane.c | 15 +
 drivers/gpu/drm/zte/zx_plane.h |  1 +
 drivers/gpu/drm/zte/zx_vou.c   | 70 ++
 drivers/gpu/drm/zte/zx_vou.h   |  3 ++
 4 files changed, 69 insertions(+), 20 deletions(-)

diff --git a/drivers/gpu/drm/zte/zx_plane.c b/drivers/gpu/drm/zte/zx_plane.c
index 78d29b1db91c..5445eebf830f 100644
--- a/drivers/gpu/drm/zte/zx_plane.c
+++ b/drivers/gpu/drm/zte/zx_plane.c
@@ -197,12 +197,27 @@ static void zx_gl_plane_atomic_update(struct drm_plane 
*plane,
/* Enable HBSC block */
zx_writel_mask(hbsc + HBSC_CTRL0, HBSC_CTRL_EN, HBSC_CTRL_EN);

+   zx_vou_layer_enable(plane);
+
zx_gl_set_update(zplane);
 }

+static void zx_plane_atomic_disable(struct drm_plane *plane,
+   struct drm_plane_state *old_state)
+{
+   struct zx_plane *zplane = to_zx_plane(plane);
+   void __iomem *hbsc = zplane->hbsc;
+
+   zx_vou_layer_disable(plane);
+
+   /* Disable HBSC block */
+   zx_writel_mask(hbsc + HBSC_CTRL0, HBSC_CTRL_EN, 0);
+}
+
 static const struct drm_plane_helper_funcs zx_gl_plane_helper_funcs = {
.atomic_check = zx_gl_plane_atomic_check,
.atomic_update = zx_gl_plane_atomic_update,
+   .atomic_disable = zx_plane_atomic_disable,
 };

 static void zx_plane_destroy(struct drm_plane *plane)
diff --git a/drivers/gpu/drm/zte/zx_plane.h b/drivers/gpu/drm/zte/zx_plane.h
index 264a92e0b532..933611ddffd0 100644
--- a/drivers/gpu/drm/zte/zx_plane.h
+++ b/drivers/gpu/drm/zte/zx_plane.h
@@ -18,6 +18,7 @@ struct zx_plane {
void __iomem *csc;
void __iomem *hbsc;
void __iomem *rsz;
+   const struct vou_layer_bits *bits;
 };

 #define to_zx_plane(plane) container_of(plane, struct zx_plane, plane)
diff --git a/drivers/gpu/drm/zte/zx_vou.c b/drivers/gpu/drm/zte/zx_vou.c
index d5c801f6f97b..3fb4fc04e693 100644
--- a/drivers/gpu/drm/zte/zx_vou.c
+++ b/drivers/gpu/drm/zte/zx_vou.c
@@ -65,7 +65,6 @@ struct zx_crtc_bits {
u32 polarity_shift;
u32 int_frame_mask;
u32 tc_enable;
-   u32 gl_enable;
 };

 static const struct zx_crtc_bits main_crtc_bits = {
@@ -73,7 +72,6 @@ struct zx_crtc_bits {
.polarity_shift = MAIN_POL_SHIFT,
.int_frame_mask = TIMING_INT_MAIN_FRAME,
.tc_enable = MAIN_TC_EN,
-   .gl_enable = OSD_CTRL0_GL0_EN,
 };

 static const struct zx_crtc_bits aux_crtc_bits = {
@@ -81,7 +79,6 @@ struct zx_crtc_bits {
.polarity_shift = AUX_POL_SHIFT,
.int_frame_mask = TIMING_INT_AUX_FRAME,
.tc_enable = AUX_TC_EN,
-   .gl_enable = OSD_CTRL0_GL1_EN,
 };

 struct zx_crtc {
@@ -97,6 +94,24 @@ struct zx_crtc {

 #define to_zx_crtc(x) container_of(x, struct zx_crtc, crtc)

+struct vou_layer_bits {
+   u32 enable;
+   u32 chnsel;
+   u32 clksel;
+};
+
+static const struct vou_layer_bits zx_gl_bits[GL_NUM] = {
+   {
+   .enable = OSD_CTRL0_GL0_EN,
+   .chnsel = OSD_CTRL0_GL0_SEL,
+   .clksel = VOU_CLK_GL0_SEL,
+   }, {
+   .enable = OSD_CTRL0_GL1_EN,
+   .chnsel = OSD_CTRL0_GL1_SEL,
+   .clksel = VOU_CLK_GL1_SEL,
+   },
+};
+
 struct zx_vou_hw {
struct device *dev;
void __iomem *osd;
@@ -220,10 +235,6 @@ static void zx_crtc_enable(struct drm_crtc *crtc)
/* Enable channel */
zx_writel_mask(zcrtc->chnreg + CHN_CTRL0, CHN_ENABLE, CHN_ENABLE);

-   /* Enable Graphic Layer */
-   zx_writel_mask(vou->osd + OSD_CTRL0, bits->gl_enable,
-  bits->gl_enable);
-
drm_crtc_vblank_on(crtc);

ret = clk_set_rate(zcrtc->pixclk, mode->clock * 1000);
@@ -247,9 +258,6 @@ static void zx_crtc_disable(struct drm_crtc *crtc)

drm_crtc_vblank_off(crtc);

-   /* Disable Graphic Layer */
-   zx_writel_mask(vou->osd + OSD_CTRL0, bits->gl_enable, 0);
-
/* Disable channel */
zx_writel_mask(zcrtc->chnreg + CHN_CTRL0, CHN_ENABLE, 0);

@@ -316,6 +324,7 @@ static int zx_crtc_init(struct drm_device *drm, struct 
zx_vou_hw *vou,
zplane->csc = vou->osd + MAIN_CSC_OFFSET;
zplane->hbsc = vou->osd + MAIN_HBSC_OFFSET;
zplane->rsz = vou->otfppu + MAIN_RSZ_OFFSET;

[PATCH v4 1/3] drm: zte: make zx_plane accessible from zx_vou driver

[Shawn Guo]

From: Shawn Guo 

Move struct zx_plane from zx_plane.c to zx_plane.h, so that it can be
accessed from zx_vou driver, and we can save the use of struct
zx_layer_data completely.  More importantly, those additional data used
by VOU controller to enable/disable graphic and video layers can later
be added and accessed much more easily from zx_vou driver.

While at it, we make two changes to zx_plane_init() interface:

 - Encode struct device pointer in zx_plane, so that we do not need to
   pass it as a parameter.
 - Change return of zx_plane_init() from struct drm_plane pointer to
   error code, since we can get the pointer from zx_plane in zx_vou
   driver now.

Signed-off-by: Shawn Guo 
Reviewed-by: Sean Paul 
---
 drivers/gpu/drm/zte/zx_plane.c | 36 +++-
 drivers/gpu/drm/zte/zx_plane.h | 11 +++
 drivers/gpu/drm/zte/zx_vou.c   | 31 +++
 3 files changed, 33 insertions(+), 45 deletions(-)

diff --git a/drivers/gpu/drm/zte/zx_plane.c b/drivers/gpu/drm/zte/zx_plane.c
index 546eb92a94e8..78d29b1db91c 100644
--- a/drivers/gpu/drm/zte/zx_plane.c
+++ b/drivers/gpu/drm/zte/zx_plane.c
@@ -21,16 +21,6 @@
 #include "zx_plane_regs.h"
 #include "zx_vou.h"

-struct zx_plane {
-   struct drm_plane plane;
-   void __iomem *layer;
-   void __iomem *csc;
-   void __iomem *hbsc;
-   void __iomem *rsz;
-};
-
-#define to_zx_plane(plane) container_of(plane, struct zx_plane, plane)
-
 static const uint32_t gl_formats[] = {
DRM_FORMAT_ARGB,
DRM_FORMAT_XRGB,
@@ -248,28 +238,16 @@ static void zx_plane_hbsc_init(struct zx_plane *zplane)
zx_writel(hbsc + HBSC_THRESHOLD_COL3, (0x3c0 << 16) | 0x40);
 }

-struct drm_plane *zx_plane_init(struct drm_device *drm, struct device *dev,
-   struct zx_layer_data *data,
-   enum drm_plane_type type)
+int zx_plane_init(struct drm_device *drm, struct zx_plane *zplane,
+ enum drm_plane_type type)
 {
const struct drm_plane_helper_funcs *helper;
-   struct zx_plane *zplane;
-   struct drm_plane *plane;
+   struct drm_plane *plane = >plane;
+   struct device *dev = zplane->dev;
const uint32_t *formats;
unsigned int format_count;
int ret;

-   zplane = devm_kzalloc(dev, sizeof(*zplane), GFP_KERNEL);
-   if (!zplane)
-   return ERR_PTR(-ENOMEM);
-
-   plane = >plane;
-
-   zplane->layer = data->layer;
-   zplane->hbsc = data->hbsc;
-   zplane->csc = data->csc;
-   zplane->rsz = data->rsz;
-
zx_plane_hbsc_init(zplane);

switch (type) {
@@ -282,7 +260,7 @@ struct drm_plane *zx_plane_init(struct drm_device *drm, 
struct device *dev,
/* TODO: add video layer (vl) support */
break;
default:
-   return ERR_PTR(-ENODEV);
+   return -ENODEV;
}

ret = drm_universal_plane_init(drm, plane, VOU_CRTC_MASK,
@@ -290,10 +268,10 @@ struct drm_plane *zx_plane_init(struct drm_device *drm, 
struct device *dev,
   type, NULL);
if (ret) {
DRM_DEV_ERROR(dev, "failed to init universal plane: %d\n", ret);
-   return ERR_PTR(ret);
+   return ret;
}

drm_plane_helper_add(plane, helper);

-   return plane;
+   return 0;
 }
diff --git a/drivers/gpu/drm/zte/zx_plane.h b/drivers/gpu/drm/zte/zx_plane.h
index 2b82cd558d9d..264a92e0b532 100644
--- a/drivers/gpu/drm/zte/zx_plane.h
+++ b/drivers/gpu/drm/zte/zx_plane.h
@@ -11,16 +11,19 @@
 #ifndef __ZX_PLANE_H__
 #define __ZX_PLANE_H__

-struct zx_layer_data {
+struct zx_plane {
+   struct drm_plane plane;
+   struct device *dev;
void __iomem *layer;
void __iomem *csc;
void __iomem *hbsc;
void __iomem *rsz;
 };

-struct drm_plane *zx_plane_init(struct drm_device *drm, struct device *dev,
-   struct zx_layer_data *data,
-   enum drm_plane_type type);
+#define to_zx_plane(plane) container_of(plane, struct zx_plane, plane)
+
+int zx_plane_init(struct drm_device *drm, struct zx_plane *zplane,
+ enum drm_plane_type type);
 void zx_plane_set_update(struct drm_plane *plane);

 #endif /* __ZX_PLANE_H__ */
diff --git a/drivers/gpu/drm/zte/zx_vou.c b/drivers/gpu/drm/zte/zx_vou.c
index 73fe15c17c32..d5c801f6f97b 100644
--- a/drivers/gpu/drm/zte/zx_vou.c
+++ b/drivers/gpu/drm/zte/zx_vou.c
@@ -294,7 +294,7 @@ static int zx_crtc_init(struct drm_device *drm, struct 
zx_vou_hw *vou,
enum vou_chn_type chn_type)
 {
struct device *dev = vou->dev;
-   struct zx_layer_data data;
+   struct zx_plane *zplane;
struct zx_crtc *zcrtc;
int ret;

@@ -305,19 +305,25 @@ static int zx_crtc_init(struct drm_device *drm, struct 
zx_vou_hw *vou,

[PATCH v4 0/3] Add overlay plane support for ZTE drm driver

[Shawn Guo]

From: Shawn Guo 

Changes for v4:
 - Instead of using val, return value directly for zx_vl_get_fmt() and
   zx_vl_rsz_get_fmt().
 - Fix typo of 'heigth'
 - Add 'enabled' in struct zx_plane to track layer enabling state, and
   check the state in zx_plane_set_update(), so that we can call
   zx_plane_set_update() unconditionally in the vou irq handler.

Changes for v3:
 - Let zx_plane be accessible from zx_vou driver, and so we can easily
   access all the data encoded in zx_plane with a drm_plane pointer.
   Thus, function zx_overlay_find_vl_idx() can be saved completely.
 - Refine the existing zx_plane driver a bit to support disable graphic
   layer, and make the support of overlay plane a bit easier, by sharing
   VOU layer setup and teardown functions between graphic and video
   layers.

Changes for v2:
 - Use clipped coordinates for overlay position calculation

Shawn Guo (3):
  drm: zte: make zx_plane accessible from zx_vou driver
  drm: zte: add .atomic_disable hook to disable graphic layer
  drm: zte: add overlay plane support

 drivers/gpu/drm/zte/zx_plane.c  | 328 +++-
 drivers/gpu/drm/zte/zx_plane.h  |  13 +-
 drivers/gpu/drm/zte/zx_plane_regs.h |  51 ++
 drivers/gpu/drm/zte/zx_vou.c| 185 +++-
 drivers/gpu/drm/zte/zx_vou.h|   3 +
 drivers/gpu/drm/zte/zx_vou_regs.h   |  18 ++
 6 files changed, 516 insertions(+), 82 deletions(-)

-- 
1.9.1

[PATCH v3 3/3] drm: zte: add overlay plane support

[Shawn Guo]

On Thu, Jan 05, 2017 at 02:26:30AM -0500, Sean Paul wrote:
> > +static u32 zx_vl_get_fmt(uint32_t format)
> > +{
> > +   u32 val = 0;
> > +
> > +   switch (format) {
> > +   case DRM_FORMAT_NV12:
> > +   val = VL_FMT_YUV420;
> > +   break;
> > +   case DRM_FORMAT_YUV420:
> > +   val = VL_YUV420_PLANAR | VL_FMT_YUV420;
> > +   break;
> > +   case DRM_FORMAT_YUYV:
> > +   val = VL_YUV422_YUYV | VL_FMT_YUV422;
> > +   break;
> > +   case DRM_FORMAT_YVYU:
> > +   val = VL_YUV422_YVYU | VL_FMT_YUV422;
> > +   break;
> > +   case DRM_FORMAT_UYVY:
> > +   val = VL_YUV422_UYVY | VL_FMT_YUV422;
> > +   break;
> > +   case DRM_FORMAT_VYUY:
> > +   val = VL_YUV422_VYUY | VL_FMT_YUV422;
> > +   break;
> > +   case DRM_FORMAT_YUV444:
> > +   val = VL_FMT_YUV444_8BIT;
> 
> Minor nit: You could have eliminated val and just returned directly
> from all of the cases. Seems like there are a few other functions this
> is also true for.

Okay.  I will change zx_vl_get_fmt() and zx_vl_rsz_get_fmt()
accordingly.

> 
> > +   break;
> > +   default:
> > +   WARN_ONCE(1, "invalid pixel format %d\n", format);
> > +   }
> > +
> > +   return val;
> > +}



> > +static void zx_vl_rsz_setup(struct zx_plane *zplane, uint32_t format,
> > +   u32 src_w, u32 src_h, u32 dst_w, u32 dst_h)
> > +{
> > +   void __iomem *rsz = zplane->rsz;
> > +   u32 src_chroma_w = src_w;
> > +   u32 src_chroma_h = src_h;
> > +   u32 fmt;
> > +
> > +   /* Set up source and destination resolution */
> > +   zx_writel(rsz + RSZ_SRC_CFG, RSZ_VER(src_h - 1) | RSZ_HOR(src_w - 
> > 1));
> > +   zx_writel(rsz + RSZ_DEST_CFG, RSZ_VER(dst_h - 1) | RSZ_HOR(dst_w - 
> > 1));
> > +
> > +   /* Configure data format for VL RSZ */
> > +   fmt = zx_vl_rsz_get_fmt(format);
> > +   zx_writel_mask(rsz + RSZ_VL_CTRL_CFG, RSZ_VL_FMT_MASK, fmt);
> > +
> > +   /* Calculate Chroma heigth and width */
> 
> s/heigth/height/

Thanks for spotting it.

> 
> > +   if (fmt == RSZ_VL_FMT_YCBCR420) {
> > +   src_chroma_w = src_w >> 1;
> > +   src_chroma_h = src_h >> 1;
> > +   } else if (fmt == RSZ_VL_FMT_YCBCR422) {
> > +   src_chroma_w = src_w >> 1;
> > +   }
> > +
> > +   /* Set up Luma and Chroma step registers */
> > +   zx_writel(rsz + RSZ_VL_LUMA_HOR, rsz_step_value(src_w, dst_w));
> > +   zx_writel(rsz + RSZ_VL_LUMA_VER, rsz_step_value(src_h, dst_h));
> > +   zx_writel(rsz + RSZ_VL_CHROMA_HOR, rsz_step_value(src_chroma_w, 
> > dst_w));
> > +   zx_writel(rsz + RSZ_VL_CHROMA_VER, rsz_step_value(src_chroma_h, 
> > dst_h));
> > +
> > +   zx_vl_rsz_set_update(zplane);
> > +}



> > diff --git a/drivers/gpu/drm/zte/zx_vou.c b/drivers/gpu/drm/zte/zx_vou.c
> > index 3fb4fc04e693..e832c2ec3156 100644
> > --- a/drivers/gpu/drm/zte/zx_vou.c
> > +++ b/drivers/gpu/drm/zte/zx_vou.c
> > @@ -84,6 +84,8 @@ struct zx_crtc_bits {
> >  struct zx_crtc {
> > struct drm_crtc crtc;
> > struct drm_plane *primary;
> > +   struct drm_plane *overlay_active[VL_NUM];
> > +   unsigned int overlay_active_num;
> 
> I don't think this belongs here. You can instead add an active (or
> enabled) bool to the zx_plane struct and keep track of it via
> atomic_plane_update/disable. This allows you to call
> zx_plane_set_update unconditionally in the vou irq handler and check
> active/enabled in zx_plane_set_update.

It's a truly great suggestion.  How did I not think of it :)  The v4 is
coming for that.

Thanks a lot for the review effort, Sean.

Shawn

[Bug 98897] Macbook pro 11,5 screen flicker when AC adapter plugged in

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

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

--- Comment #24 from Paul Gier  ---
The patch in comment 22 works for me.
Running Fedora 24 with 4.8.16 kernel.  MacBookPro11,5.
Fedora Copr repo available here:
https://copr.fedorainfracloud.org/coprs/pgier/macbook-kernel/

-- 
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/20170109/4c8e8e28/attachment.html>

[Bug 99330] Severe flickering with Fiji on Wayland

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

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

--- Comment #4 from Ernst Sjöstrand  ---
Wait, actually after some DPMS and
[ 4378.466823] [drm:amdgpu_atombios_dp_link_train [amdgpu]] *ERROR* clock
recovery tried 5 times
[ 4378.466834] [drm:amdgpu_atombios_dp_link_train [amdgpu]] *ERROR* clock
recovery failed

journalctl /usr/bin/gnome-shell now show a bunch of stuff like:
jan 09 22:06:51 mammut gnome-shell[1675]: Failed to flip: Invalid argument
jan 09 22:06:52 mammut org.gnome.Shell.desktop[1675]: Window manager warning:
Failed to read EDID of output DP-3: Filen eller katalogen finns inte
jan 09 22:06:52 mammut gnome-shell[1448]: Failed to apply DRM plane transform
0: Access denied 
jan 09 22:06:52 mammut gnome-shell[1448]: Failed to apply DRM plane transform
0: Access denied
jan 09 22:06:52 mammut gnome-shell[1675]: Failed to apply DRM plane transform
0: Invalid argument
jan 09 22:06:52 mammut gnome-shell[1675]: Failed to apply DRM plane transform
0: Invalid argument
jan 09 22:06:53 mammut org.gnome.Shell.desktop[1675]: Window manager warning:
Failed to read EDID of output DP-3: Filen eller katalogen finns inte
jan 09 22:06:53 mammut org.gnome.Shell.desktop[1675]: Window manager warning:
Failed to read EDID of output DP-3: Filen eller katalogen finns inte
jan 09 22:06:53 mammut org.gnome.Shell.desktop[1675]: Window manager warning:
Failed to read EDID of output DP-3: Filen eller katalogen finns inte
jan 09 22:06:53 mammut org.gnome.Shell.desktop[1675]: Window manager warning:
Failed to read EDID of output DP-3: Filen eller katalogen finns inte
jan 09 22:06:53 mammut org.gnome.Shell.desktop[1675]: Window manager warning:
Failed to read EDID of output DP-3: Filen eller katalogen finns inte
jan 09 22:06:53 mammut org.gnome.Shell.desktop[1675]: Window manager warning:
Failed to read EDID of output DP-3: Filen eller katalogen finns inte
jan 09 22:06:53 mammut org.gnome.Shell.desktop[1675]: Window manager warning:
Failed to read EDID of output DP-3: Filen eller katalogen finns inte
jan 09 22:06:53 mammut gnome-shell[1448]: Failed to apply DRM plane transform
0: Access denied
jan 09 22:06:53 mammut gnome-shell[1675]: Failed to apply DRM plane transform
0: Invalid argument

Still, this could just as well be a gnome-shell bug?

Does it work with an older mesa/llvm version 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/20170109/89c1df42/attachment.html>

[Bug 98856] [Regression, SI] DIRT: Showdown broken graphics

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

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

--- Comment #2 from Gregor Münch  ---
I tried getting this to work but I dont get any output file.

DEBUGGER="apitrace trace" steam steam://rungameid/201700
What am Im doing wrong here?

I installed:
apitrace
lib32-apitrace


If you want to do a regression testing,
this somewhat broke arround here:
https://cgit.freedesktop.org/mesa/mesa/commit/?id=74e39de9324d2d2333cda6adca50ae2a3fc36de2

-- 
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/20170109/12502c25/attachment.html>

[Bug 95306] Random Blank(black) screens on "Carrizo"

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

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

--- Comment #48 from cyrwyn  ---
Created attachment 128841
  --> https://bugs.freedesktop.org/attachment.cgi?id=128841=edit
latest xorg.conf file for amdgpu

The xorg.conf renamed .new so it won't work. Created by XFdrake.

-- 
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/20170109/7d7dcd4e/attachment.html>

[Bug 98856] [Regression, SI] DIRT: Showdown broken graphics

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

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

Gregor Münch  changed:

   What|Removed |Added

Summary|Dirt: Showdown broken   |[Regression, SI] DIRT:
   |graphics|Showdown broken graphics

-- 
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/20170109/5dfbf47b/attachment-0001.html>

[Bug 95306] Random Blank(black) screens on "Carrizo"

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

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

--- Comment #47 from cyrwyn  ---
Created attachment 128840
  --> https://bugs.freedesktop.org/attachment.cgi?id=128840=edit
xorg log after trying to boot with amdgpu enabled

Tried booting using new 4.8.16 kernel. Back to blank screen.

-- 
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/20170109/e1df32b1/attachment.html>

[PULL] drm-misc-fixes

[Daniel Vetter]

Hi Dave,

Another lonely core fix, picket up by Archit. I think there's 1-2 low-prio
core fixes currently under discussion on dri-devel, I guess that means
another pull somewhen next week or so at lca.

Cheers, Daniel


The following changes since commit aebe55c2d4b998741c0847ace1b4af47d73c763b:

  drm: Clean up planes in atomic commit helper failure path (2017-01-04 
11:08:13 +0100)

are available in the git repository at:

  git://anongit.freedesktop.org/git/drm-misc tags/drm-misc-fixes-2017-01-09

for you to fetch changes up to f0a8b49c03d22a511a601dc54b2a3425a41e35fa:

  drm/bridge: analogix dp: Fix runtime PM state on driver bind (2017-01-09 
13:30:37 +0530)


Marek Szyprowski (1):
  drm/bridge: analogix dp: Fix runtime PM state on driver bind

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

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

[PULL] drm-misc-next

[Daniel Vetter]

Hi Dave,

Back to regular -misc pulls with reasonable sizes:
- dma_fence error clarification (Chris)
- drm_crtc_from_index helper (Shawn), pile more patches on the m-l to roll
  this out to drivers
- mmu-less support for fbdev helpers from Benjamin
- piles of kerneldoc work
- some polish for crc support from Tomeu and Benjamin
- odd misc stuff all over

Cheers, Daniel


The following changes since commit 9b8b75de4cb379187c481a5332a12429f31c0887:

  drm: Add kerneldoc markup for new @scan parameters in drm_mm (2016-12-28 
14:05:38 +0100)

are available in the git repository at:

  git://anongit.freedesktop.org/git/drm-misc tags/drm-misc-next-2017-01-09

for you to fetch changes up to a009e975da5c7d42a7f5eaadc54946eb5f76c9af:

  dma-fence: Introduce drm_fence_set_error() helper (2017-01-09 21:13:49 +0530)


Arvind Yadav (1):
  gpu: drm: mgag200: mgag200_main:- Handle error from pci_iomap

Benjamin Gaignard (5):
  fbmem: add a default get_fb_unmapped_area function
  drm: compile drm_vm.c only when needed
  drm: allow to use mmuless SoC
  drm: crc: Call wake_up_interruptible() each time there is a new CRC entry
  drm: fix compilations issues introduced by "drm: allow to use mmuless SoC"

Chris Wilson (6):
  drm: Reduce verbosity level for drm_core_init() debug message
  drm: Avoid NULL dereference of drm_device.dev
  drm/armada: s/drm_mm_dump_table/drm_mm_print/
  dma-fence: Clear fence->status during dma_fence_init()
  dma-fence: Wrap querying the fence->status
  dma-fence: Introduce drm_fence_set_error() helper

Daniel Vetter (19):
  drm/doc: link style-guide to doc-guide
  drm/printer: add debug printer
  drm/mm: Convert to drm_printer
  drm/docs: Small cleanup in drm-uapi.rst
  drm/mm: Some doc polish
  dma-buf: use preferred struct reference in kernel-doc
  dma-buf: Use recommended structure member reference
  drm/doc: use preferred struct reference in kernel-doc
  drm: Nuke connector_list locking assert
  drm/doc: Update styleguide
  drm/rect: Fix formatting of example code
  drm/atomic-helpers: Remove outdated comment
  drm/armada: Fix compile fail
  drm/cma-helper: simplify setup for drivers with ->dirty callbacks
  drm/cma-helpers: Use recommened kerneldoc for struct member refs
  drm/bridge: Use recommened kerneldoc for struct member refs
  drm: reference count event->completion
  drm: Add kernel-doc for drm_crtc_commit_get/put
  Revert "drm: nouveau: fix build when LEDS_CLASS=m"

Fabio Estevam (1):
  drm/imx: imx-tve: Remove unused variable

Gabriel Krisman Bertazi (6):
  drm: Deduplicate driver initialization message
  drm: Drop unused forward declaration of drm_version
  drm: Export drm_ioctl_permit to kernel-doc
  drm: Update TTM initialization documentation
  drm: Document deprecated load/unload hook
  drm: Change the return type of the unload hook to void

Jani Nikula (1):
  drm/edid: constify edid quirk list

Maarten Lankhorst (1):
  drm/atomic: Fix outdated comment.

Randy Dunlap (1):
  drm: nouveau: fix build when LEDS_CLASS=m

Shawn Guo (4):
  drm: add crtc helper drm_crtc_from_index()
  drm: zte: use crtc helper drm_crtc_from_index()
  drm: rockchip: use crtc helper drm_crtc_from_index()
  drm: add more document for drm_crtc_from_index()

Tomeu Vizoso (2):
  drm: Move locking into drm_debugfs_crtc_crc_add
  drm: crc: Wait for a frame before returning from open()

Vincent Abriou (1):
  drm: remove useless parameters from drm_pick_cmdline_mode function

 Documentation/gpu/drm-mm.rst|  40 ++---
 Documentation/gpu/drm-uapi.rst  |  25 +++---
 Documentation/gpu/introduction.rst  |  15 ++--
 arch/blackfin/include/asm/vga.h |   1 +
 drivers/dma-buf/dma-buf.c   |   9 +-
 drivers/dma-buf/dma-fence.c |  26 ++
 drivers/dma-buf/sync_debug.c|  17 ++--
 drivers/dma-buf/sync_file.c |   6 +-
 drivers/gpu/drm/Kconfig |  13 ++-
 drivers/gpu/drm/Makefile|   3 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu.h |   2 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c |   3 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c |   5 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c |   6 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c|   3 +-
 drivers/gpu/drm/armada/Makefile |   2 +
 drivers/gpu/drm/armada/armada_debugfs.c |   6 +-
 drivers/gpu/drm/armada/armada_drv.c |   6 --
 drivers/gpu/drm/ast/Kconfig |   2 +-
 drivers/gpu/drm/ast/ast_drv.h   |   2 +-
 drivers/gpu/drm/ast/ast_main.c  |   3 +-
 drivers/gpu/drm/bochs/Kconfig   |   2 +-
 

[PATCH 3/3] dma-fence: Introduce drm_fence_set_error() helper

[Sumit Semwal]

Hi Chris,

On 4 January 2017 at 19:42, Chris Wilson  wrote:
> The dma_fence.error field (formerly known as dma_fence.status) is an
> optional field that may be set by drivers before calling
> dma_fence_signal(). The field can be used to indicate that the fence was
> completed in err rather than with success, and is visible to other
> consumers of the fence and to userspace via sync_file.
>
> This patch renames the field from status to error so that its meaning is
> hopefully more clear (and distinct from dma_fence_get_status() which is
> a composite between the error state and signal state) and adds a helper
> that validates the preconditions of when it is suitable to adjust the
> error field.
>
> Signed-off-by: Chris Wilson 
> ---
>  drivers/dma-buf/dma-fence.c |  2 +-
>  include/linux/dma-fence.h   | 30 +-
>  2 files changed, 26 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/dma-buf/dma-fence.c b/drivers/dma-buf/dma-fence.c
> index 7d936d19e659..ee82f36cb25e 100644
> --- a/drivers/dma-buf/dma-fence.c
> +++ b/drivers/dma-buf/dma-fence.c
> @@ -559,7 +559,7 @@ dma_fence_init(struct dma_fence *fence, const struct 
> dma_fence_ops *ops,
> fence->context = context;
> fence->seqno = seqno;
> fence->flags = 0UL;
> -   fence->status = 0;
> +   fence->error = 0;
>
> trace_dma_fence_init(fence);
>  }
> diff --git a/include/linux/dma-fence.h b/include/linux/dma-fence.h
> index 19f7af905182..6048fa404e57 100644
> --- a/include/linux/dma-fence.h
> +++ b/include/linux/dma-fence.h
> @@ -47,7 +47,7 @@ struct dma_fence_cb;
>   * can be compared to decide which fence would be signaled later.
>   * @flags: A mask of DMA_FENCE_FLAG_* defined below
>   * @timestamp: Timestamp when the fence was signaled.
> - * @status: Optional, only valid if < 0, must be set before calling
> + * @error: Optional, only valid if < 0, must be set before calling
>   * dma_fence_signal, indicates that the fence has completed with an error.
>   *
>   * the flags member must be manipulated and read using the appropriate
> @@ -79,7 +79,7 @@ struct dma_fence {
> unsigned seqno;
> unsigned long flags;
> ktime_t timestamp;
> -   int status;
> +   int error;
>  };
>
>  enum dma_fence_flag_bits {
> @@ -133,7 +133,7 @@ struct dma_fence_cb {
>   * or some failure occurred that made it impossible to enable
>   * signaling. True indicates successful enabling.
>   *
> - * fence->status may be set in enable_signaling, but only when false is
> + * fence->error may be set in enable_signaling, but only when false is
>   * returned.
>   *
>   * Calling dma_fence_signal before enable_signaling is called allows
> @@ -145,7 +145,7 @@ struct dma_fence_cb {
>   * the second time will be a noop since it was already signaled.
>   *
>   * Notes on signaled:
> - * May set fence->status if returning true.
> + * May set fence->error if returning true.
>   *
>   * Notes on wait:
>   * Must not be NULL, set to dma_fence_default_wait for default 
> implementation.
> @@ -395,13 +395,33 @@ static inline struct dma_fence *dma_fence_later(struct 
> dma_fence *f1,
>  static inline int dma_fence_get_status_locked(struct dma_fence *fence)
>  {
> if (dma_fence_is_signaled_locked(fence))
> -   return fence->status < 0 ? fence->status : 1;
> +   return fence->error ?: 1;
> else
> return 0;
>  }
>
>  int dma_fence_get_status(struct dma_fence *fence);
>
> +/**
> + * dma_fence_set_error - flag an error condition on the fence
> + * @fence: [in]the dma_fence
> + * @error: [in]the error to store
> + *
> + * Drivers can supply an optional error status condition before they signal
> + * the fence, to indicate that the fence was completed due to an error
> + * rather than success. This must be set before signaling (so that the value
> + * is visible before any waiters on the signal callback are woken). This
> + * helper exists to help catching erroneous setting of #dma_fence.error.
> + */
> +static inline void dma_fence_set_error(struct dma_fence *fence,
> +  int error)
> +{
> +   BUG_ON(test_bit(DMA_FENCE_FLAG_SIGNALED_BIT, >flags));
> +   BUG_ON(error >= 0 || error < -MAX_ERRNO);
> +
> +   fence->error = error;
> +}
Sorry I missed this earlier, but are you sure you want to use a BUG_ON
here, and not a WARN_ON?
> +
>  signed long dma_fence_wait_timeout(struct dma_fence *,
>bool intr, signed long timeout);
>  signed long dma_fence_wait_any_timeout(struct dma_fence **fences,
> --
> 2.11.0
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

Best,
Sumit.

[PULL] drm-intel-next

[Daniel Vetter]

Hi Dave,

Because of the backmerge now 3 separate tags together:

drm-intel-next-2017-01-09:
More 4.11 stuff, holidays edition (i.e. not much):

- docs and cleanups for shared dpll code (Ander)
- some kerneldoc work (Chris)
- fbc by default on gen9+ too, yeah! (Paulo)
- fixes, polish and other small things all over gem code (Chris)
- and a few small things on top

Plus a backmerge, because Dave was enjoying time off too.

drm-intel-next-2016-12-26:
2nd round of stuff for 4.11:

- DP link rate fixes (DK)
- prep work for atomic wm updates on vlv/chv (Ville)
- platform enumeration cleanup (Jani)
- dsi fixes and cleaups (Hans de Goede)
- gen9 wm fixes (Mahesh Kumar)
- prep work for DP link failure fallback handling (Manasi)
- introduce GEM_WARN_ON (Matthew Auld)
- overlay fixes and cleanups (Ville)
- make is_lp apply to all modern/gen7+ atom-based platforms (Rodrigo)

Tons of small polish, fixes and cleanups all over. This time around
this is about half the patches!

drm-intel-next-2016-12-05:
First round of stuff for 4.10!

- refactor hangcheck/ban/reset stats code in prep for TDR (Mika)
- much more fancy perf monitoring support (Robert Bragg)
- lspcon fixes (Imre)
- rework plane ids to unconfuse the code (Ville)
- fix up cdclck/atomic state handling (Ville)
- debugobjects support for i915 fences (Chris)
- guc code cleanup (Arkadiusz Hiler)
- dp mst enabling, one more attempt (Libin)
- bugfixes for request resubmission after hangs (Chris)
- add basic geminilake support (Ander)
- switch more internal functions from drm_device to dev_priv (Tvrtko)

Cheers, Daniel


The following changes since commit 0c744ea4f77d72b3dcebb7a8f2684633ec79be88:

  Linux 4.10-rc2 (2017-01-01 14:31:53 -0800)

are available in the git repository at:

  git://anongit.freedesktop.org/git/drm-intel tags/drm-intel-next-2017-01-09

for you to fetch changes up to 5d799acdd057e4f10fdd09ade22028c83f829f3e:

  drm/i915: Update DRIVER_DATE to 20170109 (2017-01-09 10:12:02 +0100)


More 4.11 stuff, holidays edition (i.e. not much):

- docs and cleanups for shared dpll code (Ander)
- some kerneldoc work (Chris)
- fbc by default on gen9+ too, yeah! (Paulo)
- fixes, polish and other small things all over gem code (Chris)
- and a few small things on top

Plus a backmerge, because Dave was enjoying time off too.


A.Sunil Kamath (1):
  drm/i915: Use num_scalers instead of SKL_NUM_SCALERS in debugfs

Ander Conselvan de Oliveira (22):
  drm/i915: Pass dev_priv to intel_setup_outputs()
  drm/i915: Don't sanitize has_decoupled_mmio if platform is not broxton
  drm/i915/glk: Introduce Geminilake platform definition
  drm/i915/glk: Add Geminilake PCI IDs
  drm/i915/glk: Add a IS_GEN9_LP() macro
  drm/i915: Fix intel_psr_init() kerneldoc
  drm/i915/glk: Reuse broxton code for geminilake
  drm/i915/glk: Add power wells for Geminilake
  drm/i915/glk: Implement Geminilake DDI init sequence
  drm/i915/glk: Set DCC delay range 2 in PLL enable sequence
  drm/i915/glk: Reuse broxton's cdclk code for GLK
  drm/i915/glk: Allow dotclock up to 2 * cdclk on geminilake
  drm/i915/glk: Implement core display init/uninit sequence for geminilake
  drm/i915/glk: Configure number of sprite planes properly
  drm/i915: Introduce intel_release_shared_dpll()
  drm/i915: Rename intel_shared_dpll_commit() to _swap_state()
  drm/i915: Rename intel_shared_dpll_config to intel_shared_dpll_state
  drm/i915: Rename intel_shared_dpll->mode_set() to prepare()
  drm/i915: Update kerneldoc for intel_dpll_mgr.c
  drm/i915: Add dpll entrypoint for dumping hw state
  drm/i915: Move intel_atomic_get_shared_dpll_state() to intel_dpll_mgr.c
  drm/i915: Initialize num_scalers for skl and glk too

Arkadiusz Hiler (6):
  drm/i915: Rename intel_guc.h to intel_uc.h
  drm/i915/guc: Drop guc2host/host2guc from names
  drm/i915/guc: Move guc_{send,recv}() to intel_uc.c
  drm/i915/guc: Init send_mutex in intel_uc_init_early()
  drm/i915/guc: Remove spurious include
  drm/i915/guc: Drop comment on fwif autogeneration

Bob Paauwe (1):
  drm/i915/bxt: Correct dual-link MIPI port control.

Chris Wilson (74):
  drm/i915: Use user, not driver, DRM_DEBUG for 2 context ioctls
  drm/i915: Add a warning on shutdown if signal threads still active
  drm/i915: Don't deref context->file_priv ERR_PTR upon reset
  drm/i915: Disable hangcheck when wedged
  drm/i915: Complete requests in nop_submit_request
  drm/i915: Stop the machine as we install the wedged submit_request handler
  drm/i915/debugfs: Drop i915_hws_info
  drm/i915/debugfs: Increment return value of gt.next_seqno
  drm/i915: Use the precomputed value for whether to enable command parsing
  drm/i915/debugfs: Update pageflip information
  drm/i915: Add is-com

[Bug 99330] Severe flickering with Fiji on Wayland

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

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

--- Comment #3 from Ernst Sjöstrand  ---
I happen to have 2 4K monitors and a Fury as well actually.

I actually couldn't run Wayland at all for some time, perhaps it was fixed by:
mutter (3.22.2-3) unstable; urgency=medium

  [ Jeremy Bicha ]
  * Add git_flush_all_swap_notifies_on_idle.patch:
- Add patch from 3.22 branch that fixes freezes with multiple monitors
  on Wayland
landing in my Ubuntu repos.

Anyway, today I can run gnome shell in Wayland and I don't have any flickering.

Do you have the very latest firmware from
http://git.kernel.org/cgit/linux/kernel/git/firmware/linux-firmware.git ?

Guess the devs always like dmesg and xorg... wait nevermind that last part. :-)
Maybe journalctl /usr/bin/gnome-shell  ?

-- 
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/20170109/882b82fd/attachment.html>

[PATCH v2 2/2] drm: Move drm_clflush prototypes to drm_cache header file

[Gabriel Krisman Bertazi]

Continue to clean up drmP.h by moving the cache flushing functions into
it's own header file.

Compile-tested only

Signed-off-by: Gabriel Krisman Bertazi 
---
 drivers/gpu/drm/i915/i915_drv.h | 1 +
 drivers/gpu/drm/vgem/vgem_drv.h | 1 +
 include/drm/drmP.h  | 5 -
 include/drm/drm_cache.h | 4 
 4 files changed, 6 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 89dbe55077f5..7143f28b5cf1 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -49,6 +49,7 @@
 #include  /* for struct drm_dma_handle */
 #include 
 #include 
+#include 

 #include "i915_params.h"
 #include "i915_reg.h"
diff --git a/drivers/gpu/drm/vgem/vgem_drv.h b/drivers/gpu/drm/vgem/vgem_drv.h
index 1f8798ad329c..cb59c7ab98b9 100644
--- a/drivers/gpu/drm/vgem/vgem_drv.h
+++ b/drivers/gpu/drm/vgem/vgem_drv.h
@@ -31,6 +31,7 @@

 #include 
 #include 
+#include 

 #include 

diff --git a/include/drm/drmP.h b/include/drm/drmP.h
index ffa8b6d6d367..6d71083d9124 100644
--- a/include/drm/drmP.h
+++ b/include/drm/drmP.h
@@ -731,11 +731,6 @@ int drm_noop(struct drm_device *dev, void *data,
 int drm_invalid_op(struct drm_device *dev, void *data,
   struct drm_file *file_priv);

-/* Cache management (drm_cache.c) */
-void drm_clflush_pages(struct page *pages[], unsigned long num_pages);
-void drm_clflush_sg(struct sg_table *st);
-void drm_clflush_virt_range(void *addr, unsigned long length);
-
 /*
  * These are exported to drivers so that they can implement fencing using
  * DMA quiscent + idle. DMA quiescent usually requires the hardware lock.
diff --git a/include/drm/drm_cache.h b/include/drm/drm_cache.h
index cebecff536a3..beab0f0d0cfb 100644
--- a/include/drm/drm_cache.h
+++ b/include/drm/drm_cache.h
@@ -33,7 +33,11 @@
 #ifndef _DRM_CACHE_H_
 #define _DRM_CACHE_H_

+#include 
+
 void drm_clflush_pages(struct page *pages[], unsigned long num_pages);
+void drm_clflush_sg(struct sg_table *st);
+void drm_clflush_virt_range(void *addr, unsigned long length);

 static inline bool drm_arch_can_wc_memory(void)
 {
-- 
2.11.0

[PATCH v2 1/2] drm: Document drm_cache interface

[Gabriel Krisman Bertazi]

Notice that this uncovers an issue with the kernel-doc handling of array
arguments, causing the first parameter of drm_clflush_pages() to not
show up in the rst-generated page.  A proposed fix is under review in
linux-doc: 

Changes since v1:
 - Add section to drm-mm.rst.
 - Fix kernel-doc style issues.
 - s/memory/kernel memory/.

Signed-off-by: Gabriel Krisman Bertazi 
---
 Documentation/gpu/drm-mm.rst |  6 ++
 drivers/gpu/drm/drm_cache.c  | 23 +++
 2 files changed, 29 insertions(+)

diff --git a/Documentation/gpu/drm-mm.rst b/Documentation/gpu/drm-mm.rst
index 1ea94fc86caa..91d82f39fbf4 100644
--- a/Documentation/gpu/drm-mm.rst
+++ b/Documentation/gpu/drm-mm.rst
@@ -470,3 +470,9 @@ DRM MM Range Allocator Function References

 .. kernel-doc:: include/drm/drm_mm.h
:internal:
+
+DRM Cache Handling
+==
+
+.. kernel-doc:: drivers/gpu/drm/drm_cache.c
+   :export:
diff --git a/drivers/gpu/drm/drm_cache.c b/drivers/gpu/drm/drm_cache.c
index a7916e5f8864..5066638928ec 100644
--- a/drivers/gpu/drm/drm_cache.c
+++ b/drivers/gpu/drm/drm_cache.c
@@ -67,6 +67,14 @@ static void drm_cache_flush_clflush(struct page *pages[],
 }
 #endif

+/**
+ * drm_clflush_pages - Flush dcache lines of a set of pages.
+ * @pages: List of pages to be flushed.
+ * @num_pages: Number of pages in the array.
+ *
+ * Flush every data cache line entry that points to an address belonging
+ * to a page in the array.
+ */
 void
 drm_clflush_pages(struct page *pages[], unsigned long num_pages)
 {
@@ -101,6 +109,13 @@ drm_clflush_pages(struct page *pages[], unsigned long 
num_pages)
 }
 EXPORT_SYMBOL(drm_clflush_pages);

+/**
+ * drm_clflush_sg - Flush dcache lines pointing to a scather-gather.
+ * @st: struct sg_table.
+ *
+ * Flush every data cache line entry that points to an address in the
+ * sg.
+ */
 void
 drm_clflush_sg(struct sg_table *st)
 {
@@ -125,6 +140,14 @@ drm_clflush_sg(struct sg_table *st)
 }
 EXPORT_SYMBOL(drm_clflush_sg);

+/**
+ * drm_clflush_virt_range - Flush dcache lines of a region
+ * @addr: Initial kernel memory address.
+ * @length: Region size.
+ *
+ * Flush every data cache line entry that points to an address in the
+ * region requested.
+ */
 void
 drm_clflush_virt_range(void *addr, unsigned long length)
 {
-- 
2.11.0

[PATCH 4/4] drm: imx: remove struct imx_drm_crtc and imx_drm_crtc_helper_funcs

[Shawn Guo]

From: Shawn Guo 

With the vblank hooks in struct drm_crtc_funcs, we do not need to
maintain the CRTC specific vblank callbacks with struct
imx_drm_crtc_helper_funcs any more.  By moving the stuff that we
currently do in imx_drm_add_crtc(), like of_node setting and
drm_crtc_helper_add()/drm_crtc_init_with_planes() invoking, we can kill
things like struct imx_drm_crtc, imx_drm_crtc_helper_funcs and related
functions completely.

Functions ipu_enable_vblank() and ipu_disable_vblank() are moved around
without changes, only for saving the forward declarations.

Signed-off-by: Shawn Guo 
Cc: Philipp Zabel 
---
 drivers/gpu/drm/imx/imx-drm-core.c | 103 +
 drivers/gpu/drm/imx/imx-drm.h  |  13 -
 drivers/gpu/drm/imx/ipuv3-crtc.c   |  58 -
 3 files changed, 24 insertions(+), 150 deletions(-)

diff --git a/drivers/gpu/drm/imx/imx-drm-core.c 
b/drivers/gpu/drm/imx/imx-drm-core.c
index 33404295b447..934ca32cf8f4 100644
--- a/drivers/gpu/drm/imx/imx-drm-core.c
+++ b/drivers/gpu/drm/imx/imx-drm-core.c
@@ -40,17 +40,11 @@ struct imx_drm_component {

 struct imx_drm_device {
struct drm_device   *drm;
-   struct imx_drm_crtc *crtc[MAX_CRTC];
unsigned intpipes;
struct drm_fbdev_cma*fbhelper;
struct drm_atomic_state *state;
 };

-struct imx_drm_crtc {
-   struct drm_crtc *crtc;
-   struct imx_drm_crtc_helper_funcsimx_drm_helper_funcs;
-};
-
 #if IS_ENABLED(CONFIG_DRM_FBDEV_EMULATION)
 static int legacyfb_depth = 16;
 module_param(legacyfb_depth, int, 0444);
@@ -63,38 +57,6 @@ static void imx_drm_driver_lastclose(struct drm_device *drm)
drm_fbdev_cma_restore_mode(imxdrm->fbhelper);
 }

-static int imx_drm_enable_vblank(struct drm_device *drm, unsigned int pipe)
-{
-   struct imx_drm_device *imxdrm = drm->dev_private;
-   struct imx_drm_crtc *imx_drm_crtc = imxdrm->crtc[pipe];
-   int ret;
-
-   if (!imx_drm_crtc)
-   return -EINVAL;
-
-   if (!imx_drm_crtc->imx_drm_helper_funcs.enable_vblank)
-   return -ENOSYS;
-
-   ret = imx_drm_crtc->imx_drm_helper_funcs.enable_vblank(
-   imx_drm_crtc->crtc);
-
-   return ret;
-}
-
-static void imx_drm_disable_vblank(struct drm_device *drm, unsigned int pipe)
-{
-   struct imx_drm_device *imxdrm = drm->dev_private;
-   struct imx_drm_crtc *imx_drm_crtc = imxdrm->crtc[pipe];
-
-   if (!imx_drm_crtc)
-   return;
-
-   if (!imx_drm_crtc->imx_drm_helper_funcs.disable_vblank)
-   return;
-
-   imx_drm_crtc->imx_drm_helper_funcs.disable_vblank(imx_drm_crtc->crtc);
-}
-
 static const struct file_operations imx_drm_driver_fops = {
.owner = THIS_MODULE,
.open = drm_open,
@@ -180,67 +142,6 @@ static void imx_drm_atomic_commit_tail(struct 
drm_atomic_state *state)
.atomic_commit_tail = imx_drm_atomic_commit_tail,
 };

-/*
- * imx_drm_add_crtc - add a new crtc
- */
-int imx_drm_add_crtc(struct drm_device *drm, struct drm_crtc *crtc,
-   struct imx_drm_crtc **new_crtc, struct drm_plane *primary_plane,
-   const struct imx_drm_crtc_helper_funcs *imx_drm_helper_funcs,
-   struct device_node *port)
-{
-   struct imx_drm_device *imxdrm = drm->dev_private;
-   struct imx_drm_crtc *imx_drm_crtc;
-
-   /*
-* The vblank arrays are dimensioned by MAX_CRTC - we can't
-* pass IDs greater than this to those functions.
-*/
-   if (imxdrm->pipes >= MAX_CRTC)
-   return -EINVAL;
-
-   if (imxdrm->drm->open_count)
-   return -EBUSY;
-
-   imx_drm_crtc = kzalloc(sizeof(*imx_drm_crtc), GFP_KERNEL);
-   if (!imx_drm_crtc)
-   return -ENOMEM;
-
-   imx_drm_crtc->imx_drm_helper_funcs = *imx_drm_helper_funcs;
-   imx_drm_crtc->crtc = crtc;
-
-   crtc->port = port;
-
-   imxdrm->crtc[imxdrm->pipes++] = imx_drm_crtc;
-
-   *new_crtc = imx_drm_crtc;
-
-   drm_crtc_helper_add(crtc,
-   imx_drm_crtc->imx_drm_helper_funcs.crtc_helper_funcs);
-
-   drm_crtc_init_with_planes(drm, crtc, primary_plane, NULL,
-   imx_drm_crtc->imx_drm_helper_funcs.crtc_funcs, NULL);
-
-   return 0;
-}
-EXPORT_SYMBOL_GPL(imx_drm_add_crtc);
-
-/*
- * imx_drm_remove_crtc - remove a crtc
- */
-int imx_drm_remove_crtc(struct imx_drm_crtc *imx_drm_crtc)
-{
-   struct imx_drm_device *imxdrm = imx_drm_crtc->crtc->dev->dev_private;
-   unsigned int pipe = drm_crtc_index(imx_drm_crtc->crtc);
-
-   drm_crtc_cleanup(imx_drm_crtc->crtc);
-
-   imxdrm->crtc[pipe] = NULL;
-
-   kfree(imx_drm_crtc);
-
-   return 0;
-}
-EXPORT_SYMBOL_GPL(imx_drm_remove_crtc);

 int imx_drm_encoder_parse_of(struct drm_device *drm,
struct drm_encoder 

[PATCH 3/4] drm: rockchip: remove struct rockchip_crtc_funcs

[Shawn Guo]

From: Shawn Guo 

With the vblank hooks in struct drm_crtc_funcs, we do not need to
maintain struct rockchip_crtc_funcs and the related registration
functions.  Remove them.

Signed-off-by: Shawn Guo 
Cc: Mark Yao 
---
 drivers/gpu/drm/rockchip/rockchip_drm_drv.c | 53 ++---
 drivers/gpu/drm/rockchip/rockchip_drm_drv.h | 14 
 drivers/gpu/drm/rockchip/rockchip_drm_vop.c |  9 ++---
 3 files changed, 4 insertions(+), 72 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_drv.c 
b/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
index c30d649cb147..51a21c5e3b78 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
@@ -74,55 +74,6 @@ void rockchip_drm_dma_detach_device(struct drm_device 
*drm_dev,
arm_iommu_detach_device(dev);
 }

-int rockchip_register_crtc_funcs(struct drm_crtc *crtc,
-const struct rockchip_crtc_funcs *crtc_funcs)
-{
-   int pipe = drm_crtc_index(crtc);
-   struct rockchip_drm_private *priv = crtc->dev->dev_private;
-
-   if (pipe >= ROCKCHIP_MAX_CRTC)
-   return -EINVAL;
-
-   priv->crtc_funcs[pipe] = crtc_funcs;
-
-   return 0;
-}
-
-void rockchip_unregister_crtc_funcs(struct drm_crtc *crtc)
-{
-   int pipe = drm_crtc_index(crtc);
-   struct rockchip_drm_private *priv = crtc->dev->dev_private;
-
-   if (pipe >= ROCKCHIP_MAX_CRTC)
-   return;
-
-   priv->crtc_funcs[pipe] = NULL;
-}
-
-static int rockchip_drm_crtc_enable_vblank(struct drm_device *dev,
-  unsigned int pipe)
-{
-   struct rockchip_drm_private *priv = dev->dev_private;
-   struct drm_crtc *crtc = drm_crtc_from_index(dev, pipe);
-
-   if (crtc && priv->crtc_funcs[pipe] &&
-   priv->crtc_funcs[pipe]->enable_vblank)
-   return priv->crtc_funcs[pipe]->enable_vblank(crtc);
-
-   return 0;
-}
-
-static void rockchip_drm_crtc_disable_vblank(struct drm_device *dev,
-unsigned int pipe)
-{
-   struct rockchip_drm_private *priv = dev->dev_private;
-   struct drm_crtc *crtc = drm_crtc_from_index(dev, pipe);
-
-   if (crtc && priv->crtc_funcs[pipe] &&
-   priv->crtc_funcs[pipe]->enable_vblank)
-   priv->crtc_funcs[pipe]->disable_vblank(crtc);
-}
-
 static int rockchip_drm_bind(struct device *dev)
 {
struct drm_device *drm_dev;
@@ -271,8 +222,8 @@ static void rockchip_drm_lastclose(struct drm_device *dev)
  DRIVER_PRIME | DRIVER_ATOMIC,
.lastclose  = rockchip_drm_lastclose,
.get_vblank_counter = drm_vblank_no_hw_counter,
-   .enable_vblank  = rockchip_drm_crtc_enable_vblank,
-   .disable_vblank = rockchip_drm_crtc_disable_vblank,
+   .enable_vblank  = drm_crtc_enable_vblank,
+   .disable_vblank = drm_crtc_disable_vblank,
.gem_vm_ops = _gem_cma_vm_ops,
.gem_free_object_unlocked = rockchip_gem_free_object,
.dumb_create= rockchip_gem_dumb_create,
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_drv.h 
b/drivers/gpu/drm/rockchip/rockchip_drm_drv.h
index fb6226cf84b7..9f9bc959b108 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_drv.h
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_drv.h
@@ -31,16 +31,6 @@
 struct drm_device;
 struct drm_connector;

-/*
- * Rockchip drm private crtc funcs.
- * @enable_vblank: enable crtc vblank irq.
- * @disable_vblank: disable crtc vblank irq.
- */
-struct rockchip_crtc_funcs {
-   int (*enable_vblank)(struct drm_crtc *crtc);
-   void (*disable_vblank)(struct drm_crtc *crtc);
-};
-
 struct rockchip_crtc_state {
struct drm_crtc_state base;
int output_type;
@@ -58,16 +48,12 @@ struct rockchip_crtc_state {
 struct rockchip_drm_private {
struct drm_fb_helper fbdev_helper;
struct drm_gem_object *fbdev_bo;
-   const struct rockchip_crtc_funcs *crtc_funcs[ROCKCHIP_MAX_CRTC];
struct drm_atomic_state *state;

struct list_head psr_list;
spinlock_t psr_list_lock;
 };

-int rockchip_register_crtc_funcs(struct drm_crtc *crtc,
-const struct rockchip_crtc_funcs *crtc_funcs);
-void rockchip_unregister_crtc_funcs(struct drm_crtc *crtc);
 int rockchip_drm_dma_attach_device(struct drm_device *drm_dev,
   struct device *dev);
 void rockchip_drm_dma_detach_device(struct drm_device *drm_dev,
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c 
b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
index c7eba305c488..a61a7e1ce9a4 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
@@ -853,11 +853,6 @@ static void vop_crtc_disable_vblank(struct drm_crtc *crtc)
spin_unlock_irqrestore(>irq_lock, flags);
 }

-static const 

[PATCH 2/4] drm: zte: zx_vou_enable[disable]_vblank can be static

[Shawn Guo]

From: Shawn Guo 

With the vblank hooks in struct drm_crtc_funcs, we can directly use the
drm_crtc pointer passed in as parameter and make the functions static.

The functions are moved around to save forward delarations.

Signed-off-by: Shawn Guo 
---
 drivers/gpu/drm/zte/zx_drm_drv.c |  4 +--
 drivers/gpu/drm/zte/zx_vou.c | 61 +++-
 drivers/gpu/drm/zte/zx_vou.h |  3 --
 3 files changed, 25 insertions(+), 43 deletions(-)

diff --git a/drivers/gpu/drm/zte/zx_drm_drv.c b/drivers/gpu/drm/zte/zx_drm_drv.c
index 3e76f72c92ff..6489d720baef 100644
--- a/drivers/gpu/drm/zte/zx_drm_drv.c
+++ b/drivers/gpu/drm/zte/zx_drm_drv.c
@@ -72,8 +72,8 @@ static void zx_drm_lastclose(struct drm_device *drm)
   DRIVER_ATOMIC,
.lastclose = zx_drm_lastclose,
.get_vblank_counter = drm_vblank_no_hw_counter,
-   .enable_vblank = zx_vou_enable_vblank,
-   .disable_vblank = zx_vou_disable_vblank,
+   .enable_vblank = drm_crtc_enable_vblank,
+   .disable_vblank = drm_crtc_disable_vblank,
.gem_free_object = drm_gem_cma_free_object,
.gem_vm_ops = _gem_cma_vm_ops,
.dumb_create = drm_gem_cma_dumb_create,
diff --git a/drivers/gpu/drm/zte/zx_vou.c b/drivers/gpu/drm/zte/zx_vou.c
index a86e3a5852a2..424f4f133067 100644
--- a/drivers/gpu/drm/zte/zx_vou.c
+++ b/drivers/gpu/drm/zte/zx_vou.c
@@ -281,6 +281,27 @@ static void zx_crtc_atomic_flush(struct drm_crtc *crtc,
.atomic_flush = zx_crtc_atomic_flush,
 };

+static int zx_vou_enable_vblank(struct drm_crtc *crtc)
+{
+   struct zx_crtc *zcrtc = to_zx_crtc(crtc);
+   struct zx_vou_hw *vou = crtc_to_vou(crtc);
+   u32 int_frame_mask = zcrtc->bits->int_frame_mask;
+
+   zx_writel_mask(vou->timing + TIMING_INT_CTRL, int_frame_mask,
+  int_frame_mask);
+
+   return 0;
+}
+
+static void zx_vou_disable_vblank(struct drm_crtc *crtc)
+{
+   struct zx_crtc *zcrtc = to_zx_crtc(crtc);
+   struct zx_vou_hw *vou = crtc_to_vou(crtc);
+
+   zx_writel_mask(vou->timing + TIMING_INT_CTRL,
+  zcrtc->bits->int_frame_mask, 0);
+}
+
 static const struct drm_crtc_funcs zx_crtc_funcs = {
.destroy = drm_crtc_cleanup,
.set_config = drm_atomic_helper_set_config,
@@ -288,6 +309,8 @@ static void zx_crtc_atomic_flush(struct drm_crtc *crtc,
.reset = drm_atomic_helper_crtc_reset,
.atomic_duplicate_state = drm_atomic_helper_crtc_duplicate_state,
.atomic_destroy_state = drm_atomic_helper_crtc_destroy_state,
+   .enable_vblank = zx_vou_enable_vblank,
+   .disable_vblank = zx_vou_disable_vblank,
 };

 static int zx_crtc_init(struct drm_device *drm, struct zx_vou_hw *vou,
@@ -355,44 +378,6 @@ static int zx_crtc_init(struct drm_device *drm, struct 
zx_vou_hw *vou,
return 0;
 }

-int zx_vou_enable_vblank(struct drm_device *drm, unsigned int pipe)
-{
-   struct drm_crtc *crtc;
-   struct zx_crtc *zcrtc;
-   struct zx_vou_hw *vou;
-   u32 int_frame_mask;
-
-   crtc = drm_crtc_from_index(drm, pipe);
-   if (!crtc)
-   return 0;
-
-   vou = crtc_to_vou(crtc);
-   zcrtc = to_zx_crtc(crtc);
-   int_frame_mask = zcrtc->bits->int_frame_mask;
-
-   zx_writel_mask(vou->timing + TIMING_INT_CTRL, int_frame_mask,
-  int_frame_mask);
-
-   return 0;
-}
-
-void zx_vou_disable_vblank(struct drm_device *drm, unsigned int pipe)
-{
-   struct drm_crtc *crtc;
-   struct zx_crtc *zcrtc;
-   struct zx_vou_hw *vou;
-
-   crtc = drm_crtc_from_index(drm, pipe);
-   if (!crtc)
-   return;
-
-   vou = crtc_to_vou(crtc);
-   zcrtc = to_zx_crtc(crtc);
-
-   zx_writel_mask(vou->timing + TIMING_INT_CTRL,
-  zcrtc->bits->int_frame_mask, 0);
-}
-
 static irqreturn_t vou_irq_handler(int irq, void *dev_id)
 {
struct zx_vou_hw *vou = dev_id;
diff --git a/drivers/gpu/drm/zte/zx_vou.h b/drivers/gpu/drm/zte/zx_vou.h
index 349e06cd86f4..644e1d81a393 100644
--- a/drivers/gpu/drm/zte/zx_vou.h
+++ b/drivers/gpu/drm/zte/zx_vou.h
@@ -40,7 +40,4 @@ struct vou_inf {
 void vou_inf_enable(const struct vou_inf *inf, struct drm_crtc *crtc);
 void vou_inf_disable(const struct vou_inf *inf, struct drm_crtc *crtc);

-int zx_vou_enable_vblank(struct drm_device *drm, unsigned int pipe);
-void zx_vou_disable_vblank(struct drm_device *drm, unsigned int pipe);
-
 #endif /* __ZX_VOU_H__ */
-- 
1.9.1

[PATCH 1/4] drm: add vblank hooks to struct drm_crtc_funcs

[Shawn Guo]

From: Shawn Guo 

The vblank is mostly CRTC specific and implemented as part of CRTC
driver.  So having vblank hooks in struct drm_crtc_funcs should
generally help to reduce code from client drivers in implementing
drm_driver's vblank callbacks.

Signed-off-by: Shawn Guo 
---
 drivers/gpu/drm/drm_crtc.c | 36 
 include/drm/drm_crtc.h | 21 +
 2 files changed, 57 insertions(+)

diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 85a7452d0fb4..59ff00f48101 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -70,6 +70,42 @@ struct drm_crtc *drm_crtc_from_index(struct drm_device *dev, 
int idx)
 EXPORT_SYMBOL(drm_crtc_from_index);

 /**
+ * drm_crtc_enable_vblank - vblank enable callback helper
+ * @dev: DRM device
+ * @pipe: CRTC index
+ *
+ * It's a helper function as the generic vblank enable callback implementation,
+ * which calls into _crtc_funcs.enable_vblank function.
+ */
+int drm_crtc_enable_vblank(struct drm_device *dev, unsigned int pipe)
+{
+   struct drm_crtc *crtc = drm_crtc_from_index(dev, pipe);
+
+   if (crtc && crtc->funcs && crtc->funcs->enable_vblank)
+   return crtc->funcs->enable_vblank(crtc);
+
+   return 0;
+}
+EXPORT_SYMBOL(drm_crtc_enable_vblank);
+
+/**
+ * drm_crtc_disable_vblank - vblank disable callback helper
+ * @dev: DRM device
+ * @pipe: CRTC index
+ *
+ * It's a helper function as the generic vblank disable callback 
implementation,
+ * which calls into _crtc_funcs.disable_vblank function.
+ */
+void drm_crtc_disable_vblank(struct drm_device *dev, unsigned int pipe)
+{
+   struct drm_crtc *crtc = drm_crtc_from_index(dev, pipe);
+
+   if (crtc && crtc->funcs && crtc->funcs->disable_vblank)
+   return crtc->funcs->disable_vblank(crtc);
+}
+EXPORT_SYMBOL(drm_crtc_disable_vblank);
+
+/**
  * drm_crtc_force_disable - Forcibly turn off a CRTC
  * @crtc: CRTC to turn off
  *
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index a5627eb8621f..20874b3903a6 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -599,6 +599,25 @@ struct drm_crtc_funcs {
 */
void (*atomic_print_state)(struct drm_printer *p,
   const struct drm_crtc_state *state);
+
+   /**
+* @enable_vblank:
+*
+* Enable vblank interrupts for the CRTC.
+*
+* Returns:
+*
+* Zero on success, appropriate errno if the vblank interrupt cannot
+* be enabled.
+*/
+   int (*enable_vblank)(struct drm_crtc *crtc);
+
+   /**
+* @disable_vblank:
+*
+* Disable vblank interrupts for the CRTC.
+*/
+   void (*disable_vblank)(struct drm_crtc *crtc);
 };

 /**
@@ -831,6 +850,8 @@ void drm_crtc_get_hv_timing(const struct drm_display_mode 
*mode,

 int drm_mode_set_config_internal(struct drm_mode_set *set);
 struct drm_crtc *drm_crtc_from_index(struct drm_device *dev, int idx);
+int drm_crtc_enable_vblank(struct drm_device *dev, unsigned int pipe);
+void drm_crtc_disable_vblank(struct drm_device *dev, unsigned int pipe);

 /* Helpers */
 static inline struct drm_crtc *drm_crtc_find(struct drm_device *dev,
-- 
1.9.1

[PATCH 0/4] Add vblank hooks to struct drm_crtc_funcs

[Shawn Guo]

From: Shawn Guo 

Although it can help to clean up driver code quite a bit, I'm not sure
it's been done in the right way.  So the series can be treated as RFC.

When I was going through DRM drivers for candidates of using
drm_crtc_from_index() helper, I found vblank handling is mostly a CRTC
specific thing.  A few drivers (imx and rockchip) even have defined
their own hooks and registration functions to handle per-CRTC vblank
callbacks.  The series is trying to demonstrate how these driver code
can be cleaned up by simply adding a couple of vblank hooks to
struct drm_crtc_funcs.

The ZTE DRM driver doesn't have per-CRTC vblank callbacks.  It uses the
same pair of vblank functions for both CRTCs.  But it's being included
here to show the benefit of saving vblank function exporting.

Rockchip is compile-tested, while ZTE and IMX drivers are tested on
hardware.

Shawn Guo (4):
  drm: add vblank hooks to struct drm_crtc_funcs
  drm: zte: zx_vou_enable[disable]_vblank can be static
  drm: rockchip: remove struct rockchip_crtc_funcs
  drm: imx: remove struct imx_drm_crtc and imx_drm_crtc_helper_funcs

 drivers/gpu/drm/drm_crtc.c  |  36 ++
 drivers/gpu/drm/imx/imx-drm-core.c  | 103 +---
 drivers/gpu/drm/imx/imx-drm.h   |  13 
 drivers/gpu/drm/imx/ipuv3-crtc.c|  58 ++--
 drivers/gpu/drm/rockchip/rockchip_drm_drv.c |  53 +-
 drivers/gpu/drm/rockchip/rockchip_drm_drv.h |  14 
 drivers/gpu/drm/rockchip/rockchip_drm_vop.c |   9 +--
 drivers/gpu/drm/zte/zx_drm_drv.c|   4 +-
 drivers/gpu/drm/zte/zx_vou.c|  61 +++-
 drivers/gpu/drm/zte/zx_vou.h|   3 -
 include/drm/drm_crtc.h  |  21 ++
 11 files changed, 110 insertions(+), 265 deletions(-)

-- 
1.9.1

[Bug 99236] System (seems to) completely freeze when interacting with java swing applications.

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

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

--- Comment #11 from Vitaly Ostrosablin  ---
Further narrowed date range: between Dec 6 and Dec 12.

-- 
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/20170109/be13de9d/attachment.html>

[PATCH 6/6] drm: vc4: use crtc helper drm_crtc_from_index()

[Shawn Guo]

From: Shawn Guo 

Use drm_crtc_from_index() to find drm_crtc for given index, so that we
do not need to maintain a pointer array in struct vc4_dev.

Signed-off-by: Shawn Guo 
Cc: Eric Anholt 
---
 drivers/gpu/drm/vc4/vc4_crtc.c | 17 +++--
 drivers/gpu/drm/vc4/vc4_drv.h  |  1 -
 2 files changed, 7 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/vc4/vc4_crtc.c b/drivers/gpu/drm/vc4/vc4_crtc.c
index a0fd3e66bc4b..75b708b36890 100644
--- a/drivers/gpu/drm/vc4/vc4_crtc.c
+++ b/drivers/gpu/drm/vc4/vc4_crtc.c
@@ -156,7 +156,8 @@ int vc4_crtc_get_scanoutpos(struct drm_device *dev, 
unsigned int crtc_id,
const struct drm_display_mode *mode)
 {
struct vc4_dev *vc4 = to_vc4_dev(dev);
-   struct vc4_crtc *vc4_crtc = vc4->crtc[crtc_id];
+   struct drm_crtc *crtc = drm_crtc_from_index(dev, crtc_id);
+   struct vc4_crtc *vc4_crtc = to_vc4_crtc(crtc);
u32 val;
int fifo_lines;
int vblank_lines;
@@ -272,9 +273,7 @@ int vc4_crtc_get_vblank_timestamp(struct drm_device *dev, 
unsigned int crtc_id,
  int *max_error, struct timeval *vblank_time,
  unsigned flags)
 {
-   struct vc4_dev *vc4 = to_vc4_dev(dev);
-   struct vc4_crtc *vc4_crtc = vc4->crtc[crtc_id];
-   struct drm_crtc *crtc = _crtc->base;
+   struct drm_crtc *crtc = drm_crtc_from_index(dev, crtc_id);
struct drm_crtc_state *state = crtc->state;

/* Helper routine in DRM core does all the work: */
@@ -652,8 +651,8 @@ static void vc4_crtc_atomic_flush(struct drm_crtc *crtc,

 int vc4_enable_vblank(struct drm_device *dev, unsigned int crtc_id)
 {
-   struct vc4_dev *vc4 = to_vc4_dev(dev);
-   struct vc4_crtc *vc4_crtc = vc4->crtc[crtc_id];
+   struct drm_crtc *crtc = drm_crtc_from_index(dev, crtc_id);
+   struct vc4_crtc *vc4_crtc = to_vc4_crtc(crtc);

CRTC_WRITE(PV_INTEN, PV_INT_VFP_START);

@@ -662,8 +661,8 @@ int vc4_enable_vblank(struct drm_device *dev, unsigned int 
crtc_id)

 void vc4_disable_vblank(struct drm_device *dev, unsigned int crtc_id)
 {
-   struct vc4_dev *vc4 = to_vc4_dev(dev);
-   struct vc4_crtc *vc4_crtc = vc4->crtc[crtc_id];
+   struct drm_crtc *crtc = drm_crtc_from_index(dev, crtc_id);
+   struct vc4_crtc *vc4_crtc = to_vc4_crtc(crtc);

CRTC_WRITE(PV_INTEN, 0);
 }
@@ -937,7 +936,6 @@ static int vc4_crtc_bind(struct device *dev, struct device 
*master, void *data)
 {
struct platform_device *pdev = to_platform_device(dev);
struct drm_device *drm = dev_get_drvdata(master);
-   struct vc4_dev *vc4 = to_vc4_dev(drm);
struct vc4_crtc *vc4_crtc;
struct drm_crtc *crtc;
struct drm_plane *primary_plane, *cursor_plane, *destroy_plane, *temp;
@@ -975,7 +973,6 @@ static int vc4_crtc_bind(struct device *dev, struct device 
*master, void *data)
  _crtc_funcs, NULL);
drm_crtc_helper_add(crtc, _crtc_helper_funcs);
primary_plane->crtc = crtc;
-   vc4->crtc[drm_crtc_index(crtc)] = vc4_crtc;
vc4_crtc->channel = vc4_crtc->data->hvs_channel;
drm_mode_crtc_set_gamma_size(crtc, ARRAY_SIZE(vc4_crtc->lut_r));

diff --git a/drivers/gpu/drm/vc4/vc4_drv.h b/drivers/gpu/drm/vc4/vc4_drv.h
index b5c4bb14d0d1..5d8486cbd574 100644
--- a/drivers/gpu/drm/vc4/vc4_drv.h
+++ b/drivers/gpu/drm/vc4/vc4_drv.h
@@ -14,7 +14,6 @@ struct vc4_dev {

struct vc4_hdmi *hdmi;
struct vc4_hvs *hvs;
-   struct vc4_crtc *crtc[3];
struct vc4_v3d *v3d;
struct vc4_dpi *dpi;
struct vc4_vec *vec;
-- 
1.9.1

[PATCH 5/6] drm: tegra: use crtc helper drm_crtc_from_index()

[Shawn Guo]

From: Shawn Guo 

Function tegra_crtc_from_pipe() does the exactly same thing as what
crtc helper drm_crtc_from_index() provides.  Use the helper to save
some code.

Signed-off-by: Shawn Guo 
Cc: Thierry Reding 
---
 drivers/gpu/drm/tegra/drm.c | 19 +++
 1 file changed, 3 insertions(+), 16 deletions(-)

diff --git a/drivers/gpu/drm/tegra/drm.c b/drivers/gpu/drm/tegra/drm.c
index b8be3ee4d3b8..e8ad2c1bfc76 100644
--- a/drivers/gpu/drm/tegra/drm.c
+++ b/drivers/gpu/drm/tegra/drm.c
@@ -806,23 +806,10 @@ static int tegra_gem_get_flags(struct drm_device *drm, 
void *data,
.llseek = noop_llseek,
 };

-static struct drm_crtc *tegra_crtc_from_pipe(struct drm_device *drm,
-unsigned int pipe)
-{
-   struct drm_crtc *crtc;
-
-   list_for_each_entry(crtc, >mode_config.crtc_list, head) {
-   if (pipe == drm_crtc_index(crtc))
-   return crtc;
-   }
-
-   return NULL;
-}
-
 static u32 tegra_drm_get_vblank_counter(struct drm_device *drm,
unsigned int pipe)
 {
-   struct drm_crtc *crtc = tegra_crtc_from_pipe(drm, pipe);
+   struct drm_crtc *crtc = drm_crtc_from_index(drm, pipe);
struct tegra_dc *dc = to_tegra_dc(crtc);

if (!crtc)
@@ -833,7 +820,7 @@ static u32 tegra_drm_get_vblank_counter(struct drm_device 
*drm,

 static int tegra_drm_enable_vblank(struct drm_device *drm, unsigned int pipe)
 {
-   struct drm_crtc *crtc = tegra_crtc_from_pipe(drm, pipe);
+   struct drm_crtc *crtc = drm_crtc_from_index(drm, pipe);
struct tegra_dc *dc = to_tegra_dc(crtc);

if (!crtc)
@@ -846,7 +833,7 @@ static int tegra_drm_enable_vblank(struct drm_device *drm, 
unsigned int pipe)

 static void tegra_drm_disable_vblank(struct drm_device *drm, unsigned int pipe)
 {
-   struct drm_crtc *crtc = tegra_crtc_from_pipe(drm, pipe);
+   struct drm_crtc *crtc = drm_crtc_from_index(drm, pipe);
struct tegra_dc *dc = to_tegra_dc(crtc);

if (crtc)
-- 
1.9.1

[PATCH 4/6] drm: nouveau: use crtc helper drm_crtc_from_index()

[Shawn Guo]

From: Shawn Guo 

Use drm_crtc_from_index() to find drm_crtc for given index.

Signed-off-by: Shawn Guo 
Cc: Ben Skeggs 
---
 drivers/gpu/drm/nouveau/nouveau_display.c | 33 +--
 1 file changed, 18 insertions(+), 15 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/nouveau_display.c 
b/drivers/gpu/drm/nouveau/nouveau_display.c
index cef08da1da4e..a0e7221d6568 100644
--- a/drivers/gpu/drm/nouveau/nouveau_display.c
+++ b/drivers/gpu/drm/nouveau/nouveau_display.c
@@ -58,27 +58,30 @@
 nouveau_display_vblank_enable(struct drm_device *dev, unsigned int pipe)
 {
struct drm_crtc *crtc;
-   list_for_each_entry(crtc, >mode_config.crtc_list, head) {
-   struct nouveau_crtc *nv_crtc = nouveau_crtc(crtc);
-   if (nv_crtc->index == pipe) {
-   nvif_notify_get(_crtc->vblank);
-   return 0;
-   }
-   }
-   return -EINVAL;
+   struct nouveau_crtc *nv_crtc;
+
+   crtc = drm_crtc_from_index(dev, pipe);
+   if (!crtc)
+   return -EINVAL;
+
+   nv_crtc = nouveau_crtc(crtc);
+   nvif_notify_get(_crtc->vblank);
+
+   return 0;
 }

 void
 nouveau_display_vblank_disable(struct drm_device *dev, unsigned int pipe)
 {
struct drm_crtc *crtc;
-   list_for_each_entry(crtc, >mode_config.crtc_list, head) {
-   struct nouveau_crtc *nv_crtc = nouveau_crtc(crtc);
-   if (nv_crtc->index == pipe) {
-   nvif_notify_put(_crtc->vblank);
-   return;
-   }
-   }
+   struct nouveau_crtc *nv_crtc;
+
+   crtc = drm_crtc_from_index(dev, pipe);
+   if (!crtc)
+   return;
+
+   nv_crtc = nouveau_crtc(crtc);
+   nvif_notify_put(_crtc->vblank);
 }

 static inline int
-- 
1.9.1

[PATCH 3/6] drm: mediatek: use crtc helper drm_crtc_from_index()

[Shawn Guo]

From: Shawn Guo 

Use drm_crtc_from_index() to find drm_crtc for given index, so that we
do not need to maintain a pointer array in struct mtk_drm_private.

Signed-off-by: Shawn Guo 
Cc: CK Hu 
---
 drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 9 -
 drivers/gpu/drm/mediatek/mtk_drm_drv.h  | 1 -
 2 files changed, 4 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c 
b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
index 01a21dd835b5..a73de1e669c2 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
@@ -170,8 +170,8 @@ static void mtk_drm_crtc_mode_set_nofb(struct drm_crtc 
*crtc)

 int mtk_drm_crtc_enable_vblank(struct drm_device *drm, unsigned int pipe)
 {
-   struct mtk_drm_private *priv = drm->dev_private;
-   struct mtk_drm_crtc *mtk_crtc = to_mtk_crtc(priv->crtc[pipe]);
+   struct drm_crtc *crtc = drm_crtc_from_index(drm, pipe);
+   struct mtk_drm_crtc *mtk_crtc = to_mtk_crtc(crtc);
struct mtk_ddp_comp *ovl = mtk_crtc->ddp_comp[0];

mtk_ddp_comp_enable_vblank(ovl, _crtc->base);
@@ -181,8 +181,8 @@ int mtk_drm_crtc_enable_vblank(struct drm_device *drm, 
unsigned int pipe)

 void mtk_drm_crtc_disable_vblank(struct drm_device *drm, unsigned int pipe)
 {
-   struct mtk_drm_private *priv = drm->dev_private;
-   struct mtk_drm_crtc *mtk_crtc = to_mtk_crtc(priv->crtc[pipe]);
+   struct drm_crtc *crtc = drm_crtc_from_index(drm, pipe);
+   struct mtk_drm_crtc *mtk_crtc = to_mtk_crtc(crtc);
struct mtk_ddp_comp *ovl = mtk_crtc->ddp_comp[0];

mtk_ddp_comp_disable_vblank(ovl);
@@ -588,7 +588,6 @@ int mtk_drm_crtc_create(struct drm_device *drm_dev,
goto unprepare;
drm_mode_crtc_set_gamma_size(_crtc->base, MTK_LUT_SIZE);
drm_crtc_enable_color_mgmt(_crtc->base, 0, false, MTK_LUT_SIZE);
-   priv->crtc[pipe] = _crtc->base;
priv->num_pipes++;

return 0;
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_drv.h 
b/drivers/gpu/drm/mediatek/mtk_drm_drv.h
index aa9389446785..df322a7a5fcb 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_drv.h
+++ b/drivers/gpu/drm/mediatek/mtk_drm_drv.h
@@ -32,7 +32,6 @@ struct mtk_drm_private {
struct drm_device *drm;
struct device *dma_dev;

-   struct drm_crtc *crtc[MAX_CRTC];
unsigned int num_pipes;

struct device_node *mutex_node;
-- 
1.9.1

[PATCH 2/6] drm: kirin: use crtc helper drm_crtc_from_index()

[Shawn Guo]

From: Shawn Guo 

Use drm_crtc_from_index() to find drm_crtc for given index, so that we
do not need to maintain a pointer array in struct kirin_drm_private.

Signed-off-by: Shawn Guo 
Cc: Xinliang Liu 
---
 drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c | 10 --
 drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.h |  1 -
 2 files changed, 4 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c 
b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c
index afc2b5d2d5f0..29d8d1cf109d 100644
--- a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c
+++ b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c
@@ -304,8 +304,8 @@ static void ade_set_medianoc_qos(struct ade_crtc *acrtc)

 static int ade_enable_vblank(struct drm_device *dev, unsigned int pipe)
 {
-   struct kirin_drm_private *priv = dev->dev_private;
-   struct ade_crtc *acrtc = to_ade_crtc(priv->crtc[pipe]);
+   struct drm_crtc *crtc = drm_crtc_from_index(dev, pipe);
+   struct ade_crtc *acrtc = to_ade_crtc(crtc);
struct ade_hw_ctx *ctx = acrtc->ctx;
void __iomem *base = ctx->base;

@@ -320,8 +320,8 @@ static int ade_enable_vblank(struct drm_device *dev, 
unsigned int pipe)

 static void ade_disable_vblank(struct drm_device *dev, unsigned int pipe)
 {
-   struct kirin_drm_private *priv = dev->dev_private;
-   struct ade_crtc *acrtc = to_ade_crtc(priv->crtc[pipe]);
+   struct drm_crtc *crtc = drm_crtc_from_index(dev, pipe);
+   struct ade_crtc *acrtc = to_ade_crtc(crtc);
struct ade_hw_ctx *ctx = acrtc->ctx;
void __iomem *base = ctx->base;

@@ -575,7 +575,6 @@ static void ade_crtc_atomic_flush(struct drm_crtc *crtc,
 static int ade_crtc_init(struct drm_device *dev, struct drm_crtc *crtc,
 struct drm_plane *plane)
 {
-   struct kirin_drm_private *priv = dev->dev_private;
struct device_node *port;
int ret;

@@ -599,7 +598,6 @@ static int ade_crtc_init(struct drm_device *dev, struct 
drm_crtc *crtc,
}

drm_crtc_helper_add(crtc, _crtc_helper_funcs);
-   priv->crtc[drm_crtc_index(crtc)] = crtc;

return 0;
 }
diff --git a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.h 
b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.h
index 1a07caf8e7f4..c6453b24d612 100644
--- a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.h
+++ b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.h
@@ -20,7 +20,6 @@ struct kirin_dc_ops {
 };

 struct kirin_drm_private {
-   struct drm_crtc *crtc[MAX_CRTC];
 #ifdef CONFIG_DRM_FBDEV_EMULATION
struct drm_fbdev_cma *fbdev;
 #endif
-- 
1.9.1

[PATCH 1/6] drm: exynos: use crtc helper drm_crtc_from_index()

[Shawn Guo]

From: Shawn Guo 

Use drm_crtc_from_index() to find drm_crtc for given index, so that we
do not need to maintain a pointer array in struct exynos_drm_private.

Signed-off-by: Shawn Guo 
Cc: Inki Dae 
---
 drivers/gpu/drm/exynos/exynos_drm_crtc.c |  6 --
 drivers/gpu/drm/exynos/exynos_drm_drv.h  | 10 ++
 2 files changed, 2 insertions(+), 14 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_crtc.c 
b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
index 2530bf57716a..309c8ee52524 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_crtc.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
@@ -109,9 +109,6 @@ static void exynos_crtc_atomic_flush(struct drm_crtc *crtc,
 static void exynos_drm_crtc_destroy(struct drm_crtc *crtc)
 {
struct exynos_drm_crtc *exynos_crtc = to_exynos_crtc(crtc);
-   struct exynos_drm_private *private = crtc->dev->dev_private;
-
-   private->crtc[exynos_crtc->pipe] = NULL;

drm_crtc_cleanup(crtc);
kfree(exynos_crtc);
@@ -134,7 +131,6 @@ struct exynos_drm_crtc *exynos_drm_crtc_create(struct 
drm_device *drm_dev,
void *ctx)
 {
struct exynos_drm_crtc *exynos_crtc;
-   struct exynos_drm_private *private = drm_dev->dev_private;
struct drm_crtc *crtc;
int ret;

@@ -149,8 +145,6 @@ struct exynos_drm_crtc *exynos_drm_crtc_create(struct 
drm_device *drm_dev,

crtc = _crtc->base;

-   private->crtc[pipe] = crtc;
-
ret = drm_crtc_init_with_planes(drm_dev, crtc, plane, NULL,
_crtc_funcs, NULL);
if (ret < 0)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.h 
b/drivers/gpu/drm/exynos/exynos_drm_drv.h
index 80c4d5b81689..cf6e08cb35a7 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.h
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.h
@@ -211,12 +211,6 @@ struct drm_exynos_file_private {
 struct exynos_drm_private {
struct drm_fb_helper *fb_helper;

-   /*
-* created crtc object would be contained at this array and
-* this array is used to be aware of which crtc did it request vblank.
-*/
-   struct drm_crtc *crtc[MAX_CRTC];
-
struct device *dma_dev;
void *mapping;

@@ -231,9 +225,9 @@ struct exynos_drm_private {
 static inline struct exynos_drm_crtc *
 exynos_drm_crtc_from_pipe(struct drm_device *dev, int pipe)
 {
-   struct exynos_drm_private *private = dev->dev_private;
+   struct drm_crtc *crtc = drm_crtc_from_index(dev, pipe);

-   return to_exynos_crtc(private->crtc[pipe]);
+   return to_exynos_crtc(crtc);
 }

 static inline struct device *to_dma_dev(struct drm_device *dev)
-- 
1.9.1

[PATCH 0/6] Use crtc helper drm_crtc_from_index() for more drivers

[Shawn Guo]

From: Shawn Guo 

This is a follow-up series for "[PATCH 0/3] Add CRTC helper
drm_crtc_from_index()" per Daniel's comment [1].

Basically, it changes some drivers to use helper drm_crtc_from_index()
for the vblank code, so that either they do not need to store CRTC
pointers in private struct, or the exactly same code for finding CRTC
can be saved.

Compile tested against the following branch.

 git://anongit.freedesktop.org/drm/drm-misc drm-misc-next

Shawn

[1] http://www.spinics.net/lists/dri-devel/msg128065.html

Shawn Guo (6):
  drm: exynos: use crtc helper drm_crtc_from_index()
  drm: kirin: use crtc helper drm_crtc_from_index()
  drm: mediatek: use crtc helper drm_crtc_from_index()
  drm: nouveau: use crtc helper drm_crtc_from_index()
  drm: tegra: use crtc helper drm_crtc_from_index()
  drm: vc4: use crtc helper drm_crtc_from_index()

 drivers/gpu/drm/exynos/exynos_drm_crtc.c|  6 -
 drivers/gpu/drm/exynos/exynos_drm_drv.h | 10 ++--
 drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c | 10 +++-
 drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.h |  1 -
 drivers/gpu/drm/mediatek/mtk_drm_crtc.c |  9 +++
 drivers/gpu/drm/mediatek/mtk_drm_drv.h  |  1 -
 drivers/gpu/drm/nouveau/nouveau_display.c   | 33 ++---
 drivers/gpu/drm/tegra/drm.c | 19 +++---
 drivers/gpu/drm/vc4/vc4_crtc.c  | 17 ++---
 drivers/gpu/drm/vc4/vc4_drv.h   |  1 -
 10 files changed, 38 insertions(+), 69 deletions(-)

-- 
1.9.1

[Bug 99236] System (seems to) completely freeze when interacting with java swing applications.

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

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

--- Comment #10 from Vitaly Ostrosablin  ---
Yes, will try to bisect mesa. Unfortunately, in looks like I'll have to do that
manually, since Gentoo doesn't seem to have bisect tools for portage. So far I
can say following initial info:

1) Bug wasn't introduced at least until November 30, 2016.
2) White button artefact doesn't seem to be related to hang. In Nov 30 commit
button is white, but pressing it doesn't hang the system.
3) On Dec 20, 2016, hang was already introduced.

-- 
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/20170109/d8e3a459/attachment.html>

[RFC] drm: Parse HDMI 2.0 YCbCr 4:2:0 VDB and VCB

[Sharma, Shashank]

Regards

Shashank


On 1/9/2017 6:53 PM, Jose Abreu wrote:
> Hi Shashank,
>
>
> On 09-01-2017 12:45, Sharma, Shashank wrote:
>> Regards
>>
>> Shashank
>>
>>
>> On 1/9/2017 4:41 PM, Jose Abreu wrote:
>>> Hi Shashank,
>>>
>>>
>>> Thanks for the review.
>>>
>>>
>>> On 09-01-2017 05:22, Sharma, Shashank wrote:
 Regards

 Shashank


 On 12/30/2016 10:23 PM, Jose Abreu wrote:
> HDMI 2.0 introduces a new sampling mode called YCbCr 4:2:0.
> According to the spec the EDID may contain two blocks that
> signal this sampling mode:
>   - YCbCr 4:2:0 Video Data Block
>   - YCbCr 4:2:0 Video Capability Map Data Block
>
> The video data block contains the list of vic's were
> only YCbCr 4:2:0 sampling mode shall be used while the
> video capability map data block contains a mask were
> YCbCr 4:2:0 sampling mode may be used.
>
> This RFC patch adds support for parsing these two new blocks
> and introduces new flags to signal the drivers if the
> mode is 4:2:0'only or 4:2:0'able.
>
> The reason this is still a RFC is because there is no
> reference in kernel for this new sampling mode (specially in
> AVI infoframe part), so, I was hoping to hear some feedback
> first.
>
> Tested in a HDMI 2.0 compliance scenario.
>
> Signed-off-by: Jose Abreu 
> Cc: Carlos Palminha 
> Cc: Daniel Vetter 
> Cc: Jani Nikula 
> Cc: Sean Paul 
> Cc: David Airlie 
> Cc: dri-devel at lists.freedesktop.org
> Cc: linux-kernel at vger.kernel.org
> ---
> drivers/gpu/drm/drm_edid.c  | 139
> +++-
> drivers/gpu/drm/drm_modes.c |  10 +++-
> include/uapi/drm/drm_mode.h |   6 ++
> 3 files changed, 151 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_edid.c
> b/drivers/gpu/drm/drm_edid.c
> index 67d6a73..6ce1a38 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -2549,6 +2549,8 @@ static int drm_cvt_modes(struct
> drm_connector *connector,
> #define VENDOR_BLOCK0x03
> #define SPEAKER_BLOCK0x04
> #define VIDEO_CAPABILITY_BLOCK0x07
> +#define VIDEO_DATA_BLOCK_4200x0E
> +#define VIDEO_CAP_BLOCK_4200x0F
> #define EDID_BASIC_AUDIO(1 << 6)
> #define EDID_CEA_YCRCB444(1 << 5)
> #define EDID_CEA_YCRCB422(1 << 4)
> @@ -3050,6 +3052,98 @@ static int add_3d_struct_modes(struct
> drm_connector *connector, u16 structure,
> return modes;
> }
> +static int add_420_mode(struct drm_connector *connector, u8
> vic)
> +{
> +struct drm_device *dev = connector->dev;
> +struct drm_display_mode *newmode;
> +
> +if (!drm_valid_cea_vic(vic))
> +return 0;
> +
> +newmode = drm_mode_duplicate(dev, _cea_modes[vic]);
 Sorry to start the review late, I missed this mail chain. It
 would be great if you can please keep me in CC for this chain.
>>> Sure. Will do that next time.
>>>
 Practically, YUV420 modes are being used for 4k and UHD video
 modes. Now here, when we want to
 add these modes from edid_cea_db, using the VIC index, we
 should have full list of cea_modes from 1 - 107
 Particularly 93-107 ( which is for new 38x21 and 40x21 modes,
 added in CEA-861-F). right now, edid_cea_modes
 cant index 4k modes, so practically this this patch series will
 do nothing (even though its doing everything right)
>>> This is correct but not entirely true. I realize 4:2:0 is mostly
>>> used in 4k modes but it can also be used in any other video mode,
>>> as long as it is declared in the VCB.
>> I agree (that's why I called it practically).
>> As such I doubt we will find anything less than a 4k here, coz
>> HDMI 1.4b itself can driver 4k at 30.
>> So the biggest benefit of YUV 420, which is half the clock, is
>> mostly useful in 4k at 60 and above.
>> I guess we will see more cases of deep-color pixels at non-4k
>> modes soon.
 To handle this scenario, I had added a patch series
 https://urldefense.proofpoint.com/v2/url?u=https-3A__patchwork.freedesktop.org_patch_119627_=DgICaQ=DPL6_X_6JkXFx7AXWqB0tg=WHDsc6kcWAl4i96Vm5hJ_19IJiuxx_p_Rzo2g-uHDKw=6JwJ_PEZj3MSeRaLTHuLtPZCb0uPPjUqR5raxY_qILI=DPBQ2MpLgngWGJEOg2v9CQhg2CSf_4LOIAC30B6AAyg=

 (complete the cea modedb (VIC=65 onwards)) Now, this patch
 series had dependency on new aspect ratios
 being added in CEA-861-F which I tried to add in series
 (https://urldefense.proofpoint.com/v2/url?u=https-3A__patchwork.freedesktop.org_patch_116095_=DgICaQ=DPL6_X_6JkXFx7AXWqB0tg=WHDsc6kcWAl4i96Vm5hJ_19IJiuxx_p_Rzo2g-uHDKw=6JwJ_PEZj3MSeRaLTHuLtPZCb0uPPjUqR5raxY_qILI=PX2M1hM2cF_aWiDe5oZeLWjsOgL-hvUR54Ion9kYMxM=

 )
 Which was added and later reverted by Ville
 

[PATCH 06/10] drm/i915/psr: set CHICKEN_TRANS for psr2

[vathsala nagaraju]

As per bpsec, CHICKEN_TRANS_EDP bit 12 ,15 must be programmed in
psr2 enable sequence.
Program Transcoder EDP VSC DIP header with a valid setting for PSR2
and Set CHICKEN_TRANS_EDP(0x420cc) bit 12 for programmable header
packet.
Set CHICKEN_TRANS_EDP(0x420cc) bit 15 if Y coordinate is supported

v2: (Rodrigo)
- move CHICKEN_TRANS_EDP bit set logic right after setup_vsc

v3:(Rodrigo)
- initialize chicken_trans to CHICKEN_TRANS_BIT12 instead of 0

v4:(chris wilson)
- use BIT(12), remove CHICKEN_TRANS_BIT12
- remove unnecessary comments
- update commit message

Cc: Rodrigo Vivi 
Cc: Jim Bride 
Signed-off-by: vathsala nagaraju 
Signed-off-by: Patil Deepti 
---
 drivers/gpu/drm/i915/i915_reg.h  | 5 +
 drivers/gpu/drm/i915/intel_psr.c | 5 +
 2 files changed, 10 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 7830e6e..3299e01 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -6449,6 +6449,11 @@ enum {
 #define  BDW_DPRS_MASK_VBLANK_SRD  (1 << 0)
 #define CHICKEN_PIPESL_1(pipe) _MMIO_PIPE(pipe, _CHICKEN_PIPESL_1_A, 
_CHICKEN_PIPESL_1_B)

+#define CHICKEN_TRANS_A 0x420c0
+#define CHICKEN_TRANS_B 0x420c4
+#define CHICKEN_TRANS(trans) _MMIO_TRANS(trans, CHICKEN_TRANS_A, 
CHICKEN_TRANS_B)
+#define TRANS_EDP  3
+
 #define DISP_ARB_CTL   _MMIO(0x45000)
 #define  DISP_FBC_MEMORY_WAKE  (1<<31)
 #define  DISP_TILE_SURFACE_SWIZZLING   (1<<13)
diff --git a/drivers/gpu/drm/i915/intel_psr.c b/drivers/gpu/drm/i915/intel_psr.c
index b28891b..b1686c2 100644
--- a/drivers/gpu/drm/i915/intel_psr.c
+++ b/drivers/gpu/drm/i915/intel_psr.c
@@ -475,6 +475,7 @@ void intel_psr_enable(struct intel_dp *intel_dp)
struct drm_device *dev = intel_dig_port->base.base.dev;
struct drm_i915_private *dev_priv = to_i915(dev);
struct intel_crtc *crtc = to_intel_crtc(intel_dig_port->base.base.crtc);
+   u32 chicken = 0;

if (!HAS_PSR(dev_priv)) {
DRM_DEBUG_KMS("PSR not supported on this platform\n");
@@ -505,6 +506,10 @@ void intel_psr_enable(struct intel_dp *intel_dp)
dev_priv->psr.psr2_support = false;
else
skl_psr_setup_su_vsc(intel_dp);
+   chicken = BIT(12);
+   if (dev_priv->psr.y_cord_support)
+   chicken |= BIT(15);
+   I915_WRITE(CHICKEN_TRANS(TRANS_EDP), chicken);
} else {
/* set up vsc header for psr1 */
hsw_psr_setup_vsc(intel_dp);
-- 
1.9.1

[PATCH 03/10] drm/i915/psr: fix blank screen issue for psr2

[vathsala nagaraju]

Psr1 and psr2 are mutually exclusive,ie when psr2 is enabled,
psr1 should be disabled.When psr2 is exited , bit 31 of reg
PSR2_CTL must be set to 0 but currently bit 31 of SRD_CTL
(psr1 control register)is set to 0.
Also ,PSR2_IDLE state is looked up from SRD_STATUS(psr1 register)
instead of PSR2_STATUS register, which has wrong data, resulting
in blankscreen.
hsw_enable_source is split into hsw_enable_source_psr1 and
hsw_enable_source_psr2 for easier code review and maintenance,
as suggested by rodrigo and jim.

v2: (Rodrigo)
- Rename hsw_enable_source_psr* to intel_enable_source_psr*

v3: (Rodrigo)
- In hsw_psr_disable ,
  1) for psr active case, handle psr2 followed by psr1.
  2) psr inactive case, handle psr2 followed by psr1

Cc: Rodrigo Vivi 
Cc: Jim Bride 
Signed-off-by: Vathsala Nagaraju 
Signed-off-by: Patil Deepti 
---
 drivers/gpu/drm/i915/i915_reg.h  |   3 +
 drivers/gpu/drm/i915/intel_psr.c | 126 +--
 2 files changed, 97 insertions(+), 32 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 00970aa..7830e6e 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -3615,6 +3615,9 @@ enum {
 #define   EDP_PSR2_FRAME_BEFORE_SU_MASK(0xf<<4)
 #define   EDP_PSR2_IDLE_MASK   0xf

+#define EDP_PSR2_STATUS_CTL_MMIO(0x6f940)
+#define EDP_PSR2_STATUS_STATE_MASK (0xf<<28)
+
 /* VGA port control */
 #define ADPA   _MMIO(0x61100)
 #define PCH_ADPA_MMIO(0xe1100)
diff --git a/drivers/gpu/drm/i915/intel_psr.c b/drivers/gpu/drm/i915/intel_psr.c
index c3aa649..6c161aa 100644
--- a/drivers/gpu/drm/i915/intel_psr.c
+++ b/drivers/gpu/drm/i915/intel_psr.c
@@ -261,12 +261,11 @@ static void vlv_psr_activate(struct intel_dp *intel_dp)
   VLV_EDP_PSR_ACTIVE_ENTRY);
 }

-static void hsw_psr_enable_source(struct intel_dp *intel_dp)
+static void intel_enable_source_psr1(struct intel_dp *intel_dp)
 {
struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp);
struct drm_device *dev = dig_port->base.base.dev;
struct drm_i915_private *dev_priv = to_i915(dev);
-
uint32_t max_sleep_time = 0x1f;
/*
 * Let's respect VBT in case VBT asks a higher idle_frame value.
@@ -312,14 +311,30 @@ static void hsw_psr_enable_source(struct intel_dp 
*intel_dp)
val |= EDP_PSR_TP1_TP2_SEL;

I915_WRITE(EDP_PSR_CTL, val);
+}

-   if (!dev_priv->psr.psr2_support)
-   return;
+static void intel_enable_source_psr2(struct intel_dp *intel_dp)
+{
+   struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp);
+   struct drm_device *dev = dig_port->base.base.dev;
+   struct drm_i915_private *dev_priv = to_i915(dev);
+
+   /*
+* Let's respect VBT in case VBT asks a higher idle_frame value.
+* Let's use 6 as the minimum to cover all known cases including
+* the off-by-one issue that HW has in some cases. Also there are
+* cases where sink should be able to train
+* with the 5 or 6 idle patterns.
+*/
+   uint32_t idle_frames = max(6, dev_priv->vbt.psr.idle_frames);
+   uint32_t val = EDP_PSR_ENABLE;
+
+   val |= idle_frames << EDP_PSR_IDLE_FRAME_SHIFT;

/* FIXME: selective update is probably totally broken because it doesn't
 * mesh at all with our frontbuffer tracking. And the hw alone isn't
 * good enough. */
-   val = EDP_PSR2_ENABLE | EDP_SU_TRACK_ENABLE;
+   val |= EDP_PSR2_ENABLE | EDP_SU_TRACK_ENABLE;

if (dev_priv->vbt.psr.tp2_tp3_wakeup_time > 5)
val |= EDP_PSR2_TP2_TIME_2500;
@@ -333,6 +348,20 @@ static void hsw_psr_enable_source(struct intel_dp 
*intel_dp)
I915_WRITE(EDP_PSR2_CTL, val);
 }

+
+static void hsw_psr_enable_source(struct intel_dp *intel_dp)
+{
+   struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp);
+   struct drm_device *dev = dig_port->base.base.dev;
+   struct drm_i915_private *dev_priv = to_i915(dev);
+
+   /* psr1 and psr2 are mutually exclusive.*/
+   if (dev_priv->psr.psr2_support)
+   intel_enable_source_psr2(intel_dp);
+   else
+   intel_enable_source_psr1(intel_dp);
+}
+
 static bool intel_psr_match_conditions(struct intel_dp *intel_dp)
 {
struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp);
@@ -410,7 +439,10 @@ static void intel_psr_activate(struct intel_dp *intel_dp)
struct drm_device *dev = intel_dig_port->base.base.dev;
struct drm_i915_private *dev_priv = to_i915(dev);

-   WARN_ON(I915_READ(EDP_PSR_CTL) & EDP_PSR_ENABLE);
+   if (dev_priv->psr.psr2_support)
+   WARN_ON(I915_READ(EDP_PSR2_CTL) & EDP_PSR2_ENABLE);
+   else
+   WARN_ON(I915_READ(EDP_PSR_CTL) & EDP_PSR_ENABLE);
WARN_ON(dev_priv->psr.active);
lockdep_assert_held(_priv->psr.lock);

@@ -462,8 

[PATCH v7 3/4] drm/panel: Add support for S6E3HA2 panel driver on TM2 board

[Inki Dae]

2017년 01월 09일 16:37에 Andrzej Hajda 이(가) 쓴 글:
> On 06.01.2017 09:36, Inki Dae wrote:
>>
>> 2017년 01월 06일 17:18에 Andi Shyti 이(가) 쓴 글:
>>> Hi Inki,
>>>
>>> Thanks for the reply, but...
>>>
>> +static const struct drm_display_mode default_mode = {
>> +.clock = 222372,
>> +.hdisplay = 1440,
>> +.hsync_start = 1440 + 1,
>> +.hsync_end = 1440 + 1 + 1,
>> +.htotal = 1440 + 1 + 1 + 1,
>> +.vdisplay = 2560,
>> +.vsync_start = 2560 + 1,
>> +.vsync_end = 2560 + 1 + 1,
>> +.vtotal = 2560 + 1 + 1 + 15,
>> +.vrefresh = 60,
>> +.flags = 0,
>> +};
> how is this working with tm2e? Are these values valid for both
> the boards?
 We don't need to consider tm2e board with two reasones,
 1. there is no tm2e board support in mainline
 2. the panel on tm2 would be a little bit different from one on tm2e
>>> ... this display in the Tizen Kernel is supported by both:
>>> tm2 [1] and tm2e [2]. The only differences are:
>> Why tm2e dts file is in mainline? Seems communication miss with Chanwoo. :( 
>>
>>> TM2:
>>>clock-frequency = <1487>;
>>>hactive = <1440>;
>>>
>>> TM2E:
>>>clock-frequency = <16523724>;
>>>hactive = <1600>;
>>>
>>> I don't know much about the differences you mention in point 2,
>>> but it's a pity to drop support only because we don't want to put
>>> in the dts the 'hactive', and 'clock-frequency' properties.
>> Anyway, tm2e board is already in mainline so Panel driver may need to 
>> identify what kinds of panel is probed to decide porch values. I think there 
>> are relevant registers in MCU of the Panel device to check version or 
>> similar thing.
> 
> I think we can safely use different compatible string for tm2e - it uses
> different display IC controller - s6e3hf2, driver will provide timings
> based on it.

Using compatable string wouldn't be a good idea because Panel is a device not 
specific to board.

> As far as I examined available specs/docs there is no reliable register
> which can be used to safely distinguish it on runtime, but the docs I
> have are far from completeness.

The data sheet I am seeing says a RDDIDS register describes manufacturer and 
module version information. With this we could identify the Panel device.
Of course, we may need to check the register has really different values 
according to board.

Below is the version information Hoegeun checked,

TM2
[4.908666] panel_s6e3ha2 1390.dsi.0: Manufacture date: 2014-10-31 06:41
[5.035768] panel_s6e3ha2 1390.dsi.0: Id: 50 20 09

TM2e
[4.929265] panel_s6e3ha2 1390.dsi.0: Manufacture date: 2014-09-03 06:30
[5.056287] panel_s6e3ha2 1390.dsi.0: Id: 40 40 14


Thanks.

> 
> Regards
> Andrzej
> 
>>
>> Thanks.
>>
>>> Andi
>>>
>>> [1] 
>>> https://git.tizen.org/cgit/platform/kernel/linux-exynos/tree/arch/arm64/boot/dts/exynos/exynos5433-tm2.dts?h=tizen#n1284
>>> [2] 
>>> https://git.tizen.org/cgit/platform/kernel/linux-exynos/tree/arch/arm64/boot/dts/exynos/exynos5433-tm2e.dts?h=tizen#n1270
>>> --
>>> To unsubscribe from this list: send the line "unsubscribe devicetree" in
>>> the body of a message to majordomo at vger.kernel.org
>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>>
>>> .
>>>
>>
> 
> --
> To unsubscribe from this list: send the line "unsubscribe devicetree" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 
> 

[RFC] drm: Parse HDMI 2.0 YCbCr 4:2:0 VDB and VCB

[Sharma, Shashank]

Regards

Shashank


On 1/9/2017 4:41 PM, Jose Abreu wrote:
> Hi Shashank,
>
>
> Thanks for the review.
>
>
> On 09-01-2017 05:22, Sharma, Shashank wrote:
>> Regards
>>
>> Shashank
>>
>>
>> On 12/30/2016 10:23 PM, Jose Abreu wrote:
>>> HDMI 2.0 introduces a new sampling mode called YCbCr 4:2:0.
>>> According to the spec the EDID may contain two blocks that
>>> signal this sampling mode:
>>>  - YCbCr 4:2:0 Video Data Block
>>>  - YCbCr 4:2:0 Video Capability Map Data Block
>>>
>>> The video data block contains the list of vic's were
>>> only YCbCr 4:2:0 sampling mode shall be used while the
>>> video capability map data block contains a mask were
>>> YCbCr 4:2:0 sampling mode may be used.
>>>
>>> This RFC patch adds support for parsing these two new blocks
>>> and introduces new flags to signal the drivers if the
>>> mode is 4:2:0'only or 4:2:0'able.
>>>
>>> The reason this is still a RFC is because there is no
>>> reference in kernel for this new sampling mode (specially in
>>> AVI infoframe part), so, I was hoping to hear some feedback
>>> first.
>>>
>>> Tested in a HDMI 2.0 compliance scenario.
>>>
>>> Signed-off-by: Jose Abreu 
>>> Cc: Carlos Palminha 
>>> Cc: Daniel Vetter 
>>> Cc: Jani Nikula 
>>> Cc: Sean Paul 
>>> Cc: David Airlie 
>>> Cc: dri-devel at lists.freedesktop.org
>>> Cc: linux-kernel at vger.kernel.org
>>> ---
>>>drivers/gpu/drm/drm_edid.c  | 139
>>> +++-
>>>drivers/gpu/drm/drm_modes.c |  10 +++-
>>>include/uapi/drm/drm_mode.h |   6 ++
>>>3 files changed, 151 insertions(+), 4 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/drm_edid.c
>>> b/drivers/gpu/drm/drm_edid.c
>>> index 67d6a73..6ce1a38 100644
>>> --- a/drivers/gpu/drm/drm_edid.c
>>> +++ b/drivers/gpu/drm/drm_edid.c
>>> @@ -2549,6 +2549,8 @@ static int drm_cvt_modes(struct
>>> drm_connector *connector,
>>>#define VENDOR_BLOCK0x03
>>>#define SPEAKER_BLOCK0x04
>>>#define VIDEO_CAPABILITY_BLOCK0x07
>>> +#define VIDEO_DATA_BLOCK_4200x0E
>>> +#define VIDEO_CAP_BLOCK_4200x0F
>>>#define EDID_BASIC_AUDIO(1 << 6)
>>>#define EDID_CEA_YCRCB444(1 << 5)
>>>#define EDID_CEA_YCRCB422(1 << 4)
>>> @@ -3050,6 +3052,98 @@ static int add_3d_struct_modes(struct
>>> drm_connector *connector, u16 structure,
>>>return modes;
>>>}
>>>+static int add_420_mode(struct drm_connector *connector, u8
>>> vic)
>>> +{
>>> +struct drm_device *dev = connector->dev;
>>> +struct drm_display_mode *newmode;
>>> +
>>> +if (!drm_valid_cea_vic(vic))
>>> +return 0;
>>> +
>>> +newmode = drm_mode_duplicate(dev, _cea_modes[vic]);
>> Sorry to start the review late, I missed this mail chain. It
>> would be great if you can please keep me in CC for this chain.
> Sure. Will do that next time.
>
>> Practically, YUV420 modes are being used for 4k and UHD video
>> modes. Now here, when we want to
>> add these modes from edid_cea_db, using the VIC index, we
>> should have full list of cea_modes from 1 - 107
>> Particularly 93-107 ( which is for new 38x21 and 40x21 modes,
>> added in CEA-861-F). right now, edid_cea_modes
>> cant index 4k modes, so practically this this patch series will
>> do nothing (even though its doing everything right)
> This is correct but not entirely true. I realize 4:2:0 is mostly
> used in 4k modes but it can also be used in any other video mode,
> as long as it is declared in the VCB.
I agree (that's why I called it practically).
As such I doubt we will find anything less than a 4k here, coz HDMI 1.4b 
itself can driver 4k at 30.
So the biggest benefit of YUV 420, which is half the clock, is mostly 
useful in 4k at 60 and above.
I guess we will see more cases of deep-color pixels at non-4k modes soon.
>> To handle this scenario, I had added a patch series
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__patchwork.freedesktop.org_patch_119627_=DgICaQ=DPL6_X_6JkXFx7AXWqB0tg=WHDsc6kcWAl4i96Vm5hJ_19IJiuxx_p_Rzo2g-uHDKw=6JwJ_PEZj3MSeRaLTHuLtPZCb0uPPjUqR5raxY_qILI=DPBQ2MpLgngWGJEOg2v9CQhg2CSf_4LOIAC30B6AAyg=
>> (complete the cea modedb (VIC=65 onwards)) Now, this patch
>> series had dependency on new aspect ratios
>> being added in CEA-861-F which I tried to add in series
>> (https://urldefense.proofpoint.com/v2/url?u=https-3A__patchwork.freedesktop.org_patch_116095_=DgICaQ=DPL6_X_6JkXFx7AXWqB0tg=WHDsc6kcWAl4i96Vm5hJ_19IJiuxx_p_Rzo2g-uHDKw=6JwJ_PEZj3MSeRaLTHuLtPZCb0uPPjUqR5raxY_qILI=PX2M1hM2cF_aWiDe5oZeLWjsOgL-hvUR54Ion9kYMxM=
>> )
>> Which was added and later reverted by Ville
>> (https://urldefense.proofpoint.com/v2/url?u=https-3A__patchwork.freedesktop.org_patch_119808_=DgICaQ=DPL6_X_6JkXFx7AXWqB0tg=WHDsc6kcWAl4i96Vm5hJ_19IJiuxx_p_Rzo2g-uHDKw=6JwJ_PEZj3MSeRaLTHuLtPZCb0uPPjUqR5raxY_qILI=FAa6aHQ_HjlaVRzDm282p9bSY_tBiN1PngZBhsTqYdI=
>> ).
> Yes, I remember that. If it was breaking userspace then there was
> nothing left to do, revert was needed.
As we discovered over the discussions, It dint break 

[PATCH 3/3] drm/atomic: Make disable_all helper fully disable the crtc.

[Maarten Lankhorst]

It seems that nouveau requires this, so best to do this in the helper.
This allows nouveau to use the atomic suspend helper.

Cc: nouveau at lists.freedesktop.org
Signed-off-by: Maarten Lankhorst 
---
 drivers/gpu/drm/drm_atomic_helper.c   |  51 ++
 drivers/gpu/drm/nouveau/nouveau_display.c | 113 +-
 2 files changed, 38 insertions(+), 126 deletions(-)

diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
b/drivers/gpu/drm/drm_atomic_helper.c
index 3a8a46510c36..f010a11874b9 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -2436,9 +2436,13 @@ int drm_atomic_helper_disable_all(struct drm_device *dev,
  struct drm_modeset_acquire_ctx *ctx)
 {
struct drm_atomic_state *state;
+   struct drm_connector_state *conn_state;
struct drm_connector *conn;
-   struct drm_connector_list_iter conn_iter;
-   int err;
+   struct drm_plane_state *plane_state;
+   struct drm_plane *plane;
+   struct drm_crtc_state *crtc_state;
+   struct drm_crtc *crtc;
+   int ret, i;

state = drm_atomic_state_alloc(dev);
if (!state)
@@ -2446,29 +2450,48 @@ int drm_atomic_helper_disable_all(struct drm_device 
*dev,

state->acquire_ctx = ctx;

-   drm_connector_list_iter_get(dev, _iter);
-   drm_for_each_connector_iter(conn, _iter) {
-   struct drm_crtc *crtc = conn->state->crtc;
-   struct drm_crtc_state *crtc_state;
-
-   if (!crtc || conn->dpms != DRM_MODE_DPMS_ON)
-   continue;
-
+   drm_for_each_crtc(crtc, dev) {
crtc_state = drm_atomic_get_crtc_state(state, crtc);
if (IS_ERR(crtc_state)) {
-   err = PTR_ERR(crtc_state);
+   ret = PTR_ERR(crtc_state);
goto free;
}

crtc_state->active = false;
+
+   ret = drm_atomic_set_mode_prop_for_crtc(crtc_state, NULL);
+   if (ret < 0)
+   goto free;
+
+   ret = drm_atomic_add_affected_planes(state, crtc);
+   if (ret < 0)
+   goto free;
+
+   ret = drm_atomic_add_affected_connectors(state, crtc);
+   if (ret < 0)
+   goto free;
}

-   err = drm_atomic_commit(state);
+   for_each_connector_in_state(state, conn, conn_state, i) {
+   ret = drm_atomic_set_crtc_for_connector(conn_state, NULL);
+   if (ret < 0)
+   goto free;
+   }
+
+   for_each_plane_in_state(state, plane, plane_state, i) {
+   ret = drm_atomic_set_crtc_for_plane(plane_state, NULL);
+   if (ret < 0)
+   goto free;
+
+   drm_atomic_set_fb_for_plane(plane_state, NULL);
+   }
+
+   ret = drm_atomic_commit(state);
 free:
-   drm_connector_list_iter_put(_iter);
drm_atomic_state_put(state);
-   return err;
+   return ret;
 }
+
 EXPORT_SYMBOL(drm_atomic_helper_disable_all);

 /**
diff --git a/drivers/gpu/drm/nouveau/nouveau_display.c 
b/drivers/gpu/drm/nouveau/nouveau_display.c
index add353e230f4..09f195f8756f 100644
--- a/drivers/gpu/drm/nouveau/nouveau_display.c
+++ b/drivers/gpu/drm/nouveau/nouveau_display.c
@@ -621,117 +621,6 @@ nouveau_display_destroy(struct drm_device *dev)
kfree(disp);
 }

-static int
-nouveau_atomic_disable_connector(struct drm_atomic_state *state,
-struct drm_connector *connector)
-{
-   struct drm_connector_state *connector_state;
-   struct drm_crtc *crtc;
-   struct drm_crtc_state *crtc_state;
-   struct drm_plane_state *plane_state;
-   struct drm_plane *plane;
-   int ret;
-
-   if (!(crtc = connector->state->crtc))
-   return 0;
-
-   connector_state = drm_atomic_get_connector_state(state, connector);
-   if (IS_ERR(connector_state))
-   return PTR_ERR(connector_state);
-
-   ret = drm_atomic_set_crtc_for_connector(connector_state, NULL);
-   if (ret)
-   return ret;
-
-   crtc_state = drm_atomic_get_crtc_state(state, crtc);
-   if (IS_ERR(crtc_state))
-   return PTR_ERR(crtc_state);
-
-   ret = drm_atomic_set_mode_for_crtc(crtc_state, NULL);
-   if (ret)
-   return ret;
-
-   crtc_state->active = false;
-
-   drm_for_each_plane_mask(plane, connector->dev, crtc_state->plane_mask) {
-   plane_state = drm_atomic_get_plane_state(state, plane);
-   if (IS_ERR(plane_state))
-   return PTR_ERR(plane_state);
-
-   ret = drm_atomic_set_crtc_for_plane(plane_state, NULL);
-   if (ret)
-   return ret;
-
-   drm_atomic_set_fb_for_plane(plane_state, NULL);
-   }
-
-   return 0;
-}
-
-static int

[PATCH 2/3] drm/i915: Wait for pending modesets to complete before trying link training

[Maarten Lankhorst]

We're protected by the connection_mutex lock against blocking modesets,
but nonblocking modesets are performed without any locking. This is
causing WARN in drm_wait_for_vblank and in general it's better to wait
before modeset completes before trying anything.

Signed-off-by: Maarten Lankhorst 
---
 drivers/gpu/drm/i915/intel_dp.c | 51 +++--
 1 file changed, 39 insertions(+), 12 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index fb12896bafee..71882d887393 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -4080,24 +4080,38 @@ intel_dp_check_link_status(struct intel_dp *intel_dp)
struct intel_encoder *intel_encoder = _to_dig_port(intel_dp)->base;
struct drm_device *dev = intel_dp_to_dev(intel_dp);
u8 link_status[DP_LINK_STATUS_SIZE];
+   struct drm_modeset_acquire_ctx ctx;
+   struct intel_connector *intel_connector = intel_dp->attached_connector;
+   int ret;
+   struct drm_crtc *crtc;

-   WARN_ON(!drm_modeset_is_locked(>mode_config.connection_mutex));
+   drm_modeset_acquire_init(, 0);
+
+retry:
+   ret = drm_modeset_lock(>mode_config.connection_mutex, );
+   if (ret)
+   goto out;

if (!intel_dp_get_link_status(intel_dp, link_status)) {
DRM_ERROR("Failed to get link status\n");
-   return;
+   goto out;
}

-   if (!intel_encoder->base.crtc)
-   return;
+   crtc = intel_connector->base.state->crtc;
+   if (!crtc)
+   goto out;

-   if (!to_intel_crtc(intel_encoder->base.crtc)->active)
-   return;
+   ret = drm_modeset_lock(>mutex, );
+   if (ret)
+   goto out;
+
+   if (!crtc->state->active)
+   goto out;

/* FIXME: we need to synchronize this sort of stuff with hardware
 * readout. Currently fast link training doesn't work on boot-up. */
if (!intel_dp->lane_count)
-   return;
+   goto out;

/* if link training is requested we should perform it always */
if ((intel_dp->compliance.test_type == DP_TEST_LINK_TRAINING) ||
@@ -4105,8 +4119,26 @@ intel_dp_check_link_status(struct intel_dp *intel_dp)
DRM_DEBUG_KMS("%s: channel EQ not ok, retraining\n",
  intel_encoder->base.name);

+   if (drm_atomic_crtc_needs_modeset(crtc->state)) {
+   /* wait for atomic modeset to complete */
+   ret = drm_atomic_helper_wait_for_hw_done(crtc);
+   if (ret < 0)
+   DRM_ERROR("Waiting for hw_done timed out\n");
+   }
+
intel_dp_retrain_link(intel_dp);
}
+
+out:
+   if (ret == -EDEADLK) {
+   drm_modeset_backoff();
+   goto retry;
+   }
+
+   drm_modeset_drop_locks();
+   drm_modeset_acquire_fini();
+   if (ret)
+   DRM_ERROR("Locking failed with %i\n", ret);
 }

 /*
@@ -4125,7 +4157,6 @@ intel_dp_check_link_status(struct intel_dp *intel_dp)
 static bool
 intel_dp_short_pulse(struct intel_dp *intel_dp)
 {
-   struct drm_device *dev = intel_dp_to_dev(intel_dp);
u8 sink_irq_vector = 0;
u8 old_sink_count = intel_dp->sink_count;
bool ret;
@@ -4164,9 +4195,7 @@ intel_dp_short_pulse(struct intel_dp *intel_dp)
DRM_DEBUG_DRIVER("CP or sink specific irq unhandled\n");
}

-   drm_modeset_lock(>mode_config.connection_mutex, NULL);
intel_dp_check_link_status(intel_dp);
-   drm_modeset_unlock(>mode_config.connection_mutex);

return true;
 }
@@ -4499,9 +4528,7 @@ intel_dp_long_pulse(struct intel_connector 
*intel_connector)
 * check links status, there has been known issues of
 * link loss triggerring long pulse
 */
-   drm_modeset_lock(>mode_config.connection_mutex, NULL);
intel_dp_check_link_status(intel_dp);
-   drm_modeset_unlock(>mode_config.connection_mutex);
goto out;
}

-- 
2.7.4

[PATCH 1/3] drm/atomic: move waiting for hw_done to a helper

[Maarten Lankhorst]

This will allow i915 to perform a wait on pending modeset using the
same code.

Signed-off-by: Maarten Lankhorst 
---
 drivers/gpu/drm/drm_atomic_helper.c | 51 +++--
 include/drm/drm_atomic_helper.h |  1 +
 2 files changed, 38 insertions(+), 14 deletions(-)

diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
b/drivers/gpu/drm/drm_atomic_helper.c
index 7b71ac48b8a4..3a8a46510c36 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -1936,6 +1936,41 @@ void drm_atomic_helper_cleanup_planes(struct drm_device 
*dev,
 EXPORT_SYMBOL(drm_atomic_helper_cleanup_planes);

 /**
+ * drm_atomic_helper_wait_for_hw_done - wait for all previous hw updates to 
complete.
+ * @crtc: crtc to wait on.
+ *
+ * This function waits for all previous hardware updates queued on @crtc
+ * to complete.
+ *
+ * Returns:
+ * 0 on success, negative error code on failure.
+ */
+int drm_atomic_helper_wait_for_hw_done(struct drm_crtc *crtc)
+{
+   struct drm_crtc_commit *commit;
+   long ret;
+
+   spin_lock(>commit_lock);
+   commit = list_first_entry_or_null(>commit_list,
+   struct drm_crtc_commit, commit_entry);
+   if (commit)
+   drm_crtc_commit_get(commit);
+   spin_unlock(>commit_lock);
+
+   if (!commit)
+   return 0;
+
+   ret = wait_for_completion_timeout(>hw_done, 10 * HZ);
+   drm_crtc_commit_put(commit);
+
+   if (ret == 0)
+   return -EBUSY;
+
+   return ret > 0 ? 0 : ret;
+}
+EXPORT_SYMBOL(drm_atomic_helper_wait_for_hw_done);
+
+/**
  * drm_atomic_helper_swap_state - store atomic state into current sw state
  * @state: atomic state
  * @stall: stall for proceeding commits
@@ -1976,26 +2011,14 @@ void drm_atomic_helper_swap_state(struct 
drm_atomic_state *state,
struct drm_crtc_state *crtc_state;
struct drm_plane *plane;
struct drm_plane_state *plane_state;
-   struct drm_crtc_commit *commit;

if (stall) {
for_each_crtc_in_state(state, crtc, crtc_state, i) {
-   spin_lock(>commit_lock);
-   commit = list_first_entry_or_null(>commit_list,
-   struct drm_crtc_commit, commit_entry);
-   if (commit)
-   drm_crtc_commit_get(commit);
-   spin_unlock(>commit_lock);
+   ret = drm_atomic_helper_wait_for_hw_done(crtc);

-   if (!commit)
-   continue;
-
-   ret = wait_for_completion_timeout(>hw_done,
- 10*HZ);
-   if (ret == 0)
+   if (ret < 0)
DRM_ERROR("[CRTC:%d:%s] hw_done timed out\n",
  crtc->base.id, crtc->name);
-   drm_crtc_commit_put(commit);
}
}

diff --git a/include/drm/drm_atomic_helper.h b/include/drm/drm_atomic_helper.h
index 4b2353dc34ba..e15d2fe7b274 100644
--- a/include/drm/drm_atomic_helper.h
+++ b/include/drm/drm_atomic_helper.h
@@ -77,6 +77,7 @@ void
 drm_atomic_helper_disable_planes_on_crtc(struct drm_crtc_state *old_crtc_state,
 bool atomic);

+int drm_atomic_helper_wait_for_hw_done(struct drm_crtc *crtc);
 void drm_atomic_helper_swap_state(struct drm_atomic_state *state,
  bool stall);

-- 
2.7.4

[PATCH 0/3] drm/atomic: Add helper for hw_done and fix suspend.

[Maarten Lankhorst]

Fix hw_done in i915 and make nouveau use drm_atomic_helper_disable_all()
after fixing it to properly disable everything.

Maarten Lankhorst (3):
  drm/atomic: move waiting for hw_done to a helper
  drm/i915: Wait for pending modesets to complete before trying link
training
  drm/atomic: Make disable_all helper fully disable the crtc.

 drivers/gpu/drm/drm_atomic_helper.c   | 102 +++
 drivers/gpu/drm/i915/intel_dp.c   |  51 ++
 drivers/gpu/drm/nouveau/nouveau_display.c | 113 +-
 include/drm/drm_atomic_helper.h   |   1 +
 4 files changed, 115 insertions(+), 152 deletions(-)

-- 
2.7.4

[PATCH v2 1/2] drm: Document drm_cache interface

[Alex Deucher]

On Mon, Jan 9, 2017 at 4:56 PM, Gabriel Krisman Bertazi
 wrote:
> Notice that this uncovers an issue with the kernel-doc handling of array
> arguments, causing the first parameter of drm_clflush_pages() to not
> show up in the rst-generated page.  A proposed fix is under review in
> linux-doc: 
>
> Changes since v1:
>  - Add section to drm-mm.rst.
>  - Fix kernel-doc style issues.
>  - s/memory/kernel memory/.
>
> Signed-off-by: Gabriel Krisman Bertazi 

For the series:
Reviewed-by: Alex Deucher 

> ---
>  Documentation/gpu/drm-mm.rst |  6 ++
>  drivers/gpu/drm/drm_cache.c  | 23 +++
>  2 files changed, 29 insertions(+)
>
> diff --git a/Documentation/gpu/drm-mm.rst b/Documentation/gpu/drm-mm.rst
> index 1ea94fc86caa..91d82f39fbf4 100644
> --- a/Documentation/gpu/drm-mm.rst
> +++ b/Documentation/gpu/drm-mm.rst
> @@ -470,3 +470,9 @@ DRM MM Range Allocator Function References
>
>  .. kernel-doc:: include/drm/drm_mm.h
> :internal:
> +
> +DRM Cache Handling
> +==
> +
> +.. kernel-doc:: drivers/gpu/drm/drm_cache.c
> +   :export:
> diff --git a/drivers/gpu/drm/drm_cache.c b/drivers/gpu/drm/drm_cache.c
> index a7916e5f8864..5066638928ec 100644
> --- a/drivers/gpu/drm/drm_cache.c
> +++ b/drivers/gpu/drm/drm_cache.c
> @@ -67,6 +67,14 @@ static void drm_cache_flush_clflush(struct page *pages[],
>  }
>  #endif
>
> +/**
> + * drm_clflush_pages - Flush dcache lines of a set of pages.
> + * @pages: List of pages to be flushed.
> + * @num_pages: Number of pages in the array.
> + *
> + * Flush every data cache line entry that points to an address belonging
> + * to a page in the array.
> + */
>  void
>  drm_clflush_pages(struct page *pages[], unsigned long num_pages)
>  {
> @@ -101,6 +109,13 @@ drm_clflush_pages(struct page *pages[], unsigned long 
> num_pages)
>  }
>  EXPORT_SYMBOL(drm_clflush_pages);
>
> +/**
> + * drm_clflush_sg - Flush dcache lines pointing to a scather-gather.
> + * @st: struct sg_table.
> + *
> + * Flush every data cache line entry that points to an address in the
> + * sg.
> + */
>  void
>  drm_clflush_sg(struct sg_table *st)
>  {
> @@ -125,6 +140,14 @@ drm_clflush_sg(struct sg_table *st)
>  }
>  EXPORT_SYMBOL(drm_clflush_sg);
>
> +/**
> + * drm_clflush_virt_range - Flush dcache lines of a region
> + * @addr: Initial kernel memory address.
> + * @length: Region size.
> + *
> + * Flush every data cache line entry that points to an address in the
> + * region requested.
> + */
>  void
>  drm_clflush_virt_range(void *addr, unsigned long length)
>  {
> --
> 2.11.0
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Intel-gfx] 4.10-rc2 oops in DRM connector code

[Daniel Vetter]

On Mon, Jan 9, 2017 at 5:50 PM, Dave Hansen  wrote:
> On 01/09/2017 08:41 AM, Daniel Vetter wrote:
>> On Mon, Jan 9, 2017 at 2:40 PM, Dave Hansen  wrote:
>>> Well, now I found where the -2 comes from.
>>> intel_dp_register_mst_connector() calls drm_connector_register(), which
>>> fails to add the kobject (warning below).  But, it does zero error
>>> checking on the drm_connector_register() call and leaves the
>>> partially-constructed connector in place.
>>>
>>> The next time some poor, hapless code goes and tries to do anything with
>>> that kdev, they oops.  I'm perplexed by this, though.  The
>>> drm_dp_mst_topology_cbs->register_connector just returns void.  It seems
>>> a bit goofy that it can't even _return_ failure.
>>>
>>> Is there some stable code to go back to here?  Or, is there something
>>> about my configuration that's unique?  I really wonder why nobody else
>>> is running into this.
>>>
>>> There's probably some other race going on here.  This warning doesn't
>>> happen on every boot.
>> This smells more like the root-cause: Something goes wrong on boot
>> that prevents connectors from properly registering, then we fall over
>> later on. And the register callback is intentionally void, assuming
>> that any prep work has been done earlier and that therefore the
>> register step can't fail. Can you pls check whether the oops later on
>> only happens together with this warning at boot, or whether they're
>> not correlated?
>
> Looking through my logs, I can't find any instance of the oops without
> the warning at boot.  So I do think the later oops is entirely caused by
> the issue warned about in early boot.

Hm, I guess then we'd need to fix that boot-up warning. Can you try to
figure out why it's unhappy? On a hunch it could be that we call
drm_connector_register from the mst probe worker before the main
driver load thread has reached the drm_dev_register call. A few printk
to decide whether that's the case (plus a few boot-up tests to gather
the statistics, sorry about that) would be real great.

If that's inconclusive I'm again a bit low on ideas ...

> My distro kernel (4.4.0-57-generic) is also unstable, but I haven't
> managed to capture a good oops there.  It's hitting this, which I assume
> is unrelated:
>
> WARNING: CPU: 0 PID: 41 at /build/linux-lts-xenial-FdAdUy/linux-
> lts-xenial-4.4.0/ubuntu/i915/intel_pm.c:3675
> skl_update_other_pipe_wm+0x191/0x1a0 [i915_bpo]()

wm programming issues, which will kill your box. Needs a newer kernel
to fix (both the wm programming issues, and that wm programming issues
lead to system death).
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

[Intel-gfx] 4.10-rc2 oops in DRM connector code

[Daniel Vetter]

On Mon, Jan 9, 2017 at 2:40 PM, Dave Hansen  wrote:
> Well, now I found where the -2 comes from.
> intel_dp_register_mst_connector() calls drm_connector_register(), which
> fails to add the kobject (warning below).  But, it does zero error
> checking on the drm_connector_register() call and leaves the
> partially-constructed connector in place.
>
> The next time some poor, hapless code goes and tries to do anything with
> that kdev, they oops.  I'm perplexed by this, though.  The
> drm_dp_mst_topology_cbs->register_connector just returns void.  It seems
> a bit goofy that it can't even _return_ failure.
>
> Is there some stable code to go back to here?  Or, is there something
> about my configuration that's unique?  I really wonder why nobody else
> is running into this.
>
> There's probably some other race going on here.  This warning doesn't
> happen on every boot.

This smells more like the root-cause: Something goes wrong on boot
that prevents connectors from properly registering, then we fall over
later on. And the register callback is intentionally void, assuming
that any prep work has been done earlier and that therefore the
register step can't fail. Can you pls check whether the oops later on
only happens together with this warning at boot, or whether they're
not correlated?

Still no idea though why this blows up for you.
-Daniel

>
>> [1.396475] [ cut here ]
>> [1.396486] WARNING: CPU: 0 PID: 91 at lib/kobject.c:244 
>> kobject_add_internal+0x108/0x2d0
>> [1.396492] kobject_add_internal failed for card0-DP-3 (error: -2 parent: 
>> card0)
>> [1.396496] Modules linked in:
>> [1.396500] CPU: 0 PID: 91 Comm: kworker/0:2 Not tainted 4.10.0-rc2-dirty 
>> #58
>> [1.396503] Hardware name: LENOVO 20F5S7V800/20F5S7V800, BIOS R02ET50W 
>> (1.23 ) 09/20/2016
>> [1.396509] Workqueue: events_long drm_dp_mst_link_probe_work
>> [1.396511] Call Trace:
>> [1.396517]  dump_stack+0x67/0x99
>> [1.396521]  __warn+0xd1/0xf0
>> [1.396524]  warn_slowpath_fmt+0x4f/0x60
>> [1.396527]  kobject_add_internal+0x108/0x2d0
>> [1.396531]  ? vsnprintf+0x112/0x4b0
>> [1.396533]  kobject_add+0x65/0xb0
>> [1.396537]  ? klist_init+0x31/0x40
>> [1.396542]  device_add+0x102/0x5d0
>> [1.396546]  ? kfree_const+0x22/0x30
>> [1.396549]  device_create_groups_vargs+0xd8/0x100
>> [1.396553]  device_create_with_groups+0x36/0x40
>> [1.396557]  ? drm_fb_helper_add_one_connector+0x57/0xd0
>> [1.396561]  ? kmem_cache_alloc_trace+0x1d2/0x1f0
>> [1.396566]  drm_sysfs_connector_add+0x60/0xe0
>> [1.396570]  drm_connector_register+0x21/0xc0
>> [1.396575]  intel_dp_register_mst_connector+0x41/0x50
>> [1.396579]  drm_dp_add_port+0x350/0x450
>> [1.396583]  ? rcu_early_boot_tests+0x1/0x10
>> [1.396587]  ? schedule_timeout+0x1cd/0x390
>> [1.396591]  ? __might_sleep+0x4a/0x90
>> [1.396594]  ? mutex_lock+0x25/0x50
>> [1.396597]  ? drm_dp_mst_wait_tx_reply+0x118/0x1e0
>> [1.396600]  ? prepare_to_wait_event+0x120/0x120
>> [1.396603]  ? drm_dp_check_mstb_guid+0x3d/0x120
>> [1.396606] drm_sysfs_connector_add() connector: 88040ed3f000 kdev: 
>> 88040c55dc00
>> [1.396610]  drm_dp_send_link_address+0x185/0x1f0
>> [1.396614]  drm_dp_check_and_send_link_address+0xad/0xc0
>> [1.396617]  drm_dp_mst_link_probe_work+0x57/0xa0
>> [1.396620]  process_one_work+0x14b/0x430
>> [1.396623]  worker_thread+0x12b/0x4a0
>> [1.396626]  kthread+0x10c/0x140
>> [1.396629]  ? process_one_work+0x430/0x430
>> [1.396632]  ? kthread_create_on_node+0x40/0x40
>> [1.396635]  ret_from_fork+0x27/0x40
>> [1.396639] ---[ end trace dd05bb2cd9ebd900 ]---
>> [1.396643] drm_sysfs_connector_add() connector: 88040c75a000 kdev: 
>> fffe
>> [1.396648] [drm:drm_sysfs_connector_add] *ERROR* failed to register 
>> connector device: -2
>> [1.396651] drm_connector_register(88040ed3f000) 
>> connector->registered: 1
>> [1.39] drm_sysfs_connector_add() connector: 88040ed3f800 kdev: 
>> 88040c55e400
>> [1.396700] drm_connector_register(88040ed3f800) 
>> connector->registered: 1
>> [1.396717] drm_sysfs_connector_add() connector: 88040ed39800 kdev: 
>> 88040c55e800
>> [1.396726] drm_connector_register(88040ed39800) 
>> connector->registered: 1
>> [1.396743] drm_sysfs_connector_add() connector: 88040c758000 kdev: 
>> 88040c55ec00
>> [1.396769] drm_connector_register(88040c758000) 
>> connector->registered: 1
>> [1.396786] drm_sysfs_connector_add() connector: 88040c758800 kdev: 
>> 88040c55f000
>> [1.396799] drm_connector_register(88040c758800) 
>> connector->registered: 1
>> [1.396804] drm_connector_register(88040c75a000) 
>> connector->registered: 1
>> [1.398665] ACPI: Video Device [GFX0] (multi-head: yes  rom: no  post: no)
>> [1.398893] drm_sysfs_connector_add() connector: 

[Bug 99330] Severe flickering with Fiji on Wayland

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

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

--- Comment #2 from Vedran Miletić  ---
(In reply to Ernst Sjöstrand from comment #1)
> Which exact version is that of gnome-shell and mutter?

gnome-shell-3.22.2-2.fc25.x86_64
mutter-3.22.2-3.fc25.x86_64

-- 
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/20170109/e8d84d78/attachment.html>

[PATCH 03/10] drm/i915/psr: fix blank screen issue for psr2

[Vivi, Rodrigo]

On Mon, 2017-01-09 at 18:26 +0530, vathsala nagaraju wrote:
> Psr1 and psr2 are mutually exclusive,ie when psr2 is enabled,
> psr1 should be disabled.When psr2 is exited , bit 31 of reg
> PSR2_CTL must be set to 0 but currently bit 31 of SRD_CTL
> (psr1 control register)is set to 0.
> Also ,PSR2_IDLE state is looked up from SRD_STATUS(psr1 register)
> instead of PSR2_STATUS register, which has wrong data, resulting
> in blankscreen.
> hsw_enable_source is split into hsw_enable_source_psr1 and
> hsw_enable_source_psr2 for easier code review and maintenance,
> as suggested by rodrigo and jim.
> 
> v2: (Rodrigo)
> - Rename hsw_enable_source_psr* to intel_enable_source_psr*
> 
> v3: (Rodrigo)
> - In hsw_psr_disable ,
>   1) for psr active case, handle psr2 followed by psr1.
>   2) psr inactive case, handle psr2 followed by psr1

much better, thanks, but still has one blocking issue imho:

> 
> Cc: Rodrigo Vivi 
> Cc: Jim Bride 
> Signed-off-by: Vathsala Nagaraju 
> Signed-off-by: Patil Deepti 
> ---
>  drivers/gpu/drm/i915/i915_reg.h  |   3 +
>  drivers/gpu/drm/i915/intel_psr.c | 126 
> +--
>  2 files changed, 97 insertions(+), 32 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 00970aa..7830e6e 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -3615,6 +3615,9 @@ enum {
>  #define   EDP_PSR2_FRAME_BEFORE_SU_MASK  (0xf<<4)
>  #define   EDP_PSR2_IDLE_MASK 0xf
>  
> +#define EDP_PSR2_STATUS_CTL_MMIO(0x6f940)
> +#define EDP_PSR2_STATUS_STATE_MASK (0xf<<28)
> +
>  /* VGA port control */
>  #define ADPA _MMIO(0x61100)
>  #define PCH_ADPA_MMIO(0xe1100)
> diff --git a/drivers/gpu/drm/i915/intel_psr.c 
> b/drivers/gpu/drm/i915/intel_psr.c
> index c3aa649..6c161aa 100644
> --- a/drivers/gpu/drm/i915/intel_psr.c
> +++ b/drivers/gpu/drm/i915/intel_psr.c
> @@ -261,12 +261,11 @@ static void vlv_psr_activate(struct intel_dp *intel_dp)
>  VLV_EDP_PSR_ACTIVE_ENTRY);
>  }
>  
> -static void hsw_psr_enable_source(struct intel_dp *intel_dp)
> +static void intel_enable_source_psr1(struct intel_dp *intel_dp)
>  {
>   struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp);
>   struct drm_device *dev = dig_port->base.base.dev;
>   struct drm_i915_private *dev_priv = to_i915(dev);
> -
>   uint32_t max_sleep_time = 0x1f;
>   /*
>* Let's respect VBT in case VBT asks a higher idle_frame value.
> @@ -312,14 +311,30 @@ static void hsw_psr_enable_source(struct intel_dp 
> *intel_dp)
>   val |= EDP_PSR_TP1_TP2_SEL;
>  
>   I915_WRITE(EDP_PSR_CTL, val);
> +}
>  
> - if (!dev_priv->psr.psr2_support)
> - return;
> +static void intel_enable_source_psr2(struct intel_dp *intel_dp)
> +{
> + struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp);
> + struct drm_device *dev = dig_port->base.base.dev;
> + struct drm_i915_private *dev_priv = to_i915(dev);
> +
> + /*
> +  * Let's respect VBT in case VBT asks a higher idle_frame value.
> +  * Let's use 6 as the minimum to cover all known cases including
> +  * the off-by-one issue that HW has in some cases. Also there are
> +  * cases where sink should be able to train
> +  * with the 5 or 6 idle patterns.
> +  */
> + uint32_t idle_frames = max(6, dev_priv->vbt.psr.idle_frames);
> + uint32_t val = EDP_PSR_ENABLE;
> +
> + val |= idle_frames << EDP_PSR_IDLE_FRAME_SHIFT;
>  
>   /* FIXME: selective update is probably totally broken because it doesn't
>* mesh at all with our frontbuffer tracking. And the hw alone isn't
>* good enough. */
> - val = EDP_PSR2_ENABLE | EDP_SU_TRACK_ENABLE;
> + val |= EDP_PSR2_ENABLE | EDP_SU_TRACK_ENABLE;
>  
>   if (dev_priv->vbt.psr.tp2_tp3_wakeup_time > 5)
>   val |= EDP_PSR2_TP2_TIME_2500;
> @@ -333,6 +348,20 @@ static void hsw_psr_enable_source(struct intel_dp 
> *intel_dp)
>   I915_WRITE(EDP_PSR2_CTL, val);
>  }
>  
> +
> +static void hsw_psr_enable_source(struct intel_dp *intel_dp)
> +{
> + struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp);
> + struct drm_device *dev = dig_port->base.base.dev;
> + struct drm_i915_private *dev_priv = to_i915(dev);
> +
> + /* psr1 and psr2 are mutually exclusive.*/
> + if (dev_priv->psr.psr2_support)
> + intel_enable_source_psr2(intel_dp);
> + else
> + intel_enable_source_psr1(intel_dp);
> +}
> +
>  static bool intel_psr_match_conditions(struct intel_dp *intel_dp)
>  {
>   struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp);
> @@ -410,7 +439,10 @@ static void intel_psr_activate(struct intel_dp *intel_dp)
>   struct drm_device *dev = intel_dig_port->base.base.dev;
>   struct drm_i915_private *dev_priv = to_i915(dev);
>  
> - WARN_ON(I915_READ(EDP_PSR_CTL) & EDP_PSR_ENABLE);
> 

[PATCH 0/3] Add CRTC helper drm_crtc_from_index()

[Shawn Guo]

On Fri, Dec 30, 2016 at 12:16:43PM +0100, Daniel Vetter wrote:
> Entire series applied. I suspect that there's more drivers open-coding
> something like this in their vblank code, might be worth it to grep for
> them all and do a quick audit.

I did a round of audit on all drivers vblank code, and found there are
basically 3 categories:

1. Drivers that only support one CRTC.  In this case, the 'pipe' is not
used at all in vblank code.  So we need to do thing about them.
Examples: arm, atmel-hlcdc, mxsfb, etc.

2. Drivers that maintain CRTC pointers and number in the private
structure.  And the fields are used in somewhere else beside vblank
code.  The cleanup will need a bit surgery on the driver code.  I would
leave them out for driver owners/maintainers.  Examples: armada, msm,
sti, etc.

3. Drivers that can use the helper for benefit, including exynos, kirin,
mediatek, nouveau, tegra and vc4.  I have already prepared a series for
these drivers, and will send it out for review shortly.

Shawn

[Bug 99312] Long-running OpenCL kernels cause ring stalls and GPU lockups on Kabini when radeon.lockup_timeout is enabled

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

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

Vedran Miletić  changed:

   What|Removed |Added

Summary|Long-running OpenCL kernels |Long-running OpenCL kernels
   |cause ring stalls and GPU   |cause ring stalls and GPU
   |lockups on Kabini   |lockups on Kabini when
   ||radeon.lockup_timeout is
   ||enabled

--- Comment #2 from Vedran Miletić  ---
(In reply to John Bridgman from comment #1)
> If you have not already done so, try disabling the watchdog timer:
> 
> 
> MODULE_PARM_DESC(lockup_timeout, "GPU lockup timeout in ms (default 1 =
> 10 seconds, 0 = disable)");
> module_param_named(lockup_timeout, radeon_lockup_timeout, int, 0444);
> 

Yup, that works around the problem.

> As part of HSA/ROC development we dropped the priority of compute work
> relative to graphics which improved interactivity and *almost* eliminated
> timeouts without having to disable the timer  - when I get back in the
> office I'll dig up the changes. In the meantime, I think disabling the timer
> will do what you need although you will still have sluggish graphics while
> long-running kernels are active.
> 

Eager to hear the details.

-- 
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/20170109/52ce6e29/attachment.html>

[PATCH libdrm 3/3] xf86drm: Add platform and host1x bus support

[Emil Velikov]

On 2 January 2017 at 13:53, Thierry Reding  wrote:
> On Sat, Dec 24, 2016 at 05:00:27PM +, Emil Velikov wrote:
>> On 23 December 2016 at 17:49, Thierry Reding  
>> wrote:
>> > From: Thierry Reding 
>> >
>> > ARM SoCs usually have their DRM/KMS devices on the platform bus, so add
>> > support for that to enable these devices to be used with the drmDevice
>> > infrastructure.
>> >
>> > NVIDIA Tegra SoCs have an additional level in the hierarchy and DRM/KMS
>> > devices can also be on the host1x bus. This is mostly equivalent to the
>> > platform bus.
>> >
>> > Signed-off-by: Thierry Reding 
>> > ---
>> > Note that we could probably get away with treating host1x as platform
>> > bus. However, they are technically two different busses in the kernel
>> > and hence we may want to make use of that differentiation later on.
>> >
>> Admittedly there's no clear cut either way, but I'm inclined to have
>> host1x as platform.
>> I'm leaning towards that since there is no /sys/bus/host1x (afaict),
>
> Actually there is:
>
> # find /sys/bus/host1x
> /sys/bus/host1x
> /sys/bus/host1x/drivers_probe
> /sys/bus/host1x/devices
> /sys/bus/host1x/devices/drm
> /sys/bus/host1x/uevent
> /sys/bus/host1x/drivers
> /sys/bus/host1x/drivers/drm
> /sys/bus/host1x/drivers/drm/bind
> /sys/bus/host1x/drivers/drm/unbind
> /sys/bus/host1x/drivers/drm/module
> /sys/bus/host1x/drivers/drm/uevent
> /sys/bus/host1x/drivers/drm/drm
> /sys/bus/host1x/drivers_autoprobe
>
>> plus otherwise devices (like imx-vpu/vc4) will end with their own bus
>> type.
>
> I don't think that would happen. Tegra is somewhat special in this case
> because of the host1x device that is a parent for both display and
> capture devices. The host1x bus is architected to allow binding each of
> the DRM/KMS and V4L2 devices (the V4L2 driver hasn't been merged yet)
> to the host1x device.
>
> The reason for this is mostly historical. Back when Tegra support was
> added there was a strict rule against adding dummy device nodes to the
> device tree. For Tegra this wasn't much of a problem because the host1x
> device is the logical choice for a parent, so I just had to write some
> glue (the host1x bus) to instantiate a dummy device for each composite
> driver.
>
> Later on the component/master infrastructure was added and the rules
> regarding dummy device nodes were relaxed, so as far as I know all other
> devices end up anchored to a dummy device on the platform bus.
>
I see. Thanks for the correction and the educational comment.

>> > +static int drmParsePlatformBusInfo(int maj, int min, 
>> > drmPlatformBusInfoPtr info)
>> > +{
>> > +char path[PATH_MAX + 1], *name;
>> > +
>> > +snprintf(path, PATH_MAX, "/sys/dev/char/%d:%d/device", maj, min);
>> > +
>> > +name = sysfs_uevent_get(path, "OF_FULLNAME");
>> > +strcpy(info->fullname, name);
>> > +free(name);
>> > +
>> Let's be extra careful and ensure that we don't overrun (and properly
>> terminate) the fixed size fullname[].
>
> Okay, will do.
>
>> > +return 0;
>> > +}
>> > +
>> > +static int drmParsePlatformDeviceInfo(int maj, int min,
>> > +  drmPlatformDeviceInfoPtr info)
>> > +{
>> > +/* XXX fill in platform device info */
>> > +
>> Not 100% sure what exactly we should consider bus and what device
>> info, either way an empty struct is not going to go well.
>> As a food for thought, here is some info for imx/etna and vc4.
>>
>> cat /sys/dev/char/226\:*/device/uevent
>>
>> DRIVER=etnaviv
>> OF_NAME=gpu-subsystem
>> OF_FULLNAME=/gpu-subsystem
>> OF_COMPATIBLE_0=fsl,imx-gpu-subsystem
>> OF_COMPATIBLE_N=1
>> MODALIAS=of:Ngpu-subsystemTCfsl,imx-gpu-subsystem
>> DRIVER=imx-drm
>> OF_NAME=display-subsystem
>> OF_FULLNAME=/display-subsystem
>> OF_COMPATIBLE_0=fsl,imx-display-subsystem
>> OF_COMPATIBLE_N=1
>>
>> DRIVER=vc4-drm
>> OF_NAME=gpu
>> OF_FULLNAME=/soc/gpu
>> OF_COMPATIBLE_0=brcm,bcm2835-vc4
>> OF_COMPATIBLE_N=1
>> MODALIAS=of:NgpuTCbrcm,bcm2835-vc4
>
> I think the full name is appropriate for bus info because it's about the
> closest thing we have to address the device (the equivalent to domain,
> bus, device and function numbers).
>
> The list of compatible strings might be suitable for device information
> and might be useful for drivers to determine capabilities if the kernel
> doesn't have another means of communicating that to userspace.
>
Agreed. With your thorough explanation in mind I think your
patch/proposal is spot on.

So with the overflow check, this is safe to land.

Thanks
Emil

[PATCH v2] drm: Schedule the output_poll_work with 1s delay if we have delayed event

[Peter Ujfalusi]

Instead of scheduling the work to handle the initial delayed event, use 1s
delay.

This delay should not be needed, but Optimus/nouveau will fail in a
mysterious way if the delayed event is handled as soon as possible like it
is done in drm_helper_probe_single_connector_modes() in case the poll
was enabled before.

Reverting 339fd36238dd would give back the 10 sec (!) delay to handle the
delayed event. Adding 1sec delay to the poll_work is enough to work around
the issue in Optimus setups and gives shorter response on handling the
initial delayed event.

Fixes: 339fd36238dd ("drm: drm_probe_helper: Fix output_poll_work scheduling")
Cc: stable at vger.kernel.org   # v4.9
Signed-off-by: Peter Ujfalusi 
---
 drivers/gpu/drm/drm_probe_helper.c | 10 +-
 1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/drm_probe_helper.c 
b/drivers/gpu/drm/drm_probe_helper.c
index 06a62e37fbdc..258abed43e38 100644
--- a/drivers/gpu/drm/drm_probe_helper.c
+++ b/drivers/gpu/drm/drm_probe_helper.c
@@ -146,8 +146,16 @@ void drm_kms_helper_poll_enable_locked(struct drm_device 
*dev)
drm_connector_list_iter_put(_iter);

if (dev->mode_config.delayed_event) {
+   /*
+* Use short (1s) delay to handle the initial delayed event.
+* This delay should not be needed, but Optimus/nouveau will
+* fail in a mysterious way if the delayed event is handled as
+* soon as possible like it is done in
+* drm_helper_probe_single_connector_modes() in case the poll
+* was enabled before.
+*/
poll = true;
-   delay = 0;
+   delay = HZ;
}

if (poll)
-- 
2.11.0

[PATCH] drm: Fix broken VT switch with video=1366x768 option

[Takashi Iwai]

I noticed that the VT switch doesn't work any longer with a Dell
laptop with 1366x768 eDP when the machine is connected with a DP
monitor.  It behaves as if VT were switched, but the graphics remain
frozen.  Actually the keyboard works, so I could switch back to VT7
again.

I tried to track down the problem, and encountered a long story until
we reach to this error:

- The machine is booted with video=1366x768 option (the distro
  installer seems to add it as default).
- Recently, drm_helper_probe_single_connector_modes() deals with
  cmdline modes, and it tries to create a new mode when no
  matching mode is found.
- The drm_mode_create_from_cmdline_mode() creates a mode based on
  either CVT of GFT according to the given cmdline mode; in our case,
  it's 1366x768.
- Since both CVT and GFT can't express the width 1366 due to
  alignment, the resultant mode becomes 1368x768, slightly larger than
  the given size.
- Later on, the atomic commit is performed, and in
  drm_atomic_check_only(), the size of each plane is checked.
- The size check of 1366x768 fails due to the above, and eventually
  the whole VT switch fails.

Back in the history, we've had a manual fix-up of 1368x768 in various
places via c09dedb7a50e ("drm/edid: Add a workaround for 1366x768 HD
panel"), but they have been all in drm_edid.c at probing the modes
from EDID.  For addressing the problem above, we need a similar hack
to the mode newly created from cmdline, manually adjusting the width
when the expected size is 1366 while we get 1368 instead.

Fixes: eaf99c749d43 ("drm: Perform cmdline mode parsing during...")
Cc: 
Signed-off-by: Takashi Iwai 
---
 drivers/gpu/drm/drm_modes.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
index ac6a35212501..e6b19bc9021a 100644
--- a/drivers/gpu/drm/drm_modes.c
+++ b/drivers/gpu/drm/drm_modes.c
@@ -1460,6 +1460,13 @@ drm_mode_create_from_cmdline_mode(struct drm_device *dev,
return NULL;

mode->type |= DRM_MODE_TYPE_USERDEF;
+   /* fix up 1368x768: GFT/CVT can't express 1366 width due to alignment */
+   if (cmd->xres == 1366 && mode->hdisplay == 1368) {
+   mode->hdisplay = 1366;
+   mode->hsync_start--;
+   mode->hsync_end--;
+   drm_mode_set_name(mode);
+   }
drm_mode_set_crtcinfo(mode, CRTC_INTERLACE_HALVE_V);
return mode;
 }
-- 
2.11.0

[Bug 99330] Severe flickering with Fiji on Wayland

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

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

--- Comment #1 from Ernst Sjöstrand  ---
Which exact version is that of gnome-shell and mutter?

-- 
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/20170109/eec21687/attachment.html>

4.10-rc2 i915 LVDS display noise on X61s thinkpad

[Jani Nikula]

On Mon, 09 Jan 2017, vcaputo at pengaru.com wrote:
> Hi All,
>
> Booted 4.10-rc2 today, and the display shows random spots of flickering
> short horizontal bars 1px tall, maybe 8 or 16px wide.  Machine is the
> venerable X61s thinkpad, 1.8ghz, XGA.  Problem was not present on 4.9.0,
> same kernel config.
>
> I'll see if I can get around to bisecting, consider this a heads-up.
>
> Attached config for the curious, it's clearly visible in my drm eye
> candy toy https://github.com/vcaputo/rototiller.
>
> Not on list so please CC me in replies, thanks

Please file any drm/i915 issues at
https://bugs.freedesktop.org/enter_bug.cgi?product=DRI=DRM/Intel

BR,
Jani.

-- 
Jani Nikula, Intel Open Source Technology Center

[PATCH] drm/exynos/decon5433: update shadow registers iff there are active windows

[Andrzej Hajda]

Improper usage of DECON_UPDATE register leads to subtle errors.
If it set in decon_commit when there are no active windows it results
in slow registry updates - all subsequent shadow registry updates takes more
than full vblank. On the other side if it is not set when there are
active windows it results in garbage on the screen after suspend/resume of
FB console.

The patch hopefully fixes it.

Signed-off-by: Andrzej Hajda 
---
 drivers/gpu/drm/exynos/exynos5433_drm_decon.c | 7 +++
 1 file changed, 3 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c 
b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
index ca75fe1..f15d9b1 100644
--- a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
+++ b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
@@ -209,8 +209,6 @@ static void decon_commit(struct exynos_drm_crtc *crtc)

/* enable output and display signal */
decon_set_bits(ctx, DECON_VIDCON0, VIDCON0_ENVID | VIDCON0_ENVID_F, ~0);
-
-   decon_set_bits(ctx, DECON_UPDATE, STANDALONE_UPDATE_F, ~0);
 }

 static void decon_win_set_pixfmt(struct decon_context *ctx, unsigned int win,
@@ -361,8 +359,9 @@ static void decon_atomic_flush(struct exynos_drm_crtc *crtc)
for (i = ctx->first_win; i < WINDOWS_NR; i++)
decon_shadow_protect_win(ctx, i, false);

-   /* standalone update */
-   decon_set_bits(ctx, DECON_UPDATE, STANDALONE_UPDATE_F, ~0);
+   /* update iff there are active windows */
+   if (crtc->base.state->plane_mask)
+   decon_set_bits(ctx, DECON_UPDATE, STANDALONE_UPDATE_F, ~0);

if (ctx->out_type & IFTYPE_I80)
set_bit(BIT_WIN_UPDATED, >flags);
-- 
2.7.4

[PATCH] drm: zte: select VIDEOMODE_HELPERS in Kconfig

[Shawn Guo]

From: Shawn Guo 

ZTE DRM driver uses drm_display_mode_to_videomode() in function
zx_crtc_enable().  Select VIDEOMODE_HELPERS in Kconfig to fix the
following link error.

  LD  vmlinux.o
  MODPOST vmlinux.o
drivers/built-in.o: In function `zx_crtc_enable':
:(.text+0xbdeb8): undefined reference to `drm_display_mode_to_videomode'

Signed-off-by: Shawn Guo 
---
 drivers/gpu/drm/zte/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/zte/Kconfig b/drivers/gpu/drm/zte/Kconfig
index 4065b2840f1c..5f9b4e7f2a36 100644
--- a/drivers/gpu/drm/zte/Kconfig
+++ b/drivers/gpu/drm/zte/Kconfig
@@ -4,5 +4,6 @@ config DRM_ZTE
select DRM_KMS_CMA_HELPER
select DRM_KMS_FB_HELPER
select DRM_KMS_HELPER
+   select VIDEOMODE_HELPERS
help
  Choose this option to enable DRM on ZTE ZX SoCs.
-- 
1.9.1

[PATCH] drm: zte: select VIDEOMODE_HELPERS in Kconfig

[Shawn Guo]

From: Shawn Guo 

ZTE DRM driver uses drm_display_mode_to_videomode() in function
zx_crtc_enable().  Select VIDEOMODE_HELPERS in Kconfig to fix the
following link error.

  LD  vmlinux.o
  MODPOST vmlinux.o
drivers/built-in.o: In function `zx_crtc_enable':
:(.text+0xbdeb8): undefined reference to `drm_display_mode_to_videomode'

Signed-off-by: Shawn Guo 
---
 drivers/gpu/drm/zte/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/zte/Kconfig b/drivers/gpu/drm/zte/Kconfig
index 4065b2840f1c..5f9b4e7f2a36 100644
--- a/drivers/gpu/drm/zte/Kconfig
+++ b/drivers/gpu/drm/zte/Kconfig
@@ -4,5 +4,6 @@ config DRM_ZTE
select DRM_KMS_CMA_HELPER
select DRM_KMS_FB_HELPER
select DRM_KMS_HELPER
+   select VIDEOMODE_HELPERS
help
  Choose this option to enable DRM on ZTE ZX SoCs.
-- 
1.9.1

[Bug 95306] Random Blank(black) screens on "Carrizo"

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

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

--- Comment #46 from Patrick Laurin  ---
Heh, nan, EUSERDRUNKONFLOOR error usually rotates both ways and displays
some blurring effects!
I'm not near the machine having this behaviour i'll give feed back asap on
this.

On 9 January 2017 at 10:18,  wrote:

> *Comment # 45 <https://bugs.freedesktop.org/show_bug.cgi?id=95306#c45> on
> bug 95306 <https://bugs.freedesktop.org/show_bug.cgi?id=95306> from Tom St
> Denis  *
>
> Just to rule out the low hanging fruit.  There was no celebratory champagne
> involved in the screen rotation issues right?  :-) (EUSERDRUNKONFLOOR error
> happens from time to time)
>
> What does xrandr report normally and while inverted?
>
> --
> You are receiving this mail because:
>
>- You are on the CC list for the 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/20170109/cb273f15/attachment-0001.html>

[Bug 95306] Random Blank(black) screens on "Carrizo"

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

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

--- Comment #45 from Tom St Denis  ---
Just to rule out the low hanging fruit.  There was no celebratory champagne
involved in the screen rotation issues right?  :-) (EUSERDRUNKONFLOOR error
happens from time to time)

What does xrandr report normally and while inverted?

-- 
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/20170109/2c3af6f9/attachment.html>

[PATCH] drm/bridge: analogix dp: Fix runtime PM state on driver bind

[Archit Taneja]

On 01/05/2017 01:01 PM, Sean Paul wrote:
> On Fri, Dec 30, 2016 at 4:57 AM, Marek Szyprowski
>  wrote:
>> Analogix_dp_bind() can be called from component framework, which doesn't
>> guarantee proper runtime PM state of the device during bind operation,
>> so ensure that device is runtime active before doing any register access.
>> This ensures that the power domain, to which DP module belongs, is turned
>> on. While at it, also fix the unbalanced call to phy_power_on() in
>> analogix_dp_bind() function.

Pushed to drm-misc-fixes.

Thanks,
Archit

>>
>> This patch solves the following kernel oops on Samsung Exynos5250 Snow
>> board:
>>
>> Unhandled fault: imprecise external abort (0x406) at 0x
>> pgd = c0004000
>> [] *pgd=
>> Internal error: : 406 [#1] PREEMPT SMP ARM
>> Modules linked in:
>> CPU: 0 PID: 75 Comm: kworker/0:2 Not tainted 4.9.0 #1046
>> Hardware name: SAMSUNG EXYNOS (Flattened Device Tree)
>> Workqueue: events deferred_probe_work_func
>> task: ee272300 task.stack: ee312000
>> PC is at analogix_dp_enable_sw_function+0x18/0x2c
>> LR is at analogix_dp_init_dp+0x2c/0x50
>> ...
>> [] (analogix_dp_enable_sw_function) from [] 
>> (analogix_dp_init_dp+0x2c/0x50)
>> [] (analogix_dp_init_dp) from [] 
>> (analogix_dp_bind+0x184/0x42c)
>> [] (analogix_dp_bind) from [] 
>> (component_bind_all+0xf0/0x218)
>> [] (component_bind_all) from [] 
>> (exynos_drm_load+0x134/0x200)
>> [] (exynos_drm_load) from [] (drm_dev_register+0xa0/0xd0)
>> [] (drm_dev_register) from [] 
>> (drm_platform_init+0x58/0xb0)
>> [] (drm_platform_init) from [] 
>> (try_to_bring_up_master+0x14c/0x188)
>> [] (try_to_bring_up_master) from [] 
>> (component_add+0x88/0x138)
>> [] (component_add) from [] (platform_drv_probe+0x50/0xb0)
>> [] (platform_drv_probe) from [] 
>> (driver_probe_device+0x1f0/0x2a8)
>> [] (driver_probe_device) from [] 
>> (bus_for_each_drv+0x44/0x8c)
>> [] (bus_for_each_drv) from [] 
>> (__device_attach+0x9c/0x100)
>> [] (__device_attach) from [] (bus_probe_device+0x84/0x8c)
>> [] (bus_probe_device) from [] 
>> (deferred_probe_work_func+0x60/0x8c)
>> [] (deferred_probe_work_func) from [] 
>> (process_one_work+0x120/0x318)
>> [] (process_one_work) from [] 
>> (process_scheduled_works+0x28/0x38)
>> [] (process_scheduled_works) from [] 
>> (worker_thread+0x204/0x4ac)
>> [] (worker_thread) from [] (kthread+0xd8/0xf4)
>> [] (kthread) from [] (ret_from_fork+0x14/0x3c)
>> Code: e59035f0 e5935018 f57ff04f e3c55001 (f57ff04e)
>> ---[ end trace 3d1d0d87796de344 ]---
>>
>
> Reviewed-by: Sean Paul 
>
>> Signed-off-by: Marek Szyprowski 
>> ---
>>  drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 7 +++
>>  1 file changed, 7 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c 
>> b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
>> index eb9bf8786c24..18eefdcbf1ba 100644
>> --- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
>> +++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
>> @@ -1382,6 +1382,7 @@ 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);
>> @@ -1414,9 +1415,15 @@ int analogix_dp_bind(struct device *dev, struct 
>> drm_device *drm_dev,
>> goto err_disable_pm_runtime;
>> }
>>
>> +   phy_power_off(dp->phy);
>> +   pm_runtime_put(dev);
>> +
>> return 0;
>>
>>  err_disable_pm_runtime:
>> +
>> +   phy_power_off(dp->phy);
>> +   pm_runtime_put(dev);
>> pm_runtime_disable(dev);
>>
>> return ret;
>> --
>> 1.9.1
>>
>
>
>

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

[Bug 95306] Random Blank(black) screens on "Carrizo"

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

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

--- Comment #44 from Patrick Laurin  ---
I confirm I didn't get the black screen after more than 20 minutes while
trying kernel 4.10. This is GREAT new !!!

But, My screen was rotating by itself in a random manner, after a couple of
minutes. (Counter-clockwise after 15 minutes, counter-clockwize again after
5 minutes, etc...) Not sure if related tough...

On 9 January 2017 at 02:02,  wrote:

> *Comment # 43 <https://bugs.freedesktop.org/show_bug.cgi?id=95306#c43> on
> bug 95306 <https://bugs.freedesktop.org/show_bug.cgi?id=95306> from Kelly
> Anderson  *
>
> Amdgpu eems to be fixed since my last testing!
>
> Kernel 4.9.1
> Mesa 13.0.3
> LibDrm 2.4.74
>
> --
> You are receiving this mail because:
>
>- You are on the CC list for the 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/20170109/63c34214/attachment.html>

[Bug 99330] Severe flickering with Fiji on Wayland

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

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

Bug ID: 99330
   Summary: Severe flickering with Fiji on Wayland
   Product: Mesa
   Version: unspecified
  Hardware: Other
OS: All
Status: NEW
  Severity: normal
  Priority: medium
 Component: Drivers/Gallium/radeonsi
  Assignee: dri-devel at lists.freedesktop.org
  Reporter: vedran at miletic.net
QA Contact: dri-devel at lists.freedesktop.org

I am using

01:00.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc.
[AMD/ATI] Fiji [Radeon R9 FURY / NANO Series] [1002:7300] (rev ca) (prog-if 00
[VGA controller])

on Fedora 25 running GNOME 3 with Mesa git and LLVM git on two 4K monitors.
When using Wayland, there is a noticeable flickering in the upper part of the
screen when switching between desktops. Nothing relevant is shown in dmesg.

Also, when using Xorg, everything works fine.

Would a screenshot be useful? Any other info I can provide?

-- 
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/20170109/4efec96e/attachment.html>

[PATCH 3/3] dma-fence: Introduce drm_fence_set_error() helper

[Chris Wilson]

On Mon, Jan 09, 2017 at 08:13:11PM +0530, Sumit Semwal wrote:
> Hi Chris,
> 
> On 4 January 2017 at 19:42, Chris Wilson  wrote:
> > The dma_fence.error field (formerly known as dma_fence.status) is an
> > optional field that may be set by drivers before calling
> > dma_fence_signal(). The field can be used to indicate that the fence was
> > completed in err rather than with success, and is visible to other
> > consumers of the fence and to userspace via sync_file.
> >
> > This patch renames the field from status to error so that its meaning is
> > hopefully more clear (and distinct from dma_fence_get_status() which is
> > a composite between the error state and signal state) and adds a helper
> > that validates the preconditions of when it is suitable to adjust the
> > error field.
> >
> > Signed-off-by: Chris Wilson 
> > ---
> >  drivers/dma-buf/dma-fence.c |  2 +-
> >  include/linux/dma-fence.h   | 30 +-
> >  2 files changed, 26 insertions(+), 6 deletions(-)
> >
> > diff --git a/drivers/dma-buf/dma-fence.c b/drivers/dma-buf/dma-fence.c
> > index 7d936d19e659..ee82f36cb25e 100644
> > --- a/drivers/dma-buf/dma-fence.c
> > +++ b/drivers/dma-buf/dma-fence.c
> > @@ -559,7 +559,7 @@ dma_fence_init(struct dma_fence *fence, const struct 
> > dma_fence_ops *ops,
> > fence->context = context;
> > fence->seqno = seqno;
> > fence->flags = 0UL;
> > -   fence->status = 0;
> > +   fence->error = 0;
> >
> > trace_dma_fence_init(fence);
> >  }
> > diff --git a/include/linux/dma-fence.h b/include/linux/dma-fence.h
> > index 19f7af905182..6048fa404e57 100644
> > --- a/include/linux/dma-fence.h
> > +++ b/include/linux/dma-fence.h
> > @@ -47,7 +47,7 @@ struct dma_fence_cb;
> >   * can be compared to decide which fence would be signaled later.
> >   * @flags: A mask of DMA_FENCE_FLAG_* defined below
> >   * @timestamp: Timestamp when the fence was signaled.
> > - * @status: Optional, only valid if < 0, must be set before calling
> > + * @error: Optional, only valid if < 0, must be set before calling
> >   * dma_fence_signal, indicates that the fence has completed with an error.
> >   *
> >   * the flags member must be manipulated and read using the appropriate
> > @@ -79,7 +79,7 @@ struct dma_fence {
> > unsigned seqno;
> > unsigned long flags;
> > ktime_t timestamp;
> > -   int status;
> > +   int error;
> >  };
> >
> >  enum dma_fence_flag_bits {
> > @@ -133,7 +133,7 @@ struct dma_fence_cb {
> >   * or some failure occurred that made it impossible to enable
> >   * signaling. True indicates successful enabling.
> >   *
> > - * fence->status may be set in enable_signaling, but only when false is
> > + * fence->error may be set in enable_signaling, but only when false is
> >   * returned.
> >   *
> >   * Calling dma_fence_signal before enable_signaling is called allows
> > @@ -145,7 +145,7 @@ struct dma_fence_cb {
> >   * the second time will be a noop since it was already signaled.
> >   *
> >   * Notes on signaled:
> > - * May set fence->status if returning true.
> > + * May set fence->error if returning true.
> >   *
> >   * Notes on wait:
> >   * Must not be NULL, set to dma_fence_default_wait for default 
> > implementation.
> > @@ -395,13 +395,33 @@ static inline struct dma_fence 
> > *dma_fence_later(struct dma_fence *f1,
> >  static inline int dma_fence_get_status_locked(struct dma_fence *fence)
> >  {
> > if (dma_fence_is_signaled_locked(fence))
> > -   return fence->status < 0 ? fence->status : 1;
> > +   return fence->error ?: 1;
> > else
> > return 0;
> >  }
> >
> >  int dma_fence_get_status(struct dma_fence *fence);
> >
> > +/**
> > + * dma_fence_set_error - flag an error condition on the fence
> > + * @fence: [in]the dma_fence
> > + * @error: [in]the error to store
> > + *
> > + * Drivers can supply an optional error status condition before they signal
> > + * the fence, to indicate that the fence was completed due to an error
> > + * rather than success. This must be set before signaling (so that the 
> > value
> > + * is visible before any waiters on the signal callback are woken). This
> > + * helper exists to help catching erroneous setting of #dma_fence.error.
> > + */
> > +static inline void dma_fence_set_error(struct dma_fence *fence,
> > +  int error)
> > +{
> > +   BUG_ON(test_bit(DMA_FENCE_FLAG_SIGNALED_BIT, >flags));
> > +   BUG_ON(error >= 0 || error < -MAX_ERRNO);
> > +
> > +   fence->error = error;
> > +}
> Sorry I missed this earlier, but are you sure you want to use a BUG_ON
> here, and not a WARN_ON?

Given that it is a void return, there's nowhere for the warning to go.
The second is a definite programming error and should hopefully be
eliminated at compiletime, but writing it as a BUILD_BUG or
__builtin_constant_p may not work - BUILD_BUG_ON(error...) happens to
work for my 

[Intel-gfx] 4.10-rc2 oops in DRM connector code

[Alex Deucher]

On Mon, Jan 9, 2017 at 12:22 PM, Dave Hansen  wrote:
> On 01/09/2017 08:59 AM, Daniel Vetter wrote:
>> On Mon, Jan 9, 2017 at 5:50 PM, Dave Hansen  wrote:
>>> On 01/09/2017 08:41 AM, Daniel Vetter wrote:
 On Mon, Jan 9, 2017 at 2:40 PM, Dave Hansen  
 wrote:
> Well, now I found where the -2 comes from.
> intel_dp_register_mst_connector() calls drm_connector_register(), which
> fails to add the kobject (warning below).  But, it does zero error
> checking on the drm_connector_register() call and leaves the
> partially-constructed connector in place.
>
> The next time some poor, hapless code goes and tries to do anything with
> that kdev, they oops.  I'm perplexed by this, though.  The
> drm_dp_mst_topology_cbs->register_connector just returns void.  It seems
> a bit goofy that it can't even _return_ failure.
>
> Is there some stable code to go back to here?  Or, is there something
> about my configuration that's unique?  I really wonder why nobody else
> is running into this.
>
> There's probably some other race going on here.  This warning doesn't
> happen on every boot.
 This smells more like the root-cause: Something goes wrong on boot
 that prevents connectors from properly registering, then we fall over
 later on. And the register callback is intentionally void, assuming
 that any prep work has been done earlier and that therefore the
 register step can't fail. Can you pls check whether the oops later on
 only happens together with this warning at boot, or whether they're
 not correlated?
>>>
>>> Looking through my logs, I can't find any instance of the oops without
>>> the warning at boot.  So I do think the later oops is entirely caused by
>>> the issue warned about in early boot.
>>
>> Hm, I guess then we'd need to fix that boot-up warning. Can you try to
>> figure out why it's unhappy? On a hunch it could be that we call
>> drm_connector_register from the mst probe worker before the main
>> driver load thread has reached the drm_dev_register call. A few printk
>> to decide whether that's the case (plus a few boot-up tests to gather
>> the statistics, sorry about that) would be real great.
>>
>> If that's inconclusive I'm again a bit low on ideas ...
>
> I'll do that shortly.  But, for now I can confirm that the failure is
> precipitated by the !parent check in sysfs_create_dir_ns().
>
> I also can't reproduce this if I build i915 as a module.  It only
> happens when built in.

FWIW, we ran into a race with fbdev and mst topology discovery.  Maybe
you are seeing something similar?

Alex


>
>> Jan  9 09:07:34 ray kernel: [1.400547] sysfs_create_dir_ns()::53 error: 
>> -2
>> Jan  9 09:07:34 ray kernel: [1.400554] create_dir()::75 error: -2
>> Jan  9 09:07:34 ray kernel: [1.400558] [ cut here 
>> ]
>> Jan  9 09:07:34 ray kernel: [1.400565] WARNING: CPU: 1 PID: 90 at 
>> lib/kobject.c:249 kobject_add_internal+0x273/0x320
>> Jan  9 09:07:34 ray kernel: [1.400569] kobject_add_internal failed for 
>> card0-DP-3 (error: -2 parent: card0)
>> Jan  9 09:07:34 ray kernel: [1.400572] Modules linked in:
>> Jan  9 09:07:34 ray kernel: [1.400577] CPU: 1 PID: 90 Comm: kworker/1:2 
>> Not tainted 4.10.0-rc3-dirty #61
>> Jan  9 09:07:34 ray kernel: [1.400579] Hardware name: LENOVO 
>> 20F5S7V800/20F5S7V800, BIOS R02ET50W (1.23 ) 09/20/2016
>> Jan  9 09:07:34 ray kernel: [1.400585] Workqueue: events_long 
>> drm_dp_mst_link_probe_work
>> Jan  9 09:07:34 ray kernel: [1.400588] Call Trace:
>> Jan  9 09:07:34 ray kernel: [1.400593]  dump_stack+0x67/0x99
>> Jan  9 09:07:34 ray kernel: [1.400598]  __warn+0xd1/0xf0
>> Jan  9 09:07:34 ray kernel: [1.400601]  warn_slowpath_fmt+0x4f/0x60
>> Jan  9 09:07:34 ray kernel: [1.400604]  kobject_add_internal+0x273/0x320
>> Jan  9 09:07:34 ray kernel: [1.400607]  kobject_add+0x65/0xb0
>> Jan  9 09:07:34 ray kernel: [1.400611]  ? klist_init+0x31/0x40
>> Jan  9 09:07:34 ray kernel: [1.400615]  device_add+0x102/0x5d0
>> Jan  9 09:07:34 ray kernel: [1.400619]  ? kfree_const+0x22/0x30
>> Jan  9 09:07:34 ray kernel: [1.400623]  
>> device_create_groups_vargs+0xd8/0x100
>> Jan  9 09:07:34 ray kernel: [1.400626]  
>> device_create_with_groups+0x36/0x40
>> Jan  9 09:07:34 ray kernel: [1.400631]  ? 
>> drm_fb_helper_add_one_connector+0x57/0xd0
>> Jan  9 09:07:34 ray kernel: [1.400636]  ? 
>> kmem_cache_alloc_trace+0x1d2/0x1f0
>> Jan  9 09:07:34 ray kernel: [1.400641]  drm_sysfs_connector_add+0x60/0xe0
>> Jan  9 09:07:34 ray kernel: [1.400645]  drm_connector_register+0x21/0xc0
>> Jan  9 09:07:34 ray kernel: [1.400649]  
>> intel_dp_register_mst_connector+0x41/0x50
>> Jan  9 09:07:34 ray kernel: [1.400653]  drm_dp_add_port+0x350/0x450
>> Jan  9 09:07:34 ray kernel: [1.400657]  ? rcu_early_boot_tests+0x1/0x10
>> Jan  9 09:07:34 ray kernel: [1.400660]  ? 

[PATCH v4 5/5] drm/rockchip: Implement CRC debugfs API

[Tomeu Vizoso]

Implement the .set_crc_source() callback and call the DP helpers
accordingly to start and stop CRC capture.

This is only done if this CRTC is currently using the eDP connector.

v3: Remove superfluous check on rockchip_crtc_state->output_type

Signed-off-by: Tomeu Vizoso 
---

 drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 42 +
 1 file changed, 42 insertions(+)

diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c 
b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
index fb5f001f51c3..6e5eb1aa182a 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
@@ -19,6 +19,7 @@
 #include 
 #include 
 #include 
+#include 

 #include 
 #include 
@@ -1105,6 +1106,46 @@ static void vop_crtc_destroy_state(struct drm_crtc *crtc,
kfree(s);
 }

+static struct drm_connector *vop_get_edp_connector(struct vop *vop)
+{
+   struct drm_crtc *crtc = >crtc;
+   struct drm_connector *connector;
+
+   mutex_lock(>dev->mode_config.mutex);
+   drm_for_each_connector(connector, crtc->dev)
+   if (connector->connector_type == DRM_MODE_CONNECTOR_eDP) {
+   mutex_unlock(>dev->mode_config.mutex);
+   return connector;
+   }
+   mutex_unlock(>dev->mode_config.mutex);
+
+   return NULL;
+}
+
+static int vop_crtc_set_crc_source(struct drm_crtc *crtc,
+  const char *source_name, size_t *values_cnt)
+{
+   struct vop *vop = to_vop(crtc);
+   struct rockchip_crtc_state *s = to_rockchip_crtc_state(crtc->state);
+   struct drm_connector *connector;
+   int ret;
+
+   connector = vop_get_edp_connector(vop);
+   if (!connector)
+   return -EINVAL;
+
+   *values_cnt = 3;
+
+   if (source_name && strcmp(source_name, "auto") == 0)
+   ret = analogix_dp_start_crc(connector);
+   else if (!source_name)
+   ret = analogix_dp_stop_crc(connector);
+   else
+   ret = -EINVAL;
+
+   return ret;
+}
+
 static const struct drm_crtc_funcs vop_crtc_funcs = {
.set_config = drm_atomic_helper_set_config,
.page_flip = drm_atomic_helper_page_flip,
@@ -1112,6 +1153,7 @@ static const struct drm_crtc_funcs vop_crtc_funcs = {
.reset = vop_crtc_reset,
.atomic_duplicate_state = vop_crtc_duplicate_state,
.atomic_destroy_state = vop_crtc_destroy_state,
+   .set_crc_source = vop_crtc_set_crc_source,
 };

 static void vop_fb_unref_worker(struct drm_flip_work *work, void *val)
-- 
2.9.3

[PATCH v4 4/5] drm/bridge: analogix_dp: add helpers for capture of frame CRCs

[Tomeu Vizoso]

Add two simple functions that just take the drm_dp_aux from our struct
and calls the corresponding DP helpers with it.

Signed-off-by: Tomeu Vizoso 
---

 drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 16 
 include/drm/bridge/analogix_dp.h   |  3 +++
 2 files changed, 19 insertions(+)

diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c 
b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
index 7d45d3e4600a..02f63eb1b887 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
@@ -1483,6 +1483,22 @@ int analogix_dp_resume(struct device *dev)
 EXPORT_SYMBOL_GPL(analogix_dp_resume);
 #endif

+int analogix_dp_start_crc(struct drm_connector *connector)
+{
+   struct analogix_dp_device *dp = to_dp(connector);
+
+   return drm_dp_start_crc(>aux);
+}
+EXPORT_SYMBOL_GPL(analogix_dp_start_crc);
+
+int analogix_dp_stop_crc(struct drm_connector *connector)
+{
+   struct analogix_dp_device *dp = to_dp(connector);
+
+   return drm_dp_stop_crc(>aux);
+}
+EXPORT_SYMBOL_GPL(analogix_dp_stop_crc);
+
 MODULE_AUTHOR("Jingoo Han ");
 MODULE_DESCRIPTION("Analogix DP Core Driver");
 MODULE_LICENSE("GPL v2");
diff --git a/include/drm/bridge/analogix_dp.h b/include/drm/bridge/analogix_dp.h
index f6f0c062205c..c99d6eaef1ac 100644
--- a/include/drm/bridge/analogix_dp.h
+++ b/include/drm/bridge/analogix_dp.h
@@ -49,4 +49,7 @@ int analogix_dp_bind(struct device *dev, struct drm_device 
*drm_dev,
 struct analogix_dp_plat_data *plat_data);
 void analogix_dp_unbind(struct device *dev, struct device *master, void *data);

+int analogix_dp_start_crc(struct drm_connector *connector);
+int analogix_dp_stop_crc(struct drm_connector *connector);
+
 #endif /* _ANALOGIX_DP_H_ */
-- 
2.9.3

[PATCH v4 3/5] drm/dp: add helpers for capture of frame CRCs

[Tomeu Vizoso]

Adds helpers for starting and stopping capture of frame CRCs through the
DPCD. When capture is on, a worker waits for vblanks and retrieves the
frame CRC to put it in the queue on the CRTC that is using the
eDP connector, so it's passed to userspace.

v2: Reuse drm_crtc_wait_one_vblank
Update locking, as drm_crtc_add_crc_entry now takes the lock

v3: Don't call wake_up_interruptible directly, that's now done in
drm_crtc_add_crc_entry.

v4: Style fixes (Sean Paul)
Reworked retry of CRC reads (Sean Paul)
Flush worker after stopping CRC generationa (Sean Paul)

Signed-off-by: Tomeu Vizoso 
---

 drivers/gpu/drm/drm_dp_helper.c | 129 
 include/drm/drm_dp_helper.h |   7 +++
 2 files changed, 136 insertions(+)

diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
index 3e6fe82c6d64..f9018faf7e07 100644
--- a/drivers/gpu/drm/drm_dp_helper.c
+++ b/drivers/gpu/drm/drm_dp_helper.c
@@ -981,6 +981,83 @@ static const struct i2c_lock_operations 
drm_dp_i2c_lock_ops = {
.unlock_bus = unlock_bus,
 };

+static int drm_dp_aux_get_crc(struct drm_dp_aux *aux, u8 *crc)
+{
+   u8 buf, count;
+   int ret;
+
+   ret = drm_dp_dpcd_readb(aux, DP_TEST_SINK, );
+   if (ret < 0)
+   return ret;
+
+   WARN_ON(!(buf & DP_TEST_SINK_START));
+
+   ret = drm_dp_dpcd_readb(aux, DP_TEST_SINK_MISC, );
+   if (ret < 0)
+   return ret;
+
+   count = buf & DP_TEST_COUNT_MASK;
+   if (count == aux->crc_count)
+   return -EAGAIN; /* No CRC yet */
+
+   aux->crc_count = count;
+
+   /*
+* At DP_TEST_CRC_R_CR, there's 6 bytes containing CRC data, 2 bytes
+* per component (RGB or CrYCb).
+*/
+   ret = drm_dp_dpcd_read(aux, DP_TEST_CRC_R_CR, crc, 6);
+   if (ret < 0)
+   return ret;
+
+   return 0;
+}
+
+static void drm_dp_aux_crc_work(struct work_struct *work)
+{
+   struct drm_dp_aux *aux = container_of(work, struct drm_dp_aux,
+ crc_work);
+   struct drm_crtc *crtc;
+   u8 crc_bytes[6];
+   uint32_t crcs[3];
+   bool retry = false;
+   int ret;
+
+   if (WARN_ON(!aux->connector))
+   return;
+
+   crtc = aux->connector->state->crtc;
+   while (crtc->crc.opened) {
+   if (!retry) {
+   drm_crtc_wait_one_vblank(crtc);
+   if (!crtc->crc.opened)
+   break;
+   }
+
+   ret = drm_dp_aux_get_crc(aux, crc_bytes);
+   if (ret == -EAGAIN) {
+   if (retry)
+   DRM_DEBUG_KMS("Failed to get a CRC even after 
retrying: %d\n",
+ ret);
+   retry = !retry;
+   usleep_range(1000, 2000);
+   continue;
+   }
+
+   retry = false;
+   if (!ret) {
+   crcs[0] = crc_bytes[0] | crc_bytes[1] << 8;
+   crcs[1] = crc_bytes[2] | crc_bytes[3] << 8;
+   crcs[2] = crc_bytes[4] | crc_bytes[5] << 8;
+   ret = drm_crtc_add_crc_entry(crtc, false, 0, crcs);
+   if (ret)
+   DRM_DEBUG_KMS("Failed to add crc entry %d\n", 
ret);
+   } else {
+   DRM_DEBUG_KMS("Get CRC failed: %d\n", ret);
+   }
+   }
+}
+
 /**
  * drm_dp_aux_init() - minimally initialise an aux channel
  * @aux: DisplayPort AUX channel
@@ -993,6 +1070,7 @@ static const struct i2c_lock_operations 
drm_dp_i2c_lock_ops = {
 void drm_dp_aux_init(struct drm_dp_aux *aux)
 {
mutex_init(>hw_mutex);
+   INIT_WORK(>crc_work, drm_dp_aux_crc_work);

aux->ddc.algo = _dp_i2c_algo;
aux->ddc.algo_data = aux;
@@ -1081,3 +1159,54 @@ int drm_dp_psr_setup_time(const u8 
psr_cap[EDP_PSR_RECEIVER_CAP_SIZE])
 EXPORT_SYMBOL(drm_dp_psr_setup_time);

 #undef PSR_SETUP_TIME
+
+/**
+ * drm_dp_start_crc() - start capture of frame CRCs
+ * @aux: DisplayPort AUX channel
+ *
+ * Returns 0 on success or a negative error code on failure.
+ */
+int drm_dp_start_crc(struct drm_dp_aux *aux)
+{
+   u8 buf;
+   int ret;
+
+   ret = drm_dp_dpcd_readb(aux, DP_TEST_SINK, );
+   if (ret < 0)
+   return ret;
+
+   ret = drm_dp_dpcd_writeb(aux, DP_TEST_SINK, buf | DP_TEST_SINK_START);
+   if (ret < 0)
+   return ret;
+
+   aux->crc_count = 0;
+   schedule_work(>crc_work);
+
+   return 0;
+}
+EXPORT_SYMBOL(drm_dp_start_crc);
+
+/**
+ * drm_dp_stop_crc() - stop capture of frame CRCs
+ * @aux: DisplayPort AUX channel
+ *
+ * Returns 0 on success or a negative error code on failure.
+ */
+int drm_dp_stop_crc(struct drm_dp_aux *aux)
+{
+   u8 buf;
+   int ret;
+
+   ret = 

[PATCH v4 2/5] drm/bridge: analogix_dp: set connector to drm_dp_aux

[Tomeu Vizoso]

Set the backpointer so that the DP helpers are able to access the
connector that the drm_dp_aux is associated with.

Signed-off-by: Tomeu Vizoso 
---

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

diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c 
b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
index 02b97bf64ee4..7d45d3e4600a 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
@@ -1402,23 +1402,25 @@ int analogix_dp_bind(struct device *dev, struct 
drm_device *drm_dev,
dp->drm_dev = drm_dev;
dp->encoder = dp->plat_data->encoder;

+   ret = analogix_dp_create_bridge(drm_dev, dp);
+   if (ret) {
+   DRM_ERROR("failed to create bridge (%d)\n", ret);
+   goto err_encoder_cleanup;
+   }
+
dp->aux.name = "DP-AUX";
dp->aux.transfer = analogix_dpaux_transfer;
dp->aux.dev = >dev;
+   dp->aux.connector = >connector;

ret = drm_dp_aux_register(>aux);
if (ret)
-   goto err_disable_pm_runtime;
-
-   ret = analogix_dp_create_bridge(drm_dev, dp);
-   if (ret) {
-   DRM_ERROR("failed to create bridge (%d)\n", ret);
-   drm_encoder_cleanup(dp->encoder);
-   goto err_disable_pm_runtime;
-   }
+   goto err_encoder_cleanup;

return 0;

+err_encoder_cleanup:
+   drm_encoder_cleanup(dp->encoder);
 err_disable_pm_runtime:
pm_runtime_disable(dev);

-- 
2.9.3

[PATCH v4 1/5] drm/dp: add connector backpointer to drm_dp_aux

[Tomeu Vizoso]

This backpointer allows DP helpers to access the connector it's being
used for.

Signed-off-by: Tomeu Vizoso 
---

 include/drm/drm_dp_helper.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
index 55bbeb0ff594..4fa77b434594 100644
--- a/include/drm/drm_dp_helper.h
+++ b/include/drm/drm_dp_helper.h
@@ -721,6 +721,7 @@ struct drm_dp_aux_msg {
  * @name: user-visible name of this AUX channel and the I2C-over-AUX adapter
  * @ddc: I2C adapter that can be used for I2C-over-AUX communication
  * @dev: pointer to struct device that is the parent for this AUX channel
+ * @connector: backpointer to connector that uses this AUX channel
  * @hw_mutex: internal mutex used for locking transfers
  * @transfer: transfers a message representing a single AUX transaction
  *
@@ -757,6 +758,7 @@ struct drm_dp_aux {
const char *name;
struct i2c_adapter ddc;
struct device *dev;
+   struct drm_connector *connector;
struct mutex hw_mutex;
ssize_t (*transfer)(struct drm_dp_aux *aux,
struct drm_dp_aux_msg *msg);
-- 
2.9.3

[PATCH v4 0/5] drm/dp: Implement CRC debugfs API

[Tomeu Vizoso]

Hi,

this series builds up on the API for exposing captured CRCs through
debugfs.

It adds new DP helpers for starting and stopping CRC capture and gets
the Rockchip driver to use it.

Also had to add a connector backpointer to the drm_dp_aux struct so we could
wait for the right vblank and store the CRCs afterwards, I will be glad
to hear about better alternatives.

With these patches, tests in IGT such as kms_pipe_crc_basic and
kms_plane do pass on RK3288.

In this v4, "drm/dp: add helpers for capture of frame CRCs" has been
modified to address some of the comments from Sean Paul.

Thanks,

Tomeu


Tomeu Vizoso (5):
  drm/dp: add connector backpointer to drm_dp_aux
  drm/bridge: analogix_dp: set connector to drm_dp_aux
  drm/dp: add helpers for capture of frame CRCs
  drm/bridge: analogix_dp: add helpers for capture of frame CRCs
  drm/rockchip: Implement CRC debugfs API

 drivers/gpu/drm/bridge/analogix/analogix_dp_core.c |  34 --
 drivers/gpu/drm/drm_dp_helper.c| 129 +
 drivers/gpu/drm/rockchip/rockchip_drm_vop.c|  42 +++
 include/drm/bridge/analogix_dp.h   |   3 +
 include/drm/drm_dp_helper.h|   9 ++
 5 files changed, 209 insertions(+), 8 deletions(-)

-- 
2.9.3

[PATCH v3 5/5] drm/rockchip: Implement CRC debugfs API

[Tomeu Vizoso]

On 6 January 2017 at 16:56, Sean Paul  wrote:
> On Fri, Jan 6, 2017 at 9:30 AM, Tomeu Vizoso  
> wrote:
>> Implement the .set_crc_source() callback and call the DP helpers
>> accordingly to start and stop CRC capture.
>>
>> This is only done if this CRTC is currently using the eDP connector.
>>
>> v3: Remove superfluous check on rockchip_crtc_state->output_type
>>
>> Signed-off-by: Tomeu Vizoso 
>> ---
>>
>>  drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 48 
>> +
>>  1 file changed, 48 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c 
>> b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
>> index fb5f001f51c3..5e19bef6d5b4 100644
>> --- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
>> +++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
>> @@ -19,6 +19,7 @@
>>  #include 
>>  #include 
>>  #include 
>> +#include 
>>
>>  #include 
>>  #include 
>> @@ -1105,6 +1106,52 @@ static void vop_crtc_destroy_state(struct drm_crtc 
>> *crtc,
>> kfree(s);
>>  }
>>
>> +static struct drm_connector *vop_get_edp_connector(struct vop *vop)
>> +{
>> +   struct drm_crtc *crtc = >crtc;
>> +   struct drm_connector *connector;
>> +
>> +   mutex_lock(>dev->mode_config.mutex);
>> +   drm_for_each_connector(connector, crtc->dev)
>> +   if (connector->connector_type == DRM_MODE_CONNECTOR_eDP) {
>> +   mutex_unlock(>dev->mode_config.mutex);
>> +   return connector;
>> +   }
>> +   mutex_unlock(>dev->mode_config.mutex);
>> +
>> +   return NULL;
>> +}
>> +
>> +static int vop_crtc_set_crc_source(struct drm_crtc *crtc,
>> +  const char *source_name, size_t 
>> *values_cnt)
>> +{
>> +   struct vop *vop = to_vop(crtc);
>> +   struct rockchip_crtc_state *s = to_rockchip_crtc_state(crtc->state);
>> +   struct drm_connector *connector;
>> +   int ret;
>> +
>> +   connector = vop_get_edp_connector(vop);
>> +   if (!connector)
>> +   return -EINVAL;
>> +
>> +   *values_cnt = 3;
>> +
>> +   if (source_name &&
>> +   strcmp(source_name, "auto") == 0) {
>> +
>> +   if (s->output_type != DRM_MODE_CONNECTOR_eDP)
>> +   return -EINVAL;
>> +
>> +   ret = analogix_dp_start_crc(connector);
>
> To pick up my thoughts from 1/5, you could do the following instead:
>
> analogix_dp_start_crc(drm_crtc_index(crtc));

Well, I still need the dpaux to access the dpcd, so that would have to be:

analogix_dp_start_crc(connector, drm_crtc_index(crtc));

Regards,

Tomeu

>> +   } else if (!source_name)
>> +
>> +   ret = analogix_dp_stop_crc(connector);
>> +   else
>> +   ret = -EINVAL;
>> +
>> +   return ret;
>> +}
>> +
>>  static const struct drm_crtc_funcs vop_crtc_funcs = {
>> .set_config = drm_atomic_helper_set_config,
>> .page_flip = drm_atomic_helper_page_flip,
>> @@ -1112,6 +1159,7 @@ static const struct drm_crtc_funcs vop_crtc_funcs = {
>> .reset = vop_crtc_reset,
>> .atomic_duplicate_state = vop_crtc_duplicate_state,
>> .atomic_destroy_state = vop_crtc_destroy_state,
>> +   .set_crc_source = vop_crtc_set_crc_source,
>>  };
>>
>>  static void vop_fb_unref_worker(struct drm_flip_work *work, void *val)
>> --
>> 2.9.3
>>
>>
>> ___
>> linux-arm-kernel mailing list
>> linux-arm-kernel at lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>
>
>
> --
> Sean Paul, Software Engineer, Google / Chromium OS

[PATCH v3 3/5] drm/dp: add helpers for capture of frame CRCs

[Tomeu Vizoso]

On 6 January 2017 at 16:56, Sean Paul  wrote:
> On Fri, Jan 6, 2017 at 9:30 AM, Tomeu Vizoso  
> wrote:
>> Adds helpers for starting and stopping capture of frame CRCs through the
>> DPCD. When capture is on, a worker waits for vblanks and retrieves the
>> frame CRC to put it in the queue on the CRTC that is using the
>> eDP connector, so it's passed to userspace.
>>
>> v2: Reuse drm_crtc_wait_one_vblank
>> Update locking, as drm_crtc_add_crc_entry now takes the lock
>>
>> v3: Don't call wake_up_interruptible directly, that's now done in
>> drm_crtc_add_crc_entry.
>>
>> Signed-off-by: Tomeu Vizoso 
>> ---
>>
>>  drivers/gpu/drm/drm_dp_helper.c | 118 
>> 
>>  include/drm/drm_dp_helper.h |   7 +++
>>  2 files changed, 125 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/drm_dp_helper.c 
>> b/drivers/gpu/drm/drm_dp_helper.c
>> index 3e6fe82c6d64..e531f1317268 100644
>> --- a/drivers/gpu/drm/drm_dp_helper.c
>> +++ b/drivers/gpu/drm/drm_dp_helper.c
>> @@ -981,6 +981,74 @@ static const struct i2c_lock_operations 
>> drm_dp_i2c_lock_ops = {
>> .unlock_bus = unlock_bus,
>>  };
>>
>> +static int drm_dp_aux_get_crc(struct drm_dp_aux *aux, u8 *crc)
>> +{
>> +   u8 buf, count;
>> +   int ret;
>> +
>> +   ret = drm_dp_dpcd_readb(aux, DP_TEST_SINK, );
>> +   if (ret < 0)
>> +   return ret;
>> +
>> +   WARN_ON(!(buf & DP_TEST_SINK_START));
>> +
>> +   ret = drm_dp_dpcd_readb(aux, DP_TEST_SINK_MISC, );
>> +   if (ret < 0)
>> +   return ret;
>> +
>> +   count = buf & DP_TEST_COUNT_MASK;
>> +   if (count == aux->crc_count)
>> +   return -EAGAIN; /* No CRC yet */
>> +
>> +   aux->crc_count = count;
>> +
>> +   /* At DP_TEST_CRC_R_CR, there's 6 bytes containing CRC data, 2 bytes
>> +* per component (RGB or CrYCb).
>
> nit: doesn't conform to CodingStyle
>
>> +*/
>> +   ret = drm_dp_dpcd_read(aux, DP_TEST_CRC_R_CR, crc, 6);
>> +   if (ret < 0)
>> +   return ret;
>> +
>> +   return 0;
>> +}
>> +
>> +static void drm_dp_aux_crc_work(struct work_struct *work)
>> +{
>> +   struct drm_dp_aux *aux = container_of(work, struct drm_dp_aux,
>> + crc_work);
>> +   struct drm_crtc *crtc;
>> +   u8 crc_bytes[6];
>> +   uint32_t crcs[3];
>> +   int ret;
>> +
>> +   if (WARN_ON(!aux->connector))
>> +   return;
>> +
>> +   crtc = aux->connector->state->crtc;
>> +   while (crtc->crc.opened) {
>> +   drm_crtc_wait_one_vblank(crtc);
>> +   if (!crtc->crc.opened)
>> +   break;
>> +
>> +   ret = drm_dp_aux_get_crc(aux, crc_bytes);
>> +   if (ret == -EAGAIN) {
>> +   usleep_range(1000, 2000);
>> +   ret = drm_dp_aux_get_crc(aux, crc_bytes);
>> +   }
>> +
>> +   if (ret) {
>> +   DRM_DEBUG_KMS("Failed to get a CRC even after 
>> retrying: %d\n",
>> + ret);
>> +   continue;
>> +   }
>
> I think it'd be better to restructure this to only call
> drm_dp_aux_get_crc in one place

I'm not completely sure, TBH, as I liked that it was very clear that
we only retry once. I'm about to send v4 with this change and you can
judge by yourself.

> (and differentiate between EAGAIN and
> other failures):

Good point.

> bool retry = false;
> while (...) {
> ...
>
> ret = drm_dp_aux_get_crc(aux, crc_bytes);
> if (ret == -EAGAIN) {
> if (retry)
> DRM_DEBUG_KMS("Get CRC failed after retrying: %d\n",
>   ret);
> retry = !retry;
> usleep_range(1000, 2000);
> continue;
> }
>
> retry = false;
> if (!ret) {
> crcs[0] = crc_bytes[0] | crc_bytes[1] << 8;
> crcs[1] = crc_bytes[2] | crc_bytes[3] << 8;
> crcs[2] = crc_bytes[4] | crc_bytes[5] << 8;
> ret = drm_crtc_add_crc_entry(crtc, false, 0, crcs);
> if (ret)
> DRM_DEBUG_KMS("Failed to add crc entry %d\n", ret);
> } else {
> DRM_DEBUG_KMS("Get CRC failed: %d\n", ret);
> }
> }
>
>> +
>> +   crcs[0] = crc_bytes[0] | crc_bytes[1] << 8;
>> +   crcs[1] = crc_bytes[2] | crc_bytes[3] << 8;
>> +   crcs[2] = crc_bytes[4] | crc_bytes[5] << 8;
>> +   ret = drm_crtc_add_crc_entry(crtc, false, 0, crcs);
>> +   }
>> +}
>> +
>>  /**
>>   * drm_dp_aux_init() - minimally initialise an aux channel
>>   * @aux: DisplayPort AUX channel
>> @@ -993,6 +1061,7 @@ static const struct i2c_lock_operations 
>> drm_dp_i2c_lock_ops = {
>>  void drm_dp_aux_init(struct drm_dp_aux *aux)
>>  {
>> mutex_init(>hw_mutex);

[Bug 99323] White horizontal lines and graphics curruption in ATI HD 4570 when radeon.dpm=1

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

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

--- Comment #4 from Alex Deucher  ---
Please attach your dmesg output with radeon.dpm=1 explicitly set.

-- 
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/20170109/266907c5/attachment.html>

NULL pointer dereference in i915_gem_request_alloc()

[vcap...@pengaru.com]

On Mon, Jan 02, 2017 at 10:09:35AM +, Chris Wilson wrote:
> On Sun, Jan 01, 2017 at 03:16:31PM -0600, vcaputo at pengaru.com wrote:
> > Hi Chris,
> > 
> > I've uncovered a bug in i915_gem_request_alloc():
> > https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/gpu/drm/i915/i915_gem_request.c?h=v4.9#n425
> > 
> > ctx here may be NULL, and i915_gem_context_get() is unconditionally
> > adding a reference to the supplied ctx, which makes things go boom when
> > NULL.
> 
> ctx is not allowed to be NULL.
>  
> > This happens for me in practice via:
> > https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/gpu/drm/i915/intel_display.c?h=v4.9#n12317
> > 
> > It appears engine->last_context may be NULL.
> 
> It was meant to be using mmioflip if last_context was NULL, since we can
> do that immediately (i.e. lower latency) than via queuing the csflip.
>  
> > The comment heading i915_gem_request_alloc() states that ctx shall be
> > NULL and that an appropriate context will be chosen automatically.  This
> > is not what is currently implemented.
> 
> Comment is wrong.

Ok, that makes sense, and thanks for the response.

Is it appropriate to consider it fixed upstream at this point or is
anything else needed from my end?

Cheers,
Vito Caputo

[RFC] drm: Parse HDMI 2.0 YCbCr 4:2:0 VDB and VCB

[Jose Abreu]

Hi Shashank,


On 09-01-2017 12:45, Sharma, Shashank wrote:
> Regards
>
> Shashank
>
>
> On 1/9/2017 4:41 PM, Jose Abreu wrote:
>> Hi Shashank,
>>
>>
>> Thanks for the review.
>>
>>
>> On 09-01-2017 05:22, Sharma, Shashank wrote:
>>> Regards
>>>
>>> Shashank
>>>
>>>
>>> On 12/30/2016 10:23 PM, Jose Abreu wrote:
 HDMI 2.0 introduces a new sampling mode called YCbCr 4:2:0.
 According to the spec the EDID may contain two blocks that
 signal this sampling mode:
  - YCbCr 4:2:0 Video Data Block
  - YCbCr 4:2:0 Video Capability Map Data Block

 The video data block contains the list of vic's were
 only YCbCr 4:2:0 sampling mode shall be used while the
 video capability map data block contains a mask were
 YCbCr 4:2:0 sampling mode may be used.

 This RFC patch adds support for parsing these two new blocks
 and introduces new flags to signal the drivers if the
 mode is 4:2:0'only or 4:2:0'able.

 The reason this is still a RFC is because there is no
 reference in kernel for this new sampling mode (specially in
 AVI infoframe part), so, I was hoping to hear some feedback
 first.

 Tested in a HDMI 2.0 compliance scenario.

 Signed-off-by: Jose Abreu 
 Cc: Carlos Palminha 
 Cc: Daniel Vetter 
 Cc: Jani Nikula 
 Cc: Sean Paul 
 Cc: David Airlie 
 Cc: dri-devel at lists.freedesktop.org
 Cc: linux-kernel at vger.kernel.org
 ---
drivers/gpu/drm/drm_edid.c  | 139
 +++-
drivers/gpu/drm/drm_modes.c |  10 +++-
include/uapi/drm/drm_mode.h |   6 ++
3 files changed, 151 insertions(+), 4 deletions(-)

 diff --git a/drivers/gpu/drm/drm_edid.c
 b/drivers/gpu/drm/drm_edid.c
 index 67d6a73..6ce1a38 100644
 --- a/drivers/gpu/drm/drm_edid.c
 +++ b/drivers/gpu/drm/drm_edid.c
 @@ -2549,6 +2549,8 @@ static int drm_cvt_modes(struct
 drm_connector *connector,
#define VENDOR_BLOCK0x03
#define SPEAKER_BLOCK0x04
#define VIDEO_CAPABILITY_BLOCK0x07
 +#define VIDEO_DATA_BLOCK_4200x0E
 +#define VIDEO_CAP_BLOCK_4200x0F
#define EDID_BASIC_AUDIO(1 << 6)
#define EDID_CEA_YCRCB444(1 << 5)
#define EDID_CEA_YCRCB422(1 << 4)
 @@ -3050,6 +3052,98 @@ static int add_3d_struct_modes(struct
 drm_connector *connector, u16 structure,
return modes;
}
+static int add_420_mode(struct drm_connector *connector, u8
 vic)
 +{
 +struct drm_device *dev = connector->dev;
 +struct drm_display_mode *newmode;
 +
 +if (!drm_valid_cea_vic(vic))
 +return 0;
 +
 +newmode = drm_mode_duplicate(dev, _cea_modes[vic]);
>>> Sorry to start the review late, I missed this mail chain. It
>>> would be great if you can please keep me in CC for this chain.
>> Sure. Will do that next time.
>>
>>> Practically, YUV420 modes are being used for 4k and UHD video
>>> modes. Now here, when we want to
>>> add these modes from edid_cea_db, using the VIC index, we
>>> should have full list of cea_modes from 1 - 107
>>> Particularly 93-107 ( which is for new 38x21 and 40x21 modes,
>>> added in CEA-861-F). right now, edid_cea_modes
>>> cant index 4k modes, so practically this this patch series will
>>> do nothing (even though its doing everything right)
>> This is correct but not entirely true. I realize 4:2:0 is mostly
>> used in 4k modes but it can also be used in any other video mode,
>> as long as it is declared in the VCB.
> I agree (that's why I called it practically).
> As such I doubt we will find anything less than a 4k here, coz
> HDMI 1.4b itself can driver 4k at 30.
> So the biggest benefit of YUV 420, which is half the clock, is
> mostly useful in 4k at 60 and above.
> I guess we will see more cases of deep-color pixels at non-4k
> modes soon.
>>> To handle this scenario, I had added a patch series
>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__patchwork.freedesktop.org_patch_119627_=DgICaQ=DPL6_X_6JkXFx7AXWqB0tg=WHDsc6kcWAl4i96Vm5hJ_19IJiuxx_p_Rzo2g-uHDKw=6JwJ_PEZj3MSeRaLTHuLtPZCb0uPPjUqR5raxY_qILI=DPBQ2MpLgngWGJEOg2v9CQhg2CSf_4LOIAC30B6AAyg=
>>>
>>> (complete the cea modedb (VIC=65 onwards)) Now, this patch
>>> series had dependency on new aspect ratios
>>> being added in CEA-861-F which I tried to add in series
>>> (https://urldefense.proofpoint.com/v2/url?u=https-3A__patchwork.freedesktop.org_patch_116095_=DgICaQ=DPL6_X_6JkXFx7AXWqB0tg=WHDsc6kcWAl4i96Vm5hJ_19IJiuxx_p_Rzo2g-uHDKw=6JwJ_PEZj3MSeRaLTHuLtPZCb0uPPjUqR5raxY_qILI=PX2M1hM2cF_aWiDe5oZeLWjsOgL-hvUR54Ion9kYMxM=
>>>
>>> )
>>> Which was added and later reverted by Ville
>>> 

[PATCH] drm: nouveau: fix build when LEDS_CLASS=m

[Jani Nikula]

On Thu, 05 Jan 2017, Randy Dunlap  wrote:
> That particular circular/recursive dependency is ugly. I spent about
> one hour trying/testing various fixes and don't have one.

I didn't really look at this one all that much, but when I face problems
with kconfig, it's almost invariably because of overuse of
select. Documentation/kbuild/kconfig-language.txt says, "In general use
select only for non-visible symbols (no prompts anywhere) and for
symbols with no dependencies." People violate this all the time because
it's convenient. If they depended, they'd have to enable all deps to
even see their config.

I wish kconfig would warn about incorrect use of select... though I
guess that would produce a wall of warnings. Additionally, it really
should be easier to find and enable unmet dependencies in
menuconfig. Someone(tm) has a lot of work to do...

BR,
Jani.



-- 
Jani Nikula, Intel Open Source Technology Center

[PATCH v2] drm: Schedule the output_poll_work with 1s delay if we have delayed event

[Sean Paul]

On Mon, Jan 9, 2017 at 9:31 AM, Peter Ujfalusi  wrote:
> Instead of scheduling the work to handle the initial delayed event, use 1s
> delay.
>
> This delay should not be needed, but Optimus/nouveau will fail in a
> mysterious way if the delayed event is handled as soon as possible like it

Has anyone tried to demystify the failure? It seems like fixing the
root problem would be better than this.

Perhaps we should just revert 339fd36238dd to fix stable.

Sean

> is done in drm_helper_probe_single_connector_modes() in case the poll
> was enabled before.
>
> Reverting 339fd36238dd would give back the 10 sec (!) delay to handle the
> delayed event. Adding 1sec delay to the poll_work is enough to work around
> the issue in Optimus setups and gives shorter response on handling the
> initial delayed event.
>
> Fixes: 339fd36238dd ("drm: drm_probe_helper: Fix output_poll_work scheduling")
> Cc: stable at vger.kernel.org   # v4.9
> Signed-off-by: Peter Ujfalusi 
> ---
>  drivers/gpu/drm/drm_probe_helper.c | 10 +-
>  1 file changed, 9 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/drm_probe_helper.c 
> b/drivers/gpu/drm/drm_probe_helper.c
> index 06a62e37fbdc..258abed43e38 100644
> --- a/drivers/gpu/drm/drm_probe_helper.c
> +++ b/drivers/gpu/drm/drm_probe_helper.c
> @@ -146,8 +146,16 @@ void drm_kms_helper_poll_enable_locked(struct drm_device 
> *dev)
> drm_connector_list_iter_put(_iter);
>
> if (dev->mode_config.delayed_event) {
> +   /*
> +* Use short (1s) delay to handle the initial delayed event.
> +* This delay should not be needed, but Optimus/nouveau will
> +* fail in a mysterious way if the delayed event is handled as
> +* soon as possible like it is done in
> +* drm_helper_probe_single_connector_modes() in case the poll
> +* was enabled before.
> +*/
> poll = true;
> -   delay = 0;
> +   delay = HZ;
> }
>
> if (poll)
> --
> 2.11.0
>



-- 
Sean Paul, Software Engineer, Google / Chromium OS

[GIT PULL] omapdrm changes for 4.11

[Tomi Valkeinen]

Hi Dave,

Please pull omapdrm changes for 4.11.

 Tomi

The following changes since commit 2cf026ae85c42f253feb9f420d1b4bc99bd5503d:

  Merge branch 'linux-4.10' of git://github.com/skeggsb/linux into drm-next 
(2016-12-13 14:29:05 +1000)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/tomba/linux.git 
tags/omapdrm-4.11

for you to fetch changes up to 42f7f3c4811b3149253ecf2e133832c969884466:

  drm/omap: panel-sony-acx565akm.c: Add MODULE_ALIAS (2017-01-04 14:08:14 +0200)


omapdrm changes for 4.11

The main change here is the IRQ code cleanup, which gives us properly working
vblank counts and timestamps. We also get much less calls to runtime PM gets &
puts.


H. Nikolaus Schaller (1):
  drm/omap: dsi: fix compile errors when enabling debug prints

Jarkko Nikula (1):
  drm/omap: panel-sony-acx565akm.c: Add MODULE_ALIAS

Laurent Pinchart (24):
  drm: Kbuild: add omap_drm.h to the installed headers
  drm: omapdrm: fb: Limit number of planes per framebuffer to two
  drm: omapdrm: fb: Use format information provided by the DRM core
  drm: omapdrm: fb: Simplify objects lookup when creating framebuffer
  drm: omapdrm: fb: Simplify mode command checks when creating framebuffer
  drm: omapdrm: fb: Turn framebuffer creation error messages into debug
  drm: omapdrm: Handle FIFO underflow IRQs internally
  drm: omapdrm: Handle CRTC error IRQs directly
  drm: omapdrm: Handle OCP error IRQ directly
  drm: omapdrm: Replace DSS manager state check with omapdrm CRTC state
  drm: omapdrm: Let the DRM core skip plane commit on inactive CRTCs
  drm: omapdrm: Check the CRTC software state at enable/disable time
  drm: omapdrm: Prevent processing the same event multiple times
  drm: omapdrm: Use a spinlock to protect the CRTC pending flag
  drm: omapdrm: Keep vblank interrupt enabled while CRTC is active
  drm: omapdrm: Don't expose the omap_irq_(un)register() functions
  drm: omapdrm: Remove unused parameter from omap_drm_irq handler
  drm: omapdrm: Don't call DISPC power handling in IRQ wait functions
  drm: omapdrm: Inline the pipe2vbl function
  drm: omapdrm: Simplify IRQ wait implementation
  drm: omapdrm: Remove global variables
  drm: omapdrm: Use sizeof(*var) instead of sizeof(type) for structures
  drm: Move vblank cleanup from unregister to release
  drm: omapdrm: Perform initialization/cleanup at probe/remove time

Tomi Valkeinen (1):
  Merge omapdrm work from Laurent

 drivers/gpu/drm/drm_drv.c  |   4 +-
 drivers/gpu/drm/omapdrm/displays/panel-dsi-cm.c|   2 +-
 .../drm/omapdrm/displays/panel-sony-acx565akm.c|   1 +
 drivers/gpu/drm/omapdrm/dss/dispc.c|  27 ++-
 drivers/gpu/drm/omapdrm/dss/dsi.c  |  18 +-
 drivers/gpu/drm/omapdrm/dss/omapdss-boot-init.c|   3 +-
 drivers/gpu/drm/omapdrm/dss/omapdss.h  |   1 -
 drivers/gpu/drm/omapdrm/omap_connector.c   |   6 +-
 drivers/gpu/drm/omapdrm/omap_crtc.c| 154 ++---
 drivers/gpu/drm/omapdrm/omap_dmm_tiler.c   |   4 +-
 drivers/gpu/drm/omapdrm/omap_drv.c | 218 +--
 drivers/gpu/drm/omapdrm/omap_drv.h |  51 +
 drivers/gpu/drm/omapdrm/omap_encoder.c |   2 +-
 drivers/gpu/drm/omapdrm/omap_fb.c  | 164 +++---
 drivers/gpu/drm/omapdrm/omap_irq.c | 242 +++--
 drivers/gpu/drm/omapdrm/omap_plane.c   |  24 --
 include/uapi/drm/Kbuild|   1 +
 17 files changed, 441 insertions(+), 481 deletions(-)

-- 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/20170109/f8156cd4/attachment.sig>

[PATCH v4 3/5] drm/dp: add helpers for capture of frame CRCs

[Sean Paul]

On Mon, Jan 9, 2017 at 8:32 AM, Tomeu Vizoso  
wrote:
> Adds helpers for starting and stopping capture of frame CRCs through the
> DPCD. When capture is on, a worker waits for vblanks and retrieves the
> frame CRC to put it in the queue on the CRTC that is using the
> eDP connector, so it's passed to userspace.
>
> v2: Reuse drm_crtc_wait_one_vblank
> Update locking, as drm_crtc_add_crc_entry now takes the lock
>
> v3: Don't call wake_up_interruptible directly, that's now done in
> drm_crtc_add_crc_entry.
>
> v4: Style fixes (Sean Paul)
> Reworked retry of CRC reads (Sean Paul)
> Flush worker after stopping CRC generationa (Sean Paul)
>
> Signed-off-by: Tomeu Vizoso 
> ---
>
>  drivers/gpu/drm/drm_dp_helper.c | 129 
> 
>  include/drm/drm_dp_helper.h |   7 +++
>  2 files changed, 136 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
> index 3e6fe82c6d64..f9018faf7e07 100644
> --- a/drivers/gpu/drm/drm_dp_helper.c
> +++ b/drivers/gpu/drm/drm_dp_helper.c
> @@ -981,6 +981,83 @@ static const struct i2c_lock_operations 
> drm_dp_i2c_lock_ops = {
> .unlock_bus = unlock_bus,
>  };
>
> +static int drm_dp_aux_get_crc(struct drm_dp_aux *aux, u8 *crc)
> +{
> +   u8 buf, count;
> +   int ret;
> +
> +   ret = drm_dp_dpcd_readb(aux, DP_TEST_SINK, );
> +   if (ret < 0)
> +   return ret;
> +
> +   WARN_ON(!(buf & DP_TEST_SINK_START));
> +
> +   ret = drm_dp_dpcd_readb(aux, DP_TEST_SINK_MISC, );
> +   if (ret < 0)
> +   return ret;
> +
> +   count = buf & DP_TEST_COUNT_MASK;
> +   if (count == aux->crc_count)
> +   return -EAGAIN; /* No CRC yet */
> +
> +   aux->crc_count = count;
> +
> +   /*
> +* At DP_TEST_CRC_R_CR, there's 6 bytes containing CRC data, 2 bytes
> +* per component (RGB or CrYCb).
> +*/
> +   ret = drm_dp_dpcd_read(aux, DP_TEST_CRC_R_CR, crc, 6);
> +   if (ret < 0)
> +   return ret;
> +
> +   return 0;
> +}
> +
> +static void drm_dp_aux_crc_work(struct work_struct *work)
> +{
> +   struct drm_dp_aux *aux = container_of(work, struct drm_dp_aux,
> + crc_work);
> +   struct drm_crtc *crtc;
> +   u8 crc_bytes[6];
> +   uint32_t crcs[3];
> +   bool retry = false;
> +   int ret;
> +
> +   if (WARN_ON(!aux->connector))
> +   return;
> +
> +   crtc = aux->connector->state->crtc;
> +   while (crtc->crc.opened) {
> +   if (!retry) {
> +   drm_crtc_wait_one_vblank(crtc);
> +   if (!crtc->crc.opened)
> +   break;
> +   }
> +
> +   ret = drm_dp_aux_get_crc(aux, crc_bytes);
> +   if (ret == -EAGAIN) {
> +   if (retry)
> +   DRM_DEBUG_KMS("Failed to get a CRC even after 
> retrying: %d\n",
> + ret);
> +   retry = !retry;
> +   usleep_range(1000, 2000);
> +   continue;
> +   }
> +
> +   retry = false;

Yeah, the retry handling gets ugly fast, doesn't it? I think I'm
coming around to your original way of handing things (with the
addition of handling EAGAIN separately from other errors)

Sean

> +   if (!ret) {
> +   crcs[0] = crc_bytes[0] | crc_bytes[1] << 8;
> +   crcs[1] = crc_bytes[2] | crc_bytes[3] << 8;
> +   crcs[2] = crc_bytes[4] | crc_bytes[5] << 8;
> +   ret = drm_crtc_add_crc_entry(crtc, false, 0, crcs);
> +   if (ret)
> +   DRM_DEBUG_KMS("Failed to add crc entry %d\n", 
> ret);
> +   } else {
> +   DRM_DEBUG_KMS("Get CRC failed: %d\n", ret);
> +   }
> +   }
> +}
> +
>  /**
>   * drm_dp_aux_init() - minimally initialise an aux channel
>   * @aux: DisplayPort AUX channel
> @@ -993,6 +1070,7 @@ static const struct i2c_lock_operations 
> drm_dp_i2c_lock_ops = {
>  void drm_dp_aux_init(struct drm_dp_aux *aux)
>  {
> mutex_init(>hw_mutex);
> +   INIT_WORK(>crc_work, drm_dp_aux_crc_work);
>
> aux->ddc.algo = _dp_i2c_algo;
> aux->ddc.algo_data = aux;
> @@ -1081,3 +1159,54 @@ int drm_dp_psr_setup_time(const u8 
> psr_cap[EDP_PSR_RECEIVER_CAP_SIZE])
>  EXPORT_SYMBOL(drm_dp_psr_setup_time);
>
>  #undef PSR_SETUP_TIME
> +
> +/**
> + * drm_dp_start_crc() - start capture of frame CRCs
> + * @aux: DisplayPort AUX channel
> + *
> + * Returns 0 on success or a negative error code on failure.
> + */
> +int drm_dp_start_crc(struct drm_dp_aux *aux)
> +{
> +   u8 buf;
> +   int ret;
> +
> +   ret = drm_dp_dpcd_readb(aux, DP_TEST_SINK, );
> +   if (ret < 0)
> +   return ret;
> +

[PATCH v3 1/5] drm/dp: add connector backpointer to drm_dp_aux

[Sean Paul]

On Mon, Jan 9, 2017 at 4:03 AM, Tomeu Vizoso  
wrote:
> On 6 January 2017 at 16:56, Sean Paul  wrote:
>> On Fri, Jan 6, 2017 at 9:30 AM, Tomeu Vizoso  
>> wrote:
>>> This backpointer allows DP helpers to access the connector it's being
>>> used for.
>>>
>>> Signed-off-by: Tomeu Vizoso 
>>> ---
>>>
>>>  include/drm/drm_dp_helper.h | 2 ++
>>>  1 file changed, 2 insertions(+)
>>>
>>> diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
>>> index 55bbeb0ff594..4fa77b434594 100644
>>> --- a/include/drm/drm_dp_helper.h
>>> +++ b/include/drm/drm_dp_helper.h
>>> @@ -721,6 +721,7 @@ struct drm_dp_aux_msg {
>>>   * @name: user-visible name of this AUX channel and the I2C-over-AUX 
>>> adapter
>>>   * @ddc: I2C adapter that can be used for I2C-over-AUX communication
>>>   * @dev: pointer to struct device that is the parent for this AUX channel
>>> + * @connector: backpointer to connector that uses this AUX channel
>>>   * @hw_mutex: internal mutex used for locking transfers
>>>   * @transfer: transfers a message representing a single AUX transaction
>>>   *
>>> @@ -757,6 +758,7 @@ struct drm_dp_aux {
>>> const char *name;
>>> struct i2c_adapter ddc;
>>> struct device *dev;
>>> +   struct drm_connector *connector;
>>
>> Perhaps I'm misreading the series, but it seems like you could instead
>> add int crc_pipe along with the other crc fields. Then when you start
>> the crc, set the pipe number. If you have the pipe in the crc worker,
>> you can wait vblank on that pipe (no pointers needed).
>>
>> Reasonable?
>
> I think that would work fine, but is it any better? I like that the
> connector isn't going to change during the lifetime of the drm_dp_aux,

Is this actually guaranteed, though? I am having a hard time thinking
about a practical example where it's not implemented this way, but I
don't see anything actually enforcing the lifetime relationship.

> but crc_pipe could be changing between sampling sessions and any bugs
> in keeping that field updated would be quite disconcerting and
> cumbersome to debug.

Couldn't the same could be said for connector->state->crtc?

Sean

>
> crc_pipe's advantage is that we wouldn't need to update all callers of
> drm_dp_aux_register, but I think it's better to have a connector field
> that is mistakenly NULL, than a crc_pipe field with the wrong value.
>
> Regards,
>
> Tomeu
>
>> Sean
>>
>>> struct mutex hw_mutex;
>>> ssize_t (*transfer)(struct drm_dp_aux *aux,
>>> struct drm_dp_aux_msg *msg);
>>> --
>>> 2.9.3
>>>
>>
>>
>>
>> --
>> Sean Paul, Software Engineer, Google / Chromium OS



-- 
Sean Paul, Software Engineer, Google / Chromium OS

[PATCH] drm: fix compilations issues introduced by "drm: allow to use mmuless SoC"

[Daniel Vetter]

On Sat, Jan 07, 2017 at 12:39:11PM +0100, Benjamin Gaignard wrote:
> Removing MMU configuration flag from DRM make few automatic
> build failed when they answer yes to all flags.
> 
> Add asm/vga.h file on Blackfin architecture to not broke compilation.
> 
> Signed-off-by: Benjamin Gaignard 

Applied with the Fixes: tag, as discussed on irc.

Thanks, Daniel

> ---
>  arch/blackfin/include/asm/vga.h | 1 +
>  drivers/gpu/drm/Kconfig | 4 ++--
>  drivers/gpu/drm/ast/Kconfig | 2 +-
>  drivers/gpu/drm/bochs/Kconfig   | 2 +-
>  drivers/gpu/drm/cirrus/Kconfig  | 2 +-
>  drivers/gpu/drm/gma500/Kconfig  | 2 +-
>  drivers/gpu/drm/hisilicon/hibmc/Kconfig | 2 +-
>  drivers/gpu/drm/mgag200/Kconfig | 2 +-
>  drivers/gpu/drm/nouveau/Kconfig | 2 +-
>  drivers/gpu/drm/qxl/Kconfig | 2 +-
>  drivers/gpu/drm/virtio/Kconfig  | 2 +-
>  drivers/gpu/drm/vmwgfx/Kconfig  | 2 +-
>  12 files changed, 13 insertions(+), 12 deletions(-)
>  create mode 100644 arch/blackfin/include/asm/vga.h
> 
> diff --git a/arch/blackfin/include/asm/vga.h b/arch/blackfin/include/asm/vga.h
> new file mode 100644
> index 000..89d82fd
> --- /dev/null
> +++ b/arch/blackfin/include/asm/vga.h
> @@ -0,0 +1 @@
> +#include 
> diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
> index 505ca1d..6f3f9e6 100644
> --- a/drivers/gpu/drm/Kconfig
> +++ b/drivers/gpu/drm/Kconfig
> @@ -146,7 +146,7 @@ source "drivers/gpu/drm/arm/Kconfig"
>  
>  config DRM_RADEON
>   tristate "ATI Radeon"
> - depends on DRM && PCI
> + depends on DRM && PCI && MMU
>   select FW_LOADER
>  select DRM_KMS_HELPER
>  select DRM_TTM
> @@ -166,7 +166,7 @@ source "drivers/gpu/drm/radeon/Kconfig"
>  
>  config DRM_AMDGPU
>   tristate "AMD GPU"
> - depends on DRM && PCI
> + depends on DRM && PCI && MMU
>   select FW_LOADER
>  select DRM_KMS_HELPER
>  select DRM_TTM
> diff --git a/drivers/gpu/drm/ast/Kconfig b/drivers/gpu/drm/ast/Kconfig
> index 15f6ce7..9647e1f 100644
> --- a/drivers/gpu/drm/ast/Kconfig
> +++ b/drivers/gpu/drm/ast/Kconfig
> @@ -1,6 +1,6 @@
>  config DRM_AST
>   tristate "AST server chips"
> - depends on DRM && PCI
> + depends on DRM && PCI && MMU
>   select DRM_TTM
>   select DRM_KMS_HELPER
>   select DRM_TTM
> diff --git a/drivers/gpu/drm/bochs/Kconfig b/drivers/gpu/drm/bochs/Kconfig
> index f739763..bd27180 100644
> --- a/drivers/gpu/drm/bochs/Kconfig
> +++ b/drivers/gpu/drm/bochs/Kconfig
> @@ -1,6 +1,6 @@
>  config DRM_BOCHS
>   tristate "DRM Support for bochs dispi vga interface (qemu stdvga)"
> - depends on DRM && PCI
> + depends on DRM && PCI && MMU
>   select DRM_KMS_HELPER
>   select DRM_TTM
>   help
> diff --git a/drivers/gpu/drm/cirrus/Kconfig b/drivers/gpu/drm/cirrus/Kconfig
> index 04b3c16..ca38098 100644
> --- a/drivers/gpu/drm/cirrus/Kconfig
> +++ b/drivers/gpu/drm/cirrus/Kconfig
> @@ -1,6 +1,6 @@
>  config DRM_CIRRUS_QEMU
>   tristate "Cirrus driver for QEMU emulated device"
> - depends on DRM && PCI
> + depends on DRM && PCI && MMU
>   select DRM_KMS_HELPER
>   select DRM_TTM
>   help
> diff --git a/drivers/gpu/drm/gma500/Kconfig b/drivers/gpu/drm/gma500/Kconfig
> index 8906d67..df11582 100644
> --- a/drivers/gpu/drm/gma500/Kconfig
> +++ b/drivers/gpu/drm/gma500/Kconfig
> @@ -1,6 +1,6 @@
>  config DRM_GMA500
>   tristate "Intel GMA5/600 KMS Framebuffer"
> - depends on DRM && PCI && X86
> + depends on DRM && PCI && X86 && MMU
>   select DRM_KMS_HELPER
>   select DRM_TTM
>   # GMA500 depends on ACPI_VIDEO when ACPI is enabled, just like i915
> diff --git a/drivers/gpu/drm/hisilicon/hibmc/Kconfig 
> b/drivers/gpu/drm/hisilicon/hibmc/Kconfig
> index 380622a..c7129dc 100644
> --- a/drivers/gpu/drm/hisilicon/hibmc/Kconfig
> +++ b/drivers/gpu/drm/hisilicon/hibmc/Kconfig
> @@ -1,6 +1,6 @@
>  config DRM_HISI_HIBMC
>   tristate "DRM Support for Hisilicon Hibmc"
> - depends on DRM && PCI
> + depends on DRM && PCI && MMU
>   select DRM_KMS_HELPER
>   select DRM_TTM
>  
> diff --git a/drivers/gpu/drm/mgag200/Kconfig b/drivers/gpu/drm/mgag200/Kconfig
> index 520e5e6..db58578 100644
> --- a/drivers/gpu/drm/mgag200/Kconfig
> +++ b/drivers/gpu/drm/mgag200/Kconfig
> @@ -1,6 +1,6 @@
>  config DRM_MGAG200
>   tristate "Kernel modesetting driver for MGA G200 server engines"
> - depends on DRM && PCI
> + depends on DRM && PCI && MMU
>   select DRM_KMS_HELPER
>   select DRM_TTM
>   help
> diff --git a/drivers/gpu/drm/nouveau/Kconfig b/drivers/gpu/drm/nouveau/Kconfig
> index 0f2f0af..c02a134 100644
> --- a/drivers/gpu/drm/nouveau/Kconfig
> +++ b/drivers/gpu/drm/nouveau/Kconfig
> @@ -1,6 +1,6 @@
>  config DRM_NOUVEAU
>   tristate "Nouveau (NVIDIA) cards"
> - depends on DRM && PCI
> + depends on DRM && PCI && MMU
>  select FW_LOADER
>   select 

[PATCH v4 3/3] drm: zte: add overlay plane support

[Sean Paul]

On Mon, Jan 9, 2017 at 9:35 AM, Shawn Guo  wrote:
> From: Shawn Guo 
>
> It enables VOU VL (Video Layer) to support overlay plane with scaling
> function.  VL0 has some quirks on scaling support.  We choose to skip it
> and only adds VL1 and VL2 into DRM core for now.
>
> Function zx_plane_atomic_disable() gets moved around with no changes to
> save a forward declaration.
>
> Signed-off-by: Shawn Guo 
> ---
>  drivers/gpu/drm/zte/zx_plane.c  | 301 
> +---
>  drivers/gpu/drm/zte/zx_plane.h  |   1 +
>  drivers/gpu/drm/zte/zx_plane_regs.h |  51 ++
>  drivers/gpu/drm/zte/zx_vou.c|  84 +-
>  drivers/gpu/drm/zte/zx_vou_regs.h   |  18 +++
>  5 files changed, 426 insertions(+), 29 deletions(-)
>
> diff --git a/drivers/gpu/drm/zte/zx_plane.c b/drivers/gpu/drm/zte/zx_plane.c
> index 5445eebf830f..24426c2b4b8f 100644



> diff --git a/drivers/gpu/drm/zte/zx_vou.c b/drivers/gpu/drm/zte/zx_vou.c
> index 3fb4fc04e693..8e7edda184d0 100644
> --- a/drivers/gpu/drm/zte/zx_vou.c
> +++ b/drivers/gpu/drm/zte/zx_vou.c
> @@ -112,6 +112,22 @@ struct vou_layer_bits {
> },
>  };
>
> +static const struct vou_layer_bits zx_vl_bits[VL_NUM] = {
> +   {
> +   .enable = OSD_CTRL0_VL0_EN,
> +   .chnsel = OSD_CTRL0_VL0_SEL,
> +   .clksel = VOU_CLK_VL0_SEL,
> +   }, {
> +   .enable = OSD_CTRL0_VL1_EN,
> +   .chnsel = OSD_CTRL0_VL1_SEL,
> +   .clksel = VOU_CLK_VL1_SEL,
> +   }, {
> +   .enable = OSD_CTRL0_VL2_EN,
> +   .chnsel = OSD_CTRL0_VL2_SEL,
> +   .clksel = VOU_CLK_VL2_SEL,
> +   },
> +};
> +
>  struct zx_vou_hw {
> struct device *dev;
> void __iomem *osd;
> @@ -125,6 +141,7 @@ struct zx_vou_hw {
> struct clk *aux_clk;
> struct zx_crtc *main_crtc;
> struct zx_crtc *aux_crtc;
> +   struct drm_plane *overlays[VL_NUM];
>  };
>
>  static inline struct zx_vou_hw *crtc_to_vou(struct drm_crtc *crtc)
> @@ -439,6 +456,8 @@ void zx_vou_layer_enable(struct drm_plane *plane)
> }
>
> zx_writel_mask(vou->osd + OSD_CTRL0, bits->enable, bits->enable);
> +
> +   zplane->enabled = true;
>  }
>
>  void zx_vou_layer_disable(struct drm_plane *plane)
> @@ -449,6 +468,57 @@ void zx_vou_layer_disable(struct drm_plane *plane)
> const struct vou_layer_bits *bits = zplane->bits;
>
> zx_writel_mask(vou->osd + OSD_CTRL0, bits->enable, 0);
> +
> +   zplane->enabled = false;
> +}
> +
> +static void zx_overlay_init(struct drm_device *drm, struct zx_vou_hw *vou)
> +{
> +   struct device *dev = vou->dev;
> +   struct zx_plane *zplane;
> +   int i;
> +   int ret;
> +
> +   /*
> +* VL0 has some quirks on scaling support which need special handling.
> +* Let's leave it out for now.
> +*/
> +   for (i = 1; i < VL_NUM; i++) {
> +   zplane = devm_kzalloc(dev, sizeof(*zplane), GFP_KERNEL);
> +   if (!zplane) {
> +   DRM_DEV_ERROR(dev, "failed to allocate zplane %d\n", 
> i);
> +   return;
> +   }
> +
> +   zplane->layer = vou->osd + OSD_VL_OFFSET(i);
> +   zplane->hbsc = vou->osd + HBSC_VL_OFFSET(i);
> +   zplane->rsz = vou->otfppu + RSZ_VL_OFFSET(i);
> +   zplane->bits = _vl_bits[i];
> +
> +   ret = zx_plane_init(drm, zplane, DRM_PLANE_TYPE_OVERLAY);
> +   if (ret) {
> +   DRM_DEV_ERROR(dev, "failed to init overlay %d\n", i);
> +   continue;
> +   }
> +
> +   vou->overlays[i] = >plane;
> +   }
> +}
> +
> +static inline void zx_osd_int_update(struct zx_crtc *zcrtc)
> +{
> +   struct zx_vou_hw *vou = zcrtc->vou;
> +   int i;
> +
> +   vou_chn_set_update(zcrtc);
> +   zx_plane_set_update(zcrtc->primary);
> +
> +   for (i = 0; i < VL_NUM; i++) {
> +   struct drm_plane *overlay = vou->overlays[i];
> +
> +   if (overlay)
> +   zx_plane_set_update(overlay);
> +   }

Hi Shawn,
Thanks so much for revving this patch, it's looking really good. I
just have one (1.5, really) suggestion.

I don't think we need to keep vou->overlays around. You should be able
to loop through all the planes registered with drm core and use
crtc->state->plane_mask to determine which are active for a given crtc
(this would also encapsulate the zcrtc->primary update above).

I think you can also use if (plane->state->crtc) as your
enable/disable check in zx_plane_set_update() and eliminate the new
enabled flag. I fully realize this was my suggestion, and I apologize
for the churn. I'll try not to do reviews past midnight again :-)

Sean

>  }
>
>  static irqreturn_t vou_irq_handler(int irq, void *dev_id)
> @@ -470,15 +540,11 @@ static irqreturn_t vou_irq_handler(int irq, void 
> *dev_id)
> state = 

[PATCH 1/2] drm: remove useless parameters from drm_pick_cmdline_mode function

[Daniel Vetter]

On Fri, Jan 06, 2017 at 05:44:43PM +0100, Vincent Abriou wrote:
> drm_pick_cmdline_mode width and height parameters are useless.
> Just remove them.
> 
> Cc: Daniel Vetter 
> Cc: Jani Nikula 
> Signed-off-by: Vincent Abriou 

Applied, thanks a lot. I'll wait for someone else to review patch 2 before
merging it.
-Daniel
> ---
>  drivers/gpu/drm/drm_fb_helper.c| 7 +++
>  drivers/gpu/drm/i915/intel_fbdev.c | 2 +-
>  include/drm/drm_fb_helper.h| 3 +--
>  3 files changed, 5 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
> index e934b54..77d9ac6 100644
> --- a/drivers/gpu/drm/drm_fb_helper.c
> +++ b/drivers/gpu/drm/drm_fb_helper.c
> @@ -1748,8 +1748,7 @@ static bool drm_has_cmdline_mode(struct 
> drm_fb_helper_connector *fb_connector)
>   return fb_connector->connector->cmdline_mode.specified;
>  }
>  
> -struct drm_display_mode *drm_pick_cmdline_mode(struct 
> drm_fb_helper_connector *fb_helper_conn,
> -   int width, int height)
> +struct drm_display_mode *drm_pick_cmdline_mode(struct 
> drm_fb_helper_connector *fb_helper_conn)
>  {
>   struct drm_cmdline_mode *cmdline_mode;
>   struct drm_display_mode *mode;
> @@ -1867,7 +1866,7 @@ static bool drm_target_cloned(struct drm_fb_helper 
> *fb_helper,
>   if (!enabled[i])
>   continue;
>   fb_helper_conn = fb_helper->connector_info[i];
> - modes[i] = drm_pick_cmdline_mode(fb_helper_conn, width, height);
> + modes[i] = drm_pick_cmdline_mode(fb_helper_conn);
>   if (!modes[i]) {
>   can_clone = false;
>   break;
> @@ -1989,7 +1988,7 @@ static bool drm_target_preferred(struct drm_fb_helper 
> *fb_helper,
> fb_helper_conn->connector->base.id);
>  
>   /* got for command line mode first */
> - modes[i] = drm_pick_cmdline_mode(fb_helper_conn, width, height);
> + modes[i] = drm_pick_cmdline_mode(fb_helper_conn);
>   if (!modes[i]) {
>   DRM_DEBUG_KMS("looking for preferred mode on connector 
> %d %d\n",
> fb_helper_conn->connector->base.id, 
> fb_helper_conn->connector->tile_group ? 
> fb_helper_conn->connector->tile_group->id : 0);
> diff --git a/drivers/gpu/drm/i915/intel_fbdev.c 
> b/drivers/gpu/drm/i915/intel_fbdev.c
> index beb0898..4b302f8 100644
> --- a/drivers/gpu/drm/i915/intel_fbdev.c
> +++ b/drivers/gpu/drm/i915/intel_fbdev.c
> @@ -447,7 +447,7 @@ static bool intel_fb_initial_config(struct drm_fb_helper 
> *fb_helper,
> connector->name);
>  
>   /* go for command line mode first */
> - modes[i] = drm_pick_cmdline_mode(fb_conn, width, height);
> + modes[i] = drm_pick_cmdline_mode(fb_conn);
>  
>   /* try for preferred next */
>   if (!modes[i]) {
> diff --git a/include/drm/drm_fb_helper.h b/include/drm/drm_fb_helper.h
> index 975deed..48e09e8 100644
> --- a/include/drm/drm_fb_helper.h
> +++ b/include/drm/drm_fb_helper.h
> @@ -295,8 +295,7 @@ struct drm_display_mode *
>  drm_has_preferred_mode(struct drm_fb_helper_connector *fb_connector,
>   int width, int height);
>  struct drm_display_mode *
> -drm_pick_cmdline_mode(struct drm_fb_helper_connector *fb_helper_conn,
> -   int width, int height);
> +drm_pick_cmdline_mode(struct drm_fb_helper_connector *fb_helper_conn);
>  
>  int drm_fb_helper_add_one_connector(struct drm_fb_helper *fb_helper, struct 
> drm_connector *connector);
>  int drm_fb_helper_remove_one_connector(struct drm_fb_helper *fb_helper,
> -- 
> 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

[PATCH] drm: add more document for drm_crtc_from_index()

[Daniel Vetter]

On Sat, Jan 07, 2017 at 04:52:11PM +0800, Shawn Guo wrote:
> From: Shawn Guo 
> 
> Add a bit more document for function drm_crtc_from_index() to cross
> link it with drm_crtc_from_index(), and explain that the function is
> useful in vblank code.
> 
> While at it, add cross link comment for drm_plane_from_index() as well.
> 
> Signed-off-by: Shawn Guo 

Applied, thanks.
-Daniel

> ---
> This is a follow-up patch to address Daniel's comment [1] on my patch
> "[PATCH 1/3] drm: add crtc helper drm_crtc_from_index()".
> 
> Shawn
> 
> [1] http://www.spinics.net/lists/dri-devel/msg128062.html
> 
>  drivers/gpu/drm/drm_crtc.c  | 5 -
>  drivers/gpu/drm/drm_plane.c | 2 +-
>  2 files changed, 5 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> index 5c1bb1f34697..85a7452d0fb4 100644
> --- a/drivers/gpu/drm/drm_crtc.c
> +++ b/drivers/gpu/drm/drm_crtc.c
> @@ -52,7 +52,10 @@
>   * @idx: index of registered CRTC to find for
>   *
>   * Given a CRTC index, return the registered CRTC from DRM device's
> - * list of CRTCs with matching index.
> + * list of CRTCs with matching index. This is the inverse of 
> drm_crtc_index().
> + * It's useful in the vblank callbacks (like _driver.enable_vblank or
> + * _driver.disable_vblank), since that still deals with indices instead
> + * of pointers to  drm_crtc."
>   */
>  struct drm_crtc *drm_crtc_from_index(struct drm_device *dev, int idx)
>  {
> diff --git a/drivers/gpu/drm/drm_plane.c b/drivers/gpu/drm/drm_plane.c
> index 62b98f386fd1..535dec4f508d 100644
> --- a/drivers/gpu/drm/drm_plane.c
> +++ b/drivers/gpu/drm/drm_plane.c
> @@ -254,7 +254,7 @@ void drm_plane_cleanup(struct drm_plane *plane)
>   * @idx: index of registered plane to find for
>   *
>   * Given a plane index, return the registered plane from DRM device's
> - * list of planes with matching index.
> + * list of planes with matching index. This is the inverse of 
> drm_plane_index().
>   */
>  struct drm_plane *
>  drm_plane_from_index(struct drm_device *dev, int idx)
> -- 
> 1.9.1
> 

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

Why does OUT_FENCE_PTR point not to an fd (s32) but to an s64?

[Daniel Vetter]

On Fri, Jan 06, 2017 at 01:04:55PM -0800, Chad Versace wrote:
> Was this a mistake in the API? If so, can we fix this ABI mistake before
> kernel consumers rely on this?
> 
> I naïvely expected that OUT_FENCE_PTR would be a pointer to, obviously, a 
> fence
> fd (s32 __user *). But it's not. It's s64 __user *. Due to that surprise, I
> spent several hours chasing down weird corruption in Rob Clark's kmscube. The
> kernel unexpectedly cleared the 32 bits *above* an `int kms_fence_fd` in
> userspace.

Never use unsized types for uabi. I guess we could have used s32, but then
someone is going to store this in a long and it goes boom on 64 bit, while
it works on 32 bit. "int" doesn't have that problem directly, but it's
still a red flag imo.
-Daniel

> 
> For reference, here's the relevant DRM code.
> 
> // file: drivers/gpu/drm/drm_atomic.c
> struct drm_out_fence_state {
> s64 __user *out_fence_ptr;
> struct sync_file *sync_file;
> int fd;
> };
> 
> static int setup_out_fence(struct drm_out_fence_state *fence_state,
>struct dma_fence *fence)
> {
> fence_state->fd = get_unused_fd_flags(O_CLOEXEC);
> if (fence_state->fd < 0)
> return fence_state->fd;
> 
> if (put_user(fence_state->fd, fence_state->out_fence_ptr))
> return -EFAULT;
> 
> fence_state->sync_file = sync_file_create(fence);
> if (!fence_state->sync_file)
> return -ENOMEM;
> 
> return 0;
> }

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

[PATCH v2 9/9] drm/i915: Add render decompression support

[Jason Ekstrand]

cluding bits outside the page in the hash would
> +* require 2 (or 4?) MiB alignment of resources. Just
> +* assume the defaul hashing mode which only uses bits
> +* within the page.
> +*/
> +   I915_WRITE(CHICKEN_PAR1_1,
> +  I915_READ(CHICKEN_PAR1_1) & ~SKL_RC_HASH_OUTSIDE);
> +
> I915_WRITE(GEN8_CONFIG0,
>I915_READ(GEN8_CONFIG0) | GEN9_DEFAULT_FIXES);
>
> @@ -3314,7 +3328,9 @@ skl_ddb_min_alloc(const struct drm_plane_state
> *pstate,
>
> /* For Non Y-tile return 8-blocks */
> if (fb->modifier != I915_FORMAT_MOD_Y_TILED &&
> -   fb->modifier != I915_FORMAT_MOD_Yf_TILED)
> +   fb->modifier != I915_FORMAT_MOD_Yf_TILED &&
> +   fb->modifier != I915_FORMAT_MOD_Y_TILED_CCS &&
> +   fb->modifier != I915_FORMAT_MOD_Yf_TILED_CCS)
> return 8;
>
> src_w = drm_rect_width(_pstate->base.src) >> 16;
> @@ -3590,7 +3606,9 @@ static int skl_compute_plane_wm(const struct
> drm_i915_private *dev_priv,
> }
>
> y_tiled = fb->modifier == I915_FORMAT_MOD_Y_TILED ||
> - fb->modifier == I915_FORMAT_MOD_Yf_TILED;
> + fb->modifier == I915_FORMAT_MOD_Yf_TILED ||
> + fb->modifier == I915_FORMAT_MOD_Y_TILED_CCS ||
> + fb->modifier == I915_FORMAT_MOD_Yf_TILED_CCS;
> x_tiled = fb->modifier == I915_FORMAT_MOD_X_TILED;
>
> /* Display WA #1141: kbl. */
> @@ -3675,6 +3693,13 @@ static int skl_compute_plane_wm(const struct
> drm_i915_private *dev_priv,
> res_lines = DIV_ROUND_UP(selected_result.val,
>  plane_blocks_per_line.val);
>
> +   /* Display WA #1125: skl,bxt,kbl,glk */
> +   if (level == 0 &&
> +   (fb->modifier == I915_FORMAT_MOD_Y_TILED_CCS ||
> +fb->modifier == I915_FORMAT_MOD_Yf_TILED_CCS))
> +   res_blocks += fixed_16_16_to_u32_round_up(y_tile_minimum);
> +
> +   /* Display WA #1126: skl,bxt,kbl,glk */
> if (level >= 1 && level <= 7) {
> if (y_tiled) {
> res_blocks += fixed_16_16_to_u32_round_up(y_
> tile_minimum);
> diff --git a/drivers/gpu/drm/i915/intel_sprite.c
> b/drivers/gpu/drm/i915/intel_sprite.c
> index 7031bc733d97..063a994815d0 100644
> --- a/drivers/gpu/drm/i915/intel_sprite.c
> +++ b/drivers/gpu/drm/i915/intel_sprite.c
> @@ -210,6 +210,7 @@ skl_update_plane(struct drm_plane *drm_plane,
> u32 surf_addr = plane_state->main.offset;
> unsigned int rotation = plane_state->base.rotation;
> u32 stride = skl_plane_stride(fb, 0, rotation);
> +   u32 aux_stride = skl_plane_stride(fb, 1, rotation);
> int crtc_x = plane_state->base.dst.x1;
> int crtc_y = plane_state->base.dst.y1;
> uint32_t crtc_w = drm_rect_width(_state->base.dst);
> @@ -248,6 +249,10 @@ skl_update_plane(struct drm_plane *drm_plane,
> I915_WRITE(PLANE_OFFSET(pipe, plane_id), (y << 16) | x);
> I915_WRITE(PLANE_STRIDE(pipe, plane_id), stride);
> I915_WRITE(PLANE_SIZE(pipe, plane_id), (src_h << 16) | src_w);
> +   I915_WRITE(PLANE_AUX_DIST(pipe, plane_id),
> +  (plane_state->aux.offset - surf_addr) | aux_stride);
> +   I915_WRITE(PLANE_AUX_OFFSET(pipe, plane_id),
> +  (plane_state->aux.y << 16) | plane_state->aux.x);
>
> /* program plane scaler */
> if (plane_state->scaler_id >= 0) {
> --
> 2.10.2
>
>
-- next part --
An HTML attachment was scrubbed...
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20170109/6fc7dd6d/attachment-0001.html>

[PATCH] drm: disable deep color when EDID violates spec

[Daniel Vetter]

On Thu, Jan 05, 2017 at 05:45:23PM -0600, Nicholas Sielicki wrote:
> As per the HDMI 1.3 and 1.4 spec, "deep color modes" are color depths
> greater than 24 bits per pixel. The spec explicitly states, "All Deep
> Color modes are optional though if an HDMI Source or Sink supports any
> Deep Color mode, it shall support 36-bit mode." (6.2.4 Color Depth
> Requirements).
> 
> I came across a monitor (Acer X233H) that supplies an illegal EDID where
> DC_30bit is set and DC_36bit is not set. The end result is badly garbled
> output because the driver is sending 36BPP when the monitor can't handle
> it.
> 
> Much of the intel hardware is incapable of operating at any
> bit-per-component setting outside of 8 or 12, and the spec seems to
> imply that if any deep color support is found, then it is a safe
> assumption to operate at 12.
> 
> This patch ensures that the EDID is within the spec (specifically, that
> DC_36bit is set) before committing to going forward with any deep
> colors.  There was already a check for this EDID inconsistency, but it
> resulted only in a warning and did not fall-back to safer settings.
> 
> CC: Ville Syrjälä 
> Signed-off-by: Nicholas Sielicki 

I guess we need Cc: stable at vger.kernel.org on this too? Any bugzilla links
to reference?

Ville, if this makes sense for you too, can you pls push it to
drm-misc-fixes?

Thanks, Daniel

> ---
>  drivers/gpu/drm/drm_edid.c | 35 +++
>  1 file changed, 23 insertions(+), 12 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> index 336be31ff3de..42ce3f54d2dc 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -3772,30 +3772,34 @@ static void drm_parse_hdmi_deep_color_info(struct 
> drm_connector *connector,
>  {
>   struct drm_display_info *info = >display_info;
>   unsigned int dc_bpc = 0;
> + u8 modes = 0;
>  
>   /* HDMI supports at least 8 bpc */
>   info->bpc = 8;
>  
> + /* Ensure all DC modes are unset if we return early */
> + info->edid_hdmi_dc_modes = 0;
> +
>   if (cea_db_payload_len(hdmi) < 6)
>   return;
>  
>   if (hdmi[6] & DRM_EDID_HDMI_DC_30) {
>   dc_bpc = 10;
> - info->edid_hdmi_dc_modes |= DRM_EDID_HDMI_DC_30;
> + modes |= DRM_EDID_HDMI_DC_30;
>   DRM_DEBUG("%s: HDMI sink does deep color 30.\n",
> connector->name);
>   }
>  
>   if (hdmi[6] & DRM_EDID_HDMI_DC_36) {
>   dc_bpc = 12;
> - info->edid_hdmi_dc_modes |= DRM_EDID_HDMI_DC_36;
> + modes |= DRM_EDID_HDMI_DC_36;
>   DRM_DEBUG("%s: HDMI sink does deep color 36.\n",
> connector->name);
>   }
>  
>   if (hdmi[6] & DRM_EDID_HDMI_DC_48) {
>   dc_bpc = 16;
> - info->edid_hdmi_dc_modes |= DRM_EDID_HDMI_DC_48;
> + modes |= DRM_EDID_HDMI_DC_48;
>   DRM_DEBUG("%s: HDMI sink does deep color 48.\n",
> connector->name);
>   }
> @@ -3806,9 +3810,24 @@ static void drm_parse_hdmi_deep_color_info(struct 
> drm_connector *connector,
>   return;
>   }
>  
> + /*
> +  * All deep color modes are optional, but if a sink supports any deep
> +  * color mode, it must support 36-bit mode. If this is found not
> +  * to be the case, sink is in violation of HDMI 1.3 / 1.4 spec and it
> +  * is prudent to disable all deep color modes. Return here before
> +  * committing bpc and edid_hdmi_dc_modes.
> +  */
> + if (!(modes & DRM_EDID_HDMI_DC_36)) {
> + DRM_DEBUG("%s: HDMI sink should do DC_36, but does not!\n",
> +   connector->name);
> + return;
> + }
> +
> +
>   DRM_DEBUG("%s: Assigning HDMI sink color depth as %d bpc.\n",
> connector->name, dc_bpc);
>   info->bpc = dc_bpc;
> + info->edid_hdmi_dc_modes = modes;
>  
>   /*
>* Deep color support mandates RGB444 support for all video
> @@ -3823,15 +3842,6 @@ static void drm_parse_hdmi_deep_color_info(struct 
> drm_connector *connector,
>   DRM_DEBUG("%s: HDMI sink does YCRCB444 in deep color.\n",
> connector->name);
>   }
> -
> - /*
> -  * Spec says that if any deep color mode is supported at all,
> -  * then deep color 36 bit must be supported.
> -  */
> - if (!(hdmi[6] & DRM_EDID_HDMI_DC_36)) {
> - DRM_DEBUG("%s: HDMI sink should do DC_36, but does not!\n",
> -   connector->name);
> - }
>  }
>  
>  static void
> @@ -3895,6 +3905,7 @@ static void drm_add_display_info(struct drm_connector 
> *connector,
>   /* driver figures it out in this case */
>   info->bpc = 0;
>   info->color_formats = 0;
> + info->edid_hdmi_dc_modes = 0;
>   info->cea_rev = 0;
>   info->max_tmds_clock = 0;
>   info->dvi_dual = false;
> -- 
> 

[Intel-gfx] 4.10-rc2 oops in DRM connector code

[Daniel Vetter]

On Thu, Jan 05, 2017 at 11:03:44AM -0800, Dave Hansen wrote:
> My Thinkpad x260 doesn't like to be unplugged from its dock.  I don't
> think this is a new bug.  It's happening on my distro's 4.4 kernel
> as well.
> 
> The actual oops is in device_del().  It appears to have been passed a
> null 'struct device *'.
> 
> There appears to have been a race _around_ here fixed in 1f7717552e.
> I've looked for and tried to find the locking that prevents
> drm_connector_unregister() from being called twice concurrently.  I'm
> unable to find anything.
> 
> drm_dp_destroy_connector_work() has some locking that looks useful:
> 
>   mutex_lock(>destroy_connector_lock)
> 
> but it's released before the offending call:
> 
>   mgr->cbs->destroy_connector(mgr, port->connector);
> 
> which actually calls intel_dp_destroy_mst_connector().  I have no idea
> if it's correct (and haven't even run it with lockdep), but the attached
> patch does seem to fix my oopses.
> 
> Any ideas?
> 
> > Jan  5 10:22:32 ray kernel: [  537.087042] BUG: unable to handle kernel 
> > NULL pointer dereference at 009e
> > Jan  5 10:22:32 ray kernel: [  537.087954] IP: device_del+0x19/0x330
> > Jan  5 10:22:32 ray kernel: [  537.088860] PGD 0
> > Jan  5 10:22:32 ray kernel: [  537.088860]
> > Jan  5 10:22:32 ray kernel: [  537.090578] Oops:  [#1] SMP
> > Jan  5 10:22:32 ray kernel: [  537.091406] Modules linked in: ctr ccm 
> > ipt_MASQUERADE nf_nat_masquerade_ipv4 iptable_nat nf_nat_ipv4 nf_nat 
> > nf_conntrack_ipv4 nf_defrag_ipv4 xt_conntrack nf_conntrack ipt_REJECT 
> > nf_reject_ipv4 xt_CHECKSUM iptable_mangle xt_tcpudp bridge stp llc 
> > iptable_filter ip_tables ebtable_nat ebtables x_tables cmac rfcomm bnep 
> > dm_crypt arc4 iwlmvm mac80211 snd_hda_codec_hdmi snd_hda_codec_realtek 
> > snd_hda_codec_generic iwlwifi intel_rapl snd_hda_intel iosf_mbi 
> > hid_logitech_hidpp snd_seq_midi cfg80211 x86_pkg_temp_thermal snd_hda_codec 
> > snd_seq_midi_event snd_hwdep btusb snd_rawmidi snd_hda_core btrtl coretemp 
> > snd_seq snd_pcm btbcm btintel joydev bluetooth ghash_clmulni_intel 
> > snd_timer shpchp thinkpad_acpi snd_seq_device nvram wmi snd soundcore 
> > mac_hid aesni_intel aes_x86_64 crypto_simd cryptd glue_helper kvm_intel
> > Jan  5 10:22:32 ray kernel: [  537.095222]  kvm irqbypass hid_generic 
> > hid_logitech_dj usbhid hid
> > Jan  5 10:22:32 ray kernel: [  537.096272] CPU: 2 PID: 23 Comm: kworker/2:0 
> > Tainted: GW   4.10.0-rc2 #47
> > Jan  5 10:22:32 ray kernel: [  537.097263] Hardware name: LENOVO 
> > 20F5S7V800/20F5S7V800, BIOS R02ET50W (1.23 ) 09/20/2016
> > Jan  5 10:22:32 ray kernel: [  537.098291] Workqueue: events 
> > drm_dp_destroy_connector_work
> > Jan  5 10:22:32 ray kernel: [  537.099328] task: 88040f2f1e00 
> > task.stack: c9000198c000
> > Jan  5 10:22:32 ray kernel: [  537.100335] RIP: 0010:device_del+0x19/0x330
> > Jan  5 10:22:32 ray kernel: [  537.101340] RSP: 0018:c9000198fd58 
> > EFLAGS: 00010282
> > Jan  5 10:22:32 ray kernel: [  537.102361] RAX:  RBX: 
> > fffe RCX: 88040c5191b0
> > Jan  5 10:22:32 ray kernel: [  537.103418] RDX: 81cb6246 RSI: 
> > 0001 RDI: fffe
> > Jan  5 10:22:32 ray kernel: [  537.104473] RBP: c9000198fd90 R08: 
> >  R09: 880421517780
> > Jan  5 10:22:32 ray kernel: [  537.105574] R10: 007d0ce17c93 R11: 
> > 0001 R12: fffe
> > Jan  5 10:22:32 ray kernel: [  537.106636] R13: 88040ed36bd8 R14: 
> > 88040ed36788 R15: 88040c728810
> > Jan  5 10:22:32 ray kernel: [  537.107728] FS:  () 
> > GS:88042150() knlGS:
> > Jan  5 10:22:32 ray kernel: [  537.108812] CS:  0010 DS:  ES:  CR0: 
> > 80050033
> > Jan  5 10:22:32 ray kernel: [  537.109937] CR2: 009e CR3: 
> > 000384894000 CR4: 003406e0
> > Jan  5 10:22:32 ray kernel: [  537.111038] DR0:  DR1: 
> >  DR2: 
> > Jan  5 10:22:32 ray kernel: [  537.112142] DR3:  DR6: 
> > fffe0ff0 DR7: 0400
> > Jan  5 10:22:32 ray kernel: [  537.113223] Call Trace:
> > Jan  5 10:22:32 ray kernel: [  537.114293]  device_unregister+0x12/0x30
> > Jan  5 10:22:32 ray kernel: [  537.115354]  
> > drm_sysfs_connector_remove+0x3b/0x50
> > Jan  5 10:22:32 ray kernel: [  537.116391]  
> > drm_connector_unregister.part.8+0x27/0x40
> > Jan  5 10:22:32 ray kernel: [  537.117433]  
> > drm_connector_unregister+0x14/0x20
> > Jan  5 10:22:32 ray kernel: [  537.118478]  
> > intel_dp_destroy_mst_connector+0x1a/0x80
> > Jan  5 10:22:32 ray kernel: [  537.119513]  
> > drm_dp_destroy_connector_work+0xa9/0x150
> > Jan  5 10:22:32 ray kernel: [  537.120539]  process_one_work+0x14b/0x430
> > Jan  5 10:22:32 ray kernel: [  537.121568]  worker_thread+0x12b/0x4a0
> > Jan  5 10:22:32 ray kernel: [  537.122581]  kthread+0x10c/0x140
> > Jan  5 

[PATCH 0/6] Use crtc helper drm_crtc_from_index() for more drivers

[Sean Paul]

On Mon, Jan 9, 2017 at 6:25 AM, Shawn Guo  wrote:
> From: Shawn Guo 
>
> This is a follow-up series for "[PATCH 0/3] Add CRTC helper
> drm_crtc_from_index()" per Daniel's comment [1].
>
> Basically, it changes some drivers to use helper drm_crtc_from_index()
> for the vblank code, so that either they do not need to store CRTC
> pointers in private struct, or the exactly same code for finding CRTC
> can be saved.
>
> Compile tested against the following branch.
>
>  git://anongit.freedesktop.org/drm/drm-misc drm-misc-next
>

Thanks for the patches, Shawn. The entire series is

Reviewed-by: Sean Paul 

I'll apply it to -misc in a week if there are no objections between now and then

Sean


> Shawn
>
> [1] http://www.spinics.net/lists/dri-devel/msg128065.html
>
> Shawn Guo (6):
>   drm: exynos: use crtc helper drm_crtc_from_index()
>   drm: kirin: use crtc helper drm_crtc_from_index()
>   drm: mediatek: use crtc helper drm_crtc_from_index()
>   drm: nouveau: use crtc helper drm_crtc_from_index()
>   drm: tegra: use crtc helper drm_crtc_from_index()
>   drm: vc4: use crtc helper drm_crtc_from_index()
>
>  drivers/gpu/drm/exynos/exynos_drm_crtc.c|  6 -
>  drivers/gpu/drm/exynos/exynos_drm_drv.h | 10 ++--
>  drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c | 10 +++-
>  drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.h |  1 -
>  drivers/gpu/drm/mediatek/mtk_drm_crtc.c |  9 +++
>  drivers/gpu/drm/mediatek/mtk_drm_drv.h  |  1 -
>  drivers/gpu/drm/nouveau/nouveau_display.c   | 33 
> ++---
>  drivers/gpu/drm/tegra/drm.c | 19 +++---
>  drivers/gpu/drm/vc4/vc4_crtc.c  | 17 ++---
>  drivers/gpu/drm/vc4/vc4_drv.h   |  1 -
>  10 files changed, 38 insertions(+), 69 deletions(-)
>
> --
> 1.9.1
>



-- 
Sean Paul, Software Engineer, Google / Chromium OS

[RFC] drm: Parse HDMI 2.0 YCbCr 4:2:0 VDB and VCB

[Jose Abreu]

Hi Shashank,


Thanks for the review.


On 09-01-2017 05:22, Sharma, Shashank wrote:
> Regards
>
> Shashank
>
>
> On 12/30/2016 10:23 PM, Jose Abreu wrote:
>> HDMI 2.0 introduces a new sampling mode called YCbCr 4:2:0.
>> According to the spec the EDID may contain two blocks that
>> signal this sampling mode:
>> - YCbCr 4:2:0 Video Data Block
>> - YCbCr 4:2:0 Video Capability Map Data Block
>>
>> The video data block contains the list of vic's were
>> only YCbCr 4:2:0 sampling mode shall be used while the
>> video capability map data block contains a mask were
>> YCbCr 4:2:0 sampling mode may be used.
>>
>> This RFC patch adds support for parsing these two new blocks
>> and introduces new flags to signal the drivers if the
>> mode is 4:2:0'only or 4:2:0'able.
>>
>> The reason this is still a RFC is because there is no
>> reference in kernel for this new sampling mode (specially in
>> AVI infoframe part), so, I was hoping to hear some feedback
>> first.
>>
>> Tested in a HDMI 2.0 compliance scenario.
>>
>> Signed-off-by: Jose Abreu 
>> Cc: Carlos Palminha 
>> Cc: Daniel Vetter 
>> Cc: Jani Nikula 
>> Cc: Sean Paul 
>> Cc: David Airlie 
>> Cc: dri-devel at lists.freedesktop.org
>> Cc: linux-kernel at vger.kernel.org
>> ---
>>   drivers/gpu/drm/drm_edid.c  | 139
>> +++-
>>   drivers/gpu/drm/drm_modes.c |  10 +++-
>>   include/uapi/drm/drm_mode.h |   6 ++
>>   3 files changed, 151 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/drm_edid.c
>> b/drivers/gpu/drm/drm_edid.c
>> index 67d6a73..6ce1a38 100644
>> --- a/drivers/gpu/drm/drm_edid.c
>> +++ b/drivers/gpu/drm/drm_edid.c
>> @@ -2549,6 +2549,8 @@ static int drm_cvt_modes(struct
>> drm_connector *connector,
>>   #define VENDOR_BLOCK0x03
>>   #define SPEAKER_BLOCK0x04
>>   #define VIDEO_CAPABILITY_BLOCK0x07
>> +#define VIDEO_DATA_BLOCK_4200x0E
>> +#define VIDEO_CAP_BLOCK_4200x0F
>>   #define EDID_BASIC_AUDIO(1 << 6)
>>   #define EDID_CEA_YCRCB444(1 << 5)
>>   #define EDID_CEA_YCRCB422(1 << 4)
>> @@ -3050,6 +3052,98 @@ static int add_3d_struct_modes(struct
>> drm_connector *connector, u16 structure,
>>   return modes;
>>   }
>>   +static int add_420_mode(struct drm_connector *connector, u8
>> vic)
>> +{
>> +struct drm_device *dev = connector->dev;
>> +struct drm_display_mode *newmode;
>> +
>> +if (!drm_valid_cea_vic(vic))
>> +return 0;
>> +
>> +newmode = drm_mode_duplicate(dev, _cea_modes[vic]);
> Sorry to start the review late, I missed this mail chain. It
> would be great if you can please keep me in CC for this chain.

Sure. Will do that next time.

>
> Practically, YUV420 modes are being used for 4k and UHD video
> modes. Now here, when we want to
> add these modes from edid_cea_db, using the VIC index, we
> should have full list of cea_modes from 1 - 107
> Particularly 93-107 ( which is for new 38x21 and 40x21 modes,
> added in CEA-861-F). right now, edid_cea_modes
> cant index 4k modes, so practically this this patch series will
> do nothing (even though its doing everything right)

This is correct but not entirely true. I realize 4:2:0 is mostly
used in 4k modes but it can also be used in any other video mode,
as long as it is declared in the VCB.

>
> To handle this scenario, I had added a patch series
> https://urldefense.proofpoint.com/v2/url?u=https-3A__patchwork.freedesktop.org_patch_119627_=DgICaQ=DPL6_X_6JkXFx7AXWqB0tg=WHDsc6kcWAl4i96Vm5hJ_19IJiuxx_p_Rzo2g-uHDKw=6JwJ_PEZj3MSeRaLTHuLtPZCb0uPPjUqR5raxY_qILI=DPBQ2MpLgngWGJEOg2v9CQhg2CSf_4LOIAC30B6AAyg=
> (complete the cea modedb (VIC=65 onwards)) Now, this patch
> series had dependency on new aspect ratios
> being added in CEA-861-F which I tried to add in series
> (https://urldefense.proofpoint.com/v2/url?u=https-3A__patchwork.freedesktop.org_patch_116095_=DgICaQ=DPL6_X_6JkXFx7AXWqB0tg=WHDsc6kcWAl4i96Vm5hJ_19IJiuxx_p_Rzo2g-uHDKw=6JwJ_PEZj3MSeRaLTHuLtPZCb0uPPjUqR5raxY_qILI=PX2M1hM2cF_aWiDe5oZeLWjsOgL-hvUR54Ion9kYMxM=
> )
> Which was added and later reverted by Ville
> (https://urldefense.proofpoint.com/v2/url?u=https-3A__patchwork.freedesktop.org_patch_119808_=DgICaQ=DPL6_X_6JkXFx7AXWqB0tg=WHDsc6kcWAl4i96Vm5hJ_19IJiuxx_p_Rzo2g-uHDKw=6JwJ_PEZj3MSeRaLTHuLtPZCb0uPPjUqR5raxY_qILI=FAa6aHQ_HjlaVRzDm282p9bSY_tBiN1PngZBhsTqYdI=
> ).

Yes, I remember that. If it was breaking userspace then there was
nothing left to do, revert was needed. I thing we should take
your patch and rework/extend it so that userspace does not break
as this is a most welcome feature. The new HDMI spec is almost
ready, and yet, 2.0 features are still missing from the kernel.
We should take advantage from our capability of accessing these
specs, test equipment, compliance equipment ... and submit
patches for these new features :)

>
> In short, the method/sequence for effective development would be:
> - Add aspect ratio support in DRM
> - Add HDMI 2.0 (CEA-861-F) aspect ratios
> 

[PATCH 0/5] drm/sti: do not sync legacy IOCTL on vblank if not ATOMIC

[Daniel Vetter]

On Thu, Jan 05, 2017 at 03:23:24PM +, Fabien DESSENNE wrote:
> Hi Daniel
> 
> 
> I come to the conclusion that (only) Atomic Weston will solve all of my 
> troubles, so let's forget these patches (and work for atomic weston).
> 
> By the way, is the expected behavior (Vblank - sync'ed or not) of 
> drmModeSetPlane() described anywhere? The last time I browsed the 
> related documentation I could not find the answer. Maybe something that 
> needs to be clarified ?

It's undefined and depends upon driver and platform and kernel version.
And all the work is done already, we've taken all the lessons learned from
legacy planes and made sure atomic sucks less ;-) There's no point in
changing/clarifying legacy semantics, at worst you'll end up breaking more
existing userspace. And we're not going to get uniform behaviour between
all drivers anyway for the legacy interfaces. Imo not worth the trouble,
let's just use atomic.
-Daniel


> I will also re-send patch 1 & 5 out of this abandoned series since they 
> make sense independently of this (a)sync stuff.
> 
> 
> BR.
> 
> 
> Fabien
> 
> 
> On 04/01/17 10:18, Daniel Vetter wrote:
> > On Tue, Jan 03, 2017 at 05:56:47PM +0100, Fabien Dessenne wrote:
> >> These patches allow a legacy framework (eg non-atomic Weston) to call
> >> several SETPLANE within the same Vsync cycle.
> >> - [PATCH 1/5] drm/sti: use atomic_helper for commit
> >> - [PATCH 2/5] drm/sti: add drm_file to sti_private
> >> - [PATCH 3/5] drm/sti: do not sync SETPLANE on vblank if not ATOMIC
> >> - [PATCH 4/5] drm/sti: do not sync SETPROPERTY on vblank if not ATOMIC
> >> - [PATCH 5/5] drm/sti: do not check hw scaling if mode is not set
> > Upstream weston never really enabled plane support, why exactly do you
> > need this? Also, if this really is required, I think we should implement
> > something like this (aka async plane flips) in general for everyone. sti
> > is by far not the only driver playing around with these games.
> > -Daniel

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

[PATCH] drm/atomic: Add target_vblank support in atomic helpers (v2)

[Daniel Vetter]

On Fri, Jan 06, 2017 at 03:39:40PM -0500, Andrey Grodzovsky wrote:
> Allows usage of the new page_flip_target hook for drivers implementing 
> the atomic path.
> Provides default atomic helper for the new hook.
> 
> v2:
> Update code sharing logic between exsiting and the new flip hooks.
> Improve kerneldoc.
> 
> Signed-off-by: Andrey Grodzovsky 

Looks all reasonable, I think an ack from Alex that the amd side is in
shape too, and I'll pull this into drm-misc.

Thanks, Daniel

> ---
>  drivers/gpu/drm/drm_atomic_helper.c | 133 
> ++--
>  include/drm/drm_atomic_helper.h |   6 ++
>  include/drm/drm_crtc.h  |   9 +++
>  3 files changed, 127 insertions(+), 21 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
> b/drivers/gpu/drm/drm_atomic_helper.c
> index 583f47f..a4e5477 100644
> --- a/drivers/gpu/drm/drm_atomic_helper.c
> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> @@ -2733,6 +2733,44 @@ int drm_atomic_helper_resume(struct drm_device *dev,
>  }
>  EXPORT_SYMBOL(drm_atomic_helper_connector_set_property);
>  
> +static int page_flip_common(
> + struct drm_atomic_state *state,
> + struct drm_crtc *crtc,
> + struct drm_framebuffer *fb,
> + struct drm_pending_vblank_event *event)
> +{
> + struct drm_plane *plane = crtc->primary;
> + struct drm_plane_state *plane_state;
> + struct drm_crtc_state *crtc_state;
> + int ret = 0;
> +
> + crtc_state = drm_atomic_get_crtc_state(state, crtc);
> + if (IS_ERR(crtc_state))
> + return PTR_ERR(crtc_state);
> +
> + crtc_state->event = event;
> +
> + plane_state = drm_atomic_get_plane_state(state, plane);
> + if (IS_ERR(plane_state))
> + return PTR_ERR(plane_state);
> +
> +
> + ret = drm_atomic_set_crtc_for_plane(plane_state, crtc);
> + if (ret != 0)
> + return ret;
> + drm_atomic_set_fb_for_plane(plane_state, fb);
> +
> + /* Make sure we don't accidentally do a full modeset. */
> + state->allow_modeset = false;
> + if (!crtc_state->active) {
> + DRM_DEBUG_ATOMIC("[CRTC:%d] disabled, rejecting legacy flip\n",
> +  crtc->base.id);
> + return -EINVAL;
> + }
> +
> + return ret;
> +}
> +
>  /**
>   * drm_atomic_helper_page_flip - execute a legacy page flip
>   * @crtc: DRM crtc
> @@ -2740,7 +2778,8 @@ int drm_atomic_helper_resume(struct drm_device *dev,
>   * @event: optional DRM event to signal upon completion
>   * @flags: flip flags for non-vblank sync'ed updates
>   *
> - * Provides a default page flip implementation using the atomic driver 
> interface.
> + * Provides a default _crtc_funcs.page_flip implementation
> + * using the atomic driver interface.
>   *
>   * Note that for now so called async page flips (i.e. updates which are not
>   * synchronized to vblank) are not supported, since the atomic interfaces 
> have
> @@ -2748,6 +2787,9 @@ int drm_atomic_helper_resume(struct drm_device *dev,
>   *
>   * Returns:
>   * Returns 0 on success, negative errno numbers on failure.
> + *
> + * See also:
> + * drm_atomic_helper_page_flip_target()
>   */
>  int drm_atomic_helper_page_flip(struct drm_crtc *crtc,
>   struct drm_framebuffer *fb,
> @@ -2756,8 +2798,6 @@ int drm_atomic_helper_page_flip(struct drm_crtc *crtc,
>  {
>   struct drm_plane *plane = crtc->primary;
>   struct drm_atomic_state *state;
> - struct drm_plane_state *plane_state;
> - struct drm_crtc_state *crtc_state;
>   int ret = 0;
>  
>   if (flags & DRM_MODE_PAGE_FLIP_ASYNC)
> @@ -2768,35 +2808,86 @@ int drm_atomic_helper_page_flip(struct drm_crtc *crtc,
>   return -ENOMEM;
>  
>   state->acquire_ctx = drm_modeset_legacy_acquire_ctx(crtc);
> +
>  retry:
> - crtc_state = drm_atomic_get_crtc_state(state, crtc);
> - if (IS_ERR(crtc_state)) {
> - ret = PTR_ERR(crtc_state);
> + ret = page_flip_common(state, crtc, fb, event);
> + if (ret != 0)
>   goto fail;
> - }
> - crtc_state->event = event;
>  
> - plane_state = drm_atomic_get_plane_state(state, plane);
> - if (IS_ERR(plane_state)) {
> - ret = PTR_ERR(plane_state);
> - goto fail;
> - }
> + ret = drm_atomic_nonblocking_commit(state);
>  
> - ret = drm_atomic_set_crtc_for_plane(plane_state, crtc);
> +fail:
> + if (ret == -EDEADLK)
> + goto backoff;
> +
> + drm_atomic_state_put(state);
> + return ret;
> +
> +backoff:
> + drm_atomic_state_clear(state);
> + drm_atomic_legacy_backoff(state);
> +
> + /*
> +  * Someone might have exchanged the framebuffer while we dropped locks
> +  * in the backoff code. We need to fix up the fb refcount tracking the
> +  * core does for us.
> +  */
> + plane->old_fb = plane->fb;
> +
> + goto 

[PATCH 0/3] Add CRTC helper drm_crtc_from_index()

[Daniel Vetter]

On Mon, Jan 09, 2017 at 05:03:35PM +0800, Shawn Guo wrote:
> On Fri, Dec 30, 2016 at 12:16:43PM +0100, Daniel Vetter wrote:
> > Entire series applied. I suspect that there's more drivers open-coding
> > something like this in their vblank code, might be worth it to grep for
> > them all and do a quick audit.
> 
> I did a round of audit on all drivers vblank code, and found there are
> basically 3 categories:
> 
> 1. Drivers that only support one CRTC.  In this case, the 'pipe' is not
> used at all in vblank code.  So we need to do thing about them.
> Examples: arm, atmel-hlcdc, mxsfb, etc.
> 
> 2. Drivers that maintain CRTC pointers and number in the private
> structure.  And the fields are used in somewhere else beside vblank
> code.  The cleanup will need a bit surgery on the driver code.  I would
> leave them out for driver owners/maintainers.  Examples: armada, msm,
> sti, etc.
> 
> 3. Drivers that can use the helper for benefit, including exynos, kirin,
> mediatek, nouveau, tegra and vc4.  I have already prepared a series for
> these drivers, and will send it out for review shortly.

Awesome, thanks a lot for doing this. One of my long-term goals is to
switch the vblank helper callbacks over from int pipe to struct drm_crtc
*, stuff like this helps a lot in prepping the ground.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

[PATCH v7 3/4] drm/panel: Add support for S6E3HA2 panel driver on TM2 board

[Andrzej Hajda]

On 09.01.2017 10:19, Inki Dae wrote:
>
> 2017년 01월 09일 16:37에 Andrzej Hajda 이(가) 쓴 글:
>> On 06.01.2017 09:36, Inki Dae wrote:
>>> 2017년 01월 06일 17:18에 Andi Shyti 이(가) 쓴 글:
 Hi Inki,

 Thanks for the reply, but...

>>> +static const struct drm_display_mode default_mode = {
>>> +   .clock = 222372,
>>> +   .hdisplay = 1440,
>>> +   .hsync_start = 1440 + 1,
>>> +   .hsync_end = 1440 + 1 + 1,
>>> +   .htotal = 1440 + 1 + 1 + 1,
>>> +   .vdisplay = 2560,
>>> +   .vsync_start = 2560 + 1,
>>> +   .vsync_end = 2560 + 1 + 1,
>>> +   .vtotal = 2560 + 1 + 1 + 15,
>>> +   .vrefresh = 60,
>>> +   .flags = 0,
>>> +};
>> how is this working with tm2e? Are these values valid for both
>> the boards?
> We don't need to consider tm2e board with two reasones,
> 1. there is no tm2e board support in mainline
> 2. the panel on tm2 would be a little bit different from one on tm2e
 ... this display in the Tizen Kernel is supported by both:
 tm2 [1] and tm2e [2]. The only differences are:
>>> Why tm2e dts file is in mainline? Seems communication miss with Chanwoo. :( 
>>>
 TM2:
clock-frequency = <1487>;
hactive = <1440>;

 TM2E:
clock-frequency = <16523724>;
hactive = <1600>;

 I don't know much about the differences you mention in point 2,
 but it's a pity to drop support only because we don't want to put
 in the dts the 'hactive', and 'clock-frequency' properties.
>>> Anyway, tm2e board is already in mainline so Panel driver may need to 
>>> identify what kinds of panel is probed to decide porch values. I think 
>>> there are relevant registers in MCU of the Panel device to check version or 
>>> similar thing.
>> I think we can safely use different compatible string for tm2e - it uses
>> different display IC controller - s6e3hf2, driver will provide timings
>> based on it.
> Using compatable string wouldn't be a good idea because Panel is a device not 
> specific to board.

But both panels are different devices:
TM2 has: AMS567DJ01 panel on S6E3HA2 interface (called LDI/IC)
TM2E has AMB559DE01 panel on S6E3HF2 interface (called LDI/IC)

Why assigning different compatibles to different devices is not a good idea?

>
>> As far as I examined available specs/docs there is no reliable register
>> which can be used to safely distinguish it on runtime, but the docs I
>> have are far from completeness.
> The data sheet I am seeing says a RDDIDS register describes manufacturer and 
> module version information. With this we could identify the Panel device.
> Of course, we may need to check the register has really different values 
> according to board.
>
> Below is the version information Hoegeun checked,
>
> TM2
> [4.908666] panel_s6e3ha2 1390.dsi.0: Manufacture date: 2014-10-31 
> 06:41
> [5.035768] panel_s6e3ha2 1390.dsi.0: Id: 50 20 09
>
> TM2e
> [4.929265] panel_s6e3ha2 1390.dsi.0: Manufacture date: 2014-09-03 
> 06:30
> [5.056287] panel_s6e3ha2 1390.dsi.0: Id: 40 40 14

There is description of ID1, ID2, ID3 registers in specs of both panels,
I see no reliable bits to distinguish panels.
And relying on read values of random devices does not seems to me proper
solution.

Regards
Andrzej


>
>
> Thanks.
>
>> Regards
>> Andrzej
>>
>>> Thanks.
>>>
 Andi

 [1] 
 https://git.tizen.org/cgit/platform/kernel/linux-exynos/tree/arch/arm64/boot/dts/exynos/exynos5433-tm2.dts?h=tizen#n1284
 [2] 
 https://git.tizen.org/cgit/platform/kernel/linux-exynos/tree/arch/arm64/boot/dts/exynos/exynos5433-tm2e.dts?h=tizen#n1270
 --
 To unsubscribe from this list: send the line "unsubscribe devicetree" in
 the body of a message to majordomo at vger.kernel.org
 More majordomo info at  http://vger.kernel.org/majordomo-info.html

 .

>> --
>> To unsubscribe from this list: send the line "unsubscribe devicetree" in
>> the body of a message to majordomo at vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>
>>
>

[RFC] drm: Parse HDMI 2.0 YCbCr 4:2:0 VDB and VCB

[Sharma, Shashank]

Regards

Shashank


On 12/30/2016 10:23 PM, Jose Abreu wrote:
> HDMI 2.0 introduces a new sampling mode called YCbCr 4:2:0.
> According to the spec the EDID may contain two blocks that
> signal this sampling mode:
>   - YCbCr 4:2:0 Video Data Block
>   - YCbCr 4:2:0 Video Capability Map Data Block
>
> The video data block contains the list of vic's were
> only YCbCr 4:2:0 sampling mode shall be used while the
> video capability map data block contains a mask were
> YCbCr 4:2:0 sampling mode may be used.
>
> This RFC patch adds support for parsing these two new blocks
> and introduces new flags to signal the drivers if the
> mode is 4:2:0'only or 4:2:0'able.
>
> The reason this is still a RFC is because there is no
> reference in kernel for this new sampling mode (specially in
> AVI infoframe part), so, I was hoping to hear some feedback
> first.
>
> Tested in a HDMI 2.0 compliance scenario.
>
> Signed-off-by: Jose Abreu 
> Cc: Carlos Palminha 
> Cc: Daniel Vetter 
> Cc: Jani Nikula 
> Cc: Sean Paul 
> Cc: David Airlie 
> Cc: dri-devel at lists.freedesktop.org
> Cc: linux-kernel at vger.kernel.org
> ---
>   drivers/gpu/drm/drm_edid.c  | 139 
> +++-
>   drivers/gpu/drm/drm_modes.c |  10 +++-
>   include/uapi/drm/drm_mode.h |   6 ++
>   3 files changed, 151 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> index 67d6a73..6ce1a38 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -2549,6 +2549,8 @@ static int drm_cvt_modes(struct drm_connector 
> *connector,
>   #define VENDOR_BLOCK0x03
>   #define SPEAKER_BLOCK   0x04
>   #define VIDEO_CAPABILITY_BLOCK  0x07
> +#define VIDEO_DATA_BLOCK_420 0x0E
> +#define VIDEO_CAP_BLOCK_420  0x0F
>   #define EDID_BASIC_AUDIO(1 << 6)
>   #define EDID_CEA_YCRCB444   (1 << 5)
>   #define EDID_CEA_YCRCB422   (1 << 4)
> @@ -3050,6 +3052,98 @@ static int add_3d_struct_modes(struct drm_connector 
> *connector, u16 structure,
>   return modes;
>   }
>   
> +static int add_420_mode(struct drm_connector *connector, u8 vic)
> +{
> + struct drm_device *dev = connector->dev;
> + struct drm_display_mode *newmode;
> +
> + if (!drm_valid_cea_vic(vic))
> + return 0;
> +
> + newmode = drm_mode_duplicate(dev, _cea_modes[vic]);
Sorry to start the review late, I missed this mail chain. It would be 
great if you can please keep me in CC for this chain.

Practically, YUV420 modes are being used for 4k and UHD video modes. Now 
here, when we want to
add these modes from edid_cea_db, using the VIC index, we should have 
full list of cea_modes from 1 - 107
Particularly 93-107 ( which is for new 38x21 and 40x21 modes, added in 
CEA-861-F). right now, edid_cea_modes
cant index 4k modes, so practically this this patch series will do 
nothing (even though its doing everything right)

To handle this scenario, I had added a patch series 
https://patchwork.freedesktop.org/patch/119627/
(complete the cea modedb (VIC=65 onwards)) Now, this patch series had 
dependency on new aspect ratios
being added in CEA-861-F which I tried to add in series 
(https://patchwork.freedesktop.org/patch/116095/)
Which was added and later reverted by Ville 
(https://patchwork.freedesktop.org/patch/119808/).

In short, the method/sequence for effective development would be:
- Add aspect ratio support in DRM
- Add HDMI 2.0 (CEA-861-F) aspect ratios 
(https://patchwork.freedesktop.org/patch/116095/)
- Complete edid_cea_modes, adding new modes as per 4k VICs 
(https://patchwork.freedesktop.org/patch/119627/ )
- Parse these modes from 420_vdb and 420_vcb using edid_cea_modes db[]  
(This patch series)

And that we should re-prioritize the aspect ratio handling to target YUV 
420 handling from CEA blocks.
Shashank
> + if (!newmode)
> + return 0;
> +
> + newmode->flags |= DRM_MODE_FLAG_420_ONLY;
> + drm_mode_probed_add(connector, newmode);
> +
> + return 1;
> +}
> +
> +static int add_420_vdb_modes(struct drm_connector *connector, const u8 *svds,
> + u8 svds_len)
> +{
> + int modes = 0, i;
> +
> + for (i = 0; i < svds_len; i++)
> + modes += add_420_mode(connector, svds[i]);
> +
> + return modes;
> +}
> +
> +static int add_420_vcb_modes(struct drm_connector *connector, const u8 *svds,
> + u8 svds_len, const u8 *video_db, u8 video_len)
> +{
> + struct drm_display_mode *newmode = NULL;
> + int modes = 0, i, j;
> +
> + for (i = 0; i < svds_len; i++) {
> + u8 mask = svds[i];
> + for (j = 0; j < 8; j++) {
> + if (mask & (1 << j)) {
> + newmode = drm_display_mode_from_vic_index(
> + connector, video_db, video_len,
> + i * 8 + j);
> + if (newmode) {
> + 

[Bug 192161] New: Amdgpu UVD init failures at boot

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

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

Bug ID: 192161
   Summary: Amdgpu UVD init failures at boot
   Product: Drivers
   Version: 2.5
Kernel Version: 4.10-rc2
  Hardware: x86-64
OS: Linux
  Tree: Mainline
Status: NEW
  Severity: blocking
  Priority: P1
 Component: Video(DRI - non Intel)
  Assignee: drivers_video-dri at kernel-bugs.osdl.org
  Reporter: fin4478 at hotmail.com
Regression: No

Created attachment 250851
  --> https://bugzilla.kernel.org/attachment.cgi?id=250851=edit
A8-7600 dmesg (full)

UVD init fails at boot and and X server starting stops. Terminal works but
rebooting is impossible because of lightdm has hanged. Hardware: Amd A8-7600
APU, Gigabyte F2A88XM-DS2 motherboard, single 4GB ddr3 2133Mhz ram stick. OS:
Debian testing Xfce. 

When using X4 845 and RX460 I have same UVD errors at boot, but X starts ok and
the computer works ok.

Adding _netdev to /etc/fstab home partition mount options helps to start X with
A8-7600 (errors still present at boot and shutdown) and with X4 845 and RX460
removes UVD errors completely. Setting #define AMD_MAX_USEC_TIMEOUT to 100 ms
is better value for A8-7600 than 200 ms because 100ms value enables X to start,
see drivers/gpu/drm/amd/include/amd_shared.h.

The same problem is with
agd5f/linux/log/drivers/gpu/drm/amd?h=drm-next-4.10-wip kernel that is in
4.9-rc8 now. When it it was in version 4.9-rc2 the driver did work fine in both
computers. With A8-7600 pc we need to use the stock Debian kernel 4.8 radeon
kernel driver now.

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

[PATCH v3 1/5] drm/dp: add connector backpointer to drm_dp_aux

[Tomeu Vizoso]

On 6 January 2017 at 16:56, Sean Paul  wrote:
> On Fri, Jan 6, 2017 at 9:30 AM, Tomeu Vizoso  
> wrote:
>> This backpointer allows DP helpers to access the connector it's being
>> used for.
>>
>> Signed-off-by: Tomeu Vizoso 
>> ---
>>
>>  include/drm/drm_dp_helper.h | 2 ++
>>  1 file changed, 2 insertions(+)
>>
>> diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
>> index 55bbeb0ff594..4fa77b434594 100644
>> --- a/include/drm/drm_dp_helper.h
>> +++ b/include/drm/drm_dp_helper.h
>> @@ -721,6 +721,7 @@ struct drm_dp_aux_msg {
>>   * @name: user-visible name of this AUX channel and the I2C-over-AUX adapter
>>   * @ddc: I2C adapter that can be used for I2C-over-AUX communication
>>   * @dev: pointer to struct device that is the parent for this AUX channel
>> + * @connector: backpointer to connector that uses this AUX channel
>>   * @hw_mutex: internal mutex used for locking transfers
>>   * @transfer: transfers a message representing a single AUX transaction
>>   *
>> @@ -757,6 +758,7 @@ struct drm_dp_aux {
>> const char *name;
>> struct i2c_adapter ddc;
>> struct device *dev;
>> +   struct drm_connector *connector;
>
> Perhaps I'm misreading the series, but it seems like you could instead
> add int crc_pipe along with the other crc fields. Then when you start
> the crc, set the pipe number. If you have the pipe in the crc worker,
> you can wait vblank on that pipe (no pointers needed).
>
> Reasonable?

I think that would work fine, but is it any better? I like that the
connector isn't going to change during the lifetime of the drm_dp_aux,
but crc_pipe could be changing between sampling sessions and any bugs
in keeping that field updated would be quite disconcerting and
cumbersome to debug.

crc_pipe's advantage is that we wouldn't need to update all callers of
drm_dp_aux_register, but I think it's better to have a connector field
that is mistakenly NULL, than a crc_pipe field with the wrong value.

Regards,

Tomeu

> Sean
>
>> struct mutex hw_mutex;
>> ssize_t (*transfer)(struct drm_dp_aux *aux,
>> struct drm_dp_aux_msg *msg);
>> --
>> 2.9.3
>>
>
>
>
> --
> Sean Paul, Software Engineer, Google / Chromium OS

[PULL] sti-drm-next-2017-01-06

[Dave Airlie]

On 7 January 2017 at 00:56, Vincent Abriou  wrote:
> Hi Dave,
>
> Here is an update of the STI drm driver.
> It contains file cleanup and various fixes.
>
> Regard,
> Vincent
>
> The following changes since commit 2cf026ae85c42f253feb9f420d1b4bc99bd5503d:
>
>   Merge branch 'linux-4.10' of git://github.com/skeggsb/linux into drm-next 
> (2016-12-13 14:29:05 +1000)
>
> are available in the git repository at:
>
>   https://github.com/vinceab/linux.git 
> 1ae0d5af347df224a6e76334683f13a96d915a44

Hi Vincent,

please use a tag (signed preferable) rather than a straight commit id.

Dave.