[Bug 97524] Invalid sampler settings cause full GPU reset

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

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

--- Comment #9 from Matias N. Goldberg  ---
Oh I see what's happening.

That's my fault.

The paths to the shader files were hardcoded as absolute paths.

Look for:
readFile( "/home/matias/Projects/MesaRing0Bug/src/VertexShader_vs.glsl", data,
FILE_BUF );

and:
readFile( "/home/matias/Projects/MesaRing0Bug/src/PixelShader_ps.glsl", data,
FILE_BUF );

Change the hardcoded paths, and try again. Sorry about that.

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

[PATCH 8/8] drm/rockchip: Kill vop_plane_state

[Tomasz Figa]

After changes introduced by last patches, there is no useful data stored
in vop_plane_state struct.  Let's remove it and make the driver use
generic plane state alone.

Signed-off-by: Tomasz Figa 
---
 drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 94 +
 1 file changed, 15 insertions(+), 79 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c 
b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
index cacdffb..57650c9 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
@@ -88,19 +88,11 @@

 #define to_vop(x) container_of(x, struct vop, crtc)
 #define to_vop_win(x) container_of(x, struct vop_win, base)
-#define to_vop_plane_state(x) container_of(x, struct vop_plane_state, base)

 enum vop_pending {
VOP_PENDING_FB_UNREF,
 };

-struct vop_plane_state {
-   struct drm_plane_state base;
-   int format;
-   dma_addr_t yrgb_mst;
-   bool enable;
-};
-
 struct vop_win {
struct drm_plane base;
const struct vop_win_data *data;
@@ -651,7 +643,6 @@ static int vop_plane_atomic_check(struct drm_plane *plane,
struct drm_crtc_state *crtc_state;
struct drm_framebuffer *fb = state->fb;
struct vop_win *vop_win = to_vop_win(plane);
-   struct vop_plane_state *vop_plane_state = to_vop_plane_state(state);
const struct vop_win_data *win = vop_win->data;
int ret;
struct drm_rect clip;
@@ -661,7 +652,7 @@ static int vop_plane_atomic_check(struct drm_plane *plane,
DRM_PLANE_HELPER_NO_SCALING;

if (!crtc || !fb)
-   goto out_disable;
+   return 0;

crtc_state = drm_atomic_get_existing_crtc_state(state->state, crtc);
if (WARN_ON(!crtc_state))
@@ -679,11 +670,11 @@ static int vop_plane_atomic_check(struct drm_plane *plane,
return ret;

if (!state->visible)
-   goto out_disable;
+   return 0;

-   vop_plane_state->format = vop_convert_format(fb->pixel_format);
-   if (vop_plane_state->format < 0)
-   return vop_plane_state->format;
+   ret = vop_convert_format(fb->pixel_format);
+   if (ret < 0)
+   return ret;

/*
 * Src.x1 can be odd when do clip, but yuv plane start point
@@ -692,19 +683,12 @@ static int vop_plane_atomic_check(struct drm_plane *plane,
if (is_yuv_support(fb->pixel_format) && ((state->src.x1 >> 16) % 2))
return -EINVAL;

-   vop_plane_state->enable = true;
-
-   return 0;
-
-out_disable:
-   vop_plane_state->enable = false;
return 0;
 }

 static void vop_plane_atomic_disable(struct drm_plane *plane,
 struct drm_plane_state *old_state)
 {
-   struct vop_plane_state *vop_plane_state = to_vop_plane_state(old_state);
struct vop_win *vop_win = to_vop_win(plane);
const struct vop_win_data *win = vop_win->data;
struct vop *vop = to_vop(old_state->crtc);
@@ -717,8 +701,6 @@ static void vop_plane_atomic_disable(struct drm_plane 
*plane,
VOP_WIN_SET(vop, win, enable, 0);

spin_unlock(>reg_lock);
-
-   vop_plane_state->enable = false;
 }

 static void vop_plane_atomic_update(struct drm_plane *plane,
@@ -727,7 +709,6 @@ static void vop_plane_atomic_update(struct drm_plane *plane,
struct drm_plane_state *state = plane->state;
struct drm_crtc *crtc = state->crtc;
struct vop_win *vop_win = to_vop_win(plane);
-   struct vop_plane_state *vop_plane_state = to_vop_plane_state(state);
const struct vop_win_data *win = vop_win->data;
struct vop *vop = to_vop(state->crtc);
struct drm_framebuffer *fb = state->fb;
@@ -742,6 +723,7 @@ static void vop_plane_atomic_update(struct drm_plane *plane,
dma_addr_t dma_addr;
uint32_t val;
bool rb_swap;
+   int format;

/*
 * can't update plane when vop is disabled.
@@ -752,7 +734,7 @@ static void vop_plane_atomic_update(struct drm_plane *plane,
if (WARN_ON(!vop->is_enabled))
return;

-   if (!vop_plane_state->enable) {
+   if (!state->visible) {
vop_plane_atomic_disable(plane, old_state);
return;
}
@@ -773,13 +755,15 @@ static void vop_plane_atomic_update(struct drm_plane 
*plane,

offset = (src->x1 >> 16) * drm_format_plane_cpp(fb->pixel_format, 0);
offset += (src->y1 >> 16) * fb->pitches[0];
-   vop_plane_state->yrgb_mst = rk_obj->dma_addr + offset + fb->offsets[0];
+   dma_addr = rk_obj->dma_addr + offset + fb->offsets[0];
+
+   format = vop_convert_format(fb->pixel_format);

spin_lock(>reg_lock);

-   VOP_WIN_SET(vop, win, format, vop_plane_state->format);
+   VOP_WIN_SET(vop, win, format, format);
VOP_WIN_SET(vop, win, yrgb_vir, fb->pitches[0] >> 2);
-   VOP_WIN_SET(vop, win, 

[PATCH 7/8] drm/rockchip: Always signal event in next vblank after cfg_done

[Tomasz Figa]

This patch makes the driver send the pending vblank event in next vblank
following the commit, relying on vblank signalling improvements done in
previous patches. This gives us vblank events that always represent the
real moment of changes hitting on the screen (which was the case only
for complete FB changes before) and lets us remove the manual window
update check.

Signed-off-by: Tomasz Figa 
---
 drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 54 ++---
 1 file changed, 10 insertions(+), 44 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c 
b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
index bb7a865..cacdffb 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
@@ -105,10 +105,6 @@ struct vop_win {
struct drm_plane base;
const struct vop_win_data *data;
struct vop *vop;
-
-   /* protected by dev->event_lock */
-   bool enable;
-   dma_addr_t yrgb_mst;
 };

 struct vop {
@@ -716,11 +712,6 @@ static void vop_plane_atomic_disable(struct drm_plane 
*plane,
if (!old_state->crtc)
return;

-   spin_lock_irq(>dev->event_lock);
-   vop_win->enable = false;
-   vop_win->yrgb_mst = 0;
-   spin_unlock_irq(>dev->event_lock);
-
spin_lock(>reg_lock);

VOP_WIN_SET(vop, win, enable, 0);
@@ -784,11 +775,6 @@ static void vop_plane_atomic_update(struct drm_plane 
*plane,
offset += (src->y1 >> 16) * fb->pitches[0];
vop_plane_state->yrgb_mst = rk_obj->dma_addr + offset + fb->offsets[0];

-   spin_lock_irq(>dev->event_lock);
-   vop_win->enable = true;
-   vop_win->yrgb_mst = vop_plane_state->yrgb_mst;
-   spin_unlock_irq(>dev->event_lock);
-
spin_lock(>reg_lock);

VOP_WIN_SET(vop, win, format, vop_plane_state->format);
@@ -1112,6 +1098,16 @@ static void vop_crtc_atomic_flush(struct drm_crtc *crtc,
 */
vop_wait_for_irq_handler(vop);

+   spin_lock_irq(>dev->event_lock);
+   if (crtc->state->event) {
+   WARN_ON(drm_crtc_vblank_get(crtc) != 0);
+   WARN_ON(vop->event);
+
+   vop->event = crtc->state->event;
+   crtc->state->event = NULL;
+   }
+   spin_unlock_irq(>dev->event_lock);
+
for_each_plane_in_state(old_state, plane, old_plane_state, i) {
if (!old_plane_state->fb)
continue;
@@ -1129,19 +1125,7 @@ static void vop_crtc_atomic_flush(struct drm_crtc *crtc,
 static void vop_crtc_atomic_begin(struct drm_crtc *crtc,
  struct drm_crtc_state *old_crtc_state)
 {
-   struct vop *vop = to_vop(crtc);
-
rockchip_drm_psr_flush(crtc);
-
-   spin_lock_irq(>dev->event_lock);
-   if (crtc->state->event) {
-   WARN_ON(drm_crtc_vblank_get(crtc) != 0);
-   WARN_ON(vop->event);
-
-   vop->event = crtc->state->event;
-   crtc->state->event = NULL;
-   }
-   spin_unlock_irq(>dev->event_lock);
 }

 static const struct drm_crtc_helper_funcs vop_crtc_helper_funcs = {
@@ -1207,29 +1191,11 @@ static void vop_fb_unref_worker(struct drm_flip_work 
*work, void *val)
drm_framebuffer_unreference(fb);
 }

-static bool vop_win_pending_is_complete(struct vop_win *vop_win)
-{
-   dma_addr_t yrgb_mst;
-
-   if (!vop_win->enable)
-   return VOP_WIN_GET(vop_win->vop, vop_win->data, enable) == 0;
-
-   yrgb_mst = VOP_WIN_GET_YRGBADDR(vop_win->vop, vop_win->data);
-
-   return yrgb_mst == vop_win->yrgb_mst;
-}
-
 static void vop_handle_vblank(struct vop *vop)
 {
struct drm_device *drm = vop->drm_dev;
struct drm_crtc *crtc = >crtc;
unsigned long flags;
-   int i;
-
-   for (i = 0; i < vop->data->win_size; i++) {
-   if (!vop_win_pending_is_complete(>win[i]))
-   return;
-   }

spin_lock_irqsave(>event_lock, flags);
if (vop->event) {
-- 
2.8.0.rc3.226.g39d4020

[PATCH 6/8] drm/rockchip: Do not enable vblank without event

[Tomasz Figa]

Originally we needed to enable vblank for any atomic commit to kick the
PSR machine, but that was changed and we no longer need to do so from
a vblank interrupt. Let's return to original behavior of enabling
vblank only if it is really necessary.

This essentially reverts commit 5b6804034ae9 ("drm/rockchip: Enable
vblank without event").

Signed-off-by: Tomasz Figa 
---
 drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 15 ---
 1 file changed, 4 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c 
b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
index af9ddbe..bb7a865 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
@@ -116,7 +116,6 @@ struct vop {
struct device *dev;
struct drm_device *drm_dev;
bool is_enabled;
-   bool vblank_active;

/* mutex vsync_ work */
struct mutex vsync_mutex;
@@ -1135,11 +1134,10 @@ static void vop_crtc_atomic_begin(struct drm_crtc *crtc,
rockchip_drm_psr_flush(crtc);

spin_lock_irq(>dev->event_lock);
-   vop->vblank_active = true;
-   WARN_ON(drm_crtc_vblank_get(crtc) != 0);
-   WARN_ON(vop->event);
-
if (crtc->state->event) {
+   WARN_ON(drm_crtc_vblank_get(crtc) != 0);
+   WARN_ON(vop->event);
+
vop->event = crtc->state->event;
crtc->state->event = NULL;
}
@@ -1236,12 +1234,8 @@ static void vop_handle_vblank(struct vop *vop)
spin_lock_irqsave(>event_lock, flags);
if (vop->event) {
drm_crtc_send_vblank_event(crtc, vop->event);
-   vop->event = NULL;
-
-   }
-   if (vop->vblank_active) {
-   vop->vblank_active = false;
drm_crtc_vblank_put(crtc);
+   vop->event = NULL;
}
spin_unlock_irqrestore(>event_lock, flags);

@@ -1518,7 +1512,6 @@ static int vop_initial(struct vop *vop)
clk_disable(vop->aclk);

vop->is_enabled = false;
-   vop->vblank_active = false;

return 0;

-- 
2.8.0.rc3.226.g39d4020

[PATCH 5/8] drm/rockchip: Replace custom wait_for_vblanks with helper

[Tomasz Figa]

Currently the driver uses a custom function to wait for flip to complete
after an atomic commit. It was needed before because of two problems:
 - there is no hardware vblank counter, so the original helper would
   have a race condition with the vblank interrupt,
 - the driver didn't support unreferencing cursor framebuffers
   asynchronously to the commit, which was what the helper expected.
Since both problems have been solved by previous patches, we can now
make the driver use the generic helper and remove custom waiting code.

Signed-off-by: Tomasz Figa 
---
 drivers/gpu/drm/rockchip/rockchip_drm_drv.h |  1 -
 drivers/gpu/drm/rockchip/rockchip_drm_fb.c  | 64 +
 drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 14 ---
 3 files changed, 1 insertion(+), 78 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_drv.h 
b/drivers/gpu/drm/rockchip/rockchip_drm_drv.h
index 5c69845..fb6226c 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_drv.h
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_drv.h
@@ -39,7 +39,6 @@ struct drm_connector;
 struct rockchip_crtc_funcs {
int (*enable_vblank)(struct drm_crtc *crtc);
void (*disable_vblank)(struct drm_crtc *crtc);
-   void (*wait_for_update)(struct drm_crtc *crtc);
 };

 struct rockchip_crtc_state {
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_fb.c 
b/drivers/gpu/drm/rockchip/rockchip_drm_fb.c
index 9890ecc..0f6eda0 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_fb.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_fb.c
@@ -174,68 +174,6 @@ static void rockchip_drm_output_poll_changed(struct 
drm_device *dev)
drm_fb_helper_hotplug_event(fb_helper);
 }

-static void rockchip_crtc_wait_for_update(struct drm_crtc *crtc)
-{
-   struct rockchip_drm_private *priv = crtc->dev->dev_private;
-   int pipe = drm_crtc_index(crtc);
-   const struct rockchip_crtc_funcs *crtc_funcs = priv->crtc_funcs[pipe];
-
-   if (crtc_funcs && crtc_funcs->wait_for_update)
-   crtc_funcs->wait_for_update(crtc);
-}
-
-/*
- * We can't use drm_atomic_helper_wait_for_vblanks() because rk3288 and rk3066
- * have hardware counters for neither vblanks nor scanlines, which results in
- * a race where:
- * | <-- HW vsync irq and reg take effect
- *plane_commit --> |
- * get_vblank and wait --> |
- * | <-- handle_vblank, vblank->count + 1
- *  cleanup_fb --> |
- * iommu crash --> |
- * | <-- HW vsync irq and reg take effect
- *
- * This function is equivalent but uses rockchip_crtc_wait_for_update() instead
- * of waiting for vblank_count to change.
- */
-static void
-rockchip_atomic_wait_for_complete(struct drm_device *dev, struct 
drm_atomic_state *old_state)
-{
-   struct drm_crtc_state *old_crtc_state;
-   struct drm_crtc *crtc;
-   int i, ret;
-
-   for_each_crtc_in_state(old_state, crtc, old_crtc_state, i) {
-   /* No one cares about the old state, so abuse it for tracking
-* and store whether we hold a vblank reference (and should do a
-* vblank wait) in the ->enable boolean.
-*/
-   old_crtc_state->enable = false;
-
-   if (!crtc->state->active)
-   continue;
-
-   if (!drm_atomic_helper_framebuffer_changed(dev,
-   old_state, crtc))
-   continue;
-
-   ret = drm_crtc_vblank_get(crtc);
-   if (ret != 0)
-   continue;
-
-   old_crtc_state->enable = true;
-   }
-
-   for_each_crtc_in_state(old_state, crtc, old_crtc_state, i) {
-   if (!old_crtc_state->enable)
-   continue;
-
-   rockchip_crtc_wait_for_update(crtc);
-   drm_crtc_vblank_put(crtc);
-   }
-}
-
 static void
 rockchip_atomic_commit_tail(struct drm_atomic_state *state)
 {
@@ -250,7 +188,7 @@ rockchip_atomic_commit_tail(struct drm_atomic_state *state)

drm_atomic_helper_commit_hw_done(state);

-   rockchip_atomic_wait_for_complete(dev, state);
+   drm_atomic_helper_wait_for_vblanks(dev, state);

drm_atomic_helper_cleanup_planes(dev, state);
 }
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c 
b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
index 86829f5..af9ddbe 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
@@ -122,7 +122,6 @@ struct vop {
struct mutex vsync_mutex;
bool vsync_work_pending;
struct completion dsp_hold_completion;
-   struct completion wait_update_complete;

/* protected by dev->event_lock */
struct drm_pending_vblank_event *event;
@@ -937,18 +936,9 @@ static void vop_crtc_disable_vblank(struct drm_crtc *crtc)
spin_unlock_irqrestore(>irq_lock, flags);
 }

-static 

[PATCH 4/8] drm/rockchip: Unreference framebuffers from flip work

[Tomasz Figa]

Currently the driver waits for vblank and then unreferences old
framebuffers from atomic commit code path. This is however breaking the
legacy cursor API, which requires the updates to be fully asynchronous.
Instead of just adding a special case for cursor, we can have actually
smaller amount of code to unreference any changed framebuffer from a
flip work.

Signed-off-by: Tomasz Figa 
---
 drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 41 +
 1 file changed, 41 insertions(+)

diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c 
b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
index f989440..86829f5 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
@@ -17,6 +17,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 

 #include 
@@ -89,6 +90,10 @@
 #define to_vop_win(x) container_of(x, struct vop_win, base)
 #define to_vop_plane_state(x) container_of(x, struct vop_plane_state, base)

+enum vop_pending {
+   VOP_PENDING_FB_UNREF,
+};
+
 struct vop_plane_state {
struct drm_plane_state base;
int format;
@@ -122,6 +127,9 @@ struct vop {
/* protected by dev->event_lock */
struct drm_pending_vblank_event *event;

+   struct drm_flip_work fb_unref_work;
+   unsigned long pending;
+
struct completion line_flag_completion;

const struct vop_data *data;
@@ -1093,7 +1101,11 @@ static void vop_wait_for_irq_handler(struct vop *vop)
 static void vop_crtc_atomic_flush(struct drm_crtc *crtc,
  struct drm_crtc_state *old_crtc_state)
 {
+   struct drm_atomic_state *old_state = old_crtc_state->state;
+   struct drm_plane_state *old_plane_state;
struct vop *vop = to_vop(crtc);
+   struct drm_plane *plane;
+   int i;

if (WARN_ON(!vop->is_enabled))
return;
@@ -1110,6 +1122,19 @@ static void vop_crtc_atomic_flush(struct drm_crtc *crtc,
 * signalling flip completion we need to wait for it to finish.
 */
vop_wait_for_irq_handler(vop);
+
+   for_each_plane_in_state(old_state, plane, old_plane_state, i) {
+   if (!old_plane_state->fb)
+   continue;
+
+   if (old_plane_state->fb == plane->state->fb)
+   continue;
+
+   drm_framebuffer_reference(old_plane_state->fb);
+   drm_flip_work_queue(>fb_unref_work, old_plane_state->fb);
+   set_bit(VOP_PENDING_FB_UNREF, >pending);
+   WARN_ON(drm_crtc_vblank_get(crtc) != 0);
+   }
 }

 static void vop_crtc_atomic_begin(struct drm_crtc *crtc,
@@ -1185,6 +1210,15 @@ static const struct drm_crtc_funcs vop_crtc_funcs = {
.atomic_destroy_state = vop_crtc_destroy_state,
 };

+static void vop_fb_unref_worker(struct drm_flip_work *work, void *val)
+{
+   struct vop *vop = container_of(work, struct vop, fb_unref_work);
+   struct drm_framebuffer *fb = val;
+
+   drm_crtc_vblank_put(>crtc);
+   drm_framebuffer_unreference(fb);
+}
+
 static bool vop_win_pending_is_complete(struct vop_win *vop_win)
 {
dma_addr_t yrgb_mst;
@@ -1223,6 +1257,9 @@ static void vop_handle_vblank(struct vop *vop)

if (!completion_done(>wait_update_complete))
complete(>wait_update_complete);
+
+   if (test_and_clear_bit(VOP_PENDING_FB_UNREF, >pending))
+   drm_flip_work_commit(>fb_unref_work, system_unbound_wq);
 }

 static irqreturn_t vop_isr(int irq, void *data)
@@ -1361,6 +1398,9 @@ static int vop_create_crtc(struct vop *vop)
goto err_cleanup_crtc;
}

+   drm_flip_work_init(>fb_unref_work, "fb_unref",
+  vop_fb_unref_worker);
+
init_completion(>dsp_hold_completion);
init_completion(>wait_update_complete);
init_completion(>line_flag_completion);
@@ -1404,6 +1444,7 @@ static void vop_destroy_crtc(struct vop *vop)
 * references the CRTC.
 */
drm_crtc_cleanup(crtc);
+   drm_flip_work_cleanup(>fb_unref_work);
 }

 static int vop_initial(struct vop *vop)
-- 
2.8.0.rc3.226.g39d4020

[PATCH 3/8] drm/rockchip: Avoid race with vblank count increment

[Tomasz Figa]

Since VOP does not have a hardware vblank count register, the ongoing
commit might be racing with a requested vblank interrupt, which would
increment the software vblank counter before the changes being committed
actually happen.

To avoid this, we can extend .atomic_flush(), so after it sets cfg_done
bit, it polls the vblank interrupt bit until it's inactive to make sure
that any old vblank interrupt gets to the handler and then uses
synchronize_irq(vop->irq) to make sure the handler finishes running.

The polling case should happen very rarely, but even if, the total wait
time should be relatively low and in practice almost equal to the vop
hardirq handler running time.

Signed-off-by: Tomasz Figa 
---
 drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 34 +
 1 file changed, 34 insertions(+)

diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c 
b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
index 68988c6..f989440 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
@@ -23,6 +23,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -1063,6 +1064,32 @@ static void vop_crtc_enable(struct drm_crtc *crtc)
rockchip_drm_psr_activate(>crtc);
 }

+static bool vop_fs_irq_is_pending(struct vop *vop)
+{
+   return VOP_INTR_GET_TYPE(vop, status, FS_INTR);
+}
+
+static void vop_wait_for_irq_handler(struct vop *vop)
+{
+   bool pending;
+   int ret;
+
+   /*
+* Spin until frame start interrupt status bit goes low, which means
+* that interrupt handler was invoked and cleared it. The timeout of
+* 10 msecs is really too long, but it is just a safety measure if
+* something goes really wrong. The wait will only happen in the very
+* unlikely case of a vblank happening exactly at the same time and
+* shouldn't exceed microseconds range.
+*/
+   ret = readx_poll_timeout_atomic(vop_fs_irq_is_pending, vop, pending,
+   !pending, 0, 10 * 1000);
+   if (ret)
+   DRM_DEV_ERROR(vop->dev, "VOP vblank IRQ stuck for 10 ms\n");
+
+   synchronize_irq(vop->irq);
+}
+
 static void vop_crtc_atomic_flush(struct drm_crtc *crtc,
  struct drm_crtc_state *old_crtc_state)
 {
@@ -1076,6 +1103,13 @@ static void vop_crtc_atomic_flush(struct drm_crtc *crtc,
vop_cfg_done(vop);

spin_unlock(>reg_lock);
+
+   /*
+* There is a (rather unlikely) possiblity that a vblank interrupt
+* fired before we set the cfg_done bit. To avoid spuriously
+* signalling flip completion we need to wait for it to finish.
+*/
+   vop_wait_for_irq_handler(vop);
 }

 static void vop_crtc_atomic_begin(struct drm_crtc *crtc,
-- 
2.8.0.rc3.226.g39d4020

[PATCH 2/8] drm/rockchip: Get rid of some unnecessary code

[Tomasz Figa]

Current code implements prepare_fb and cleanup_fb callbacks only to
grab/release fb references, which is already done by atomic framework
when creating/destryoing plane state. Let's remove these
unused bits.

Signed-off-by: Tomasz Figa 
---
 drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 18 --
 1 file changed, 18 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c 
b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
index 7e811cf..68988c6 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
@@ -641,22 +641,6 @@ static void vop_plane_destroy(struct drm_plane *plane)
drm_plane_cleanup(plane);
 }

-static int vop_plane_prepare_fb(struct drm_plane *plane,
-   struct drm_plane_state *new_state)
-{
-   if (plane->state->fb)
-   drm_framebuffer_reference(plane->state->fb);
-
-   return 0;
-}
-
-static void vop_plane_cleanup_fb(struct drm_plane *plane,
-struct drm_plane_state *old_state)
-{
-   if (old_state->fb)
-   drm_framebuffer_unreference(old_state->fb);
-}
-
 static int vop_plane_atomic_check(struct drm_plane *plane,
   struct drm_plane_state *state)
 {
@@ -849,8 +833,6 @@ static void vop_plane_atomic_update(struct drm_plane *plane,
 }

 static const struct drm_plane_helper_funcs plane_helper_funcs = {
-   .prepare_fb = vop_plane_prepare_fb,
-   .cleanup_fb = vop_plane_cleanup_fb,
.atomic_check = vop_plane_atomic_check,
.atomic_update = vop_plane_atomic_update,
.atomic_disable = vop_plane_atomic_disable,
-- 
2.8.0.rc3.226.g39d4020

[PATCH 1/8] drm/rockchip: Clear interrupt status bits before enabling

[Tomasz Figa]

The enable register only masks the raw status bits to signal CPU
interrupt only for enabled interrupts. The status bits are activated
regardless of the enable register. This means that we might have an old
interrupt event queued, which we are not interested in. To avoid getting
a spurious interrupt signalled, we have to clear the old bit before we
update the enable register.

Signed-off-by: Tomasz Figa 
---
 drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c 
b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
index 209167b..7e811cf 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
@@ -414,6 +414,7 @@ static void vop_dsp_hold_valid_irq_enable(struct vop *vop)

spin_lock_irqsave(>irq_lock, flags);

+   VOP_INTR_SET_TYPE(vop, clear, DSP_HOLD_VALID_INTR, 1);
VOP_INTR_SET_TYPE(vop, enable, DSP_HOLD_VALID_INTR, 1);

spin_unlock_irqrestore(>irq_lock, flags);
@@ -479,6 +480,7 @@ static void vop_line_flag_irq_enable(struct vop *vop, int 
line_num)
spin_lock_irqsave(>irq_lock, flags);

VOP_CTRL_SET(vop, line_flag_num[0], line_num);
+   VOP_INTR_SET_TYPE(vop, clear, LINE_FLAG_INTR, 1);
VOP_INTR_SET_TYPE(vop, enable, LINE_FLAG_INTR, 1);

spin_unlock_irqrestore(>irq_lock, flags);
@@ -921,6 +923,7 @@ static int vop_crtc_enable_vblank(struct drm_crtc *crtc)

spin_lock_irqsave(>irq_lock, flags);

+   VOP_INTR_SET_TYPE(vop, clear, FS_INTR, 1);
VOP_INTR_SET_TYPE(vop, enable, FS_INTR, 1);

spin_unlock_irqrestore(>irq_lock, flags);
-- 
2.8.0.rc3.226.g39d4020

[PATCH 0/8] drm/rockchip: Flip wait clean-up

[Tomasz Figa]

The display controller found on Rockchip SoCs supported by Rockchip DRM
driver (VOP) is a bit problematic, because it does not provide hardware
vblank counter. Because vblank interrupt is used to feed the software
counter, the driver had custom code to wait for flip completion to avoid
race between atomic flush and vblank interrupt handler.

This, however, brought a different set of issues. In fact, even with the
custom wait code, there is stil a race between the handler and driver
state update (of the values used to compare with registers to determine
if flip has completed). On top of that, legacy cursor updates are not
implemented properly and have to wait for vblank to complete, which
is against the API specification.

This series attempts to clean up the driver from this custom waiting code,
eliminating related races and bringing correct handling of legacy cursor
plane. It also gives a nice effect of more than 100 lines of code removed.

This is a forward port of patches from 4.4 kernel used by ChromiumOS and
tested there. Even though the code base has not changed significantly, it
would be nice if someone with proper testing environment could give them
a try.

Based on for-next branch of Sean Paul's dogwood tree:
https://cgit.freedesktop.org/~seanpaul/dogwood/log/?h=for-next
git://people.freedesktop.org/~seanpaul/dogwood

Tomasz Figa (8):
  drm/rockchip: Clear interrupt status bits before enabling
  drm/rockchip: Get rid of some unnecessary code
  drm/rockchip: Avoid race with vblank count increment
  drm/rockchip: Unreference framebuffers from flip work
  drm/rockchip: Replace custom wait_for_vblanks with helper
  drm/rockchip: Do not enable vblank without event
  drm/rockchip: Always signal event in next vblank after cfg_done
  drm/rockchip: Kill vop_plane_state

 drivers/gpu/drm/rockchip/rockchip_drm_drv.h |   1 -
 drivers/gpu/drm/rockchip/rockchip_drm_fb.c  |  64 +--
 drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 247 +++-
 3 files changed, 95 insertions(+), 217 deletions(-)

-- 
2.8.0.rc3.226.g39d4020

[PATCH v6] drm: bridge/dw_hdmi: add dw hdmi i2c bus adapter support

[Vladimir Zapolskiy]

Hi Philipp,

On 08/29/2016 06:50 PM, Rob Herring wrote:
> On Wed, Aug 24, 2016 at 08:46:37AM +0300, Vladimir Zapolskiy wrote:
>> The change adds support of internal HDMI I2C master controller, this
>> subdevice is used by default, if "ddc-i2c-bus" DT property is omitted.
>>
>> The main purpose of this functionality is to support reading EDID from
>> an HDMI monitor on boards, which don't have an I2C bus connected to
>> DDC pins.
>>
>> The current implementation does not support "I2C Master Interface
>> Extended Read Mode" to read data addressed by non-zero segment
>> pointer, this means that if EDID has more than 1 extension blocks,
>> EDID reading operation won't succeed, in my practice all tested HDMI
>> monitors have at maximum one extension block.
>>
>> Signed-off-by: Vladimir Zapolskiy 
>> ---
>> The change is based on top of v4.8.0-rc1 and a fix in DW HDMI driver
>> https://patchwork.kernel.org/patch/9284717/
>>
>> Changes from v5 to v6:
>> * rebased on top of v4.8.0-rc1
>> * fixed one improper resource deallocation on error path of dw_hdmi_bind()
>> * added a comment describing a mutex asked by checkpatch.pl --strict
>>
>> Link to version v5: https://patchwork.kernel.org/patch/7279831/
>>
>> Changes from v4 to v5:
>> * do I2C bus controller initialization only once in bind() as it was done
>>   in v1-v3 of the change.
>>
>> Changes from v3 to v4, thanks to Doug and Philipp for review:
>> * set speed mode after software reset in dw_hdmi_i2c_init()
>> * by default set standard speed mode instead of fast speed mode, on iMX6Q
>>   this configures SCL to 100 KHz, which is compliant with HDMI 1.3a spec
>> * do I2C bus controller reinitialization on every data transfer,
>>   this change hopefully solves some observed problems on RK3288 platform
>> * added short functional change description to dw_hdmi.txt
>>
>> v3 of the change was
>>
>>   Tested-by: Philipp Zabel 
>>
>> Changes from v2 to v3, thanks to Russell:
>> * moved register field value definitions to dw_hdmi.h
>> * made completions uninterruptible to avoid transfer retries if interrupted
>> * use one completion for both read and write transfers as in v1,
>>   operation_reg is removed
>> * redundant i2c->stat = 0 is removed from dw_hdmi_i2c_read/write()
>> * struct i2c_algorithm dw_hdmi_algorithm is qualified as const
>> * dw_hdmi_i2c_adapter() does not modify struct dw_hdmi on error path
>> * dw_hdmi_i2c_irq() does not modify hdmi->i2c->stat, if interrupt is
>>   not for I2CM
>> * spin lock is removed from dw_hdmi_i2c_irq()
>> * removed spin lock from dw_hdmi_i2c_xfer() around write to
>>   HDMI_IH_MUTE_I2CM_STAT0 register
>> * split loop over message array in dw_hdmi_i2c_xfer() to validation
>>   and transfer parts
>> * added a mutex to serialize I2C transfer requests, i2c->lock is
>>   completely removed
>> * removed if(len) check from dw_hdmi_i2c_write(), hardware supports
>>   only len>0 transfers
>> * described extension blocks <= 1 limitation in the commit message
>> * a number of minor clean ups
>>
>> Changes from v1 to v2:
>> * fixed a devm_kfree() signature
>> * split completions for read and write operations
>>
>>  .../devicetree/bindings/display/bridge/dw_hdmi.txt |   4 +-
>
> Acked-by: Rob Herring 
>
>>  drivers/gpu/drm/bridge/dw-hdmi.c   | 265 
>> -
>>  drivers/gpu/drm/bridge/dw-hdmi.h   |  19 ++
>>  3 files changed, 281 insertions(+), 7 deletions(-)

as far as I know David accepts pull requests from you, can you please
create and send a pull request for v4.9 containing these changes?

https://patchwork.kernel.org/patch/9284717/ -- with Russell's ack
https://patchwork.kernel.org/patch/9296883/ -- with Rob's ack and yours 
tested-by

Some users anticipate this change, for example see 
https://lkml.org/lkml/2016/9/14/55

--
With best wishes,
Vladimir

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

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

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

--- Comment #4 from Laurent carlier  ---
(In reply to Nicolai Hähnle from comment #2)
> LLVM 3.8 is already fairly old for graphics stack standards. Can you try
> with current trunk?

No GPU lockup with llvm-3.9.0/mesa-git

-- 
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/20160914/b7847965/attachment.html>

[PATCH] drm/vc4: Fall back to using an EDID probe in the absence of a GPIO.

[Eric Anholt]

On Pi0/1/2, we use an external GPIO line for hotplug detection, since
the HDMI_HOTPLUG register isn't connected to anything.  However, with
the Pi3 the HPD GPIO line has moved off to a GPIO expander that will
be tricky to get to (the firmware is constantly polling the expander
using i2c0, so we'll need to coordinate with it).

As a stop-gap, if we don't have a GPIO line, use an EDID probe to
detect connection.  Fixes HDMI display on the pi3.

Signed-off-by: Eric Anholt 
---
 drivers/gpu/drm/vc4/vc4_hdmi.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c b/drivers/gpu/drm/vc4/vc4_hdmi.c
index 68ad10634b29..9f85a579da74 100644
--- a/drivers/gpu/drm/vc4/vc4_hdmi.c
+++ b/drivers/gpu/drm/vc4/vc4_hdmi.c
@@ -174,6 +174,9 @@ vc4_hdmi_connector_detect(struct drm_connector *connector, 
bool force)
return connector_status_disconnected;
}

+   if (drm_probe_ddc(vc4->hdmi->ddc))
+   return connector_status_connected;
+
if (HDMI_READ(VC4_HDMI_HOTPLUG) & VC4_HDMI_HOTPLUG_CONNECTED)
return connector_status_connected;
else
-- 
2.9.3

[PATCH] dma-buf/sync_file: Always increment refcount when merging fences.

[Chris Wilson]

On Wed, Sep 14, 2016 at 11:04:01AM -0300, Gustavo Padovan wrote:
> 2016-09-14 Chris Wilson :
> > I think there still seems to be a memory leak when calling
> > sync_file_set_fence() here with i == 1.
> 
> I think that is something we discussed already, we don't hold an extra
> ref there for i == 1 because it would leak the fence.

That's fine. I'm worried about the array we kmalloc here but
sync_file->fence = fences[0]. Where does the array go?

I *think* we need a if (i == 1) kfree(fences);
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre

[PATCH v4 3/4] gpu: ipu-ic: Add complete image conversion support with tiling

[Steve Longerbeam]

Hi Philipp,


On 09/06/2016 02:26 AM, Philipp Zabel wrote:
> Hi Steve,
>
> Am Mittwoch, den 17.08.2016, 17:50 -0700 schrieb Steve Longerbeam:
>> This patch implements complete image conversion support to ipu-ic,
>> with tiling to support scaling to and from images up to 4096x4096.
>> Image rotation is also supported.
>>
>> The internal API is subsystem agnostic (no V4L2 dependency except
>> for the use of V4L2 fourcc pixel formats).
>>
>> Callers prepare for image conversion by calling
>> ipu_image_convert_prepare(), which initializes the parameters of
>> the conversion.
> ... and possibly allocates intermediate buffers for rotation support.
> This should be documented somewhere, with a node that v4l2 users should
> be doing this during REQBUFS.

I added comment headers for all the image conversion prototypes.
It caused bloat in imx-ipu-v3.h, so I moved it to a new header:
include/video/imx-image-convert.h, but let me know if we should put
this somewhere else and/or under Documentation/ somewhere.


>>   The caller passes in the ipu_ic task to use for
>> the conversion, the input and output image formats, a rotation mode,
>> and a completion callback and completion context pointer:
>>
>> struct image_converter_ctx *
>> ipu_image_convert_prepare(struct ipu_ic *ic,
>>struct ipu_image *in, struct ipu_image *out,
>>enum ipu_rotate_mode rot_mode,
>>image_converter_cb_t complete,
>>void *complete_context);
> As I commented on the other patch, I think the image_convert functions
> should use a separate handle for the image conversion queues that sit on
> top of the ipu_ic task handles.

Here is a new prototype I came up with:

struct ipu_image_convert_ctx *
ipu_image_convert_prepare(struct ipu_soc *ipu, enum ipu_ic_task ic_task,
   struct ipu_image *in, struct ipu_image *out,
   enum ipu_rotate_mode rot_mode,
   ipu_image_convert_cb_t complete,
   void *complete_context);

In other words, the ipu_ic handle is replaced by the IPU handle and IC task
that are requested for carrying out the conversion.

The image converter will acquire the ipu_ic handle internally, whenever 
there
are queued contexts to that IC task (which I am calling a 'struct 
ipu_image_convert_chan').
This way the IC handle can be shared by all contexts using that IC task. 
After all
contexts have been freed from the (struct 
ipu_image_convert_chan)->ctx_list queue,
the ipu_ic handle is freed.

The ipu_ic handle is acquired in get_ipu_resources() and freed in 
release_ipu_resources(),
along with all the other IPU resources that *could possibly be needed* 
in that
ipu_image_convert_chan by future contexts (*all* idmac channels, *all* 
irqs).

I should have done this from the start, instead of allowing multiple 
handles the the IC tasks.
Thanks for pointing this out.

>
>> +
>> +#define MIN_W 128
>> +#define MIN_H 128
> Where does this minimum come from?

Nowhere really :) This is just some sane minimums, to pass
to clamp_align() when aligning input/output width/height in
ipu_image_convert_adjust().

>> +struct ic_task_channels {
>> +int in;
>> +int out;
>> +int rot_in;
>> +int rot_out;
>> +int vdi_in_p;
>> +int vdi_in;
>> +int vdi_in_n;
> The vdi channels are unused.

Well, I'd prefer to keep the VDI channels. It's quite possible we
can add motion compensated deinterlacing support using the
PRP_VF task to the image converter in the future.

>> +struct image_converter_ctx {
>> +struct image_converter *cvt;
>> +
>> +image_converter_cb_t complete;
>> +void *complete_context;
>> +
>> +/* Source/destination image data and rotation mode */
>> +struct ipu_ic_image in;
>> +struct ipu_ic_image out;
>> +enum ipu_rotate_mode rot_mode;
>> +
>> +/* intermediate buffer for rotation */
>> +struct ipu_ic_dma_buf rot_intermediate[2];
> No need to change it now, but I assume these could be per IC task
> instead of per context.

Actually no. The rotation intermediate buffers have the dimension
of a single tile, so they must remain in the context struct.

>> +static const struct ipu_ic_pixfmt ipu_ic_formats[] = {
>> +{
>> +.name   = "RGB565",
> Please drop the names, keeping a list of user readable format names is
> the v4l2 core's business, not ours.

done.

>> +.fourcc = V4L2_PIX_FMT_RGB565,
>> +.bpp= 16,
> bpp is only ever used in bytes, not bits (always divided by 8).
> Why not make this bytes_per_pixel or pixel_stride = 2.

Actually bpp is used to calculate *total* tile sizes and *total* bytes
per line. For the planar 4:2:0 formats that means it must be specified
in bits.


>> +}, {
>> +.name   = "4:2:0 planar, YUV",
>> +.fourcc = V4L2_PIX_FMT_YUV420,
>> +.bpp= 12,
>> +.y_depth = 8,
> y_depth is only ever used in bytes, not bits 

[PATCH v9 00/19] Add support for FDMA DMA controller and slim core rproc found on STi chipsets

[Vinod Koul]

On Tue, Sep 13, 2016 at 11:06:16AM -0700, Bjorn Andersson wrote:
> > I hate to send a ping,
> 
> Sorry about that.
> 
> > but do you think we can merge this fdma series? It has gone
> > through quite a few review rounds now.
> > 
> 
> I think the remoteproc part looks good.

yeah I was waiting for ack on other patches. But looks like at least
remoteproc ones have it


> Vinod, I don't have any changes queued in remoteproc that should cause
> merge issues. If you want to you could take the remoteproc patch
> through your tree.

I rechecked the dma part, they look good to me, so I should be able to apply
these. I will wait a day for ack/nacks. It is the time to speak up :)

-- 
~Vinod

[PATCH] dma-buf/sync-file: Avoid enable fence signaling if poll(.timeout=0)

[Rafael Antognolli]

Hi Chris and Gustavo,

On Mon, Aug 29, 2016 at 07:16:13PM +0100, Chris Wilson wrote:
> If we being polled with a timeout of zero, a nonblocking busy query,
> we don't need to install any fence callbacks as we will not be waiting.
> As we only install the callback once, the overhead comes from the atomic
> bit test that also causes serialisation between threads.
> 
> Signed-off-by: Chris Wilson 
> Cc: Sumit Semwal 
> Cc: Gustavo Padovan 
> Cc: linux-media at vger.kernel.org
> Cc: dri-devel at lists.freedesktop.org
> Cc: linaro-mm-sig at lists.linaro.org
> ---
>  drivers/dma-buf/sync_file.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/dma-buf/sync_file.c b/drivers/dma-buf/sync_file.c
> index 486d29c1a830..abb5fdab75fd 100644
> --- a/drivers/dma-buf/sync_file.c
> +++ b/drivers/dma-buf/sync_file.c
> @@ -306,7 +306,8 @@ static unsigned int sync_file_poll(struct file *file, 
> poll_table *wait)
>  
>   poll_wait(file, _file->wq, wait);
>  
> - if (!test_and_set_bit(POLL_ENABLED, _file->fence->flags)) {
> + if (!poll_does_not_wait(wait) &&
> + !test_and_set_bit(POLL_ENABLED, _file->fence->flags)) {
>   if (fence_add_callback(sync_file->fence, _file->cb,
>  fence_check_cb_func) < 0)
>   wake_up_all(_file->wq);

This commit is causing an error on one of the tests that Robert Foss
submitted for i-g-t. The one that does random merge of fences from
different timelines. A simple version of the test that still triggers
this is:

static void test_sync_simple_merge(void)
{
int fence1, fence2, fence_merge, timeline1, timeline2;
int ret;

timeline1 = sw_sync_timeline_create();
timeline2 = sw_sync_timeline_create();
fence1 = sw_sync_fence_create(timeline1, 1);
fence2 = sw_sync_fence_create(timeline2, 2);
fence_merge = sw_sync_merge(fence1, fence2);
sw_sync_timeline_inc(timeline1, 5);
sw_sync_timeline_inc(timeline2, 5);

ret = sw_sync_wait(fence_merge, 0);
igt_assert_f(ret > 0, "Failure triggering fence\n");

sw_sync_fence_destroy(fence_merge);
sw_sync_fence_destroy(fence1);
sw_sync_fence_destroy(fence2);
sw_sync_timeline_destroy(timeline1);
sw_sync_timeline_destroy(timeline2);
}

It looks like you cannot trust fence_is_signaled() without a
fence_add_callback(). I think the fence_array->num_pending won't get
updated. Although I couldn't figure out why it only happens if you merge
fences from different timelines.

Regards,
Rafael

[PATCH] dma-buf/sync_file: Increment refcount of fence when all are signaled.

[Rafael Antognolli]

When we merge several fences, if all of them are signaled already, we
still keep one of them. So instead of using add_fence(), which will not
increase the refcount of signaled fences, we should explicitly call
fence_get() for the fence we are keeping.

This patch fixes a kernel panic that can be triggered by creating a fence that
is expired (or increasing the timeline until it expires), then creating a
merged fence out of it, and deleting the merged fence. This will make the
original expired fence's refcount go to zero.

Signed-off-by: Rafael Antognolli 
---
 drivers/dma-buf/sync_file.c | 6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/drivers/dma-buf/sync_file.c b/drivers/dma-buf/sync_file.c
index abb5fda..0fe7ec2 100644
--- a/drivers/dma-buf/sync_file.c
+++ b/drivers/dma-buf/sync_file.c
@@ -253,10 +253,8 @@ static struct sync_file *sync_file_merge(const char *name, 
struct sync_file *a,
for (; i_b < b_num_fences; i_b++)
add_fence(fences, , b_fences[i_b]);

-   if (i == 0) {
-   add_fence(fences, , a_fences[0]);
-   i++;
-   }
+   if (i == 0)
+   fences[i++] = fence_get(a_fences[0]);

if (num_fences > i) {
nfences = krealloc(fences, i * sizeof(*fences),
-- 
2.7.4

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

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

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

--- Comment #3 from Laurent carlier  ---
(In reply to Nicolai Hähnle from comment #2)
> LLVM 3.8 is already fairly old for graphics stack standards. Can you try
> with current trunk?

Already done :) and i have a gpu lockup with mesa-git trunk with llvm-svn
trunk. It's working with mesa-git trunk with llvm-3.8.1

-- 
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/20160914/d2e071f6/attachment.html>

[PATCH] drm/i915: Add i915 perf infrastructure

[Robert Bragg]

Adds base i915 perf infrastructure for Gen performance metrics.

This adds a DRM_IOCTL_I915_PERF_OPEN ioctl that takes an array of uint64
properties to configure a stream of metrics and returns a new fd usable
with standard VFS system calls including read() to read typed and sized
records; ioctl() to enable or disable capture and poll() to wait for
data.

A stream is opened something like:

  uint64_t properties[] = {
  /* Single context sampling */
  DRM_I915_PERF_PROP_CTX_HANDLE,ctx_handle,

  /* Include OA reports in samples */
  DRM_I915_PERF_PROP_SAMPLE_OA, true,

  /* OA unit configuration */
  DRM_I915_PERF_PROP_OA_METRICS_SET,metrics_set_id,
  DRM_I915_PERF_PROP_OA_FORMAT, report_format,
  DRM_I915_PERF_PROP_OA_EXPONENT,   period_exponent,
   };
   struct drm_i915_perf_open_param parm = {
  .flags = I915_PERF_FLAG_FD_CLOEXEC |
   I915_PERF_FLAG_FD_NONBLOCK |
   I915_PERF_FLAG_DISABLED,
  .properties_ptr = (uint64_t)properties,
  .num_properties = sizeof(properties) / 16,
   };
   int fd = drmIoctl(drm_fd, DRM_IOCTL_I915_PERF_OPEN, );

Records read all start with a common { type, size } header with
DRM_I915_PERF_RECORD_SAMPLE being of most interest. Sample records
contain an extensible number of fields and it's the
DRM_I915_PERF_PROP_SAMPLE_xyz properties given when opening that
determine what's included in every sample.

No specific streams are supported yet so any attempt to open a stream
will return an error.

v4:
s/DRM_IORW/DRM_IOR/ - Emil Velikov
v3:
update read() interface to avoid passing state struct - Chris Wilson
fix some rebase fallout, with i915-perf init/deinit
v2:
use i915_gem_context_get() - Chris Wilson

Signed-off-by: Robert Bragg 
---
 drivers/gpu/drm/i915/Makefile|   3 +
 drivers/gpu/drm/i915/i915_drv.c  |   4 +
 drivers/gpu/drm/i915/i915_drv.h  |  91 
 drivers/gpu/drm/i915/i915_perf.c | 448 +++
 include/uapi/drm/i915_drm.h  |  67 ++
 5 files changed, 613 insertions(+)
 create mode 100644 drivers/gpu/drm/i915/i915_perf.c

diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index a998c2b..d991781 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -110,6 +110,9 @@ i915-y += dvo_ch7017.o \
 # virtual gpu code
 i915-y += i915_vgpu.o

+# perf code
+i915-y += i915_perf.o
+
 ifeq ($(CONFIG_DRM_I915_GVT),y)
 i915-y += intel_gvt.o
 include $(src)/gvt/Makefile
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 7f4e8ad..14f22fc 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -838,6 +838,8 @@ static int i915_driver_init_early(struct drm_i915_private 
*dev_priv,

intel_device_info_dump(dev_priv);

+   i915_perf_init(dev_priv);
+
/* Not all pre-production machines fall into this category, only the
 * very first ones. Almost everything should work, except for maybe
 * suspend/resume. And we don't implement workarounds that affect only
@@ -859,6 +861,7 @@ err_workqueues:
  */
 static void i915_driver_cleanup_early(struct drm_i915_private *dev_priv)
 {
+   i915_perf_fini(dev_priv);
i915_gem_load_cleanup(_priv->drm);
i915_workqueues_cleanup(dev_priv);
 }
@@ -2560,6 +2563,7 @@ static const struct drm_ioctl_desc i915_ioctls[] = {
DRM_IOCTL_DEF_DRV(I915_GEM_USERPTR, i915_gem_userptr_ioctl, 
DRM_RENDER_ALLOW),
DRM_IOCTL_DEF_DRV(I915_GEM_CONTEXT_GETPARAM, 
i915_gem_context_getparam_ioctl, DRM_RENDER_ALLOW),
DRM_IOCTL_DEF_DRV(I915_GEM_CONTEXT_SETPARAM, 
i915_gem_context_setparam_ioctl, DRM_RENDER_ALLOW),
+   DRM_IOCTL_DEF_DRV(I915_PERF_OPEN, i915_perf_open_ioctl, 
DRM_RENDER_ALLOW),
 };

 static struct drm_driver driver = {
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 1e2dda8..0f5cd8f 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1740,6 +1740,84 @@ struct intel_wm_config {
bool sprites_scaled;
 };

+struct i915_perf_stream;
+
+struct i915_perf_stream_ops {
+   /* Enables the collection of HW samples, either in response to
+* I915_PERF_IOCTL_ENABLE or implicitly called when stream is
+* opened without I915_PERF_FLAG_DISABLED.
+*/
+   void (*enable)(struct i915_perf_stream *stream);
+
+   /* Disables the collection of HW samples, either in response to
+* I915_PERF_IOCTL_DISABLE or implicitly called before
+* destroying the stream.
+*/
+   void (*disable)(struct i915_perf_stream *stream);
+
+   /* Return: true if any i915 perf records are ready to read()
+* for this stream.
+*/
+   bool (*can_read)(struct i915_perf_stream *stream);
+
+   /* Call poll_wait, passing a wait queue that will be woken
+* once there is something ready to read() for the 

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

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

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

--- Comment #2 from Nicolai Hähnle  ---
LLVM 3.8 is already fairly old for graphics stack standards. Can you try with
current trunk?

-- 
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/20160914/b7f7e04c/attachment.html>

[PATCH v4 03/14] drm: Use drm_format_info() in DRM core code

[Tomi Valkeinen]

On 08/09/16 17:44, Laurent Pinchart wrote:
> Replace calls to the drm_format_*() helper functions with direct use of
> the drm_format_info structure. This improves efficiency by removing
> duplicate lookups.
> 
> Signed-off-by: Laurent Pinchart 
> ---
>  drivers/gpu/drm/drm_fb_cma_helper.c |  23 
>  drivers/gpu/drm/drm_framebuffer.c   | 102 
> +---
>  2 files changed, 25 insertions(+), 100 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_fb_cma_helper.c 
> b/drivers/gpu/drm/drm_fb_cma_helper.c
> index 1fd6eac1400c..fac4f06f8485 100644
> --- a/drivers/gpu/drm/drm_fb_cma_helper.c
> +++ b/drivers/gpu/drm/drm_fb_cma_helper.c
> @@ -176,20 +176,20 @@ struct drm_framebuffer 
> *drm_fb_cma_create_with_funcs(struct drm_device *dev,
>   struct drm_file *file_priv, const struct drm_mode_fb_cmd2 *mode_cmd,
>   const struct drm_framebuffer_funcs *funcs)
>  {
> + const struct drm_format_info *info;
>   struct drm_fb_cma *fb_cma;
>   struct drm_gem_cma_object *objs[4];
>   struct drm_gem_object *obj;
> - unsigned int hsub;
> - unsigned int vsub;
>   int ret;
>   int i;
>  
> - hsub = drm_format_horz_chroma_subsampling(mode_cmd->pixel_format);
> - vsub = drm_format_vert_chroma_subsampling(mode_cmd->pixel_format);
> + info = drm_format_info(mode_cmd->pixel_format);
> + if (!info)
> + return ERR_PTR(-EINVAL);
>  
> - for (i = 0; i < drm_format_num_planes(mode_cmd->pixel_format); i++) {
> - unsigned int width = mode_cmd->width / (i ? hsub : 1);
> - unsigned int height = mode_cmd->height / (i ? vsub : 1);
> + for (i = 0; i < info->num_planes; i++) {
> + unsigned int width = mode_cmd->width / (i ? info->hsub : 1);
> + unsigned int height = mode_cmd->height / (i ? info->vsub : 1);
>   unsigned int min_size;
>  
>   obj = drm_gem_object_lookup(file_priv, mode_cmd->handles[i]);
> @@ -200,7 +200,7 @@ struct drm_framebuffer 
> *drm_fb_cma_create_with_funcs(struct drm_device *dev,
>   }
>  
>   min_size = (height - 1) * mode_cmd->pitches[i]
> -  + width * drm_format_plane_cpp(mode_cmd->pixel_format, 
> i)
> +  + width * info->cpp[i]
>+ mode_cmd->offsets[i];
>  
>   if (obj->size < min_size) {
> @@ -269,12 +269,15 @@ EXPORT_SYMBOL_GPL(drm_fb_cma_get_gem_obj);
>  static void drm_fb_cma_describe(struct drm_framebuffer *fb, struct seq_file 
> *m)
>  {
>   struct drm_fb_cma *fb_cma = to_fb_cma(fb);
> - int i, n = drm_format_num_planes(fb->pixel_format);
> + const struct drm_format_info *info;
> + int i;
>  
>   seq_printf(m, "fb: %dx%d@%4.4s\n", fb->width, fb->height,
>   (char *)>pixel_format);
>  
> - for (i = 0; i < n; i++) {
> + info = drm_format_info(fb->pixel_format);
> +
> + for (i = 0; i < info->num_planes; i++) {
>   seq_printf(m, "   %d: offset=%d pitch=%d, obj: ",
>   i, fb->offsets[i], fb->pitches[i]);
>   drm_gem_cma_describe(fb_cma->obj[i], m);

This change doesn't seem to improve the function. Afaics, only the num
planes is retrieved and used.

 Tomi

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

[Intel-gfx] [PATCH v5 01/11] drm/i915: Add i915 perf infrastructure

[Robert Bragg]

On Wed, Sep 14, 2016 at 3:42 PM, Emil Velikov 
wrote:

> Hi Robert,
>
> I think I've spotted one interesting, yet trivial bit.
>
> On 14 September 2016 at 15:19, Robert Bragg  wrote:
> > Adds base i915 perf infrastructure for Gen performance metrics.
> >
> > This adds a DRM_IOCTL_I915_PERF_OPEN ioctl that takes an array of uint64
> > properties to configure a stream of metrics and returns a new fd usable
> > with standard VFS system calls including read() to read typed and sized
> > records; ioctl() to enable or disable capture and poll() to wait for
> > data.
> >
> > A stream is opened something like:
> >
> >   uint64_t properties[] = {
> >   /* Single context sampling */
> >   DRM_I915_PERF_PROP_CTX_HANDLE,ctx_handle,
> >
> >   /* Include OA reports in samples */
> >   DRM_I915_PERF_PROP_SAMPLE_OA, true,
> >
> >   /* OA unit configuration */
> >   DRM_I915_PERF_PROP_OA_METRICS_SET,metrics_set_id,
> >   DRM_I915_PERF_PROP_OA_FORMAT, report_format,
> >   DRM_I915_PERF_PROP_OA_EXPONENT,   period_exponent,
> >};
> >struct drm_i915_perf_open_param parm = {
> >   .flags = I915_PERF_FLAG_FD_CLOEXEC |
> >I915_PERF_FLAG_FD_NONBLOCK |
> >I915_PERF_FLAG_DISABLED,
> >   .properties_ptr = (uint64_t)properties,
> >   .num_properties = sizeof(properties) / 16,
> >};
> >int fd = drmIoctl(drm_fd, DRM_IOCTL_I915_PERF_OPEN, );
> >
> > Records read all start with a common { type, size } header with
> > DRM_I915_PERF_RECORD_SAMPLE being of most interest. Sample records
> > contain an extensible number of fields and it's the
> > DRM_I915_PERF_PROP_SAMPLE_xyz properties given when opening that
> > determine what's included in every sample.
> >
> If I'm understanding the above correctly the ioctl can only read user
> data and does not write to params, correct ?
>
> > --- a/include/uapi/drm/i915_drm.h
> > +++ b/include/uapi/drm/i915_drm.h
>
> > +#define DRM_IOCTL_I915_PERF_OPEN   DRM_IOWR(DRM_COMMAND_BASE +
> DRM_I915_PERF_OPEN, struct drm_i915_perf_open_param)
>
> If so, we seems to have a one letter too much in DRM_IOWR - should one
> use DRM_IOW/DRM_IOR ? Then again I'm not sure how many ioctls bother,
> so please don't read too much into my suggestion :-)
>

Ah, yep, good catch, I don't write back to the param struct any more.

The first iteration of this interface was even more closely modeled on the
core linux perf interface where the param struct starts with a size member
and in a case where userspace passes a structure that's smaller than
expected the kernel returns an error but also writes back the expected size
to inform userspace.

i915 perf moved to taking an array of u64 properties and no longer writes
back a size member in the param struct like perf.

Thanks,
- Robert



>
> Regards,
> Emil
>
-- next part --
An HTML attachment was scrubbed...
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160914/b1d161bb/attachment.html>

[Intel-gfx] [PATCH v5 01/11] drm/i915: Add i915 perf infrastructure

[Emil Velikov]

Hi Robert,

I think I've spotted one interesting, yet trivial bit.

On 14 September 2016 at 15:19, Robert Bragg  wrote:
> Adds base i915 perf infrastructure for Gen performance metrics.
>
> This adds a DRM_IOCTL_I915_PERF_OPEN ioctl that takes an array of uint64
> properties to configure a stream of metrics and returns a new fd usable
> with standard VFS system calls including read() to read typed and sized
> records; ioctl() to enable or disable capture and poll() to wait for
> data.
>
> A stream is opened something like:
>
>   uint64_t properties[] = {
>   /* Single context sampling */
>   DRM_I915_PERF_PROP_CTX_HANDLE,ctx_handle,
>
>   /* Include OA reports in samples */
>   DRM_I915_PERF_PROP_SAMPLE_OA, true,
>
>   /* OA unit configuration */
>   DRM_I915_PERF_PROP_OA_METRICS_SET,metrics_set_id,
>   DRM_I915_PERF_PROP_OA_FORMAT, report_format,
>   DRM_I915_PERF_PROP_OA_EXPONENT,   period_exponent,
>};
>struct drm_i915_perf_open_param parm = {
>   .flags = I915_PERF_FLAG_FD_CLOEXEC |
>I915_PERF_FLAG_FD_NONBLOCK |
>I915_PERF_FLAG_DISABLED,
>   .properties_ptr = (uint64_t)properties,
>   .num_properties = sizeof(properties) / 16,
>};
>int fd = drmIoctl(drm_fd, DRM_IOCTL_I915_PERF_OPEN, );
>
> Records read all start with a common { type, size } header with
> DRM_I915_PERF_RECORD_SAMPLE being of most interest. Sample records
> contain an extensible number of fields and it's the
> DRM_I915_PERF_PROP_SAMPLE_xyz properties given when opening that
> determine what's included in every sample.
>
If I'm understanding the above correctly the ioctl can only read user
data and does not write to params, correct ?

> --- a/include/uapi/drm/i915_drm.h
> +++ b/include/uapi/drm/i915_drm.h

> +#define DRM_IOCTL_I915_PERF_OPEN   DRM_IOWR(DRM_COMMAND_BASE + 
> DRM_I915_PERF_OPEN, struct drm_i915_perf_open_param)

If so, we seems to have a one letter too much in DRM_IOWR - should one
use DRM_IOW/DRM_IOR ? Then again I'm not sure how many ioctls bother,
so please don't read too much into my suggestion :-)

Regards,
Emil

[PATCH] drm/radeon/radeon_device: clean function declarations in radeon_device.c up

[Baoyou Xie]

On 14 September 2016 at 15:22, Christian König 
wrote:

> Am 14.09.2016 um 08:10 schrieb Baoyou Xie:
>
>> We get 2 warnings when building kernel with W=1:
>> drivers/gpu/drm/radeon/radeon_device.c:1961:5: warning: no previous
>> prototype for 'radeon_debugfs_init' [-Wmissing-prototypes]
>> drivers/gpu/drm/radeon/radeon_device.c:1966:6: warning: no previous
>> prototype for 'radeon_debugfs_cleanup' [-Wmissing-prototypes]
>>
>> In fact, both functions are declared in
>> drivers/gpu/drm/radeon/radeon_drv.c, but should be declared in
>> a header file, thus can be recognized in other file.
>>
>> So this patch moves the declarations into drivers/gpu/drm/radeon/radeon.
>> h.
>>
>> Signed-off-by: Baoyou Xie 
>>
>
> Actually if I see it correctly we could also just remove the two callbacks
> cause they are optional and our implementations are just empty dummys.
>
>
Is it sure? if true, we can simply remove them.

someone maybe implementation these functions in order to support debugfs.


> Christian.
>
>
> ---
>>   drivers/gpu/drm/radeon/radeon_device.c | 1 +
>>   drivers/gpu/drm/radeon/radeon_drv.c| 5 -
>>   drivers/gpu/drm/radeon/radeon_drv.h| 5 +
>>   3 files changed, 6 insertions(+), 5 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/radeon/radeon_device.c
>> b/drivers/gpu/drm/radeon/radeon_device.c
>> index a00dd2f..811abde 100644
>> --- a/drivers/gpu/drm/radeon/radeon_device.c
>> +++ b/drivers/gpu/drm/radeon/radeon_device.c
>> @@ -36,6 +36,7 @@
>>   #include 
>>   #include "radeon_reg.h"
>>   #include "radeon.h"
>> +#include "radeon_drv.h"
>>   #include "atom.h"
>> static const char radeon_family_name[][16] = {
>> diff --git a/drivers/gpu/drm/radeon/radeon_drv.c
>> b/drivers/gpu/drm/radeon/radeon_drv.c
>> index 07e4493..6cc4a9e 100644
>> --- a/drivers/gpu/drm/radeon/radeon_drv.c
>> +++ b/drivers/gpu/drm/radeon/radeon_drv.c
>> @@ -156,11 +156,6 @@ void radeon_gem_prime_vunmap(struct drm_gem_object
>> *obj, void *vaddr);
>>   extern long radeon_kms_compat_ioctl(struct file *filp, unsigned int cmd,
>> unsigned long arg);
>>   -#if defined(CONFIG_DEBUG_FS)
>> -int radeon_debugfs_init(struct drm_minor *minor);
>> -void radeon_debugfs_cleanup(struct drm_minor *minor);
>> -#endif
>> -
>>   /* atpx handler */
>>   #if defined(CONFIG_VGA_SWITCHEROO)
>>   void radeon_register_atpx_handler(void);
>> diff --git a/drivers/gpu/drm/radeon/radeon_drv.h
>> b/drivers/gpu/drm/radeon/radeon_drv.h
>> index afef2d9..3d35e0e 100644
>> --- a/drivers/gpu/drm/radeon/radeon_drv.h
>> +++ b/drivers/gpu/drm/radeon/radeon_drv.h
>> @@ -119,4 +119,9 @@
>>   long radeon_drm_ioctl(struct file *filp,
>>   unsigned int cmd, unsigned long arg);
>>   +#if defined(CONFIG_DEBUG_FS)
>> +int radeon_debugfs_init(struct drm_minor *minor);
>> +void radeon_debugfs_cleanup(struct drm_minor *minor);
>> +#endif
>> +
>>   #endif/* __RADEON_DRV_H__ */
>>
>
>
>
-- next part --
An HTML attachment was scrubbed...
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160914/842ffec2/attachment-0001.html>

[PATCH v7 7/9] drm/mediatek: add dsi transfer function

[CK Hu]

Hi, YT:

On Wed, 2016-09-14 at 15:22 +0800, YT Shen wrote:
> Hi CK,
> 
> On Wed, 2016-09-14 at 14:39 +0800, CK Hu wrote:
> > Hi, YT:
> > 
> > On Wed, 2016-09-14 at 14:19 +0800, YT Shen wrote:
> > > Hi CK,
> > > 
> > > On Tue, 2016-09-13 at 17:25 +0800, CK Hu wrote:
> > > > Hi, YT:
> > > > 
> > > > On Mon, 2016-09-12 at 18:16 +0800, YT Shen wrote:
> > > > > Hi CK,
> > > > > 
> > > > > On Wed, 2016-09-07 at 10:33 +0800, CK Hu wrote:
> > > > > > Hi, YT:
> > > > > > 
> > > > > > On Fri, 2016-09-02 at 19:24 +0800, YT Shen wrote:
> > > > > > > From: shaoming chen 
> > > > > > > 
> > > > > > > add dsi read/write commands for transfer function
> > > > > > > 
> > > > > > > Signed-off-by: shaoming chen 
> > > > > > > ---
> > > > > > >  drivers/gpu/drm/mediatek/mtk_dsi.c | 188 
> > > > > > > +
> > > > > > >  1 file changed, 188 insertions(+)
> > > > > > > 
> > > > > > 
> > > > > > [snip...]
> > > > > > 
> > > > > > >  
> > > > > > > +static void mtk_dsi_irq_data_clear(struct mtk_dsi *dsi, u32 
> > > > > > > irq_bit)
> > > > > > > +{
> > > > > > > + dsi->irq_data &= ~irq_bit;
> > > > > > > +}
> > > > > > > +
> > > > > > 
> > > > > > [snip...]
> > > > > > 
> > > > > > > +
> > > > > > > +static s32 mtk_dsi_wait_for_irq_done(struct mtk_dsi *dsi, u32 
> > > > > > > irq_flag,
> > > > > > > +  unsigned int timeout)
> > > > > > > +{
> > > > > > > + s32 ret = 0;
> > > > > > > + unsigned long jiffies = msecs_to_jiffies(timeout);
> > > > > > > +
> > > > > > > + ret = wait_event_interruptible_timeout(_dsi_irq_wait_queue,
> > > > > > > +dsi->irq_data & irq_flag,
> > > > > > > +jiffies);
> > > > > > > + if (ret == 0) {
> > > > > > > + dev_info(dsi->dev, "Wait DSI IRQ(0x%08x) Timeout\n", 
> > > > > > > irq_flag);
> > > > > > > +
> > > > > > > + mtk_dsi_enable(dsi);
> > > > > > > + mtk_dsi_reset_engine(dsi);
> > > > > > > + }
> > > > > > > +
> > > > > > > + return ret;
> > > > > > > +}
> > > > > > 
> > > > > > I think mtk_dsi_irq_data_clear() and mtk_dsi_wait_for_irq_done() 
> > > > > > should
> > > > > > be moved to the 6th patch [1] of this series because these two 
> > > > > > functions
> > > > > > deal the irq control.
> > > > > We will move mtk_dsi_irq_data_clear() to patch "drm/mediatek: add dsi
> > > > > interrupt control" and put mtk_dsi_wait_for_irq_done() here, because 
> > > > > it
> > > > > is used in the transfer function.
> > > > 
> > > > mtk_dsi_irq_data_clear() is also only used in transfer function now. I
> > > > think both function could be used for other application rather than
> > > > transfer function, so these two function are general function for irq
> > > > control.
> > > We will rollback the changes here.  Move mtk_dsi_irq_data_clear() to
> > > original place.
> > > 
> > > Add new functions could be used in the future will have problems.
> > > warning: 'mtk_dsi_wait_for_irq_done' defined but not used
> > > [-Wunused-function]
> > >  static s32 mtk_dsi_wait_for_irq_done(struct mtk_dsi *dsi, u32 irq_flag,
> > > warning: 'mtk_dsi_irq_data_clear' defined but not used
> > > [-Wunused-function]
> > >  static void mtk_dsi_irq_data_clear(struct mtk_dsi *dsi, u32 irq_bit)
> > 
> > Please refer to [1], '__maybe_unused' can fix your problem.
> > 
> > [1]
> > http://lxr.free-electrons.com/source/drivers/gpu/drm/panel/panel-sharp-lq101r1sx01.c#L76
> Add __maybe_unused just let GCC not produce a warning for this function.
> So you want add patch like this?
> 
> [PATCH v7 6/9] drm/mediatek: add dsi interrupt control
> +static __maybe_unused s32 mtk_dsi_wait_for_irq_done(struct mtk_dsi
> *dsi, u32 irq_flag,
> 
> +static __maybe_unused void mtk_dsi_irq_data_set(struct mtk_dsi *dsi,
> u32 irq_bit)
> 
> [PATCH v7 7/9] drm/mediatek: add dsi transfer function
> -static __maybe_unused s32 mtk_dsi_wait_for_irq_done(struct mtk_dsi
> *dsi, u32 irq_flag,
> +static s32 mtk_dsi_wait_for_irq_done(struct mtk_dsi *dsi, u32 irq_flag,
> 
> -static __maybe_unused void mtk_dsi_irq_data_clear(struct mtk_dsi *dsi,
> u32 irq_bit)
> +static void mtk_dsi_irq_data_clear(struct mtk_dsi *dsi, u32 irq_bit)
> 
> Put the static function earlier and add __maybe_unused annotations.
> Then remove _maybe_unused annotations later.  Or you want to keep
> __maybe_unused annotations inside?  Sounds unnecessary, it is different
> from your reference sharp_panel_read().

Removing '__maybe_unused' in later patch looks good to me.

Regards,
CK

> 
> > 
> > Regards,
> > CK
> > 
> > > 
> > > > Regards,
> > > > CK
> > > > 
> > > > > 
> > > > > Regards,
> > > > > yt.shen
> > > > > > 
> > > > > > 
> > > > > > [1] https://patchwork.kernel.org/patch/9310819/
> > > > > > 
> > > > > > 
> > > > > > Regards,
> > > > > > CK
> > > > > > 
> > > > > 
> > > > > 
> > > > 
> > > > 
> > > 
> > > 
> > 
> > 
> 
> 

[PATCH v7 7/9] drm/mediatek: add dsi transfer function

[YT Shen]

Hi CK,

On Wed, 2016-09-14 at 14:39 +0800, CK Hu wrote:
> Hi, YT:
> 
> On Wed, 2016-09-14 at 14:19 +0800, YT Shen wrote:
> > Hi CK,
> > 
> > On Tue, 2016-09-13 at 17:25 +0800, CK Hu wrote:
> > > Hi, YT:
> > > 
> > > On Mon, 2016-09-12 at 18:16 +0800, YT Shen wrote:
> > > > Hi CK,
> > > > 
> > > > On Wed, 2016-09-07 at 10:33 +0800, CK Hu wrote:
> > > > > Hi, YT:
> > > > > 
> > > > > On Fri, 2016-09-02 at 19:24 +0800, YT Shen wrote:
> > > > > > From: shaoming chen 
> > > > > > 
> > > > > > add dsi read/write commands for transfer function
> > > > > > 
> > > > > > Signed-off-by: shaoming chen 
> > > > > > ---
> > > > > >  drivers/gpu/drm/mediatek/mtk_dsi.c | 188 
> > > > > > +
> > > > > >  1 file changed, 188 insertions(+)
> > > > > > 
> > > > > 
> > > > > [snip...]
> > > > > 
> > > > > >  
> > > > > > +static void mtk_dsi_irq_data_clear(struct mtk_dsi *dsi, u32 
> > > > > > irq_bit)
> > > > > > +{
> > > > > > +   dsi->irq_data &= ~irq_bit;
> > > > > > +}
> > > > > > +
> > > > > 
> > > > > [snip...]
> > > > > 
> > > > > > +
> > > > > > +static s32 mtk_dsi_wait_for_irq_done(struct mtk_dsi *dsi, u32 
> > > > > > irq_flag,
> > > > > > +unsigned int timeout)
> > > > > > +{
> > > > > > +   s32 ret = 0;
> > > > > > +   unsigned long jiffies = msecs_to_jiffies(timeout);
> > > > > > +
> > > > > > +   ret = wait_event_interruptible_timeout(_dsi_irq_wait_queue,
> > > > > > +  dsi->irq_data & irq_flag,
> > > > > > +  jiffies);
> > > > > > +   if (ret == 0) {
> > > > > > +   dev_info(dsi->dev, "Wait DSI IRQ(0x%08x) Timeout\n", 
> > > > > > irq_flag);
> > > > > > +
> > > > > > +   mtk_dsi_enable(dsi);
> > > > > > +   mtk_dsi_reset_engine(dsi);
> > > > > > +   }
> > > > > > +
> > > > > > +   return ret;
> > > > > > +}
> > > > > 
> > > > > I think mtk_dsi_irq_data_clear() and mtk_dsi_wait_for_irq_done() 
> > > > > should
> > > > > be moved to the 6th patch [1] of this series because these two 
> > > > > functions
> > > > > deal the irq control.
> > > > We will move mtk_dsi_irq_data_clear() to patch "drm/mediatek: add dsi
> > > > interrupt control" and put mtk_dsi_wait_for_irq_done() here, because it
> > > > is used in the transfer function.
> > > 
> > > mtk_dsi_irq_data_clear() is also only used in transfer function now. I
> > > think both function could be used for other application rather than
> > > transfer function, so these two function are general function for irq
> > > control.
> > We will rollback the changes here.  Move mtk_dsi_irq_data_clear() to
> > original place.
> > 
> > Add new functions could be used in the future will have problems.
> > warning: 'mtk_dsi_wait_for_irq_done' defined but not used
> > [-Wunused-function]
> >  static s32 mtk_dsi_wait_for_irq_done(struct mtk_dsi *dsi, u32 irq_flag,
> > warning: 'mtk_dsi_irq_data_clear' defined but not used
> > [-Wunused-function]
> >  static void mtk_dsi_irq_data_clear(struct mtk_dsi *dsi, u32 irq_bit)
> 
> Please refer to [1], '__maybe_unused' can fix your problem.
> 
> [1]
> http://lxr.free-electrons.com/source/drivers/gpu/drm/panel/panel-sharp-lq101r1sx01.c#L76
Add __maybe_unused just let GCC not produce a warning for this function.
So you want add patch like this?

[PATCH v7 6/9] drm/mediatek: add dsi interrupt control
+static __maybe_unused s32 mtk_dsi_wait_for_irq_done(struct mtk_dsi
*dsi, u32 irq_flag,

+static __maybe_unused void mtk_dsi_irq_data_set(struct mtk_dsi *dsi,
u32 irq_bit)

[PATCH v7 7/9] drm/mediatek: add dsi transfer function
-static __maybe_unused s32 mtk_dsi_wait_for_irq_done(struct mtk_dsi
*dsi, u32 irq_flag,
+static s32 mtk_dsi_wait_for_irq_done(struct mtk_dsi *dsi, u32 irq_flag,

-static __maybe_unused void mtk_dsi_irq_data_clear(struct mtk_dsi *dsi,
u32 irq_bit)
+static void mtk_dsi_irq_data_clear(struct mtk_dsi *dsi, u32 irq_bit)

Put the static function earlier and add __maybe_unused annotations.
Then remove _maybe_unused annotations later.  Or you want to keep
__maybe_unused annotations inside?  Sounds unnecessary, it is different
from your reference sharp_panel_read().

> 
> Regards,
> CK
> 
> > 
> > > Regards,
> > > CK
> > > 
> > > > 
> > > > Regards,
> > > > yt.shen
> > > > > 
> > > > > 
> > > > > [1] https://patchwork.kernel.org/patch/9310819/
> > > > > 
> > > > > 
> > > > > Regards,
> > > > > CK
> > > > > 
> > > > 
> > > > 
> > > 
> > > 
> > 
> > 
> 
> 

[GIT PULL] drm-vc4-fixes-2016-09-14

[Eric Anholt]

These should be the last vc4 fixes for 4.8.

The following changes since commit 552416c146fadc67cd9b53ef7adf88d3381c43a6:

  drm/vc4: Fix oops when userspace hands in a bad BO. (2016-08-19 19:17:39 
-0700)

are available in the git repository at:

  https://github.com/anholt/linux tags/drm-vc4-fixes-2016-09-14

for you to fetch changes up to ea90383837334bcebe842e719ad4d8c966f4ef51:

  drm/vc4: mark vc4_bo_cache_purge() static (2016-09-09 12:21:43 -0700)


This pull request brings in a fix for crashes in X on VC4.


Baoyou Xie (1):
  drm/vc4: mark vc4_bo_cache_purge() static

Eric Anholt (1):
  drm/vc4: Allow some more signals to be packed with uniform resets.

 drivers/gpu/drm/vc4/vc4_bo.c   |  2 +-
 drivers/gpu/drm/vc4/vc4_validate_shaders.c | 10 --
 2 files changed, 9 insertions(+), 3 deletions(-)

[PATCH v5 11/11] drm/i915: Add a kerneldoc summary for i915_perf.c

[Robert Bragg]

In particular this tries to capture for posterity some of the early
challenges we had with using the core perf infrastructure in case we
ever want to revisit adapting perf for device metrics.

Cc: Chris Wilson 
Signed-off-by: Robert Bragg 
---
 drivers/gpu/drm/i915/i915_perf.c | 163 +++
 1 file changed, 163 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c
index a7a248b..891efe6 100644
--- a/drivers/gpu/drm/i915/i915_perf.c
+++ b/drivers/gpu/drm/i915/i915_perf.c
@@ -24,6 +24,169 @@
  *   Robert Bragg 
  */

+
+/**
+ * DOC: i915 Perf, streaming API for GPU metrics
+ *
+ * Gen graphics supports a large number of performance counters that can help
+ * driver and application developers understand and optimize their use of the
+ * GPU.
+ *
+ * This i915 perf interface enables userspace to configure and open a file
+ * descriptor representing a stream of GPU metrics which can then be read() as
+ * a stream of sample records.
+ *
+ * The interface is particularly suited to exposing buffered metrics that are
+ * captured by DMA from the GPU, unsynchronized with and unrelated to the CPU.
+ *
+ * Streams representing a single context are accessible to applications with a
+ * corresponding drm file descriptor, such that OpenGL can use the interface
+ * without special privileges. Access to system-wide metrics requires root
+ * privileges by default, unless changed via the dev.i915.perf_event_paranoid
+ * sysctl option.
+ *
+ *
+ * The interface was initially inspired by the core Perf infrastructure but
+ * some notable differences are:
+ *
+ * i915 perf file descriptors represent a "stream" instead of an "event"; where
+ * a perf event primarily corresponds to a single 64bit value, while a stream
+ * might sample sets of tightly-coupled counters, depending on the
+ * configuration.  For example the Gen OA unit isn't designed to support
+ * orthogonal configurations of individual counters; it's configured for a set
+ * of related counters. Samples for an i915 perf stream capturing OA metrics
+ * will include a set of counter values packed in a compact HW specific format.
+ * The OA unit supports a number of different packing formats which can be
+ * selected by the user opening the stream. Perf has support for grouping
+ * events, but each event in the group is configured, validated and
+ * authenticated individually with separate system calls.
+ *
+ * i915 perf stream configurations are provided as an array of u64 (key,value)
+ * pairs, instead of a fixed struct with multiple miscellaneous config members,
+ * interleaved with event-type specific members.
+ *
+ * i915 perf doesn't support exposing metrics via an mmap'd circular buffer.
+ * The supported metrics are being written to memory by the GPU unsynchronized
+ * with the CPU, using HW specific packing formats for counter sets. Sometimes
+ * the constraints on HW configuration require reports to be filtered before it
+ * would be acceptable to expose them to unprivileged applications - to hide
+ * the metrics of other processes/contexts. For these use cases a read() based
+ * interface is a good fit, and provides an opportunity to filter data as it
+ * gets copied from the GPU mapped buffers to userspace buffers.
+ *
+ *
+ * Some notes regarding Linux Perf:
+ * 
+ *
+ * The first prototype of this driver was based on the core perf
+ * infrastructure, and while we did make that mostly work, with some changes to
+ * perf, we found we were breaking or working around too many assumptions baked
+ * into perf's currently cpu centric design.
+ *
+ * In the end we didn't see a clear benefit to making perf's implementation and
+ * interface more complex by changing design assumptions while we knew we still
+ * wouldn't be able to use any existing perf based userspace tools.
+ *
+ * Also considering the Gen specific nature of the Observability hardware and
+ * how userspace will sometimes need to combine i915 perf OA metrics with
+ * side-band OA data captured via MI_REPORT_PERF_COUNT commands; we're
+ * expecting the interface to be used by a platform specific userspace such as
+ * OpenGL or tools. This is to say; we aren't inherently missing out on having
+ * a standard vendor/architecture agnostic interface by not using perf.
+ *
+ *
+ * For posterity, in case we might re-visit trying to adapt core perf to be
+ * better suited to exposing i915 metrics these were the main pain points we
+ * hit:
+ *
+ * - The perf based OA PMU driver broke some significant design assumptions:
+ *
+ *   Existing perf pmus are used for profiling work on a cpu and we were
+ *   introducing the idea of _IS_DEVICE pmus with different security
+ *   implications, the need to fake cpu-related data (such as user/kernel
+ *   registers) to fit with perf's current design, and adding _DEVICE records
+ *   as a way to forward device-specific status records.
+ *
+ *   The OA unit writes 

[PATCH v5 10/11] drm/i915: Add more Haswell OA metric sets

[Robert Bragg]

This adds 'compute', 'compute extended', 'memory reads', 'memory writes'
and 'sampler balance' metric sets for Haswell.

The code is auto generated from an XML description of metric sets,
currently maintained in gputop, ref:

 https://github.com/rib/gputop
 > gputop-data/oa-*.xml
 > scripts/i915-perf-kernelgen.py

 $ make -C gputop-data -f Makefile.xml

Signed-off-by: Robert Bragg 
---
 drivers/gpu/drm/i915/i915_oa_hsw.c | 559 -
 1 file changed, 558 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_oa_hsw.c 
b/drivers/gpu/drm/i915/i915_oa_hsw.c
index 656334d..7906a26 100644
--- a/drivers/gpu/drm/i915/i915_oa_hsw.c
+++ b/drivers/gpu/drm/i915/i915_oa_hsw.c
@@ -30,9 +30,14 @@

 enum metric_set_id {
METRIC_SET_ID_RENDER_BASIC = 1,
+   METRIC_SET_ID_COMPUTE_BASIC,
+   METRIC_SET_ID_COMPUTE_EXTENDED,
+   METRIC_SET_ID_MEMORY_READS,
+   METRIC_SET_ID_MEMORY_WRITES,
+   METRIC_SET_ID_SAMPLER_BALANCE,
 };

-int i915_oa_n_builtin_metric_sets_hsw = 1;
+int i915_oa_n_builtin_metric_sets_hsw = 6;

 static const struct i915_oa_reg b_counter_config_render_basic[] = {
{ _MMIO(0x2724), 0x0080 },
@@ -111,6 +116,298 @@ get_render_basic_mux_config(struct drm_i915_private 
*dev_priv,
return mux_config_render_basic;
 }

+static const struct i915_oa_reg b_counter_config_compute_basic[] = {
+   { _MMIO(0x2710), 0x },
+   { _MMIO(0x2714), 0x0080 },
+   { _MMIO(0x2718), 0x },
+   { _MMIO(0x271c), 0x },
+   { _MMIO(0x2720), 0x },
+   { _MMIO(0x2724), 0x0080 },
+   { _MMIO(0x2728), 0x },
+   { _MMIO(0x272c), 0x },
+   { _MMIO(0x2740), 0x },
+   { _MMIO(0x2744), 0x },
+   { _MMIO(0x2748), 0x },
+   { _MMIO(0x274c), 0x },
+   { _MMIO(0x2750), 0x },
+   { _MMIO(0x2754), 0x },
+   { _MMIO(0x2758), 0x },
+   { _MMIO(0x275c), 0x },
+   { _MMIO(0x236c), 0x },
+};
+
+static const struct i915_oa_reg mux_config_compute_basic[] = {
+   { _MMIO(0x253a4), 0x },
+   { _MMIO(0x2681c), 0x01f00800 },
+   { _MMIO(0x26820), 0x1000 },
+   { _MMIO(0x2781c), 0x01f00800 },
+   { _MMIO(0x26520), 0x0007 },
+   { _MMIO(0x265a0), 0x0007 },
+   { _MMIO(0x25380), 0x0010 },
+   { _MMIO(0x2538c), 0x0030 },
+   { _MMIO(0x25384), 0xaa8a },
+   { _MMIO(0x25404), 0x },
+   { _MMIO(0x26800), 0x4202 },
+   { _MMIO(0x26808), 0x00605817 },
+   { _MMIO(0x2680c), 0x10001005 },
+   { _MMIO(0x26804), 0x },
+   { _MMIO(0x27800), 0x0102 },
+   { _MMIO(0x27808), 0x0c0701e0 },
+   { _MMIO(0x2780c), 0x000200a0 },
+   { _MMIO(0x27804), 0x },
+   { _MMIO(0x26484), 0x4400 },
+   { _MMIO(0x26704), 0x4400 },
+   { _MMIO(0x26500), 0x0006 },
+   { _MMIO(0x26510), 0x0001 },
+   { _MMIO(0x26504), 0x8800 },
+   { _MMIO(0x26580), 0x0006 },
+   { _MMIO(0x26590), 0x0020 },
+   { _MMIO(0x26584), 0x },
+   { _MMIO(0x26104), 0x5582 },
+   { _MMIO(0x26184), 0xaa86 },
+   { _MMIO(0x25420), 0x08320c83 },
+   { _MMIO(0x25424), 0x06820c83 },
+   { _MMIO(0x2541c), 0x },
+   { _MMIO(0x25428), 0x0c03 },
+};
+
+static const struct i915_oa_reg *
+get_compute_basic_mux_config(struct drm_i915_private *dev_priv,
+int *len)
+{
+   *len = ARRAY_SIZE(mux_config_compute_basic);
+   return mux_config_compute_basic;
+}
+
+static const struct i915_oa_reg b_counter_config_compute_extended[] = {
+   { _MMIO(0x2724), 0xf080 },
+   { _MMIO(0x2720), 0x },
+   { _MMIO(0x2714), 0xf080 },
+   { _MMIO(0x2710), 0x },
+   { _MMIO(0x2770), 0x0007fe2a },
+   { _MMIO(0x2774), 0xff00 },
+   { _MMIO(0x2778), 0x0007fe6a },
+   { _MMIO(0x277c), 0xff00 },
+   { _MMIO(0x2780), 0x0007fe92 },
+   { _MMIO(0x2784), 0xff00 },
+   { _MMIO(0x2788), 0x0007fea2 },
+   { _MMIO(0x278c), 0xff00 },
+   { _MMIO(0x2790), 0x0007fe32 },
+   { _MMIO(0x2794), 0xff00 },
+   { _MMIO(0x2798), 0x0007fe9a },
+   { _MMIO(0x279c), 0xff00 },
+   { _MMIO(0x27a0), 0x0007ff23 },
+   { _MMIO(0x27a4), 0xff00 },
+   { _MMIO(0x27a8), 0x0007fff3 },
+   { _MMIO(0x27ac), 0xfffe },
+};
+
+static const struct i915_oa_reg mux_config_compute_extended[] = {
+   { _MMIO(0x2681c), 0x3eb00800 },
+   { _MMIO(0x26820), 0x0090 },
+   { _MMIO(0x25384), 0x02aa },
+   { _MMIO(0x25404), 0x03ff },
+   { _MMIO(0x26800), 0x00142284 },
+   { _MMIO(0x26808), 0x0e629062 },
+   { _MMIO(0x2680c), 0x3f6f55cb },
+   { _MMIO(0x26810), 0x0014 },
+   { _MMIO(0x26804), 0x },
+   { _MMIO(0x26104), 0x02aa },
+   { 

[PATCH v5 09/11] drm/i915: add oa_event_min_timer_exponent sysctl

[Robert Bragg]

The minimal sampling period is now configurable via a
dev.i915.oa_min_timer_exponent sysctl parameter.

Following the precedent set by perf, the default is the minimum that
won't (on its own) exceed the default kernel.perf_event_max_sample_rate
default of 10 samples/s.

Signed-off-by: Robert Bragg 
---
 drivers/gpu/drm/i915/i915_perf.c | 42 
 1 file changed, 30 insertions(+), 12 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c
index 38b13fa..a7a248b 100644
--- a/drivers/gpu/drm/i915/i915_perf.c
+++ b/drivers/gpu/drm/i915/i915_perf.c
@@ -74,6 +74,23 @@ static u32 i915_perf_stream_paranoid = true;
  */
 #define OA_EXPONENT_MAX 31

+/* for sysctl proc_dointvec_minmax of i915_oa_min_timer_exponent */
+static int zero;
+static int oa_exponent_max = OA_EXPONENT_MAX;
+
+/* Theoretically we can program the OA unit to sample every 160ns but don't
+ * allow that by default unless root...
+ *
+ * The period is derived from the exponent as:
+ *
+ *   period = 80ns * 2^(exponent + 1)
+ *
+ * Referring to perf's kernel.perf_event_max_sample_rate for a precedent
+ * (10 by default); with an OA exponent of 6 we get a period of 10.240
+ * microseconds - just under 10Hz
+ */
+static u32 i915_oa_min_timer_exponent = 6;
+
 /* XXX: beware if future OA HW adds new report formats that the current
  * code assumes all reports have a power-of-two size and ~(size - 1) can
  * be used as a mask to align the OA tail pointer.
@@ -1315,21 +1332,13 @@ static int read_properties_unlocked(struct 
drm_i915_private *dev_priv,
return -EINVAL;
}

-   /* NB: The exponent represents a period as follows:
-*
-*   80ns * 2^(period_exponent + 1)
-*
-* Theoretically we can program the OA unit to sample
+   /* Theoretically we can program the OA unit to sample
 * every 160ns but don't allow that by default unless
 * root.
-*
-* Referring to perf's
-* kernel.perf_event_max_sample_rate for a precedent
-* (10 by default); with an OA exponent of 6 we get
-* a period of 10.240 microseconds -just under 10Hz
 */
-   if (value < 6 && !capable(CAP_SYS_ADMIN)) {
-   DRM_ERROR("Sampling period too high without 
root privileges\n");
+   if (value < i915_oa_min_timer_exponent &&
+   !capable(CAP_SYS_ADMIN)) {
+   DRM_ERROR("OA timer exponent too low without 
root privileges\n");
return -EACCES;
}

@@ -1433,6 +1442,15 @@ static struct ctl_table oa_table[] = {
 .mode = 0644,
 .proc_handler = proc_dointvec,
 },
+   {
+.procname = "oa_min_timer_exponent",
+.data = _oa_min_timer_exponent,
+.maxlen = sizeof(i915_oa_min_timer_exponent),
+.mode = 0644,
+.proc_handler = proc_dointvec_minmax,
+.extra1 = ,
+.extra2 = _exponent_max,
+},
{}
 };

-- 
2.9.2

[PATCH v5 08/11] drm/i915: Add dev.i915.perf_event_paranoid sysctl option

[Robert Bragg]

Consistent with the kernel.perf_event_paranoid sysctl option that can
allow non-root users to access system wide cpu metrics, this can
optionally allow non-root users to access system wide OA counter metrics
from Gen graphics hardware.

Signed-off-by: Robert Bragg 
---
 drivers/gpu/drm/i915/i915_drv.h  |  1 +
 drivers/gpu/drm/i915/i915_perf.c | 45 +++-
 2 files changed, 45 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index f5ddf70..eaba7a9 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2142,6 +2142,7 @@ struct drm_i915_private {
bool initialized;

struct kobject *metrics_kobj;
+   struct ctl_table_header *sysctl_header;

struct mutex lock;
struct list_head streams;
diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c
index e890c38..38b13fa 100644
--- a/drivers/gpu/drm/i915/i915_perf.c
+++ b/drivers/gpu/drm/i915/i915_perf.c
@@ -62,6 +62,8 @@
 #define POLL_FREQUENCY 200
 #define POLL_PERIOD (NSEC_PER_SEC / POLL_FREQUENCY)

+static u32 i915_perf_stream_paranoid = true;
+
 /* The maximum exponent the hardware accepts is 63 (essentially it selects one
  * of the 64bit timestamp bits to trigger reports from) but there's currently
  * no known use case for sampling as infrequently as once per 47 thousand 
years.
@@ -1170,7 +1172,13 @@ int i915_perf_open_ioctl_locked(struct drm_device *dev,
}
}

-   if (!specific_ctx && !capable(CAP_SYS_ADMIN)) {
+   /* Similar to perf's kernel.perf_paranoid_cpu sysctl option
+* we check a dev.i915.perf_stream_paranoid sysctl option
+* to determine if it's ok to access system wide OA counters
+* without CAP_SYS_ADMIN privileges.
+*/
+   if (!specific_ctx &&
+   i915_perf_stream_paranoid && !capable(CAP_SYS_ADMIN)) {
DRM_ERROR("Insufficient privileges to open system-wide i915 
perf stream\n");
ret = -EACCES;
goto err_ctx;
@@ -1417,6 +1425,37 @@ void i915_perf_unregister(struct drm_i915_private 
*dev_priv)
dev_priv->perf.metrics_kobj = NULL;
 }

+static struct ctl_table oa_table[] = {
+   {
+.procname = "perf_stream_paranoid",
+.data = _perf_stream_paranoid,
+.maxlen = sizeof(i915_perf_stream_paranoid),
+.mode = 0644,
+.proc_handler = proc_dointvec,
+},
+   {}
+};
+
+static struct ctl_table i915_root[] = {
+   {
+.procname = "i915",
+.maxlen = 0,
+.mode = 0555,
+.child = oa_table,
+},
+   {}
+};
+
+static struct ctl_table dev_root[] = {
+   {
+.procname = "dev",
+.maxlen = 0,
+.mode = 0555,
+.child = i915_root,
+},
+   {}
+};
+
 void i915_perf_init(struct drm_i915_private *dev_priv)
 {
if (!IS_HASWELL(dev_priv))
@@ -1449,6 +1488,8 @@ void i915_perf_init(struct drm_i915_private *dev_priv)
dev_priv->perf.oa.n_builtin_sets =
i915_oa_n_builtin_metric_sets_hsw;

+   dev_priv->perf.sysctl_header = register_sysctl_table(dev_root);
+
dev_priv->perf.initialized = true;
 }

@@ -1457,6 +1498,8 @@ void i915_perf_fini(struct drm_i915_private *dev_priv)
if (!dev_priv->perf.initialized)
return;

+   unregister_sysctl_table(dev_priv->perf.sysctl_header);
+
memset(_priv->perf.oa.ops, 0, sizeof(dev_priv->perf.oa.ops));
dev_priv->perf.initialized = false;
 }
-- 
2.9.2

[PATCH v5 07/11] drm/i915: advertise available metrics via sysfs

[Robert Bragg]

Each metric set is given a sysfs entry like:

/sys/class/drm/card0/metrics//id

This allows userspace to enumerate the specific sets that are available
for the current system. The 'id' file contains an unsigned integer that
can be used to open the associated metric set via
DRM_IOCTL_I915_PERF_OPEN. The  is a globally unique ID for a
specific OA unit register configuration that can be reliably used by
userspace as a key to lookup corresponding counter meta data and
normalization equations.

The guid registry is currently maintained as part of gputop along with
the XML metric set descriptions and code generation scripts, ref:

 https://github.com/rib/gputop
 > gputop-data/guids.xml
 > scripts/update-guids.py
 > gputop-data/oa-*.xml
 > scripts/i915-perf-kernelgen.py

 $ make -C gputop-data -f Makefile.xml SYSFS=1 WHITELIST=RenderBasic

Signed-off-by: Robert Bragg 
---
 drivers/gpu/drm/i915/i915_drv.c|  5 
 drivers/gpu/drm/i915/i915_drv.h|  4 +++
 drivers/gpu/drm/i915/i915_oa_hsw.c | 51 +
 drivers/gpu/drm/i915/i915_oa_hsw.h |  4 +++
 drivers/gpu/drm/i915/i915_perf.c   | 52 ++
 5 files changed, 116 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 14f22fc..8965df2 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -1125,6 +1125,9 @@ static void i915_driver_register(struct drm_i915_private 
*dev_priv)
if (drm_dev_register(dev, 0) == 0) {
i915_debugfs_register(dev_priv);
i915_setup_sysfs(dev_priv);
+
+   /* Depends on sysfs having been initialized */
+   i915_perf_register(dev_priv);
} else
DRM_ERROR("Failed to register driver for userspace access!\n");

@@ -1161,6 +1164,8 @@ static void i915_driver_unregister(struct 
drm_i915_private *dev_priv)
acpi_video_unregister();
intel_opregion_unregister(dev_priv);

+   i915_perf_unregister(dev_priv);
+
i915_teardown_sysfs(dev_priv);
i915_debugfs_unregister(dev_priv);
drm_dev_unregister(_priv->drm);
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 551f078..f5ddf70 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2141,6 +2141,8 @@ struct drm_i915_private {
struct {
bool initialized;

+   struct kobject *metrics_kobj;
+
struct mutex lock;
struct list_head streams;

@@ -3711,6 +3713,8 @@ int intel_engine_cmd_parser(struct intel_engine_cs 
*engine,
 /* i915_perf.c */
 extern void i915_perf_init(struct drm_i915_private *dev_priv);
 extern void i915_perf_fini(struct drm_i915_private *dev_priv);
+extern void i915_perf_register(struct drm_i915_private *dev_priv);
+extern void i915_perf_unregister(struct drm_i915_private *dev_priv);

 /* i915_suspend.c */
 extern int i915_save_state(struct drm_device *dev);
diff --git a/drivers/gpu/drm/i915/i915_oa_hsw.c 
b/drivers/gpu/drm/i915/i915_oa_hsw.c
index eb5ceca..656334d 100644
--- a/drivers/gpu/drm/i915/i915_oa_hsw.c
+++ b/drivers/gpu/drm/i915/i915_oa_hsw.c
@@ -24,6 +24,8 @@
  *
  */

+#include 
+
 #include "i915_drv.h"

 enum metric_set_id {
@@ -141,3 +143,52 @@ int i915_oa_select_metric_set_hsw(struct drm_i915_private 
*dev_priv)
return -ENODEV;
}
 }
+
+static ssize_t
+show_render_basic_id(struct device *kdev, struct device_attribute *attr, char 
*buf)
+{
+   return sprintf(buf, "%d\n", METRIC_SET_ID_RENDER_BASIC);
+}
+
+static struct device_attribute dev_attr_render_basic_id = {
+   .attr = { .name = "id", .mode = S_IRUGO },
+   .show = show_render_basic_id,
+   .store = NULL,
+};
+
+static struct attribute *attrs_render_basic[] = {
+   _attr_render_basic_id.attr,
+   NULL,
+};
+
+static struct attribute_group group_render_basic = {
+   .name = "403d8832-1a27-4aa6-a64e-f5389ce7b212",
+   .attrs =  attrs_render_basic,
+};
+
+int
+i915_perf_register_sysfs_hsw(struct drm_i915_private *dev_priv)
+{
+   int mux_len;
+   int ret = 0;
+
+   if (get_render_basic_mux_config(dev_priv, _len)) {
+   ret = sysfs_create_group(dev_priv->perf.metrics_kobj, 
_render_basic);
+   if (ret)
+   goto error_render_basic;
+   }
+
+   return 0;
+
+error_render_basic:
+   return ret;
+}
+
+void
+i915_perf_unregister_sysfs_hsw(struct drm_i915_private *dev_priv)
+{
+   int mux_len;
+
+   if (get_render_basic_mux_config(dev_priv, _len))
+   sysfs_remove_group(dev_priv->perf.metrics_kobj, 
_render_basic);
+}
diff --git a/drivers/gpu/drm/i915/i915_oa_hsw.h 
b/drivers/gpu/drm/i915/i915_oa_hsw.h
index b618a1f..429a229 100644
--- a/drivers/gpu/drm/i915/i915_oa_hsw.h
+++ b/drivers/gpu/drm/i915/i915_oa_hsw.h
@@ -31,4 +31,8 @@ extern int i915_oa_n_builtin_metric_sets_hsw;

 extern int 

[PATCH v5 06/11] drm/i915: Enable i915 perf stream for Haswell OA unit

[Robert Bragg]

Gen graphics hardware can be set up to periodically write snapshots of
performance counters into a circular buffer via its Observation
Architecture and this patch exposes that capability to userspace via the
i915 perf interface.

Cc: Chris Wilson 
Signed-off-by: Robert Bragg 
Signed-off-by: Zhenyu Wang 
---
 drivers/gpu/drm/i915/i915_drv.h |  72 ++-
 drivers/gpu/drm/i915/i915_gem_context.c |  22 +-
 drivers/gpu/drm/i915/i915_perf.c| 998 +++-
 drivers/gpu/drm/i915/i915_reg.h | 338 +++
 drivers/gpu/drm/i915/intel_ringbuffer.c |  10 +-
 include/uapi/drm/i915_drm.h |  70 ++-
 6 files changed, 1477 insertions(+), 33 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 5fad018..551f078 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1740,6 +1740,11 @@ struct intel_wm_config {
bool sprites_scaled;
 };

+struct i915_oa_format {
+   u32 format;
+   int size;
+};
+
 struct i915_oa_reg {
i915_reg_t addr;
u32 value;
@@ -1760,11 +1765,6 @@ struct i915_perf_stream_ops {
 */
void (*disable)(struct i915_perf_stream *stream);

-   /* Return: true if any i915 perf records are ready to read()
-* for this stream.
-*/
-   bool (*can_read)(struct i915_perf_stream *stream);
-
/* Call poll_wait, passing a wait queue that will be woken
 * once there is something ready to read() for the stream
 */
@@ -1774,9 +1774,7 @@ struct i915_perf_stream_ops {

/* For handling a blocking read, wait until there is something
 * to ready to read() for the stream. E.g. wait on the same
-* wait queue that would be passed to poll_wait() until
-* ->can_read() returns true (if its safe to call ->can_read()
-* without the i915 perf lock held).
+* wait queue that would be passed to poll_wait().
 */
int (*wait_unlocked)(struct i915_perf_stream *stream);

@@ -1816,11 +1814,28 @@ struct i915_perf_stream {
struct list_head link;

u32 sample_flags;
+   int sample_size;

struct i915_gem_context *ctx;
bool enabled;

-   struct i915_perf_stream_ops *ops;
+   const struct i915_perf_stream_ops *ops;
+};
+
+struct i915_oa_ops {
+   void (*init_oa_buffer)(struct drm_i915_private *dev_priv);
+   int (*enable_metric_set)(struct drm_i915_private *dev_priv);
+   void (*disable_metric_set)(struct drm_i915_private *dev_priv);
+   void (*oa_enable)(struct drm_i915_private *dev_priv);
+   void (*oa_disable)(struct drm_i915_private *dev_priv);
+   void (*update_oacontrol)(struct drm_i915_private *dev_priv);
+   void (*update_hw_ctx_id_locked)(struct drm_i915_private *dev_priv,
+   u32 ctx_id);
+   int (*read)(struct i915_perf_stream *stream,
+   char __user *buf,
+   size_t count,
+   size_t *offset);
+   bool (*oa_buffer_is_empty)(struct drm_i915_private *dev_priv);
 };

 struct drm_i915_private {
@@ -2125,16 +2140,48 @@ struct drm_i915_private {

struct {
bool initialized;
+
struct mutex lock;
struct list_head streams;

+   spinlock_t hook_lock;
+
struct {
-   u32 metrics_set;
+   struct i915_perf_stream *exclusive_stream;
+
+   u32 specific_ctx_id;
+
+   struct hrtimer poll_check_timer;
+   wait_queue_head_t poll_wq;
+   atomic_t pollin;
+
+   bool periodic;
+   int period_exponent;
+   int timestamp_frequency;
+
+   int tail_margin;
+
+   int metrics_set;

const struct i915_oa_reg *mux_regs;
int mux_regs_len;
const struct i915_oa_reg *b_counter_regs;
int b_counter_regs_len;
+
+   struct {
+   struct drm_i915_gem_object *obj;
+   struct i915_vma *vma;
+   u32 gtt_offset;
+   u8 *addr;
+   int format;
+   int format_size;
+   } oa_buffer;
+
+   u32 gen7_latched_oastatus1;
+
+   struct i915_oa_ops ops;
+   const struct i915_oa_format *oa_formats;
+   int n_builtin_sets;
} oa;
} perf;

@@ -3499,6 +3546,9 @@ struct drm_i915_gem_object *
 i915_gem_alloc_context_obj(struct drm_device *dev, size_t size);
 struct i915_gem_context *
 i915_gem_context_create_gvt(struct drm_device *dev);
+int 

[PATCH v5 05/11] drm/i915: Add 'render basic' Haswell OA unit config

[Robert Bragg]

Adds a static OA unit, MUX + B Counter configuration for basic render
metrics on Haswell. This is auto generated from an XML
description of metric sets, currently maintained in gputop, ref:

  https://github.com/rib/gputop
  > gputop-data/oa-*.xml
  > scripts/i915-perf-kernelgen.py

  $ make -C gputop-data -f Makefile.xml SYSFS=0 WHITELIST=RenderBasic

Signed-off-by: Robert Bragg 
---
 drivers/gpu/drm/i915/Makefile  |   3 +-
 drivers/gpu/drm/i915/i915_drv.h|  14 
 drivers/gpu/drm/i915/i915_oa_hsw.c | 143 +
 drivers/gpu/drm/i915/i915_oa_hsw.h |  34 +
 4 files changed, 193 insertions(+), 1 deletion(-)
 create mode 100644 drivers/gpu/drm/i915/i915_oa_hsw.c
 create mode 100644 drivers/gpu/drm/i915/i915_oa_hsw.h

diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index d991781..6cb25dd 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -111,7 +111,8 @@ i915-y += dvo_ch7017.o \
 i915-y += i915_vgpu.o

 # perf code
-i915-y += i915_perf.o
+i915-y += i915_perf.o \
+ i915_oa_hsw.o

 ifeq ($(CONFIG_DRM_I915_GVT),y)
 i915-y += intel_gvt.o
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 0f5cd8f..5fad018 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1740,6 +1740,11 @@ struct intel_wm_config {
bool sprites_scaled;
 };

+struct i915_oa_reg {
+   i915_reg_t addr;
+   u32 value;
+};
+
 struct i915_perf_stream;

 struct i915_perf_stream_ops {
@@ -2122,6 +2127,15 @@ struct drm_i915_private {
bool initialized;
struct mutex lock;
struct list_head streams;
+
+   struct {
+   u32 metrics_set;
+
+   const struct i915_oa_reg *mux_regs;
+   int mux_regs_len;
+   const struct i915_oa_reg *b_counter_regs;
+   int b_counter_regs_len;
+   } oa;
} perf;

/* Abstract the submission mechanism (legacy ringbuffer or execlists) 
away */
diff --git a/drivers/gpu/drm/i915/i915_oa_hsw.c 
b/drivers/gpu/drm/i915/i915_oa_hsw.c
new file mode 100644
index 000..eb5ceca
--- /dev/null
+++ b/drivers/gpu/drm/i915/i915_oa_hsw.c
@@ -0,0 +1,143 @@
+/*
+ * Autogenerated file, DO NOT EDIT manually!
+ *
+ * Copyright (c) 2015 Intel Corporation
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
+ * IN THE SOFTWARE.
+ *
+ */
+
+#include "i915_drv.h"
+
+enum metric_set_id {
+   METRIC_SET_ID_RENDER_BASIC = 1,
+};
+
+int i915_oa_n_builtin_metric_sets_hsw = 1;
+
+static const struct i915_oa_reg b_counter_config_render_basic[] = {
+   { _MMIO(0x2724), 0x0080 },
+   { _MMIO(0x2720), 0x },
+   { _MMIO(0x2714), 0x0080 },
+   { _MMIO(0x2710), 0x },
+};
+
+static const struct i915_oa_reg mux_config_render_basic[] = {
+   { _MMIO(0x253a4), 0x0160 },
+   { _MMIO(0x25440), 0x0010 },
+   { _MMIO(0x25128), 0x },
+   { _MMIO(0x2691c), 0x0800 },
+   { _MMIO(0x26aa0), 0x0150 },
+   { _MMIO(0x26b9c), 0x6000 },
+   { _MMIO(0x2791c), 0x0800 },
+   { _MMIO(0x27aa0), 0x0150 },
+   { _MMIO(0x27b9c), 0x6000 },
+   { _MMIO(0x2641c), 0x0400 },
+   { _MMIO(0x25380), 0x0010 },
+   { _MMIO(0x2538c), 0x },
+   { _MMIO(0x25384), 0x0800 },
+   { _MMIO(0x25400), 0x0004 },
+   { _MMIO(0x2540c), 0x06029000 },
+   { _MMIO(0x25410), 0x0002 },
+   { _MMIO(0x25404), 0x5c30 },
+   { _MMIO(0x25100), 0x0016 },
+   { _MMIO(0x25110), 0x0400 },
+   { _MMIO(0x25104), 0x },
+   { _MMIO(0x26804), 0x1211 },
+   { _MMIO(0x26884), 0x0100 },
+   { _MMIO(0x26900), 0x0002 },
+   { _MMIO(0x26908), 0x0070 },
+   { _MMIO(0x26904), 0x 

[PATCH v5 04/11] drm/i915: don't whitelist oacontrol in cmd parser

[Robert Bragg]

Being able to program OACONTROL from a non-privileged batch buffer is
not sufficient to be able to configure the OA unit. This was originally
allowed to help enable Mesa to expose OA counters via the
INTEL_performance_query extension, but the current implementation based
on programming OACONTROL via a batch buffer isn't able to report useable
data without a more complete OA unit configuration. Mesa handles the
possibility that writes to OACONTROL may not be allowed and so only
advertises the extension after explicitly testing that a write to
OACONTROL succeeds. Based on this; removing OACONTROL from the whitelist
should be ok for userspace.

Removing this simplifies adding a new kernel api for configuring the OA
unit without needing to consider the possibility that userspace might
trample on OACONTROL state which we'd like to start managing within
the kernel instead. In particular running any Mesa based GL application
currently results in clearing OACONTROL when initializing which would
disable the capturing of metrics.

Signed-off-by: Robert Bragg 
---
 drivers/gpu/drm/i915/i915_cmd_parser.c | 38 ++
 1 file changed, 2 insertions(+), 36 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_cmd_parser.c 
b/drivers/gpu/drm/i915/i915_cmd_parser.c
index 5ad02dc..bdee590 100644
--- a/drivers/gpu/drm/i915/i915_cmd_parser.c
+++ b/drivers/gpu/drm/i915/i915_cmd_parser.c
@@ -450,7 +450,6 @@ static const struct drm_i915_reg_descriptor 
gen7_render_regs[] = {
REG64(PS_INVOCATION_COUNT),
REG64(PS_DEPTH_COUNT),
REG64_IDX(RING_TIMESTAMP, RENDER_RING_BASE),
-   REG32(GEN7_OACONTROL), /* Only allowed for LRI and SRM. See below. */
REG64(MI_PREDICATE_SRC0),
REG64(MI_PREDICATE_SRC1),
REG32(GEN7_3DPRIM_END_OFFSET),
@@ -1060,8 +1059,7 @@ bool intel_engine_needs_cmd_parser(struct intel_engine_cs 
*engine)
 static bool check_cmd(const struct intel_engine_cs *engine,
  const struct drm_i915_cmd_descriptor *desc,
  const u32 *cmd, u32 length,
- const bool is_master,
- bool *oacontrol_set)
+ const bool is_master)
 {
if (desc->flags & CMD_DESC_SKIP)
return true;
@@ -1099,31 +1097,6 @@ static bool check_cmd(const struct intel_engine_cs 
*engine,
}

/*
-* OACONTROL requires some special handling for
-* writes. We want to make sure that any batch which
-* enables OA also disables it before the end of the
-* batch. The goal is to prevent one process from
-* snooping on the perf data from another process. To do
-* that, we need to check the value that will be written
-* to the register. Hence, limit OACONTROL writes to
-* only MI_LOAD_REGISTER_IMM commands.
-*/
-   if (reg_addr == i915_mmio_reg_offset(GEN7_OACONTROL)) {
-   if (desc->cmd.value == MI_LOAD_REGISTER_MEM) {
-   DRM_DEBUG_DRIVER("CMD: Rejected LRM to 
OACONTROL\n");
-   return false;
-   }
-
-   if (desc->cmd.value == MI_LOAD_REGISTER_REG) {
-   DRM_DEBUG_DRIVER("CMD: Rejected LRR to 
OACONTROL\n");
-   return false;
-   }
-
-   if (desc->cmd.value == MI_LOAD_REGISTER_IMM(1))
-   *oacontrol_set = (cmd[offset + 1] != 0);
-   }
-
-   /*
 * Check the value written to the register against the
 * allowed mask/value pair given in the whitelist entry.
 */
@@ -1214,7 +1187,6 @@ int intel_engine_cmd_parser(struct intel_engine_cs 
*engine,
u32 *cmd, *batch_end;
struct drm_i915_cmd_descriptor default_desc = noop_desc;
const struct drm_i915_cmd_descriptor *desc = _desc;
-   bool oacontrol_set = false; /* OACONTROL tracking. See check_cmd() */
bool needs_clflush_after = false;
int ret = 0;

@@ -1270,8 +1242,7 @@ int intel_engine_cmd_parser(struct intel_engine_cs 
*engine,
break;
}

-   if (!check_cmd(engine, desc, cmd, length, is_master,
-  _set)) {
+   if (!check_cmd(engine, desc, cmd, length, is_master)) {
ret = -EACCES;
break;
}
@@ -1279,11 +1250,6 @@ int intel_engine_cmd_parser(struct intel_engine_cs 
*engine,
cmd += length;
}

-   if (oacontrol_set) {
-  

[PATCH v5 03/11] drm/i915: return EACCES for check_cmd() failures

[Robert Bragg]

check_cmd() is checking whether a command adheres to certain
restrictions that ensure it's safe to execute within a privileged batch
buffer. Returning false implies a privilege problem, not that the
command is invalid.

The distinction makes the difference between allowing the buffer to be
executed as an unprivileged batch buffer or returning an EINVAL error to
userspace without executing anything.

In a case where userspace may want to test whether it can successfully
write to a register that needs privileges the distinction may be
important and an EINVAL error may be considered fatal.

In particular this is currently true for Mesa, which includes a test for
whether OACONTROL can be written too, but Mesa treats any error when
flushing a batch buffer as fatal, calling exit(1).

As it is currently Mesa can gracefully handle a failure to write to
OACONTROL if the command parser is disabled, but if we were to remove
OACONTROL from the parser's whitelist then the returned EINVAL would
break Mesa applications as they attempt an OACONTROL write.

Signed-off-by: Robert Bragg 
---
 drivers/gpu/drm/i915/i915_cmd_parser.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_cmd_parser.c 
b/drivers/gpu/drm/i915/i915_cmd_parser.c
index 7269fe8..5ad02dc 100644
--- a/drivers/gpu/drm/i915/i915_cmd_parser.c
+++ b/drivers/gpu/drm/i915/i915_cmd_parser.c
@@ -1272,7 +1272,7 @@ int intel_engine_cmd_parser(struct intel_engine_cs 
*engine,

if (!check_cmd(engine, desc, cmd, length, is_master,
   _set)) {
-   ret = -EINVAL;
+   ret = -EACCES;
break;
}

-- 
2.9.2

[PATCH v5 02/11] drm/i915: rename OACONTROL GEN7_OACONTROL

[Robert Bragg]

OACONTROL changes quite a bit for gen8, with some bits split out into a
per-context OACTXCONTROL register. Rename now before adding more gen7 OA
registers

Signed-off-by: Robert Bragg 
---
 drivers/gpu/drm/i915/i915_cmd_parser.c | 4 ++--
 drivers/gpu/drm/i915/i915_reg.h| 2 +-
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_cmd_parser.c 
b/drivers/gpu/drm/i915/i915_cmd_parser.c
index 3c72b3b..7269fe8 100644
--- a/drivers/gpu/drm/i915/i915_cmd_parser.c
+++ b/drivers/gpu/drm/i915/i915_cmd_parser.c
@@ -450,7 +450,7 @@ static const struct drm_i915_reg_descriptor 
gen7_render_regs[] = {
REG64(PS_INVOCATION_COUNT),
REG64(PS_DEPTH_COUNT),
REG64_IDX(RING_TIMESTAMP, RENDER_RING_BASE),
-   REG32(OACONTROL), /* Only allowed for LRI and SRM. See below. */
+   REG32(GEN7_OACONTROL), /* Only allowed for LRI and SRM. See below. */
REG64(MI_PREDICATE_SRC0),
REG64(MI_PREDICATE_SRC1),
REG32(GEN7_3DPRIM_END_OFFSET),
@@ -1108,7 +1108,7 @@ static bool check_cmd(const struct intel_engine_cs 
*engine,
 * to the register. Hence, limit OACONTROL writes to
 * only MI_LOAD_REGISTER_IMM commands.
 */
-   if (reg_addr == i915_mmio_reg_offset(OACONTROL)) {
+   if (reg_addr == i915_mmio_reg_offset(GEN7_OACONTROL)) {
if (desc->cmd.value == MI_LOAD_REGISTER_MEM) {
DRM_DEBUG_DRIVER("CMD: Rejected LRM to 
OACONTROL\n");
return false;
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index a29d707..90756b2 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -616,7 +616,7 @@ static inline bool i915_mmio_reg_valid(i915_reg_t reg)
 #define HSW_CS_GPR(n)   _MMIO(0x2600 + (n) * 8)
 #define HSW_CS_GPR_UDW(n)   _MMIO(0x2600 + (n) * 8 + 4)

-#define OACONTROL _MMIO(0x2360)
+#define GEN7_OACONTROL _MMIO(0x2360)

 #define _GEN7_PIPEA_DE_LOAD_SL 0x70068
 #define _GEN7_PIPEB_DE_LOAD_SL 0x71068
-- 
2.9.2

[PATCH v5 01/11] drm/i915: Add i915 perf infrastructure

[Robert Bragg]

Adds base i915 perf infrastructure for Gen performance metrics.

This adds a DRM_IOCTL_I915_PERF_OPEN ioctl that takes an array of uint64
properties to configure a stream of metrics and returns a new fd usable
with standard VFS system calls including read() to read typed and sized
records; ioctl() to enable or disable capture and poll() to wait for
data.

A stream is opened something like:

  uint64_t properties[] = {
  /* Single context sampling */
  DRM_I915_PERF_PROP_CTX_HANDLE,ctx_handle,

  /* Include OA reports in samples */
  DRM_I915_PERF_PROP_SAMPLE_OA, true,

  /* OA unit configuration */
  DRM_I915_PERF_PROP_OA_METRICS_SET,metrics_set_id,
  DRM_I915_PERF_PROP_OA_FORMAT, report_format,
  DRM_I915_PERF_PROP_OA_EXPONENT,   period_exponent,
   };
   struct drm_i915_perf_open_param parm = {
  .flags = I915_PERF_FLAG_FD_CLOEXEC |
   I915_PERF_FLAG_FD_NONBLOCK |
   I915_PERF_FLAG_DISABLED,
  .properties_ptr = (uint64_t)properties,
  .num_properties = sizeof(properties) / 16,
   };
   int fd = drmIoctl(drm_fd, DRM_IOCTL_I915_PERF_OPEN, );

Records read all start with a common { type, size } header with
DRM_I915_PERF_RECORD_SAMPLE being of most interest. Sample records
contain an extensible number of fields and it's the
DRM_I915_PERF_PROP_SAMPLE_xyz properties given when opening that
determine what's included in every sample.

No specific streams are supported yet so any attempt to open a stream
will return an error.

Signed-off-by: Robert Bragg 
---
 drivers/gpu/drm/i915/Makefile|   3 +
 drivers/gpu/drm/i915/i915_drv.c  |   4 +
 drivers/gpu/drm/i915/i915_drv.h  |  91 
 drivers/gpu/drm/i915/i915_perf.c | 448 +++
 include/uapi/drm/i915_drm.h  |  67 ++
 5 files changed, 613 insertions(+)
 create mode 100644 drivers/gpu/drm/i915/i915_perf.c

diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index a998c2b..d991781 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -110,6 +110,9 @@ i915-y += dvo_ch7017.o \
 # virtual gpu code
 i915-y += i915_vgpu.o

+# perf code
+i915-y += i915_perf.o
+
 ifeq ($(CONFIG_DRM_I915_GVT),y)
 i915-y += intel_gvt.o
 include $(src)/gvt/Makefile
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 7f4e8ad..14f22fc 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -838,6 +838,8 @@ static int i915_driver_init_early(struct drm_i915_private 
*dev_priv,

intel_device_info_dump(dev_priv);

+   i915_perf_init(dev_priv);
+
/* Not all pre-production machines fall into this category, only the
 * very first ones. Almost everything should work, except for maybe
 * suspend/resume. And we don't implement workarounds that affect only
@@ -859,6 +861,7 @@ err_workqueues:
  */
 static void i915_driver_cleanup_early(struct drm_i915_private *dev_priv)
 {
+   i915_perf_fini(dev_priv);
i915_gem_load_cleanup(_priv->drm);
i915_workqueues_cleanup(dev_priv);
 }
@@ -2560,6 +2563,7 @@ static const struct drm_ioctl_desc i915_ioctls[] = {
DRM_IOCTL_DEF_DRV(I915_GEM_USERPTR, i915_gem_userptr_ioctl, 
DRM_RENDER_ALLOW),
DRM_IOCTL_DEF_DRV(I915_GEM_CONTEXT_GETPARAM, 
i915_gem_context_getparam_ioctl, DRM_RENDER_ALLOW),
DRM_IOCTL_DEF_DRV(I915_GEM_CONTEXT_SETPARAM, 
i915_gem_context_setparam_ioctl, DRM_RENDER_ALLOW),
+   DRM_IOCTL_DEF_DRV(I915_PERF_OPEN, i915_perf_open_ioctl, 
DRM_RENDER_ALLOW),
 };

 static struct drm_driver driver = {
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 1e2dda8..0f5cd8f 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1740,6 +1740,84 @@ struct intel_wm_config {
bool sprites_scaled;
 };

+struct i915_perf_stream;
+
+struct i915_perf_stream_ops {
+   /* Enables the collection of HW samples, either in response to
+* I915_PERF_IOCTL_ENABLE or implicitly called when stream is
+* opened without I915_PERF_FLAG_DISABLED.
+*/
+   void (*enable)(struct i915_perf_stream *stream);
+
+   /* Disables the collection of HW samples, either in response to
+* I915_PERF_IOCTL_DISABLE or implicitly called before
+* destroying the stream.
+*/
+   void (*disable)(struct i915_perf_stream *stream);
+
+   /* Return: true if any i915 perf records are ready to read()
+* for this stream.
+*/
+   bool (*can_read)(struct i915_perf_stream *stream);
+
+   /* Call poll_wait, passing a wait queue that will be woken
+* once there is something ready to read() for the stream
+*/
+   void (*poll_wait)(struct i915_perf_stream *stream,
+ struct file *file,
+ poll_table *wait);
+
+   /* For handling a blocking read, wait until there 

[PATCH v5 00/11] Enable i915 perf stream for Haswell OA unit

[Robert Bragg]

This just rebases my i915 perf series on a recent drm-intel-nightly.

Considering now that this series has been reviewed a number of times by Chris,
and I think I've responded to his feedback: I wonder if this series is ready
to be added to drm-intel-nightly soon?

I think most of the effort for this series at the moment is just keeping up
with rebasing on nightlies.

Regards,
- Robert

Robert Bragg (11):
  drm/i915: Add i915 perf infrastructure
  drm/i915: rename OACONTROL GEN7_OACONTROL
  drm/i915: return EACCES for check_cmd() failures
  drm/i915: don't whitelist oacontrol in cmd parser
  drm/i915: Add 'render basic' Haswell OA unit config
  drm/i915: Enable i915 perf stream for Haswell OA unit
  drm/i915: advertise available metrics via sysfs
  drm/i915: Add dev.i915.perf_event_paranoid sysctl option
  drm/i915: add oa_event_min_timer_exponent sysctl
  drm/i915: Add more Haswell OA metric sets
  drm/i915: Add a kerneldoc summary for i915_perf.c

 drivers/gpu/drm/i915/Makefile   |4 +
 drivers/gpu/drm/i915/i915_cmd_parser.c  |   40 +-
 drivers/gpu/drm/i915/i915_drv.c |9 +
 drivers/gpu/drm/i915/i915_drv.h |  162 +++
 drivers/gpu/drm/i915/i915_gem_context.c |   22 +-
 drivers/gpu/drm/i915/i915_oa_hsw.c  |  751 ++
 drivers/gpu/drm/i915/i915_oa_hsw.h  |   38 +
 drivers/gpu/drm/i915/i915_perf.c| 1686 +++
 drivers/gpu/drm/i915/i915_reg.h |  340 ++-
 drivers/gpu/drm/i915/intel_ringbuffer.c |   10 +-
 include/uapi/drm/i915_drm.h |  133 +++
 11 files changed, 3154 insertions(+), 41 deletions(-)
 create mode 100644 drivers/gpu/drm/i915/i915_oa_hsw.c
 create mode 100644 drivers/gpu/drm/i915/i915_oa_hsw.h
 create mode 100644 drivers/gpu/drm/i915/i915_perf.c

-- 
2.9.2

[PATCH v4 02/14] drm: Implement the drm_format_*() helpers as drm_format_info() wrappers

[Tomi Valkeinen]

On 08/09/16 17:44, Laurent Pinchart wrote:
> Turn the drm_format_*() helpers into wrappers around the drm_format_info
> lookup function to centralize all format information in a single place.
> 
> Signed-off-by: Laurent Pinchart 
> ---
>  drivers/gpu/drm/drm_fourcc.c | 186 
> +--
>  1 file changed, 37 insertions(+), 149 deletions(-)

Reviewed-by: Tomi Valkeinen 

 Tomi

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

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

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

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

--- Comment #1 from Laurent carlier  ---
Oops it's with kernel 4.7.3

-- 
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/20160914/5a72e250/attachment.html>

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

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

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

Bug ID: 97806
   Summary: GPU lockup with mesa-git and llvm-svn with rx 470 on
Unigine Heaven and TombRaider 2013
   Product: Mesa
   Version: git
  Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
  Severity: blocker
  Priority: medium
 Component: Drivers/Gallium/radeonsi
  Assignee: dri-devel at lists.freedesktop.org
  Reporter: lordheavym at gmail.com
QA Contact: dri-devel at lists.freedesktop.org

Just swithed from a R9 380 to a RX 470, from the first tests i have a GPU
lockup on the first frames  with Unigine Heaven and Tom Raider 2013 benchmark.

* mesa-git a1e49b / llvm-svn trunk 281305
* AMD RX 470 nitro+ OC 8gB - AMD POLARIS10 (DRM 3.2.0 / 4.7.3-2-ARCH, LLVM
4.0.0) (0x67df)
* latest linux-firmware

It doesn't lockup with mesa-12.0.2 with llvm-3.8.1
I've also tried mesa-git with llvm-3.8.1 and it doesn't lockup too.

-- 
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/20160914/ba2cd3db/attachment.html>

[Bug 97634] [amdgpu SI] multigpu setup crashes during boot when dpm=1

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

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

--- Comment #3 from Arek Ruśniak  ---
Created attachment 126519
  --> https://bugs.freedesktop.org/attachment.cgi?id=126519=edit
dmesg log with latest drm-next-4.9-wip: 97231a9

unfortunately it doesn't
when bug 97801 is solved now, kernel log looks like similar for the first log

[   90.544035] 
amdgpu :01:00.0: fb1: amdgpudrmfb frame buffer device
[drm:gfx_v6_0_ring_test_ib [amdgpu]] *ERROR* amdgpu: IB test timed out
[drm:amdgpu_ib_ring_tests [amdgpu]] *ERROR* amdgpu: failed testing IB on GFX
ring (-110).
[drm:amdgpu_device_init [amdgpu]] *ERROR* ib ring test failed (-110).
[drm] Initialized amdgpu 3.6.0 20150101 for :01:00.0 on minor 1
NMI watchdog: BUG: soft lockup - CPU#0 stuck for 23s! [swapper/0:0]

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

[PATCH v4 01/14] drm: Centralize format information

[Tomi Valkeinen]

U,.depth = 0,  
> .num_planes = 1, .cpp = { 2, 0, 0 }, .hsub = 2, .vsub = 1 },
> + { .format = DRM_FORMAT_UYVY,.depth = 0,  
> .num_planes = 1, .cpp = { 2, 0, 0 }, .hsub = 2, .vsub = 1 },
> + { .format = DRM_FORMAT_VYUY,.depth = 0,  
> .num_planes = 1, .cpp = { 2, 0, 0 }, .hsub = 2, .vsub = 1 },
> + { .format = DRM_FORMAT_AYUV,.depth = 0,  
> .num_planes = 1, .cpp = { 4, 0, 0 }, .hsub = 1, .vsub = 1 },
> + };
> +
> + unsigned int i;
> +
> + for (i = 0; i < ARRAY_SIZE(formats); ++i) {
> + if (formats[i].format == format)
> + return [i];
> + }
> +
> + return NULL;
> +}
> +EXPORT_SYMBOL(drm_format_info);
> +
> +/**
>   * drm_fb_get_bpp_depth - get the bpp/depth values for format
>   * @format: pixel format (DRM_FORMAT_*)
>   * @depth: storage for the depth value
> diff --git a/include/drm/drm_fourcc.h b/include/drm/drm_fourcc.h
> index 30c30fa87ee8..4e79d6159856 100644
> --- a/include/drm/drm_fourcc.h
> +++ b/include/drm/drm_fourcc.h
> @@ -25,6 +25,25 @@
>  #include 
>  #include 
>  
> +/**
> + * struct drm_format_info - information about a DRM format
> + * @format: 4CC format identifier (DRM_FORMAT_*)
> + * @depth: color depth (number of bits per pixel excluding padding bits)

Depth is zero for yuv formats. Maybe that should be made clear here.

 Tomi

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

[PATCH v7 7/9] drm/mediatek: add dsi transfer function

[CK Hu]

Hi, YT:

On Wed, 2016-09-14 at 14:19 +0800, YT Shen wrote:
> Hi CK,
> 
> On Tue, 2016-09-13 at 17:25 +0800, CK Hu wrote:
> > Hi, YT:
> > 
> > On Mon, 2016-09-12 at 18:16 +0800, YT Shen wrote:
> > > Hi CK,
> > > 
> > > On Wed, 2016-09-07 at 10:33 +0800, CK Hu wrote:
> > > > Hi, YT:
> > > > 
> > > > On Fri, 2016-09-02 at 19:24 +0800, YT Shen wrote:
> > > > > From: shaoming chen 
> > > > > 
> > > > > add dsi read/write commands for transfer function
> > > > > 
> > > > > Signed-off-by: shaoming chen 
> > > > > ---
> > > > >  drivers/gpu/drm/mediatek/mtk_dsi.c | 188 
> > > > > +
> > > > >  1 file changed, 188 insertions(+)
> > > > > 
> > > > 
> > > > [snip...]
> > > > 
> > > > >  
> > > > > +static void mtk_dsi_irq_data_clear(struct mtk_dsi *dsi, u32 irq_bit)
> > > > > +{
> > > > > + dsi->irq_data &= ~irq_bit;
> > > > > +}
> > > > > +
> > > > 
> > > > [snip...]
> > > > 
> > > > > +
> > > > > +static s32 mtk_dsi_wait_for_irq_done(struct mtk_dsi *dsi, u32 
> > > > > irq_flag,
> > > > > +  unsigned int timeout)
> > > > > +{
> > > > > + s32 ret = 0;
> > > > > + unsigned long jiffies = msecs_to_jiffies(timeout);
> > > > > +
> > > > > + ret = wait_event_interruptible_timeout(_dsi_irq_wait_queue,
> > > > > +dsi->irq_data & irq_flag,
> > > > > +jiffies);
> > > > > + if (ret == 0) {
> > > > > + dev_info(dsi->dev, "Wait DSI IRQ(0x%08x) Timeout\n", 
> > > > > irq_flag);
> > > > > +
> > > > > + mtk_dsi_enable(dsi);
> > > > > + mtk_dsi_reset_engine(dsi);
> > > > > + }
> > > > > +
> > > > > + return ret;
> > > > > +}
> > > > 
> > > > I think mtk_dsi_irq_data_clear() and mtk_dsi_wait_for_irq_done() should
> > > > be moved to the 6th patch [1] of this series because these two functions
> > > > deal the irq control.
> > > We will move mtk_dsi_irq_data_clear() to patch "drm/mediatek: add dsi
> > > interrupt control" and put mtk_dsi_wait_for_irq_done() here, because it
> > > is used in the transfer function.
> > 
> > mtk_dsi_irq_data_clear() is also only used in transfer function now. I
> > think both function could be used for other application rather than
> > transfer function, so these two function are general function for irq
> > control.
> We will rollback the changes here.  Move mtk_dsi_irq_data_clear() to
> original place.
> 
> Add new functions could be used in the future will have problems.
> warning: 'mtk_dsi_wait_for_irq_done' defined but not used
> [-Wunused-function]
>  static s32 mtk_dsi_wait_for_irq_done(struct mtk_dsi *dsi, u32 irq_flag,
> warning: 'mtk_dsi_irq_data_clear' defined but not used
> [-Wunused-function]
>  static void mtk_dsi_irq_data_clear(struct mtk_dsi *dsi, u32 irq_bit)

Please refer to [1], '__maybe_unused' can fix your problem.

[1]
http://lxr.free-electrons.com/source/drivers/gpu/drm/panel/panel-sharp-lq101r1sx01.c#L76

Regards,
CK

> 
> > Regards,
> > CK
> > 
> > > 
> > > Regards,
> > > yt.shen
> > > > 
> > > > 
> > > > [1] https://patchwork.kernel.org/patch/9310819/
> > > > 
> > > > 
> > > > Regards,
> > > > CK
> > > > 
> > > 
> > > 
> > 
> > 
> 
> 

[Bug 97782] radeonsi: don't preload constants at the beginning of shaders patch break X rebirth

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

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

Rafael Castillo  changed:

   What|Removed |Added

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

--- Comment #2 from Rafael Castillo  ---
closing it, it got fixed on yesterday LLVM, i guess the mesa patch landed
earlier than a required LLVM patch.

Is working fine now

Thanks for the hard work

-- 
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/20160914/415519b7/attachment.html>

[PATCH v7 7/9] drm/mediatek: add dsi transfer function

[YT Shen]

Hi CK,

On Tue, 2016-09-13 at 17:25 +0800, CK Hu wrote:
> Hi, YT:
> 
> On Mon, 2016-09-12 at 18:16 +0800, YT Shen wrote:
> > Hi CK,
> > 
> > On Wed, 2016-09-07 at 10:33 +0800, CK Hu wrote:
> > > Hi, YT:
> > > 
> > > On Fri, 2016-09-02 at 19:24 +0800, YT Shen wrote:
> > > > From: shaoming chen 
> > > > 
> > > > add dsi read/write commands for transfer function
> > > > 
> > > > Signed-off-by: shaoming chen 
> > > > ---
> > > >  drivers/gpu/drm/mediatek/mtk_dsi.c | 188 
> > > > +
> > > >  1 file changed, 188 insertions(+)
> > > > 
> > > 
> > > [snip...]
> > > 
> > > >  
> > > > +static void mtk_dsi_irq_data_clear(struct mtk_dsi *dsi, u32 irq_bit)
> > > > +{
> > > > +   dsi->irq_data &= ~irq_bit;
> > > > +}
> > > > +
> > > 
> > > [snip...]
> > > 
> > > > +
> > > > +static s32 mtk_dsi_wait_for_irq_done(struct mtk_dsi *dsi, u32 irq_flag,
> > > > +unsigned int timeout)
> > > > +{
> > > > +   s32 ret = 0;
> > > > +   unsigned long jiffies = msecs_to_jiffies(timeout);
> > > > +
> > > > +   ret = wait_event_interruptible_timeout(_dsi_irq_wait_queue,
> > > > +  dsi->irq_data & irq_flag,
> > > > +  jiffies);
> > > > +   if (ret == 0) {
> > > > +   dev_info(dsi->dev, "Wait DSI IRQ(0x%08x) Timeout\n", 
> > > > irq_flag);
> > > > +
> > > > +   mtk_dsi_enable(dsi);
> > > > +   mtk_dsi_reset_engine(dsi);
> > > > +   }
> > > > +
> > > > +   return ret;
> > > > +}
> > > 
> > > I think mtk_dsi_irq_data_clear() and mtk_dsi_wait_for_irq_done() should
> > > be moved to the 6th patch [1] of this series because these two functions
> > > deal the irq control.
> > We will move mtk_dsi_irq_data_clear() to patch "drm/mediatek: add dsi
> > interrupt control" and put mtk_dsi_wait_for_irq_done() here, because it
> > is used in the transfer function.
> 
> mtk_dsi_irq_data_clear() is also only used in transfer function now. I
> think both function could be used for other application rather than
> transfer function, so these two function are general function for irq
> control.
We will rollback the changes here.  Move mtk_dsi_irq_data_clear() to
original place.

Add new functions could be used in the future will have problems.
warning: 'mtk_dsi_wait_for_irq_done' defined but not used
[-Wunused-function]
 static s32 mtk_dsi_wait_for_irq_done(struct mtk_dsi *dsi, u32 irq_flag,
warning: 'mtk_dsi_irq_data_clear' defined but not used
[-Wunused-function]
 static void mtk_dsi_irq_data_clear(struct mtk_dsi *dsi, u32 irq_bit)

> Regards,
> CK
> 
> > 
> > Regards,
> > yt.shen
> > > 
> > > 
> > > [1] https://patchwork.kernel.org/patch/9310819/
> > > 
> > > 
> > > Regards,
> > > CK
> > > 
> > 
> > 
> 
> 

4.8-rc1: it is now common that machine needs re-run of xrandr after resume

[Jani Nikula]

On Wed, 14 Sep 2016, Jani Nikula  wrote:
> On Wed, 14 Sep 2016, Pavel Machek  wrote:
>> For the "sometimes need xrandr after resume": I don't think I can
>> bisect that. It only happens sometimes :-(. But there's something
>> helpful in the logs:
>
>> [ 1856.218863] [drm:drm_edid_block_valid] *ERROR* EDID checksum is
>> invalid, remainder is 130
>> [ 1856.218863] Raw EDID:
>> [ 1856.218863] 00 ff ff ff ff ff ff 00 ff ff ff ff ff ff ff ff
>> [ 1856.218863] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
>> [ 1856.218863] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
>> [ 1856.218863] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
>> [ 1856.218863] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
>> [ 1856.218863] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
>> [ 1856.218863] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
>> [ 1856.218863] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
>> [ 1856.218863] [drm:drm_edid_block_valid] *ERROR* EDID checksum is
>> invalid, remainder is 130
>> [ 1856.218863] Raw EDID:
>> [ 1856.218863] 00 ff ff ff ff ff ff 00 ff ff ff ff ff ff ff ff
>> [ 1856.218863] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
>> [ 1856.218863] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
>> [ 1856.218863] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
>> [ 1856.218863] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
>> [ 1856.218863] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
>> [ 1856.218863] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
>> [ 1856.218863] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
>> [ 1856.218863] [drm:drm_edid_block_valid] *ERROR* EDID checksum is
>> invalid, remainder is 130
>> [ 1856.218863] Raw EDID:
>> [ 1856.218863] 00 ff ff ff ff ff ff 00 ff ff ff ff ff ff ff ff
>> [ 1856.218863] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
>> [ 1856.218863] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
>> [ 1856.218863] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
>> [ 1856.218863] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
>> [ 1856.218863] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
>> [ 1856.218863] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
>> [ 1856.218863] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
>> [ 1856.218863] [drm:drm_edid_block_valid] *ERROR* EDID checksum is
>> invalid, remainder is 130
>> [ 1856.218863] Raw EDID:
>> [ 1856.218863] 00 ff ff ff ff ff ff 00 ff ff ff ff ff ff ff ff
>> [ 1856.218863] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
>> [ 1856.218863] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
>> [ 1856.218863] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
>> [ 1856.218863] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
>> [ 1856.218863] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
>> [ 1856.218863] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
>> [ 1856.218863] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
>> [ 1856.218863] i915 :00:02.0: HDMI-A-1: EDID block 0 invalid.
>
> Pavel, Martin, do you always see this when the display fails to resume?
> Is it HDMI/DVI for both of you?

Please try this patch, backported from our next.

BR,
Jani.

>From c5cec7b2df1a518a632998aecd6f73f3fefe59ec Mon Sep 17 00:00:00 2001
From: David Weinehall 
Date: Wed, 17 Aug 2016 15:47:48 +0300
Subject: [PATCH] Revert "drm/i915: Check live status before reading edid"
Organization: Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo
Cc: Jani Nikula 

This reverts commit 237ed86c693d8a8e4db476976aeb30df4deac74b.

Our current implementation of live status check (repeat 9 times
with 10ms delays between each attempt as a workaround for
buggy displays) imposes a rather serious penalty, time wise,
on intel_hdmi_detect().  Since we we already skip live status
checks on platforms before gen 7, and since we seem to have
coped quite well before the live status check was introduced
for newer platforms too, the previous behaviour is probably
preferable, at least unless someone can point to a use-case
that the live status check improves (apart from "Bspec says so".)

Signed-off-by: David Weinehall 
Fixes: 237ed86c693d ("drm/i915: Check live status before reading edid")
Fixes: f8d03ea0053b ("drm/i915: increase the tries for HDMI hotplug live status 
checking")
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97139
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=94014
Acked-by: Chris Wilson 
Cc: stable at vger.kernel.org # v4.4+
Signed-off-by: Jani Nikula 
Link: 
http://patchwork.freedesktop.org/patch/msgid/20160817124748.31208-1-david.weinehall
 at linux.intel.com

Conflicts:
drivers/gpu/drm/i915/intel_drv.h
---
 drivers/gpu/drm/i915/intel_dp.c   |  2 +-
 drivers/gpu/drm/i915/intel_drv.h  |  2 --
 drivers/gpu/drm/i915/intel_hdmi.c | 43 +--
 3 files changed, 11 insertions(+), 36 deletions(-)

diff --git 

[PATCH] drm/radeon/radeon_device: clean function declarations in radeon_device.c up

[Baoyou Xie]

We get 2 warnings when building kernel with W=1:
drivers/gpu/drm/radeon/radeon_device.c:1961:5: warning: no previous prototype 
for 'radeon_debugfs_init' [-Wmissing-prototypes]
drivers/gpu/drm/radeon/radeon_device.c:1966:6: warning: no previous prototype 
for 'radeon_debugfs_cleanup' [-Wmissing-prototypes]

In fact, both functions are declared in
drivers/gpu/drm/radeon/radeon_drv.c, but should be declared in
a header file, thus can be recognized in other file.

So this patch moves the declarations into drivers/gpu/drm/radeon/radeon.h.

Signed-off-by: Baoyou Xie 
---
 drivers/gpu/drm/radeon/radeon_device.c | 1 +
 drivers/gpu/drm/radeon/radeon_drv.c| 5 -
 drivers/gpu/drm/radeon/radeon_drv.h| 5 +
 3 files changed, 6 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/radeon/radeon_device.c 
b/drivers/gpu/drm/radeon/radeon_device.c
index a00dd2f..811abde 100644
--- a/drivers/gpu/drm/radeon/radeon_device.c
+++ b/drivers/gpu/drm/radeon/radeon_device.c
@@ -36,6 +36,7 @@
 #include 
 #include "radeon_reg.h"
 #include "radeon.h"
+#include "radeon_drv.h"
 #include "atom.h"

 static const char radeon_family_name[][16] = {
diff --git a/drivers/gpu/drm/radeon/radeon_drv.c 
b/drivers/gpu/drm/radeon/radeon_drv.c
index 07e4493..6cc4a9e 100644
--- a/drivers/gpu/drm/radeon/radeon_drv.c
+++ b/drivers/gpu/drm/radeon/radeon_drv.c
@@ -156,11 +156,6 @@ void radeon_gem_prime_vunmap(struct drm_gem_object *obj, 
void *vaddr);
 extern long radeon_kms_compat_ioctl(struct file *filp, unsigned int cmd,
unsigned long arg);

-#if defined(CONFIG_DEBUG_FS)
-int radeon_debugfs_init(struct drm_minor *minor);
-void radeon_debugfs_cleanup(struct drm_minor *minor);
-#endif
-
 /* atpx handler */
 #if defined(CONFIG_VGA_SWITCHEROO)
 void radeon_register_atpx_handler(void);
diff --git a/drivers/gpu/drm/radeon/radeon_drv.h 
b/drivers/gpu/drm/radeon/radeon_drv.h
index afef2d9..3d35e0e 100644
--- a/drivers/gpu/drm/radeon/radeon_drv.h
+++ b/drivers/gpu/drm/radeon/radeon_drv.h
@@ -119,4 +119,9 @@
 long radeon_drm_ioctl(struct file *filp,
  unsigned int cmd, unsigned long arg);

+#if defined(CONFIG_DEBUG_FS)
+int radeon_debugfs_init(struct drm_minor *minor);
+void radeon_debugfs_cleanup(struct drm_minor *minor);
+#endif
+
 #endif /* __RADEON_DRV_H__ */
-- 
2.7.4

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

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

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

--- Comment #38 from AmarildoJr  ---
Does anyone have a little bit of free time to extract the files from
"lib32-catalyst-libgl" into a system running "lib32-mesa-libgl" and see if that
helps?

-- 
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/20160914/1d2adef5/attachment-0001.html>

[Bug 97801] [amdgpu SI] "drm/amd/amdgpu: Tidy up SI SMC code" prevents amdgpu loading with dpm=1

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

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

Arek Ruśniak  changed:

   What|Removed |Added

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

--- Comment #2 from Arek Ruśniak  ---
Thanks, works now.

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

[PATCH v9 16/19] ARM: DT: STi: stihxxx-b2120: Add DT nodes for STi audio card

[Patrice Chotard]

Hi Peter

On 09/05/2016 03:16 PM, Peter Griffin wrote:
> This patch enables the uniperif players 2 & 3 for b2120 boards
> and also adds the "simple-audio-card" device node to interconnect
> the SoC sound device and the codec.
> 
> Signed-off-by: Arnaud Pouliquen 
> Signed-off-by: Peter Griffin 
> ---
>  arch/arm/boot/dts/stihxxx-b2120.dtsi | 45 
> 
>  1 file changed, 45 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/stihxxx-b2120.dtsi 
> b/arch/arm/boot/dts/stihxxx-b2120.dtsi
> index 722c63f..4939501 100644
> --- a/arch/arm/boot/dts/stihxxx-b2120.dtsi
> +++ b/arch/arm/boot/dts/stihxxx-b2120.dtsi
> @@ -131,5 +131,50 @@
>   dvb-card= ;
>   };
>   };
> +
> + sti_uni_player2: sti-uni-player at 8d82000 {
> + status = "okay";
> + };
> +
> + sti_uni_player3: sti-uni-player at 8d85000 {
> + status = "okay";
> + };
> +
> + sti_sasg_codec: sti-sasg-codec {
> + status = "okay";
> + pinctrl-names = "default";
> + pinctrl-0 = <_spdif_out>;
> + };
> +
> + sound {
> + compatible = "simple-audio-card";
> + simple-audio-card,name = "sti audio card";
> + status = "okay";
> +
> + simple-audio-card,dai-link at 0 {
> + /* DAC */
> + format = "i2s";
> + mclk-fs = <256>;
> + cpu {
> + sound-dai = <_uni_player2>;
> + };
> +
> + codec {
> + sound-dai = <_sasg_codec 1>;
> + };
> + };
> + simple-audio-card,dai-link at 1 {
> + /* SPDIF */
> + format = "left_j";
> + mclk-fs = <128>;
> + cpu {
> + sound-dai = <_uni_player3>;
> + };
> +
> + codec {
> + sound-dai = <_sasg_codec 0>;
> + };
> + };
> + };
>   };
>  };
> 


Applied for STi next

Thanks

[PATCH v9 15/19] ARM: STi: DT: STiH407: Add uniperif reader dt nodes

[Patrice Chotard]

Hi Peter

On 09/05/2016 03:16 PM, Peter Griffin wrote:
> This patch adds the DT node for the uniperif reader
> IP block found on STiH407 family silicon.
> 
> Signed-off-by: Arnaud Pouliquen 
> Signed-off-by: Peter Griffin 
> ---
>  arch/arm/boot/dts/stih407-family.dtsi | 28 
>  1 file changed, 28 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/stih407-family.dtsi 
> b/arch/arm/boot/dts/stih407-family.dtsi
> index 1edc36c..883019a 100644
> --- a/arch/arm/boot/dts/stih407-family.dtsi
> +++ b/arch/arm/boot/dts/stih407-family.dtsi
> @@ -960,5 +960,33 @@
>  
>   status = "disabled";
>   };
> +
> + sti_uni_reader0: sti-uni-reader at 8d83000 {
> + compatible = "st,sti-uni-reader";
> + #sound-dai-cells = <0>;
> + st,syscfg = <_core>;
> + reg = <0x8d83000 0x158>;
> + interrupts = ;
> + dmas = < 5 0 1>;
> + dma-names = "rx";
> + dai-name = "Uni Reader #0 (PCM IN)";
> + st,version = <3>;
> +
> + status = "disabled";
> + };
> +
> + sti_uni_reader1: sti-uni-reader at 8d84000 {
> + compatible = "st,sti-uni-reader";
> + #sound-dai-cells = <0>;
> + st,syscfg = <_core>;
> + reg = <0x8d84000 0x158>;
> + interrupts = ;
> + dmas = < 6 0 1>;
> + dma-names = "rx";
> + dai-name = "Uni Reader #1 (HDMI RX)";
> + st,version = <3>;
> +
> + status = "disabled";
> + };
>   };
>  };
> 



Applied for STi next

Thanks

[PATCH v9 14/19] ARM: STi: DT: STiH407: Add uniperif player dt nodes

[Patrice Chotard]

Hi Peter

On 09/05/2016 03:16 PM, Peter Griffin wrote:
> This patch adds the DT nodes for the uniperif player
> IP blocks found on STiH407 family silicon.
> 
> Signed-off-by: Arnaud Pouliquen 
> Signed-off-by: Peter Griffin 
> ---
>  arch/arm/boot/dts/stih407-family.dtsi | 80 
> +++
>  1 file changed, 80 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/stih407-family.dtsi 
> b/arch/arm/boot/dts/stih407-family.dtsi
> index d1258d5..1edc36c 100644
> --- a/arch/arm/boot/dts/stih407-family.dtsi
> +++ b/arch/arm/boot/dts/stih407-family.dtsi
> @@ -880,5 +880,85 @@
>   status = "disabled";
>   st,syscfg = <_core>;
>   };
> +
> + sti_uni_player0: sti-uni-player at 8d8 {
> + compatible = "st,sti-uni-player";
> + #sound-dai-cells = <0>;
> + st,syscfg = <_core>;
> + clocks = <_s_d0_flexgen CLK_PCM_0>;
> + assigned-clocks = <_s_d0_quadfs 0>, 
> <_s_d0_flexgen CLK_PCM_0>;
> + assigned-clock-parents = <0>, <_s_d0_quadfs 0>;
> + assigned-clock-rates = <5000>;
> + reg = <0x8d8 0x158>;
> + interrupts = ;
> + dmas = < 2 0 1>;
> + dai-name = "Uni Player #0 (HDMI)";
> + dma-names = "tx";
> + st,uniperiph-id = <0>;
> + st,version = <5>;
> + st,mode = "HDMI";
> +
> + status  = "disabled";
> + };
> +
> + sti_uni_player1: sti-uni-player at 8d81000 {
> + compatible = "st,sti-uni-player";
> + #sound-dai-cells = <0>;
> + st,syscfg = <_core>;
> + clocks = <_s_d0_flexgen CLK_PCM_1>;
> + assigned-clocks = <_s_d0_quadfs 1>, 
> <_s_d0_flexgen CLK_PCM_1>;
> + assigned-clock-parents = <0>, <_s_d0_quadfs 1>;
> + assigned-clock-rates = <5000>;
> + reg = <0x8d81000 0x158>;
> + interrupts = ;
> + dmas = < 3 0 1>;
> + dai-name = "Uni Player #1 (PIO)";
> + dma-names = "tx";
> + st,uniperiph-id = <1>;
> + st,version = <5>;
> + st,mode = "PCM";
> +
> + status = "disabled";
> + };
> +
> + sti_uni_player2: sti-uni-player at 8d82000 {
> + compatible = "st,sti-uni-player";
> + #sound-dai-cells = <0>;
> + st,syscfg = <_core>;
> + clocks = <_s_d0_flexgen CLK_PCM_2>;
> + assigned-clocks = <_s_d0_quadfs 2>, 
> <_s_d0_flexgen CLK_PCM_2>;
> + assigned-clock-parents = <0>, <_s_d0_quadfs 2>;
> + assigned-clock-rates = <5000>;
> + reg = <0x8d82000 0x158>;
> + interrupts = ;
> + dmas = < 4 0 1>;
> + dai-name = "Uni Player #1 (DAC)";
> + dma-names = "tx";
> + st,uniperiph-id = <2>;
> + st,version = <5>;
> + st,mode = "PCM";
> +
> + status = "disabled";
> + };
> +
> + sti_uni_player3: sti-uni-player at 8d85000 {
> + compatible = "st,sti-uni-player";
> + #sound-dai-cells = <0>;
> + st,syscfg = <_core>;
> + clocks = <_s_d0_flexgen CLK_SPDIFF>;
> + assigned-clocks = <_s_d0_quadfs 3>, 
> <_s_d0_flexgen CLK_SPDIFF>;
> + assigned-clock-parents = <0>, <_s_d0_quadfs 3>;
> + assigned-clock-rates = <5000>;
> + reg = <0x8d85000 0x158>;
> + interrupts = ;
> + dmas = < 7 0 1>;
> + dma-names = "tx";
> + dai-name = "Uni Player #1 (PIO)";
> + st,uniperiph-id = <3>;
> + st,version = <5>;
> + st,mode = "SPDIF";
> +
> + status = "disabled";
> + };
>   };
>  };
> 


Applied for STi next

Thanks

[PATCH v9 13/19] ARM: STi: DT: STiH407: Add sti-sasg-codec dt node

[Patrice Chotard]

Hi Peter

On 09/05/2016 03:16 PM, Peter Griffin wrote:
> This patch adds the dt node for the internal audio
> codec IP.
> 
> Signed-off-by: Arnaud Pouliquen 
> Signed-off-by: Peter Griffin 
> ---
>  arch/arm/boot/dts/stih407-family.dtsi | 7 +++
>  1 file changed, 7 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/stih407-family.dtsi 
> b/arch/arm/boot/dts/stih407-family.dtsi
> index 45cab30..d1258d5 100644
> --- a/arch/arm/boot/dts/stih407-family.dtsi
> +++ b/arch/arm/boot/dts/stih407-family.dtsi
> @@ -873,5 +873,12 @@
>   <_s_c0_flexgen CLK_TX_ICN_DISP_0>,
>   <_s_c0_flexgen CLK_EXT2F_A9>;
>   };
> +
> + sti_sasg_codec: sti-sasg-codec {
> + compatible = "st,stih407-sas-codec";
> + #sound-dai-cells = <1>;
> + status = "disabled";
> + st,syscfg = <_core>;
> + };
>   };
>  };
> 


Applied for STi next

Thanks

[PATCH v9 12/19] ARM: DT: STiH407: Add spdif_out pinctrl config

[Patrice Chotard]

Hi Peter

On 09/05/2016 03:16 PM, Peter Griffin wrote:
> This patch adds the pinctrl config for the spidf out
> pins used by the sasg codec IP.
> 
> Signed-off-by: Arnaud Pouliquen 
> Signed-off-by: Peter Griffin 
> Acked-by: Lee Jones 
> ---
>  arch/arm/boot/dts/stih407-pinctrl.dtsi | 8 
>  1 file changed, 8 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/stih407-pinctrl.dtsi 
> b/arch/arm/boot/dts/stih407-pinctrl.dtsi
> index 537db7e..598dbab 100644
> --- a/arch/arm/boot/dts/stih407-pinctrl.dtsi
> +++ b/arch/arm/boot/dts/stih407-pinctrl.dtsi
> @@ -1114,6 +1114,14 @@
>   };
>   };
>  
> + spdif_out {
> + pinctrl_spdif_out: spdif_out{
> + st,pins {
> + spdif_out = < 7 ALT1 OUT>;
> + };
> + };
> + };
> +
>   serial3 {
>   pinctrl_serial3: serial3-0 {
>   st,pins {
> 



Applied for STi next

Thanks

[PATCH v9 11/19] ARM: DT: STiH407: Add i2s_in pinctrl configuration

[Patrice Chotard]

Hi Peter

On 09/05/2016 03:16 PM, Peter Griffin wrote:
> This patch adds the pinctrl config for the i2s_in pins
> used by the uniperif reader IP.
> 
> Signed-off-by: Arnaud Pouliquen 
> Signed-off-by: Peter Griffin 
> Acked-by: Lee Jones 
> ---
>  arch/arm/boot/dts/stih407-pinctrl.dtsi | 24 
>  1 file changed, 24 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/stih407-pinctrl.dtsi 
> b/arch/arm/boot/dts/stih407-pinctrl.dtsi
> index 0fb5c8a..537db7e 100644
> --- a/arch/arm/boot/dts/stih407-pinctrl.dtsi
> +++ b/arch/arm/boot/dts/stih407-pinctrl.dtsi
> @@ -1090,6 +1090,30 @@
>   };
>   };
>  
> + i2s_in {
> + pinctrl_i2s_8ch_in: i2s_8ch_in{
> + st,pins {
> + mclk = < 5 ALT1 IN>;
> + lrclk = < 7 ALT1 IN>;
> + sclk = < 6 ALT1 IN>;
> + data0 = < 4 ALT1 IN>;
> + data1 = < 0 ALT1 IN>;
> + data2 = < 1 ALT1 IN>;
> + data3 = < 2 ALT1 IN>;
> + data4 = < 3 ALT1 IN>;
> + };
> + };
> +
> + pinctrl_i2s_2ch_in: i2s_2ch_in{
> + st,pins {
> + mclk = < 5 ALT1 IN>;
> + lrclk = < 7 ALT1 IN>;
> + sclk = < 6 ALT1 IN>;
> + data0 = < 4 ALT1 IN>;
> + };
> + };
> + };
> +
>   serial3 {
>   pinctrl_serial3: serial3-0 {
>   st,pins {
> 



Applied for STi next

Thanks

[PATCH v9 10/19] ARM: DT: STiH407: Add i2s_out pinctrl configuration

[Patrice Chotard]

Hi Peter

On 09/05/2016 03:16 PM, Peter Griffin wrote:
> This patch adds the pinctrl config for the i2s_out pins
> used by the uniperif player IP.
> 
> Signed-off-by: Arnaud Pouliquen 
> Signed-off-by: Peter Griffin 
> Acked-by: Lee Jones 
> ---
>  arch/arm/boot/dts/stih407-pinctrl.dtsi | 23 +++
>  1 file changed, 23 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/stih407-pinctrl.dtsi 
> b/arch/arm/boot/dts/stih407-pinctrl.dtsi
> index a538ae5..0fb5c8a 100644
> --- a/arch/arm/boot/dts/stih407-pinctrl.dtsi
> +++ b/arch/arm/boot/dts/stih407-pinctrl.dtsi
> @@ -1067,6 +1067,29 @@
>   };
>   };
>  
> + i2s_out {
> + pinctrl_i2s_8ch_out: i2s_8ch_out{
> + st,pins {
> + mclk = < 5 ALT1 OUT>;
> + lrclk = < 7 ALT1 OUT>;
> + sclk = < 6 ALT1 OUT>;
> + data0 = < 4 ALT1 OUT>;
> + data1 = < 0 ALT1 OUT>;
> + data2 = < 1 ALT1 OUT>;
> + data3 = < 2 ALT1 OUT>;
> + };
> + };
> +
> + pinctrl_i2s_2ch_out: i2s_2ch_out{
> + st,pins {
> + mclk = < 5 ALT1 OUT>;
> + lrclk = < 7 ALT1 OUT>;
> + sclk = < 6 ALT1 OUT>;
> + data0 = < 4 ALT1 OUT>;
> + };
> + };
> + };
> +
>   serial3 {
>   pinctrl_serial3: serial3-0 {
>   st,pins {
> 


Applied for STi next

Thanks

[PATCH v9 06/19] ARM: STi: DT: STiH407: Add FDMA driver dt nodes.

[Patrice Chotard]

Hi Peter

On 09/05/2016 03:16 PM, Peter Griffin wrote:
> These nodes are required to get the fdma driver working
> on STiH407 based silicon.
> 
> Signed-off-by: Peter Griffin 
> Acked-by: Lee Jones 
> ---
>  arch/arm/boot/dts/stih407-family.dtsi | 52 
> +++
>  1 file changed, 52 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/stih407-family.dtsi 
> b/arch/arm/boot/dts/stih407-family.dtsi
> index d294e82..45cab30 100644
> --- a/arch/arm/boot/dts/stih407-family.dtsi
> +++ b/arch/arm/boot/dts/stih407-family.dtsi
> @@ -821,5 +821,57 @@
>   clock-frequency = <6>;
>   st,syscfg   = <_core 0x224>;
>   };
> +
> + /* fdma audio */
> + fdma0: dma-controller at 8e2 {
> + compatible = "st,stih407-fdma-mpe31-11", 
> "st,slim-rproc";
> + reg = <0x8e2 0x8000>,
> +   <0x8e3 0x3000>,
> +   <0x8e37000 0x1000>,
> +   <0x8e38000 0x8000>;
> + reg-names = "slimcore", "dmem", "peripherals", "imem";
> + clocks = <_s_c0_flexgen CLK_FDMA>,
> +  <_s_c0_flexgen CLK_EXT2F_A9>,
> +  <_s_c0_flexgen CLK_EXT2F_A9>,
> +  <_s_c0_flexgen CLK_EXT2F_A9>;
> + interrupts = ;
> + dma-channels = <16>;
> + #dma-cells = <3>;
> + };
> +
> + /* fdma app */
> + fdma1: dma-controller at 8e4 {
> + compatible = "st,stih407-fdma-mpe31-12", 
> "st,slim-rproc";
> + reg = <0x8e4 0x8000>,
> +   <0x8e5 0x3000>,
> +   <0x8e57000 0x1000>,
> +   <0x8e58000 0x8000>;
> + reg-names = "slimcore", "dmem", "peripherals", "imem";
> + clocks = <_s_c0_flexgen CLK_FDMA>,
> + <_s_c0_flexgen CLK_TX_ICN_DMU>,
> + <_s_c0_flexgen CLK_TX_ICN_DMU>,
> + <_s_c0_flexgen CLK_EXT2F_A9>;
> +
> + interrupts = ;
> + dma-channels = <16>;
> + #dma-cells = <3>;
> + };
> +
> + /* fdma free running */
> + fdma2: dma-controller at 8e6 {
> + compatible = "st,stih407-fdma-mpe31-13", 
> "st,slim-rproc";
> + reg = <0x8e6 0x8000>,
> +   <0x8e7 0x3000>,
> +   <0x8e77000 0x1000>,
> +   <0x8e78000 0x8000>;
> + reg-names = "slimcore", "dmem", "peripherals", "imem";
> + interrupts = ;
> + dma-channels = <16>;
> + #dma-cells = <3>;
> + clocks = <_s_c0_flexgen CLK_FDMA>,
> + <_s_c0_flexgen CLK_EXT2F_A9>,
> + <_s_c0_flexgen CLK_TX_ICN_DISP_0>,
> + <_s_c0_flexgen CLK_EXT2F_A9>;
> + };
>   };
>  };
> 

Applied for STi next

Thanks

[Bug 97634] [amdgpu SI] multigpu setup crashes during boot when dpm=1

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

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

--- Comment #2 from Alex Deucher  ---
probably a duplicate of bug 97801

-- 
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/20160914/6a379997/attachment.html>

[Bug 97801] [amdgpu SI] "drm/amd/amdgpu: Tidy up SI SMC code" prevents amdgpu loading with dpm=1

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

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

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

-- 
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/20160914/176d73d1/attachment.html>

[PATCH v8 8/9] drm/mediatek: update DSI sub driver flow

[CK Hu]

Hi, YT:

On Mon, 2016-09-12 at 20:01 +0800, YT Shen wrote:
> This patch update enable/disable flow of DSI module and MIPI TX module.
> Original flow works on there is a bridge chip: DSI -> bridge -> panel.
> In this case: DSI -> panel, the DSI sub driver flow should be updated.
> We need to initialize DSI first so that we can send commands to panel.
> 
> Signed-off-by: shaoming chen 
> Signed-off-by: YT Shen 
> ---
>  

[snip...]

>  
> +static void mtk_dsi_switch_to_cmd_mode(struct mtk_dsi *dsi)
> +{
> + s32 ret = 0;
> + unsigned long timeout = msecs_to_jiffies(500);
> +
> + mtk_dsi_irq_data_clear(dsi, VM_DONE_INT_FLAG);
> + mtk_dsi_set_cmd_mode(dsi);
> +
> + ret = wait_event_interruptible_timeout(dsi->irq_wait_queue,
> +dsi->irq_data & VM_DONE_INT_FLAG,
> +timeout);
> + if (ret == 0) {
> + dev_info(dsi->dev, "dsi wait engine idle timeout\n");
> +
> + mtk_dsi_enable(dsi);
> + mtk_dsi_reset_engine(dsi);
> + }

I think you should replace this event-waiting with
mtk_dsi_wait_for_irq_done(). And this is a reason for moving
mtk_dsi_wait_for_irq_done() to the patch of irq control.

> +}
> +
>  static void mtk_dsi_poweroff(struct mtk_dsi *dsi)
>  {
>   if (WARN_ON(dsi->refcount == 0))
> @@ -528,6 +574,17 @@ static void mtk_dsi_poweroff(struct mtk_dsi *dsi)
>   if (--dsi->refcount != 0)
>   return;
>  
> + mtk_dsi_switch_to_cmd_mode(dsi);
> +
> + if (dsi->panel) {
> + if (drm_panel_unprepare(dsi->panel)) {
> + DRM_ERROR("failed to unprepare the panel\n");
> + return;
> + }
> + }

I think drm_panel_unprepare should be placed after dsi is disabled. So
move this part after calling mtk_dsi_poweroff() in
mtk_output_dsi_disable().

> +
> + mtk_dsi_reset_engine(dsi);
> +
>   mtk_dsi_lane0_ulp_mode_enter(dsi);
>   mtk_dsi_clk_ulp_mode_enter(dsi);
>  
> @@ -546,29 +603,37 @@ static void mtk_output_dsi_enable(struct mtk_dsi *dsi)
>   if (dsi->enabled)
>   return;
>  
> - if (dsi->panel) {
> - if (drm_panel_prepare(dsi->panel)) {
> - DRM_ERROR("failed to setup the panel\n");
> - return;
> - }
> - }
> -
>   ret = mtk_dsi_poweron(dsi);
>   if (ret < 0) {
>   DRM_ERROR("failed to power on dsi\n");
>   return;
>   }
>  
> + usleep_range(2, 21000);
> +
>   mtk_dsi_rxtx_control(dsi);
> + mtk_dsi_phy_timconfig(dsi);
> + mtk_dsi_ps_control_vact(dsi);
> + mtk_dsi_set_vm_cmd(dsi);
> + mtk_dsi_config_vdo_timing(dsi);
> + mtk_dsi_set_interrupt_enable(dsi);
>  
> + mtk_dsi_enable(dsi);
>   mtk_dsi_clk_ulp_mode_leave(dsi);
>   mtk_dsi_lane0_ulp_mode_leave(dsi);
>   mtk_dsi_clk_hs_mode(dsi, 0);
> - mtk_dsi_set_mode(dsi);
>  
> - mtk_dsi_ps_control_vact(dsi);
> - mtk_dsi_config_vdo_timing(dsi);
> - mtk_dsi_set_interrupt_enable(dsi);
> + if (dsi->panel) {
> + if (drm_panel_prepare(dsi->panel)) {
> + DRM_ERROR("failed to prepare the panel\n");
> + return;
> + }
> +
> + if (drm_panel_enable(dsi->panel)) {
> + DRM_ERROR("failed to enable the panel\n");
> + return;
> + }
> + }

I think drm_panel_prepare() should be called before DSI is enabled and
drm_panel_enable() should be called after DSI is enabled. But you may
encounter the problem that panel need transfer data when prepare and you
can refer to [1].

[1]
http://lxr.free-electrons.com/source/drivers/gpu/drm/exynos/exynos_drm_dsi.c#L1431

>  
>   mtk_dsi_set_mode(dsi);
>   mtk_dsi_clk_hs_mode(dsi, 1);
> @@ -590,6 +655,7 @@ static void mtk_output_dsi_disable(struct mtk_dsi *dsi)
>   }
>   }
>  
> + mtk_dsi_stop(dsi);
>   mtk_dsi_poweroff(dsi);
>  
>   dsi->enabled = false;
> diff --git a/drivers/gpu/drm/mediatek/mtk_mipi_tx.c 
> b/drivers/gpu/drm/mediatek/mtk_mipi_tx.c
> index 108d31a..34e95c6 100644
> --- a/drivers/gpu/drm/mediatek/mtk_mipi_tx.c
> +++ b/drivers/gpu/drm/mediatek/mtk_mipi_tx.c
> @@ -177,7 +177,9 @@ static int mtk_mipi_tx_pll_prepare(struct clk_hw *hw)
>  
>   dev_dbg(mipi_tx->dev, "prepare: %u Hz\n", mipi_tx->data_rate);
>  
> - if (mipi_tx->data_rate >= 5) {
> + if (mipi_tx->data_rate > 125000) {
> + return -EINVAL;
> + } else if (mipi_tx->data_rate >= 5) {

What is the relationship of this part and "DSI driver flow"? Would this
be an independent patch?

>   txdiv = 1;
>   txdiv0 = 0;
>   txdiv1 = 0;
> @@ -201,6 +203,10 @@ static int mtk_mipi_tx_pll_prepare(struct clk_hw *hw)
>   return -EINVAL;
>   }
>  
> + mtk_mipi_tx_update_bits(mipi_tx, MIPITX_DSI_TOP_CON,
> 

[PATCH] drm/sti: forbid plane on several mixer

[Vincent Abriou]

When a plane is going to be enabled we re-evaluate the possible crtcs
for the associated drm plane. Only the crtc on which the plane should be
displayed is considered possible until the plane is disabled.
Indeed STI hardware does not allow to dynamically change
the plane's crtc/mixer assignment when the plane is in use (gdp is
running).

Signed-off-by: Vincent Abriou 
---
 drivers/gpu/drm/sti/sti_gdp.c   | 15 +++
 drivers/gpu/drm/sti/sti_plane.h |  2 ++
 2 files changed, 17 insertions(+)

diff --git a/drivers/gpu/drm/sti/sti_gdp.c b/drivers/gpu/drm/sti/sti_gdp.c
index 3fc62c1..f7cd671 100644
--- a/drivers/gpu/drm/sti/sti_gdp.c
+++ b/drivers/gpu/drm/sti/sti_gdp.c
@@ -71,6 +71,9 @@ static struct gdp_format_to_str {
 #define GDP_NODE_NB_BANK2
 #define GDP_NODE_PER_FIELD  2

+#define MAIN_CRTC_MASK  BIT(0)
+#define AUX_CRTC_MASK   BIT(1)
+
 struct sti_gdp_node {
u32 gam_gdp_ctl;
u32 gam_gdp_agc;
@@ -690,6 +693,12 @@ static int sti_gdp_atomic_check(struct drm_plane 
*drm_plane,
}
}

+   /* re-evaluate the possible crtcs */
+   if (mixer->id == STI_MIXER_MAIN)
+   drm_plane->possible_crtcs = MAIN_CRTC_MASK;
+   else
+   drm_plane->possible_crtcs = AUX_CRTC_MASK;
+
DRM_DEBUG_KMS("CRTC:%d (%s) drm plane:%d (%s)\n",
  crtc->base.id, sti_mixer_to_str(mixer),
  drm_plane->base.id, sti_plane_to_str(plane));
@@ -846,6 +855,9 @@ static void sti_gdp_atomic_disable(struct drm_plane 
*drm_plane,
 {
struct sti_plane *plane = to_sti_plane(drm_plane);

+   /* restore possible crtcs value with the initial value */
+   drm_plane->possible_crtcs = plane->init_possible_crtcs;
+
if (!drm_plane->crtc) {
DRM_DEBUG_DRIVER("drm plane:%d not enabled\n",
 drm_plane->base.id);
@@ -917,6 +929,9 @@ struct drm_plane *sti_gdp_create(struct drm_device *drm_dev,

sti_gdp_init(gdp);

+   /* store the initial value of possible crtcs */
+   gdp->plane.init_possible_crtcs = possible_crtcs;
+
res = drm_universal_plane_init(drm_dev, >plane.drm_plane,
   possible_crtcs,
   _gdp_plane_helpers_funcs,
diff --git a/drivers/gpu/drm/sti/sti_plane.h b/drivers/gpu/drm/sti/sti_plane.h
index ce3e8d6..70c5312 100644
--- a/drivers/gpu/drm/sti/sti_plane.h
+++ b/drivers/gpu/drm/sti/sti_plane.h
@@ -66,12 +66,14 @@ struct sti_fps_info {
  * @plane:  drm plane it is bound to (if any)
  * @desc:   plane type & id
  * @status: to know the status of the plane
+ * @init_possile_crtcs: store the initial possible crtc value
  * @fps_info:   frame per second info
  */
 struct sti_plane {
struct drm_plane drm_plane;
enum sti_plane_desc desc;
enum sti_plane_status status;
+   u32 init_possible_crtcs;
struct sti_fps_info fps_info;
 };

-- 
1.9.1

[PATCH] dma-buf/sync_file: Always increment refcount when merging fences.

[Gustavo Padovan]

2016-09-14 Rafael Antognolli :

> On Wed, Sep 14, 2016 at 11:04:01AM -0300, Gustavo Padovan wrote:
> > 2016-09-14 Chris Wilson :
> > 
> > > On Tue, Sep 13, 2016 at 04:24:27PM -0700, Rafael Antognolli wrote:
> > > > The refcount of a fence should be increased whenever it is added to a 
> > > > merged
> > > > fence, since it will later be decreased when the merged fence is 
> > > > destroyed.
> > > > Failing to do so will cause the original fence to be freed if the 
> > > > merged fence
> > > > gets freed, but other places still referencing won't know about it.
> > > > 
> > > > This patch fixes a kernel panic that can be triggered by creating a 
> > > > fence that
> > > > is expired (or increasing the timeline until it expires), then creating 
> > > > a
> > > > merged fence out of it, and deleting the merged fence. This will make 
> > > > the
> > > > original expired fence's refcount go to zero.
> > > > 
> > > > Signed-off-by: Rafael Antognolli 
> > > > ---
> > > > 
> > > > Sample code to trigger the mentioned kernel panic (might need to be 
> > > > executed a
> > > > couple times before it actually breaks everything):
> > > > 
> > > > static void test_sync_expired_merge(void)
> > > > {
> > > >int iterations = 1 << 20;
> > > >int timeline;
> > > >int i;
> > > >int fence_expired, fence_merged;
> > > > 
> > > >timeline = sw_sync_timeline_create();
> > > > 
> > > >sw_sync_timeline_inc(timeline, 100);
> > > >fence_expired = sw_sync_fence_create(timeline, 1);
> > > >fence_merged = sw_sync_merge(fence_expired, fence_expired);
> > > >sw_sync_fence_destroy(fence_merged);
> > > > 
> > > >for (i = 0; i < iterations; i++) {
> > > >int fence = sw_sync_merge(fence_expired, fence_expired);
> > > > 
> > > >igt_assert_f(sw_sync_wait(fence, -1) > 0,
> > > > "Failure waiting on fence\n");
> > > >sw_sync_fence_destroy(fence);
> > > >}
> > > > 
> > > >sw_sync_fence_destroy(fence_expired);
> > > > }
> > > > 
> > > >  drivers/dma-buf/sync_file.c | 7 ++-
> > > >  1 file changed, 2 insertions(+), 5 deletions(-)
> > > > 
> > > > diff --git a/drivers/dma-buf/sync_file.c b/drivers/dma-buf/sync_file.c
> > > > index 486d29c..6ce6b8f 100644
> > > > --- a/drivers/dma-buf/sync_file.c
> > > > +++ b/drivers/dma-buf/sync_file.c
> > > > @@ -178,11 +178,8 @@ static struct fence **get_fences(struct sync_file 
> > > > *sync_file, int *num_fences)
> > > >  static void add_fence(struct fence **fences, int *i, struct fence 
> > > > *fence)
> > > >  {
> > > > fences[*i] = fence;
> > > > -
> > > > -   if (!fence_is_signaled(fence)) {
> > > > -   fence_get(fence);
> > > > -   (*i)++;
> > > > -   }
> > > > +   fence_get(fence);
> > > > +   (*i)++;
> > > >  }
> > > 
> > > I think you'll find it's the caller:
> > > 
> > > if (i == 0) {
> > >   add_fence(fences, , a_fences[0]);
> > >   i++;
> > > }
> > > 
> > > that does the unexpected.
> > > 
> > > This should be 
> > > 
> > > if (i == 0)
> > >   fences[i++] = fence_get(a_fences[0]);
> > 
> > You are right. Otherwise we would miss the extra reference. i == 0 here
> > means that all fences are signalled.
> > 
> > > 
> > > 
> > > That ensures the sync_file inherits the signaled status without having
> > > to keep all fences.
> 
> OK, so if you are building a merged fence out of several signaled
> fences, then you only keep one of them instead? I haven't noticed that
> was the intention.
> 
> > > I think there still seems to be a memory leak when calling
> > > sync_file_set_fence() here with i == 1.
> > 
> > I think that is something we discussed already, we don't hold an extra
> > ref there for i == 1 because it would leak the fence.
> > 
> 
> I agree, we already increase the reference count in add_fence anyway (or
> here, assuming we do what Chris suggested. But I also believe that's the
> cause of confusion.
> 
> IMHO it would be better to call fence_get() inside fence_array_create(),
> so it would match the fence_put in fence_array_release(). And if we have
> only one fence, fence_get it inside sync_file_set_fence().

sync_file is not the only user of fence_array, so I would not push this
behaviour changes to others users. The current behaviour is well
documented inside sync_file_set_fence, not sure we need to change it.

Gustavo

4.8-rc1: it is now common that machine needs re-run of xrandr after resume

[Martin Steigerwald]

Am Mittwoch, 14. September 2016, 12:17:53 CEST schrieb Jani Nikula:
> On Wed, 14 Sep 2016, Pavel Machek  wrote:
> > For the "sometimes need xrandr after resume": I don't think I can
> > bisect that. It only happens sometimes :-(. But there's something
> > helpful in the logs:
> > 
> > [ 1856.218863] [drm:drm_edid_block_valid] *ERROR* EDID checksum is
> > invalid, remainder is 130
> > [ 1856.218863] Raw EDID:
> > [ 1856.218863] 00 ff ff ff ff ff ff 00 ff ff ff ff ff ff ff ff
> > [ 1856.218863] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> > [ 1856.218863] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> > [ 1856.218863] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> > [ 1856.218863] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> > [ 1856.218863] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> > [ 1856.218863] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> > [ 1856.218863] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> > [ 1856.218863] [drm:drm_edid_block_valid] *ERROR* EDID checksum is
> > invalid, remainder is 130
> > [ 1856.218863] Raw EDID:
> > [ 1856.218863] 00 ff ff ff ff ff ff 00 ff ff ff ff ff ff ff ff
> > [ 1856.218863] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> > [ 1856.218863] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> > [ 1856.218863] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> > [ 1856.218863] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> > [ 1856.218863] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> > [ 1856.218863] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> > [ 1856.218863] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> > [ 1856.218863] [drm:drm_edid_block_valid] *ERROR* EDID checksum is
> > invalid, remainder is 130
> > [ 1856.218863] Raw EDID:
> > [ 1856.218863] 00 ff ff ff ff ff ff 00 ff ff ff ff ff ff ff ff
> > [ 1856.218863] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> > [ 1856.218863] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> > [ 1856.218863] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> > [ 1856.218863] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> > [ 1856.218863] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> > [ 1856.218863] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> > [ 1856.218863] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> > [ 1856.218863] [drm:drm_edid_block_valid] *ERROR* EDID checksum is
> > invalid, remainder is 130
> > [ 1856.218863] Raw EDID:
> > [ 1856.218863] 00 ff ff ff ff ff ff 00 ff ff ff ff ff ff ff ff
> > [ 1856.218863] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> > [ 1856.218863] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> > [ 1856.218863] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> > [ 1856.218863] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> > [ 1856.218863] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> > [ 1856.218863] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> > [ 1856.218863] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> > [ 1856.218863] i915 :00:02.0: HDMI-A-1: EDID block 0 invalid.
> 
> Pavel, Martin, do you always see this when the display fails to resume?
> Is it HDMI/DVI for both of you?

According to zgrep "EDID" /var/log/kern* I don´t have any EDID related error 
messages. I am using DisplayPort cable via ThinkPad Minidock Plus (dock for 
ThinkPad T520) or what it was named.

-- 
Martin

[Bug 153121] UVD not responding, trying to reset the VCPU, ATI Mobility Radeon HD 5650

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

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

--- Comment #37 from Kontantin Ivanov  ---
I'm always ready to help with this bug. Actually, UVD is not important for me.
But the card I want to use. May be there is some documentation how to work with
similar problems... ?

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

[Bug 153121] UVD not responding, trying to reset the VCPU, ATI Mobility Radeon HD 5650

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

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

Kontantin Ivanov  changed:

   What|Removed |Added

 Kernel Version|4.8.0-040800rc2 |4.8.0-040800rc5

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

[PATCH v4 0/7] drm/imx: Add active plane reconfiguration support

[Philipp Zabel]

Hi Dave,

Am Montag, den 29.08.2016, 17:44 +0200 schrieb Daniel Vetter:
> On Mon, Aug 29, 2016 at 4:59 PM, Philipp Zabel  
> wrote:
> > Am Montag, den 29.08.2016, 12:53 +0200 schrieb Philipp Zabel:
> >> Am Freitag, den 26.08.2016, 15:30 +0800 schrieb Liu Ying:
> >> > This patch adds active plane reconfiguration support for imx-drm.
> >> > This may fixes some mode setting failure issues which were introduced
> >> > by imx-drm atomic conversion patch set.  The main idea is to disable the
> >> > plane in question in CRTC's atomic_disable operation and then the drm
> >> > atomic core will enable it again automatically.
> >>
> >> I have rebased onto drm-misc and picked up the remaining patches (4-7)
> >
> > Actually, since this is a regression and the new drm-misc patches won't
> > make it into 4.8, I'd be inclined to take the v2 patch as a fix for 4.8
> > and then apply the remaining patches as relative changes to that on top
> > of drm-misc instead.
> 
> Just apply the 4.8 to 4.8 and then once that's in an -rc do a
> backmerge with -X ours and explain in the commit what you're doing. No
> need to rework the patches once more to be incremental on top of the
> 4.8 fix.
> 
> At least that's what we're doing all the time in i915.
> -Daniel

Could you merge v4.8-rc3 into drm-next? After backmerging
drm-intel-fixes-2016-08-15 with -s ours, v4.8-rc3 just auto-merges
cleanly, but I assume I shouldn't do that inside an imx-drm pull
request.

Since imx-drm-fixes-2016-08-29 is based on v4.8-rc3, I'd otherwise have
to pull it in with that backmerge, to resolve the conflict between
commit c6c1f9bc798b ("drm/imx: Add active plane reconfiguration
support") that went into v4.8-rc5 and the newer version in imx-drm/next.

regards
Philipp

4.8-rc1: it is now common that machine needs re-run of xrandr after resume

[Jani Nikula]

On Wed, 14 Sep 2016, Pavel Machek  wrote:
> Intel folks, any ideas? Can you reproduce it?

It's possible (but not confirmed yet) we've seen this in our CI, but has
slipped through because it's sporadic.

BR,
Jani.


-- 
Jani Nikula, Intel Open Source Technology Center

[PATCH] drm: Only use compat ioctl for addfb2 on X86/IA64

[Rob Clark]

On Tue, Sep 13, 2016 at 5:20 PM, Kristian H. Kristensen
 wrote:
> Similar to struct drm_update_draw, struct drm_mode_fb_cmd2 has an
> unaligned 64 bit field (modifier). This get packed differently between
> 32 bit and 64 bit modes on architectures that can handle unaligned 64
> bit access (X86 and IA64).  Other architectures pack the structs the
> same and don't need the compat wrapper. Use the same condition for
> drm_mode_fb_cmd2 as we use for drm_update_draw.

might not hurt to mention that this only effects stuff using modifiers
in commit msg

Reviewed-by: Rob Clark 

> Signed-off-by: Kristian H. Kristensen 
> ---
>  drivers/gpu/drm/drm_ioc32.c | 4 
>  1 file changed, 4 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_ioc32.c b/drivers/gpu/drm/drm_ioc32.c
> index 57676f8..a628975 100644
> --- a/drivers/gpu/drm/drm_ioc32.c
> +++ b/drivers/gpu/drm/drm_ioc32.c
> @@ -1015,6 +1015,7 @@ static int compat_drm_wait_vblank(struct file *file, 
> unsigned int cmd,
> return 0;
>  }
>
> +#if defined(CONFIG_X86) || defined(CONFIG_IA64)
>  typedef struct drm_mode_fb_cmd232 {
> u32 fb_id;
> u32 width;
> @@ -1071,6 +1072,7 @@ static int compat_drm_mode_addfb2(struct file *file, 
> unsigned int cmd,
>
> return 0;
>  }
> +#endif
>
>  static drm_ioctl_compat_t *drm_compat_ioctls[] = {
> [DRM_IOCTL_NR(DRM_IOCTL_VERSION32)] = compat_drm_version,
> @@ -1104,7 +1106,9 @@ static drm_ioctl_compat_t *drm_compat_ioctls[] = {
> [DRM_IOCTL_NR(DRM_IOCTL_UPDATE_DRAW32)] = compat_drm_update_draw,
>  #endif
> [DRM_IOCTL_NR(DRM_IOCTL_WAIT_VBLANK32)] = compat_drm_wait_vblank,
> +#if defined(CONFIG_X86) || defined(CONFIG_IA64)
> [DRM_IOCTL_NR(DRM_IOCTL_MODE_ADDFB232)] = compat_drm_mode_addfb2,
> +#endif
>  };
>
>  /**
> --
> 2.8.0.rc3.226.g39d4020
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/amdgpu: fix semicolon.cocci warnings

[kbuild test robot]

drivers/gpu/drm/amd/amdgpu/../dal/amdgpu_dm/amdgpu_dm_types.c:827:59-60: 
Unneeded semicolon
drivers/gpu/drm/amd/amdgpu/../dal/amdgpu_dm/amdgpu_dm_types.c:828:55-56: 
Unneeded semicolon
drivers/gpu/drm/amd/amdgpu/../dal/amdgpu_dm/amdgpu_dm_types.c:829:57-58: 
Unneeded semicolon
drivers/gpu/drm/amd/amdgpu/../dal/amdgpu_dm/amdgpu_dm_types.c:830:53-54: 
Unneeded semicolon
drivers/gpu/drm/amd/amdgpu/../dal/amdgpu_dm/amdgpu_dm_types.c:831:47-48: 
Unneeded semicolon


 Remove unneeded semicolon.

Generated by: scripts/coccinelle/misc/semicolon.cocci

CC: Harry Wentland 
Signed-off-by: Fengguang Wu 
---

 amdgpu_dm_types.c |   10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

--- a/drivers/gpu/drm/amd/amdgpu/../dal/amdgpu_dm/amdgpu_dm_types.c
+++ b/drivers/gpu/drm/amd/amdgpu/../dal/amdgpu_dm/amdgpu_dm_types.c
@@ -824,11 +824,11 @@ static void copy_crtc_timing_for_drm_dis
dst_mode->crtc_hsync_end = src_mode->crtc_hsync_end;
dst_mode->crtc_htotal = src_mode->crtc_htotal;
dst_mode->crtc_hskew = src_mode->crtc_hskew;
-   dst_mode->crtc_vblank_start = src_mode->crtc_vblank_start;;
-   dst_mode->crtc_vblank_end = src_mode->crtc_vblank_end;;
-   dst_mode->crtc_vsync_start = src_mode->crtc_vsync_start;;
-   dst_mode->crtc_vsync_end = src_mode->crtc_vsync_end;;
-   dst_mode->crtc_vtotal = src_mode->crtc_vtotal;;
+   dst_mode->crtc_vblank_start = src_mode->crtc_vblank_start;
+   dst_mode->crtc_vblank_end = src_mode->crtc_vblank_end;
+   dst_mode->crtc_vsync_start = src_mode->crtc_vsync_start;
+   dst_mode->crtc_vsync_end = src_mode->crtc_vsync_end;
+   dst_mode->crtc_vtotal = src_mode->crtc_vtotal;
 }

 static void decide_crtc_timing_for_drm_display_mode(

[radeon-alex:amd-staging-4.7 367/1327] drivers/gpu/drm/amd/amdgpu/../dal/amdgpu_dm/amdgpu_dm_types.c:827:59-60: Unneeded semicolon

[kbuild test robot]

tree:   git://people.freedesktop.org/~agd5f/linux.git amd-staging-4.7
head:   af8331c5eae54c760bd990e9c96966436451fec7
commit: a0dec5cf512edb0ba5f0b34d5b83d911a890fd5c [367/1327] drm/amdgpu: Use dal 
driver for CZ


coccinelle warnings: (new ones prefixed by >>)

>> drivers/gpu/drm/amd/amdgpu/../dal/amdgpu_dm/amdgpu_dm_types.c:827:59-60: 
>> Unneeded semicolon
   drivers/gpu/drm/amd/amdgpu/../dal/amdgpu_dm/amdgpu_dm_types.c:828:55-56: 
Unneeded semicolon
   drivers/gpu/drm/amd/amdgpu/../dal/amdgpu_dm/amdgpu_dm_types.c:829:57-58: 
Unneeded semicolon
   drivers/gpu/drm/amd/amdgpu/../dal/amdgpu_dm/amdgpu_dm_types.c:830:53-54: 
Unneeded semicolon
   drivers/gpu/drm/amd/amdgpu/../dal/amdgpu_dm/amdgpu_dm_types.c:831:47-48: 
Unneeded semicolon

Please review and possibly fold the followup patch.

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation

[Intel-gfx] Bad flicker on skylake HQD due to code in the 4.7 merge window

[Jani Nikula]

On Mon, 20 Jun 2016, James Bottomley  
wrote:
> On Fri, 2016-06-17 at 16:06 -0700, James Bottomley wrote:
>> On Fri, 2016-06-17 at 16:34 +0300, Jani Nikula wrote:
>> > On Fri, 17 Jun 2016, Daniel Vetter  wrote:
>> > > On Thu, Jun 16, 2016 at 03:42:12PM -0700, James Bottomley wrote:
>> > > > On Thu, 2016-06-16 at 14:29 -0700, James Bottomley wrote:
>> > > > > On Thu, 2016-06-16 at 23:24 +0200, Daniel Vetter wrote:
>> > > > > > I guess we'll need the bisect on this one to make progress.
>> > > > > 
>> > > > > Sigh, I was afraid that might be the next step.
>> > > > 
>> > > > OK, I have a curious data point.  I assumed the problem would
>> > > > be
>> > > > somewhere in the drm update, so I started bisecting that at the
>> > > > top. 
>> > > >  However, the top most commit:
>> > > > 
>> > > > commit 1d6da87a3241deb13d073c4125d19ed0e5a0c62c
>> > > > Merge: 1f40c49 a39ed68
>> > > > Author: Linus Torvalds 
>> > > > Date:   Mon May 23 11:48:48 2016 -0700
>> > > > 
>> > > > Merge branch 'drm-next' of
>> > > > git://people.freedesktop.org/~airlied/linux
>> > > > 
>> > > > Isn't actually bad.  There's no flicker here, so whatever
>> > > > caused
>> > > > the
>> > > > problem came from some update after this.
>> > > 
>> > > There was a fixes pull after this. Might be worth it to restrict
>> > > to
>> > > just
>> > > the i915 changes, which are just
>> > > 5b4fd5bb1230cd037..157d2c7fad0863222
>> > > 
>> > > Looking at those nothing seems to stick out which might explain
>> > > what's
>> > > happening for you.
>> 
>> OK, so just on the firmware, the system seems less flickery with the
>> new 1.4.3 UEFI, so I'm starting to think it is a Skylake errata 
>> issue.  The flicker isn't gone for good, but seems to be reboot 
>> dependent (it's there in some boots, but gone on a reboot).
>> 
>> > This should be easy enough to try before bisecting:
>> > http://patchwork.freedesktop.org/patch/msgid/1466162081-12042-1-git
>> > -s
>> > end-email-mika.kahola at intel.com
>> 
>> Applying this didn't seem to make a difference: still there on some 
>> and gone on other reboots.
>
> OK, my candidate bad commit is this one:
>
> commit a05628195a0d9f3173dd9aa76f482aef692e46ee
> Author: Ville Syrjälä 
> Date:   Mon Apr 11 10:23:51 2016 +0300
>
> drm/i915: Get panel_type from OpRegion panel details
>
> After being more careful about waiting to identify flicker, this one
> seems to be the one the bisect finds.  I'm now running v4.7-rc3 with
> this one reverted and am currently seeing no flicker problems.  It is,
> however, early days because the flicker can hide for long periods, so I
> 'll wait until Monday evening and a few reboots before declaring
> victory.

Fixed by

commit ea54ff4008892b46c7a3e6bc8ab8aaec9d198639
Author: Ville Syrjälä 
Date:   Tue Sep 13 12:22:19 2016 +0300

drm/i915: Ignore OpRegion panel type except on select machines

in drm-intel-fixes, headed upstream soon-ish.

BR,
Jani.


-- 
Jani Nikula, Intel Open Source Technology Center

[PATCH 0/1] drm: i915: don't use OpRegion for XPS 13 IvyBridge

[Jani Nikula]

On Sun, 28 Aug 2016, Andrea Arcangeli  wrote:
> I was bitten by this bug all last week while running latest kernels on
> my laptop at KVMForum.
>
> I then found the bug was also reported here:
>
> https://bugzilla.kernel.org/show_bug.cgi?id=151731

Fixed by

commit ea54ff4008892b46c7a3e6bc8ab8aaec9d198639
Author: Ville Syrjälä 
Date:   Tue Sep 13 12:22:19 2016 +0300

drm/i915: Ignore OpRegion panel type except on select machines

in drm-intel-fixes.



-- 
Jani Nikula, Intel Open Source Technology Center

[ADV7393] DRM Encoder Slave or DRM Bridge

[Tomi Valkeinen]

On 13/09/16 16:13, Vikas Patil wrote:
> Thanks Tomi for quick comment.
> 
> I am thinking to base adv7393 driver on
> "drivers\gpu\drm\omapdrm\displays\encoder-tc358768.c" as I don't think
> any similar to adv7393 chip driver available. Could you please comment
> if this will help to get adv chip running?

I presume you're not using mainline kernel, as that driver is not there.
I'm not familiar with adv7393, but yes, I think you can use that as an
example.

> I tried to add the device tree config but after adding device
> configuration related to adv7393, my first display stopped working and
> whenever I run kmscube or modetest it fails.

If you don't have all the display pipelines working (i.e. the drivers
present and working), none of the displays will work.

> I have following configuration related to displays. Could anyone tell
> me if I am doing anything wrong in DTS configuration? What could be
> going wrong when I enable adv7393 related config so display 1 stops
> working?

The dts looks ok.

 Tomi

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

4.8-rc1: it is now common that machine needs re-run of xrandr after resume

[Jani Nikula]

On Wed, 14 Sep 2016, Pavel Machek  wrote:
> For the "sometimes need xrandr after resume": I don't think I can
> bisect that. It only happens sometimes :-(. But there's something
> helpful in the logs:

> [ 1856.218863] [drm:drm_edid_block_valid] *ERROR* EDID checksum is
> invalid, remainder is 130
> [ 1856.218863] Raw EDID:
> [ 1856.218863] 00 ff ff ff ff ff ff 00 ff ff ff ff ff ff ff ff
> [ 1856.218863] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> [ 1856.218863] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> [ 1856.218863] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> [ 1856.218863] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> [ 1856.218863] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> [ 1856.218863] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> [ 1856.218863] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> [ 1856.218863] [drm:drm_edid_block_valid] *ERROR* EDID checksum is
> invalid, remainder is 130
> [ 1856.218863] Raw EDID:
> [ 1856.218863] 00 ff ff ff ff ff ff 00 ff ff ff ff ff ff ff ff
> [ 1856.218863] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> [ 1856.218863] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> [ 1856.218863] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> [ 1856.218863] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> [ 1856.218863] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> [ 1856.218863] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> [ 1856.218863] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> [ 1856.218863] [drm:drm_edid_block_valid] *ERROR* EDID checksum is
> invalid, remainder is 130
> [ 1856.218863] Raw EDID:
> [ 1856.218863] 00 ff ff ff ff ff ff 00 ff ff ff ff ff ff ff ff
> [ 1856.218863] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> [ 1856.218863] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> [ 1856.218863] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> [ 1856.218863] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> [ 1856.218863] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> [ 1856.218863] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> [ 1856.218863] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> [ 1856.218863] [drm:drm_edid_block_valid] *ERROR* EDID checksum is
> invalid, remainder is 130
> [ 1856.218863] Raw EDID:
> [ 1856.218863] 00 ff ff ff ff ff ff 00 ff ff ff ff ff ff ff ff
> [ 1856.218863] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> [ 1856.218863] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> [ 1856.218863] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> [ 1856.218863] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> [ 1856.218863] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> [ 1856.218863] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> [ 1856.218863] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> [ 1856.218863] i915 :00:02.0: HDMI-A-1: EDID block 0 invalid.

Pavel, Martin, do you always see this when the display fails to resume?
Is it HDMI/DVI for both of you?


BR,
Jani.


-- 
Jani Nikula, Intel Open Source Technology Center

[Intel-gfx] 4.8-rc1: it is now common that machine needs re-run of xrandr after resume

[Chris Wilson]

On Tue, Sep 13, 2016 at 11:04:37PM +0200, Pavel Machek wrote:
> Hi!
> 
> > I have
> > 
> > 00:02.0 VGA compatible controller: Intel Corporation 4 Series Chipset
> > Integrated Graphics Controller (rev 03)
> > 
> > In previous kernels, resume worked ok. With 4.8-rc1, I quite often (1
> > in 10 resumes?) get in state where primary monitor (DVI) is dead (in
> > powersave) and all windows move to secondary monitor (VGA). Running
> > "xrandr" fixes that.
> > 
> > I'll update to newer rc and see if it happens again, but if you have
> > any ideas, now would be good time.
> 
> Ok. With -rc6, X are completely broken. I got notification "could not
> restore CRTC config for screen 63" or something like that, and window
> manager just does not start.
> 
> X log is attached as delme, kernel log as delme2. Nothing too
> suspicious :-(.

[   234.547] (EE) intel(0): failed to set mode: Permission denied
upon resume.

There is a VT switch so there should be a DropMaster, SetMaster combo
across resume, but that didn't flag any errors. I couldn't see any sign
of logind (so no revocation), so just some breakage in the setmaster
reauthentication?
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre

[PATCH v3 1/1] Add nvd9128 as a simple panel

[Fabien Lahoudere]

Add New Vision Display 7.0" 800 RGB x 480 TFT LCD panel

Signed-off-by: Fabien Lahoudere 
Acked-by: Rob Herring 
---
 .../devicetree/bindings/display/panel/nvd,9128.txt |  7 ++
 .../devicetree/bindings/vendor-prefixes.txt|  1 +
 drivers/gpu/drm/panel/panel-simple.c   | 26 ++
 3 files changed, 34 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/display/panel/nvd,9128.txt

diff --git a/Documentation/devicetree/bindings/display/panel/nvd,9128.txt 
b/Documentation/devicetree/bindings/display/panel/nvd,9128.txt
new file mode 100644
index 000..17bcd01
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/nvd,9128.txt
@@ -0,0 +1,7 @@
+New Vision Display 7.0" 800 RGB x 480 TFT LCD panel
+
+Required properties:
+- compatible: should be "nvd,9128"
+
+This binding is compatible with the simple-panel binding, which is specified
+in simple-panel.txt in this directory.
diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt 
b/Documentation/devicetree/bindings/vendor-prefixes.txt
index 0d9d4d8..f4eb4f3 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.txt
+++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
@@ -179,6 +179,7 @@ netgear NETGEAR
 netlogic   Broadcom Corporation (formerly NetLogic Microsystems)
 netxeonShenzhen Netxeon Technology CO., LTD
 newhaven   Newhaven Display International
+nvdNew Vision Display
 nintendo   Nintendo
 nokia  Nokia
 nuvotonNuvoton Technology Corporation
diff --git a/drivers/gpu/drm/panel/panel-simple.c 
b/drivers/gpu/drm/panel/panel-simple.c
index f178998..5952e16 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -1136,6 +1136,29 @@ static const struct panel_desc nec_nl4827hc19_05b = {
.bus_flags = DRM_BUS_FLAG_PIXDATA_POSEDGE,
 };

+static const struct drm_display_mode nvd_9128_mode = {
+   .clock = 29500,
+   .hdisplay = 800,
+   .hsync_start = 800 + 130,
+   .hsync_end = 800 + 130 + 98,
+   .htotal = 800 + 0 + 130 + 98,
+   .vdisplay = 480,
+   .vsync_start = 480 + 10,
+   .vsync_end = 480 + 10 + 50,
+   .vtotal = 480 + 0 + 10 + 50,
+};
+
+static const struct panel_desc nvd_9128 = {
+   .modes = _9128_mode,
+   .num_modes = 1,
+   .bpc = 8,
+   .size = {
+   .width = 156,
+   .height = 88,
+   },
+   .bus_format = MEDIA_BUS_FMT_RGB888_1X7X4_SPWG,
+};
+
 static const struct display_timing okaya_rs800480t_7x0gp_timing = {
.pixelclock = { 3000, 3000, 4000 },
.hactive = { 800, 800, 800 },
@@ -1616,6 +1639,9 @@ static const struct of_device_id platform_of_match[] = {
.compatible = "nec,nl4827hc19-05b",
.data = _nl4827hc19_05b,
}, {
+   .compatible = "nvd,9128",
+   .data = _9128,
+   }, {
.compatible = "okaya,rs800480t-7x0gp",
.data = _rs800480t_7x0gp,
}, {
-- 
2.1.4

[PATCH] dma-buf/sync_file: Always increment refcount when merging fences.

[Chris Wilson]

On Tue, Sep 13, 2016 at 04:24:27PM -0700, Rafael Antognolli wrote:
> The refcount of a fence should be increased whenever it is added to a merged
> fence, since it will later be decreased when the merged fence is destroyed.
> Failing to do so will cause the original fence to be freed if the merged fence
> gets freed, but other places still referencing won't know about it.
> 
> This patch fixes a kernel panic that can be triggered by creating a fence that
> is expired (or increasing the timeline until it expires), then creating a
> merged fence out of it, and deleting the merged fence. This will make the
> original expired fence's refcount go to zero.
> 
> Signed-off-by: Rafael Antognolli 
> ---
> 
> Sample code to trigger the mentioned kernel panic (might need to be executed a
> couple times before it actually breaks everything):
> 
> static void test_sync_expired_merge(void)
> {
>int iterations = 1 << 20;
>int timeline;
>int i;
>int fence_expired, fence_merged;
> 
>timeline = sw_sync_timeline_create();
> 
>sw_sync_timeline_inc(timeline, 100);
>fence_expired = sw_sync_fence_create(timeline, 1);
>fence_merged = sw_sync_merge(fence_expired, fence_expired);
>sw_sync_fence_destroy(fence_merged);
> 
>for (i = 0; i < iterations; i++) {
>int fence = sw_sync_merge(fence_expired, fence_expired);
> 
>igt_assert_f(sw_sync_wait(fence, -1) > 0,
> "Failure waiting on fence\n");
>sw_sync_fence_destroy(fence);
>}
> 
>sw_sync_fence_destroy(fence_expired);
> }
> 
>  drivers/dma-buf/sync_file.c | 7 ++-
>  1 file changed, 2 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/dma-buf/sync_file.c b/drivers/dma-buf/sync_file.c
> index 486d29c..6ce6b8f 100644
> --- a/drivers/dma-buf/sync_file.c
> +++ b/drivers/dma-buf/sync_file.c
> @@ -178,11 +178,8 @@ static struct fence **get_fences(struct sync_file 
> *sync_file, int *num_fences)
>  static void add_fence(struct fence **fences, int *i, struct fence *fence)
>  {
>   fences[*i] = fence;
> -
> - if (!fence_is_signaled(fence)) {
> - fence_get(fence);
> - (*i)++;
> - }
> + fence_get(fence);
> + (*i)++;
>  }

I think you'll find it's the caller:

if (i == 0) {
add_fence(fences, , a_fences[0]);
i++;
}

that does the unexpected.

This should be 

if (i == 0)
fences[i++] = fence_get(a_fences[0]);


That ensures the sync_file inherits the signaled status without having
to keep all fences.

I think there still seems to be a memory leak when calling
sync_file_set_fence() here with i == 1.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre

[PATCH] dma-buf/sync_file: Always increment refcount when merging fences.

[Gustavo Padovan]

2016-09-14 Chris Wilson :

> On Tue, Sep 13, 2016 at 04:24:27PM -0700, Rafael Antognolli wrote:
> > The refcount of a fence should be increased whenever it is added to a merged
> > fence, since it will later be decreased when the merged fence is destroyed.
> > Failing to do so will cause the original fence to be freed if the merged 
> > fence
> > gets freed, but other places still referencing won't know about it.
> > 
> > This patch fixes a kernel panic that can be triggered by creating a fence 
> > that
> > is expired (or increasing the timeline until it expires), then creating a
> > merged fence out of it, and deleting the merged fence. This will make the
> > original expired fence's refcount go to zero.
> > 
> > Signed-off-by: Rafael Antognolli 
> > ---
> > 
> > Sample code to trigger the mentioned kernel panic (might need to be 
> > executed a
> > couple times before it actually breaks everything):
> > 
> > static void test_sync_expired_merge(void)
> > {
> >int iterations = 1 << 20;
> >int timeline;
> >int i;
> >int fence_expired, fence_merged;
> > 
> >timeline = sw_sync_timeline_create();
> > 
> >sw_sync_timeline_inc(timeline, 100);
> >fence_expired = sw_sync_fence_create(timeline, 1);
> >fence_merged = sw_sync_merge(fence_expired, fence_expired);
> >sw_sync_fence_destroy(fence_merged);
> > 
> >for (i = 0; i < iterations; i++) {
> >int fence = sw_sync_merge(fence_expired, fence_expired);
> > 
> >igt_assert_f(sw_sync_wait(fence, -1) > 0,
> > "Failure waiting on fence\n");
> >sw_sync_fence_destroy(fence);
> >}
> > 
> >sw_sync_fence_destroy(fence_expired);
> > }
> > 
> >  drivers/dma-buf/sync_file.c | 7 ++-
> >  1 file changed, 2 insertions(+), 5 deletions(-)
> > 
> > diff --git a/drivers/dma-buf/sync_file.c b/drivers/dma-buf/sync_file.c
> > index 486d29c..6ce6b8f 100644
> > --- a/drivers/dma-buf/sync_file.c
> > +++ b/drivers/dma-buf/sync_file.c
> > @@ -178,11 +178,8 @@ static struct fence **get_fences(struct sync_file 
> > *sync_file, int *num_fences)
> >  static void add_fence(struct fence **fences, int *i, struct fence *fence)
> >  {
> > fences[*i] = fence;
> > -
> > -   if (!fence_is_signaled(fence)) {
> > -   fence_get(fence);
> > -   (*i)++;
> > -   }
> > +   fence_get(fence);
> > +   (*i)++;
> >  }
> 
> I think you'll find it's the caller:
> 
> if (i == 0) {
>   add_fence(fences, , a_fences[0]);
>   i++;
> }
> 
> that does the unexpected.
> 
> This should be 
> 
> if (i == 0)
>   fences[i++] = fence_get(a_fences[0]);

You are right. Otherwise we would miss the extra reference. i == 0 here
means that all fences are signalled.

> 
> 
> That ensures the sync_file inherits the signaled status without having
> to keep all fences.
> 
> I think there still seems to be a memory leak when calling
> sync_file_set_fence() here with i == 1.

I think that is something we discussed already, we don't hold an extra
ref there for i == 1 because it would leak the fence.

Gustavo

4.8-rc1: it is now common that machine needs re-run of xrandr after resume

[Jani Nikula]

On Wed, 14 Sep 2016, Jani Nikula  wrote:
> On Wed, 14 Sep 2016, Pavel Machek  wrote:
>> Hi!
>>
>>> I have
>>> 
>>> 00:02.0 VGA compatible controller: Intel Corporation 4 Series Chipset
>>> Integrated Graphics Controller (rev 03)
>>> 
>>> In previous kernels, resume worked ok. With 4.8-rc1, I quite often (1
>>> in 10 resumes?) get in state where primary monitor (DVI) is dead (in
>>> powersave) and all windows move to secondary monitor (VGA). Running
>>> "xrandr" fixes that.
>>> 
>>> I'll update to newer rc and see if it happens again, but if you have
>>> any ideas, now would be good time.
>>
>> Ok. With -rc6, X are completely broken. I got notification "could not
>> restore CRTC config for screen 63" or something like that, and window
>> manager just does not start.
>
> Ugh. Can you bisect from v4.7, assuming it worked? That's probably the
> fastest way to resolve this.

Also, if you don't mind, please file a bug at [1], attaching the logs
there. It'll be easier for me to direct attention and priority to the
bug, which will help you too in the end.

Thanks,
Jani.

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

-- 
Jani Nikula, Intel Open Source Technology Center

[PATCH] drm/vc4: cleanup with list_first_entry_or_null()

[Eric Anholt]

Masahiro Yamada  writes:

> The combo of list_empty() check and return list_first_entry()
> can be replaced with list_first_entry_or_null().
>
> Signed-off-by: Masahiro Yamada 

That's a nice little cleanup.  Applied to -next.  Thanks!
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 800 bytes
Desc: not available
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160914/a566c40c/attachment.sig>

4.8-rc1: it is now common that machine needs re-run of xrandr after resume

[Jani Nikula]

On Wed, 14 Sep 2016, Pavel Machek  wrote:
> Hi!
>
>> I have
>> 
>> 00:02.0 VGA compatible controller: Intel Corporation 4 Series Chipset
>> Integrated Graphics Controller (rev 03)
>> 
>> In previous kernels, resume worked ok. With 4.8-rc1, I quite often (1
>> in 10 resumes?) get in state where primary monitor (DVI) is dead (in
>> powersave) and all windows move to secondary monitor (VGA). Running
>> "xrandr" fixes that.
>> 
>> I'll update to newer rc and see if it happens again, but if you have
>> any ideas, now would be good time.
>
> Ok. With -rc6, X are completely broken. I got notification "could not
> restore CRTC config for screen 63" or something like that, and window
> manager just does not start.

Ugh. Can you bisect from v4.7, assuming it worked? That's probably the
fastest way to resolve this.

BR,
Jani.

>
> X log is attached as delme, kernel log as delme2. Nothing too
> suspicious :-(.
>
>   Pavel

-- 
Jani Nikula, Intel Open Source Technology Center

[PATCH 2nd RESEND v2 3/3] drm/bridge: add Silicon Image SiI8620 driver

[Andrzej Hajda]

SiI8620 transmitter converts eTMDS/HDMI signal to MHL 3.0.
It is controlled via I2C bus. Its interaction with other
devices in video pipeline is performed mainly on HW level.
The only interaction it does on device driver level is
filtering-out unsupported video modes, it exposes drm_bridge
interface to perform this operation.

Signed-off-by: Andrzej Hajda 
---
 drivers/gpu/drm/bridge/Kconfig   |7 +
 drivers/gpu/drm/bridge/Makefile  |1 +
 drivers/gpu/drm/bridge/sil-sii8620.c | 1568 ++
 drivers/gpu/drm/bridge/sil-sii8620.h | 1517 
 4 files changed, 3093 insertions(+)
 create mode 100644 drivers/gpu/drm/bridge/sil-sii8620.c
 create mode 100644 drivers/gpu/drm/bridge/sil-sii8620.h

diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
index b590e67..e7fb179 100644
--- a/drivers/gpu/drm/bridge/Kconfig
+++ b/drivers/gpu/drm/bridge/Kconfig
@@ -50,6 +50,13 @@ config DRM_PARADE_PS8622
---help---
  Parade eDP-LVDS bridge chip driver.

+config DRM_SIL_SII8620
+   tristate "Silicon Image SII8620 HDMI/MHL bridge"
+   depends on OF
+   select DRM_KMS_HELPER
+   help
+ Silicon Image SII8620 HDMI/MHL bridge chip driver.
+
 config DRM_SII902X
tristate "Silicon Image sii902x RGB/HDMI bridge"
depends on OF
diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile
index efdb07e..304cf9d 100644
--- a/drivers/gpu/drm/bridge/Makefile
+++ b/drivers/gpu/drm/bridge/Makefile
@@ -5,6 +5,7 @@ obj-$(CONFIG_DRM_DW_HDMI) += dw-hdmi.o
 obj-$(CONFIG_DRM_DW_HDMI_AHB_AUDIO) += dw-hdmi-ahb-audio.o
 obj-$(CONFIG_DRM_NXP_PTN3460) += nxp-ptn3460.o
 obj-$(CONFIG_DRM_PARADE_PS8622) += parade-ps8622.o
+obj-$(CONFIG_DRM_SIL_SII8620) += sil-sii8620.o
 obj-$(CONFIG_DRM_SII902X) += sii902x.o
 obj-$(CONFIG_DRM_TOSHIBA_TC358767) += tc358767.o
 obj-$(CONFIG_DRM_ANALOGIX_DP) += analogix/
diff --git a/drivers/gpu/drm/bridge/sil-sii8620.c 
b/drivers/gpu/drm/bridge/sil-sii8620.c
new file mode 100644
index 000..3b273c7
--- /dev/null
+++ b/drivers/gpu/drm/bridge/sil-sii8620.c
@@ -0,0 +1,1568 @@
+/*
+ * Driver for Silicon Image SiI8620 Mobile HD Transmitter
+ *
+ * Copyright (C) 2015, Samsung Electronics Co., Ltd.
+ * Andrzej Hajda 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "sil-sii8620.h"
+
+#define VAL_RX_HDMI_CTRL2_DEFVAL   VAL_RX_HDMI_CTRL2_IDLE_CNT(3)
+
+enum sii8620_mode {
+   CM_DISCONNECTED,
+   CM_DISCOVERY,
+   CM_MHL1,
+   CM_MHL3,
+   CM_ECBUS_S
+};
+
+enum sii8620_sink_type {
+   SINK_NONE,
+   SINK_HDMI,
+   SINK_DVI
+};
+
+enum sii8620_mt_state {
+   MT_STATE_READY,
+   MT_STATE_BUSY,
+   MT_STATE_DONE
+};
+
+struct sii8620 {
+   struct drm_bridge bridge;
+   struct device *dev;
+   struct clk *clk_xtal;
+   struct gpio_desc *gpio_reset;
+   struct gpio_desc *gpio_int;
+   struct regulator_bulk_data supplies[2];
+   struct mutex lock; /* context lock, protects fields below */
+   int error;
+   enum sii8620_mode mode;
+   enum sii8620_sink_type sink_type;
+   u8 cbus_status;
+   u8 stat[MHL_DST_SIZE];
+   u8 xstat[MHL_XDS_SIZE];
+   u8 devcap[MHL_DCAP_SIZE];
+   u8 xdevcap[MHL_XDC_SIZE];
+   u8 avif[19];
+   struct edid *edid;
+   unsigned int gen2_write_burst:1;
+   enum sii8620_mt_state mt_state;
+   struct list_head mt_queue;
+};
+
+struct sii8620_mt_msg;
+
+typedef void (*sii8620_mt_msg_cb)(struct sii8620 *ctx,
+ struct sii8620_mt_msg *msg);
+
+struct sii8620_mt_msg {
+   struct list_head node;
+   u8 reg[4];
+   u8 ret;
+   sii8620_mt_msg_cb send;
+   sii8620_mt_msg_cb recv;
+};
+
+static const u8 sii8620_i2c_page[] = {
+   0x39, /* Main System */
+   0x3d, /* TDM and HSIC */
+   0x49, /* TMDS Receiver, MHL EDID */
+   0x4d, /* eMSC, HDCP, HSIC */
+   0x5d, /* MHL Spec */
+   0x64, /* MHL CBUS */
+   0x59, /* Hardware TPI (Transmitter Programming Interface) */
+   0x61, /* eCBUS-S, eCBUS-D */
+};
+
+static void sii8620_fetch_edid(struct sii8620 *ctx);
+static void sii8620_set_upstream_edid(struct sii8620 *ctx);
+static void sii8620_enable_hpd(struct sii8620 *ctx);
+static void sii8620_mhl_disconnected(struct sii8620 *ctx);
+
+static int sii8620_clear_error(struct sii8620 *ctx)
+{
+   int ret = ctx->error;
+
+   ctx->error = 0;
+   return ret;
+}
+
+static void sii8620_read_buf(struct sii8620 *ctx, u16 addr, u8 *buf, int len)
+{
+   struct device *dev = ctx->dev;
+   struct i2c_client *client = 

[PATCH 2nd RESEND v2 2/3] dt-bindings: add Silicon Image SiI8620 bridge bindings

[Andrzej Hajda]

SiI8620 transmitter converts eTMDS/HDMI signal to MHL 3.0. It is controlled
via I2C bus.

Signed-off-by: Andrzej Hajda 
Acked-by: Rob Herring 
---
 .../bindings/video/bridge/sil-sii8620.txt  | 33 ++
 1 file changed, 33 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/video/bridge/sil-sii8620.txt

diff --git a/Documentation/devicetree/bindings/video/bridge/sil-sii8620.txt 
b/Documentation/devicetree/bindings/video/bridge/sil-sii8620.txt
new file mode 100644
index 000..9409d9c
--- /dev/null
+++ b/Documentation/devicetree/bindings/video/bridge/sil-sii8620.txt
@@ -0,0 +1,33 @@
+Silicon Image SiI8620 HDMI/MHL bridge bindings
+
+Required properties:
+   - compatible: "sil,sii8620"
+   - reg: i2c address of the bridge
+   - cvcc10-supply: Digital Core Supply Voltage (1.0V)
+   - iovcc18-supply: I/O Supply Voltage (1.8V)
+   - interrupts, interrupt-parent: interrupt specifier of INT pin
+   - reset-gpios: gpio specifier of RESET pin
+   - clocks, clock-names: specification and name of "xtal" clock
+   - video interfaces: Device node can contain video interface port
+   node for HDMI encoder according to [1].
+
+[1]: Documentation/devicetree/bindings/media/video-interfaces.txt
+
+Example:
+   sii8620 at 39 {
+   reg = <0x39>;
+   compatible = "sil,sii8620";
+   cvcc10-supply = <_reg>;
+   iovcc18-supply = <_reg>;
+   interrupt-parent = <>;
+   interrupts = <2 0>;
+   reset-gpio = < 0 0>;
+   clocks = <_system_controller 0>;
+   clock-names = "xtal";
+
+   port {
+   mhl_to_hdmi: endpoint {
+   remote-endpoint = <_to_mhl>;
+   };
+   };
+   };
-- 
1.9.1

[PATCH 2nd RESEND v2 1/3] video: add header file for Mobile High-Definition Link (MHL) interface

[Andrzej Hajda]

This header adds definitions specific to MHL protocol.

Signed-off-by: Andrzej Hajda 
---
 include/linux/mhl.h | 292 
 1 file changed, 292 insertions(+)
 create mode 100644 include/linux/mhl.h

diff --git a/include/linux/mhl.h b/include/linux/mhl.h
new file mode 100644
index 000..6917508
--- /dev/null
+++ b/include/linux/mhl.h
@@ -0,0 +1,292 @@
+/*
+ * Defines for Mobile High-Definition Link (MHL) interface
+ *
+ * Copyright (C) 2015, Samsung Electronics, Co., Ltd.
+ * Andrzej Hajda 
+ *
+ * Based on MHL driver for Android devices.
+ * Copyright (C) 2013-2014 Silicon Image, Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#ifndef LINUX_MHL_H
+#define LINUX_MHL_H
+
+/* Device Capabilities Registers */
+enum {
+   MHL_DCAP_DEV_STATE,
+   MHL_DCAP_MHL_VERSION,
+   MHL_DCAP_CAT,
+   MHL_DCAP_ADOPTER_ID_H,
+   MHL_DCAP_ADOPTER_ID_L,
+   MHL_DCAP_VID_LINK_MODE,
+   MHL_DCAP_AUD_LINK_MODE,
+   MHL_DCAP_VIDEO_TYPE,
+   MHL_DCAP_LOG_DEV_MAP,
+   MHL_DCAP_BANDWIDTH,
+   MHL_DCAP_FEATURE_FLAG,
+   MHL_DCAP_DEVICE_ID_H,
+   MHL_DCAP_DEVICE_ID_L,
+   MHL_DCAP_SCRATCHPAD_SIZE,
+   MHL_DCAP_INT_STAT_SIZE,
+   MHL_DCAP_RESERVED,
+   MHL_DCAP_SIZE
+};
+
+#define MHL_DCAP_CAT_SINK  0x01
+#define MHL_DCAP_CAT_SOURCE0x02
+#define MHL_DCAP_CAT_POWER 0x10
+#define MHL_DCAP_CAT_PLIM(x)   ((x) << 5)
+
+#define MHL_DCAP_VID_LINK_RGB444   0x01
+#define MHL_DCAP_VID_LINK_YCBCR444 0x02
+#define MHL_DCAP_VID_LINK_YCBCR422 0x04
+#define MHL_DCAP_VID_LINK_PPIXEL   0x08
+#define MHL_DCAP_VID_LINK_ISLANDS  0x10
+#define MHL_DCAP_VID_LINK_VGA  0x20
+#define MHL_DCAP_VID_LINK_16BPP0x40
+
+#define MHL_DCAP_AUD_LINK_2CH  0x01
+#define MHL_DCAP_AUD_LINK_8CH  0x02
+
+#define MHL_DCAP_VT_GRAPHICS   0x00
+#define MHL_DCAP_VT_PHOTO  0x02
+#define MHL_DCAP_VT_CINEMA 0x04
+#define MHL_DCAP_VT_GAMES  0x08
+#define MHL_DCAP_SUPP_VT   0x80
+
+#define MHL_DCAP_LD_DISPLAY0x01
+#define MHL_DCAP_LD_VIDEO  0x02
+#define MHL_DCAP_LD_AUDIO  0x04
+#define MHL_DCAP_LD_MEDIA  0x08
+#define MHL_DCAP_LD_TUNER  0x10
+#define MHL_DCAP_LD_RECORD 0x20
+#define MHL_DCAP_LD_SPEAKER0x40
+#define MHL_DCAP_LD_GUI0x80
+#define MHL_DCAP_LD_ALL0xFF
+
+#define MHL_DCAP_FEATURE_RCP_SUPPORT   0x01
+#define MHL_DCAP_FEATURE_RAP_SUPPORT   0x02
+#define MHL_DCAP_FEATURE_SP_SUPPORT0x04
+#define MHL_DCAP_FEATURE_UCP_SEND_SUPPOR   0x08
+#define MHL_DCAP_FEATURE_UCP_RECV_SUPPORT  0x10
+#define MHL_DCAP_FEATURE_RBP_SUPPORT   0x40
+
+/* Extended Device Capabilities Registers */
+enum {
+   MHL_XDC_ECBUS_SPEEDS,
+   MHL_XDC_TMDS_SPEEDS,
+   MHL_XDC_ECBUS_ROLES,
+   MHL_XDC_LOG_DEV_MAPX,
+   MHL_XDC_SIZE
+};
+
+#define MHL_XDC_ECBUS_S_0750x01
+#define MHL_XDC_ECBUS_S_8BIT   0x02
+#define MHL_XDC_ECBUS_S_12BIT  0x04
+#define MHL_XDC_ECBUS_D_1500x10
+#define MHL_XDC_ECBUS_D_8BIT   0x20
+
+#define MHL_XDC_TMDS_000   0x00
+#define MHL_XDC_TMDS_150   0x01
+#define MHL_XDC_TMDS_300   0x02
+#define MHL_XDC_TMDS_600   0x04
+
+/* MHL_XDC_ECBUS_ROLES flags */
+#define MHL_XDC_DEV_HOST   0x01
+#define MHL_XDC_DEV_DEVICE 0x02
+#define MHL_XDC_DEV_CHARGER0x04
+#define MHL_XDC_HID_HOST   0x08
+#define MHL_XDC_HID_DEVICE 0x10
+
+/* MHL_XDC_LOG_DEV_MAPX flags */
+#define MHL_XDC_LD_PHONE   0x01
+
+/* Device Status Registers */
+enum {
+   MHL_DST_CONNECTED_RDY,
+   MHL_DST_LINK_MODE,
+   MHL_DST_VERSION,
+   MHL_DST_SIZE
+};
+
+/* Offset of DEVSTAT registers */
+#define MHL_DST_OFFSET 0x30
+#define MHL_DST_REG(name) (MHL_DST_OFFSET + MHL_DST_##name)
+
+#define MHL_DST_CONN_DCAP_RDY  0x01
+#define MHL_DST_CONN_XDEVCAPP_SUPP 0x02
+#define MHL_DST_CONN_POW_STAT  0x04
+#define MHL_DST_CONN_PLIM_STAT_MASK0x38
+
+#define MHL_DST_LM_CLK_MODE_MASK   0x07
+#define MHL_DST_LM_CLK_MODE_PACKED_PIXEL   0x02
+#define MHL_DST_LM_CLK_MODE_NORMAL 0x03
+#define 

[PATCH 2nd RESEND v2 0/3] drm/bridge: add Silicon Image SiI8620 driver

[Andrzej Hajda]

Hi,

This is 2nd RESEND of the patchset from Jan 2016.
There are no changes beside more informative log message about discovered dongle
and sink.

This patchset adds MHL bridge driver for Silicon Image SiI8620 chip.
The chip is quite powerful, supports MHL versions up to 3.0. It is present
in multiple mobile devices.

I have put common MHL definitions into include/linux/mhl.h header file,
similarily to include/linux/hdmi.h.

Regards
Andrzej


Andrzej Hajda (3):
  video: add header file for Mobile High-Definition Link (MHL) interface
  dt-bindings: add Silicon Image SiI8620 bridge bindings
  drm/bridge: add Silicon Image SiI8620 driver

 .../bindings/video/bridge/sil-sii8620.txt  |   33 +
 drivers/gpu/drm/bridge/Kconfig |7 +
 drivers/gpu/drm/bridge/Makefile|1 +
 drivers/gpu/drm/bridge/sil-sii8620.c   | 1568 
 drivers/gpu/drm/bridge/sil-sii8620.h   | 1517 +++
 include/linux/mhl.h|  292 
 6 files changed, 3418 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/video/bridge/sil-sii8620.txt
 create mode 100644 drivers/gpu/drm/bridge/sil-sii8620.c
 create mode 100644 drivers/gpu/drm/bridge/sil-sii8620.h
 create mode 100644 include/linux/mhl.h

-- 
1.9.1

[PATCH] drm/sti: dpms function missing for HDMI connector

[Vincent Abriou]

Signed-off-by: Vincent Abriou 
---
 drivers/gpu/drm/sti/sti_hdmi.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/sti/sti_hdmi.c b/drivers/gpu/drm/sti/sti_hdmi.c
index c6aa291..d850dda 100644
--- a/drivers/gpu/drm/sti/sti_hdmi.c
+++ b/drivers/gpu/drm/sti/sti_hdmi.c
@@ -1054,6 +1054,7 @@ static int sti_hdmi_late_register(struct drm_connector 
*connector)
 }

 static const struct drm_connector_funcs sti_hdmi_connector_funcs = {
+   .dpms = drm_atomic_helper_connector_dpms,
.fill_modes = drm_helper_probe_single_connector_modes,
.detect = sti_hdmi_connector_detect,
.destroy = drm_connector_cleanup,
-- 
1.9.1

4.8-rc1: it is now common that machine needs re-run of xrandr after resume

[Pavel Machek]

On Wed 2016-09-14 10:38:18, Jani Nikula wrote:
> On Wed, 14 Sep 2016, Pavel Machek  wrote:
> > Hi!
> >
> >> I have
> >> 
> >> 00:02.0 VGA compatible controller: Intel Corporation 4 Series Chipset
> >> Integrated Graphics Controller (rev 03)
> >> 
> >> In previous kernels, resume worked ok. With 4.8-rc1, I quite often (1
> >> in 10 resumes?) get in state where primary monitor (DVI) is dead (in
> >> powersave) and all windows move to secondary monitor (VGA). Running
> >> "xrandr" fixes that.
> >> 
> >> I'll update to newer rc and see if it happens again, but if you have
> >> any ideas, now would be good time.
> >
> > Ok. With -rc6, X are completely broken. I got notification "could not
> > restore CRTC config for screen 63" or something like that, and window
> > manager just does not start.
> 
> Ugh. Can you bisect from v4.7, assuming it worked? That's probably the
> fastest way to resolve this.

The "completely broken" part -- something broke in my userland, as
booting to the old kernel does not fix it. I'll have to figure it out.

For the "sometimes need xrandr after resume": I don't think I can
bisect that. It only happens sometimes :-(. But there's something
helpful in the logs:

Best regards,
Pavel

[ 1856.213154] CPU1 is up
[ 1856.213167] ACPI: Waking up from system sleep state S3
[ 1856.217998] clocksource: Switched to clocksource hpet
[ 1856.218170] uhci_hcd :00:1d.0: System wakeup disabled by ACPI
[ 1856.218470] uhci_hcd :00:1d.2: System wakeup disabled by ACPI
[ 1856.218656] uhci_hcd :00:1d.1: System wakeup disabled by ACPI
[ 1856.218665] uhci_hcd :00:1d.3: System wakeup disabled by ACPI
[ 1856.218863] ehci-pci :00:1d.7: System wakeup disabled by ACPI
[ 1856.218863] PM: noirq resume of devices complete after 19.597 msecs
[ 1856.218863] PM: early resume of devices complete after 1.092 msecs
[ 1856.218863] usb usb2: root hub lost power or was reset
[ 1856.218863] usb usb3: root hub lost power or was reset
[ 1856.218863] usb usb4: root hub lost power or was reset
[ 1856.218863] usb usb5: root hub lost power or was reset
[ 1856.218863] pcieport :00:1c.1: System wakeup disabled by ACPI
[ 1856.218863] serial 00:03: activated
[ 1856.218863] parport_pc 00:04: activated
[ 1856.218863] rtc_cmos 00:05: System wakeup disabled by ACPI
[ 1856.218863] ata2: port disabled--ignoring
[ 1856.218863] r8169 :03:00.0 eth0: link down
[ 1856.218863] sd 2:0:0:0: [sda] Starting disk
[ 1856.218863] sd 2:0:1:0: [sdb] Starting disk
[ 1856.218863] ata4.01: NODEV after polling detection
[ 1856.218863] ata3.01: ACPI cmd ef/03:45:00:00:00:b0 (SET FEATURES)
filtered out
[ 1856.218863] ata3.01: ACPI cmd ef/03:0c:00:00:00:b0 (SET FEATURES)
filtered out
[ 1856.218863] ata3.01: ACPI cmd f5/00:00:00:00:00:00 (SECURITY FREEZE
LOCK) filtered out
[ 1856.218863] ata3.00: ACPI cmd ef/03:45:00:00:00:a0 (SET FEATURES)
filtered out
[ 1856.218863] ata3.00: ACPI cmd ef/03:0c:00:00:00:a0 (SET FEATURES)
filtered out
[ 1856.218863] ata3.00: ACPI cmd c6/00:10:00:00:00:a0 (SET MULTIPLE
MODE) succeeded
[ 1856.218863] ata3.00: ACPI cmd f5/00:00:00:00:00:00 (SECURITY FREEZE
LOCK) filtered out
[ 1856.218863] ata3.00: configured for UDMA/133
[ 1856.218863] ata4.00: ACPI cmd ef/03:45:00:00:00:a0 (SET FEATURES)
filtered out
[ 1856.218863] ata4.00: ACPI cmd ef/03:0c:00:00:00:a0 (SET FEATURES)
filtered out
[ 1856.218863] ata4.00: ACPI cmd f5/00:00:00:00:00:00 (SECURITY FREEZE
LOCK) filtered out
[ 1856.218863] ata3.01: configured for UDMA/133
[ 1856.218863] ata4.00: configured for UDMA/133
[ 1856.218863] [drm:drm_edid_block_valid] *ERROR* EDID checksum is
invalid, remainder is 130
[ 1856.218863] Raw EDID:
[ 1856.218863] 00 ff ff ff ff ff ff 00 ff ff ff ff ff ff ff ff
[ 1856.218863] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
[ 1856.218863] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
[ 1856.218863] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
[ 1856.218863] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
[ 1856.218863] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
[ 1856.218863] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
[ 1856.218863] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
[ 1856.218863] [drm:drm_edid_block_valid] *ERROR* EDID checksum is
invalid, remainder is 130
[ 1856.218863] Raw EDID:
[ 1856.218863] 00 ff ff ff ff ff ff 00 ff ff ff ff ff ff ff ff
[ 1856.218863] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
[ 1856.218863] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
[ 1856.218863] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
[ 1856.218863] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
[ 1856.218863] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
[ 1856.218863] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
[ 1856.218863] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
[ 1856.218863] [drm:drm_edid_block_valid] *ERROR* EDID checksum is
invalid, remainder is 130
[ 

[Bug 97796] Parts of screen do not update

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

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

--- Comment #4 from Paul Menzel  ---
(In reply to Michel Dänzer from comment #3)
> Are you using a compositing manager? If yes, which one, and what is its
> configuration?

I guess you mean something like Compiz? I am pretty sure I don’t. I use the
plain awesome WM, or Xfce configuration.

> (In reply to Paul Menzel from comment #0)
> > 2. In the window manager *awesome* the top bar is not updated when changing
> > tags (think of virtual screen, although different). See the attached screen,
> > which doesn’t show the problem, as doing the screenshot didn’t capture 
> > it,
> > despite me seeing it.
> 
> So the screenshot doesn't match the problem you were seeing?

Indeed. Unfortunately it does not. So when I switch to a different tag, the bar
still contains the boxes from the Firefox windows, and not the terminal, for
example.

> Did taking the screenshot also make the problem visibly disappear? If not, it
> sounds like it might be a kernel driver issue.

No, it could still visually be seen. Drawing the box for ImageMagick’s tool
`import`, some parts in the bar were visually a little corrupted, that means,
the color of some pixel changed.

-- 
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/20160914/66f229cb/attachment-0001.html>

4.8-rc1: it is now common that machine needs re-run of xrandr after resume

[Pavel Machek]

On Tue 2016-09-13 22:38:45, Martin Steigerwald wrote:
> Hi.
> 
> Am Dienstag, 13. September 2016, 22:23:50 CEST schrieb Pavel Machek: 
> > I have
> > 
> > 00:02.0 VGA compatible controller: Intel Corporation 4 Series Chipset
> > Integrated Graphics Controller (rev 03)
> 
> 00:02.0 VGA compatible controller [0300]: Intel Corporation 2nd Generation 
> Core Processor Family Integrated Graphics Controller [8086:0126] (rev 09)
> 
> Phoronix Test Suite system-info:

...
> > In previous kernels, resume worked ok. With 4.8-rc1, I quite often (1
> > in 10 resumes?) get in state where primary monitor (DVI) is dead (in
> > powersave) and all windows move to secondary monitor (VGA). Running
> > "xrandr" fixes that.
> 
> I have seen this in 4.8 up to rc5 as well. I am not sure yet about rc6 which 
> I 
> am currently running.

Ok, it happened again today, with yesterdays version of 4.8-rc6. I'm
glad I'm not the only one.

Intel folks, any ideas? Can you reproduce it?

Best regards,
Pavel

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

[Bug 97796] Parts of screen do not update

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

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

--- Comment #3 from Michel Dänzer  ---
Are you using a compositing manager? If yes, which one, and what is its
configuration?

(In reply to Paul Menzel from comment #0)
> 2. In the window manager *awesome* the top bar is not updated when changing
> tags (think of virtual screen, although different). See the attached screen,
> which doesn’t show the problem, as doing the screenshot didn’t capture it,
> despite me seeing it.

So the screenshot doesn't match the problem you were seeing? Did taking the
screenshot also make the problem visibly disappear? If not, it sounds like it
might be a kernel driver issue.

-- 
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/20160914/ef87f609/attachment.html>

[Bug 97796] Parts of screen do not update

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

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

--- Comment #2 from Paul Menzel  ---
Created attachment 126513
  --> https://bugs.freedesktop.org/attachment.cgi?id=126513=edit
X server log file

(In reply to Michel Dänzer from comment #1)
> If this is not the same as bug 90910, please attach the corresponding Xorg
> log file.

I don’t think it’s the same bug, as I use the integrated graphics device 
from
Intel with the X video driver *modesetting*.

Please find the Xorg log file attached.

-- 
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/20160914/bcf80605/attachment.html>

[PATCH v9 01/19] remoteproc: st_slim_rproc: add a slimcore rproc driver

[Lee Jones]

On Tue, 13 Sep 2016, Bjorn Andersson wrote:

> On Mon 05 Sep 06:16 PDT 2016, Peter Griffin wrote:
> 
> > slim core is used as a basis for many IPs in the STi
> > chipsets such as fdma and demux. To avoid duplicating
> > the elf loading code in each device driver a slim
> > rproc driver has been created.
> > 
> > This driver is designed to be used by other device drivers
> > such as fdma, or demux whose IP is based around a slim core.
> > The device driver can call slim_rproc_alloc() to allocate
> > a slim rproc and slim_rproc_put() when finished.
> > 
> > This driver takes care of ioremapping the slim
> > registers (dmem, imem, slimcore, peripherals), whose offsets
> > and sizes can change between IP's. It also obtains and enables
> > any clocks used by the device. This approach avoids having
> > a double mapping of the registers as slim_rproc does not register
> > its own platform device. It also maps well to device tree
> > abstraction as it allows us to have one dt node for the whole
> > device.
> > 
> > All of the generic rproc elf loading code can be reused, and
> > we provide start() stop() hooks to start and stop the slim
> > core once the firmware has been loaded. This has been tested
> > successfully with fdma driver.
> > 
> > Signed-off-by: Peter Griffin 
> 
> Acked-by: Bjorn Andersson 

What's preventing this from being applied right away?

> > ---
> >  drivers/remoteproc/Kconfig   |   4 +
> >  drivers/remoteproc/Makefile  |   1 +
> >  drivers/remoteproc/st_slim_rproc.c   | 364 
> > +++
> >  include/linux/remoteproc/st_slim_rproc.h |  58 +
> >  4 files changed, 427 insertions(+)
> >  create mode 100644 drivers/remoteproc/st_slim_rproc.c
> >  create mode 100644 include/linux/remoteproc/st_slim_rproc.h
> > 
> > diff --git a/drivers/remoteproc/Kconfig b/drivers/remoteproc/Kconfig
> > index 1a8bf76a..a7bedc6 100644
> > --- a/drivers/remoteproc/Kconfig
> > +++ b/drivers/remoteproc/Kconfig
> > @@ -100,4 +100,8 @@ config ST_REMOTEPROC
> >   processor framework.
> >   This can be either built-in or a loadable module.
> >  
> > +config ST_SLIM_REMOTEPROC
> > +   tristate
> > +   select REMOTEPROC
> > +
> >  endmenu
> > diff --git a/drivers/remoteproc/Makefile b/drivers/remoteproc/Makefile
> > index 92d3758..db1dae7 100644
> > --- a/drivers/remoteproc/Makefile
> > +++ b/drivers/remoteproc/Makefile
> > @@ -14,3 +14,4 @@ obj-$(CONFIG_DA8XX_REMOTEPROC)+= 
> > da8xx_remoteproc.o
> >  obj-$(CONFIG_QCOM_MDT_LOADER)  += qcom_mdt_loader.o
> >  obj-$(CONFIG_QCOM_Q6V5_PIL)+= qcom_q6v5_pil.o
> >  obj-$(CONFIG_ST_REMOTEPROC)+= st_remoteproc.o
> > +obj-$(CONFIG_ST_SLIM_REMOTEPROC)   += st_slim_rproc.o
> > diff --git a/drivers/remoteproc/st_slim_rproc.c 
> > b/drivers/remoteproc/st_slim_rproc.c
> > new file mode 100644
> > index 000..1484e97
> > --- /dev/null
> > +++ b/drivers/remoteproc/st_slim_rproc.c
> > @@ -0,0 +1,364 @@
> > +/*
> > + * SLIM core rproc driver
> > + *
> > + * Copyright (C) 2016 STMicroelectronics
> > + *
> > + * Author: Peter Griffin 
> > + *
> > + * This program is free software; you can redistribute it and/or modify
> > + * it under the terms of the GNU General Public License as published by
> > + * the Free Software Foundation; either version 2 of the License, or
> > + * (at your option) any later version.
> > + */
> > +
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include "remoteproc_internal.h"
> > +
> > +/* SLIM core registers */
> > +#define SLIM_ID_OFST   0x0
> > +#define SLIM_VER_OFST  0x4
> > +
> > +#define SLIM_EN_OFST   0x8
> > +#define SLIM_EN_RUNBIT(0)
> > +
> > +#define SLIM_CLK_GATE_OFST 0xC
> > +#define SLIM_CLK_GATE_DIS  BIT(0)
> > +#define SLIM_CLK_GATE_RESETBIT(2)
> > +
> > +#define SLIM_SLIM_PC_OFST  0x20
> > +
> > +/* DMEM registers */
> > +#define SLIM_REV_ID_OFST   0x0
> > +#define SLIM_REV_ID_MIN_MASK   GENMASK(15, 8)
> > +#define SLIM_REV_ID_MIN(id)((id & SLIM_REV_ID_MIN_MASK) >> 
> > 8)
> > +#define SLIM_REV_ID_MAJ_MASK   GENMASK(23, 16)
> > +#define SLIM_REV_ID_MAJ(id)((id & SLIM_REV_ID_MAJ_MASK) >> 
> > 16)
> > +
> > +
> > +/* peripherals registers */
> > +#define SLIM_STBUS_SYNC_OFST   0xF88
> > +#define SLIM_STBUS_SYNC_DISBIT(0)
> > +
> > +#define SLIM_INT_SET_OFST  0xFD4
> > +#define SLIM_INT_CLR_OFST  0xFD8
> > +#define SLIM_INT_MASK_OFST 0xFDC
> > +
> > +#define SLIM_CMD_CLR_OFST  0xFC8
> > +#define SLIM_CMD_MASK_OFST 0xFCC
> > +
> > +static const char *mem_names[ST_SLIM_MEM_MAX] = {
> > +   [ST_SLIM_DMEM]  = "dmem",
> > +   [ST_SLIM_IMEM]  = "imem",
> > +};
> > +
> > +static int slim_clk_get(struct st_slim_rproc *slim_rproc, struct device 
> > *dev)
> > +{
> > +   int clk, err;
> > +
> > 

[PATCH] drm/radeon/radeon_device: clean function declarations in radeon_device.c up

[Christian König]

Am 14.09.2016 um 08:10 schrieb Baoyou Xie:
> We get 2 warnings when building kernel with W=1:
> drivers/gpu/drm/radeon/radeon_device.c:1961:5: warning: no previous prototype 
> for 'radeon_debugfs_init' [-Wmissing-prototypes]
> drivers/gpu/drm/radeon/radeon_device.c:1966:6: warning: no previous prototype 
> for 'radeon_debugfs_cleanup' [-Wmissing-prototypes]
>
> In fact, both functions are declared in
> drivers/gpu/drm/radeon/radeon_drv.c, but should be declared in
> a header file, thus can be recognized in other file.
>
> So this patch moves the declarations into drivers/gpu/drm/radeon/radeon.h.
>
> Signed-off-by: Baoyou Xie 

Actually if I see it correctly we could also just remove the two 
callbacks cause they are optional and our implementations are just empty 
dummys.

Christian.

> ---
>   drivers/gpu/drm/radeon/radeon_device.c | 1 +
>   drivers/gpu/drm/radeon/radeon_drv.c| 5 -
>   drivers/gpu/drm/radeon/radeon_drv.h| 5 +
>   3 files changed, 6 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeon/radeon_device.c 
> b/drivers/gpu/drm/radeon/radeon_device.c
> index a00dd2f..811abde 100644
> --- a/drivers/gpu/drm/radeon/radeon_device.c
> +++ b/drivers/gpu/drm/radeon/radeon_device.c
> @@ -36,6 +36,7 @@
>   #include 
>   #include "radeon_reg.h"
>   #include "radeon.h"
> +#include "radeon_drv.h"
>   #include "atom.h"
>   
>   static const char radeon_family_name[][16] = {
> diff --git a/drivers/gpu/drm/radeon/radeon_drv.c 
> b/drivers/gpu/drm/radeon/radeon_drv.c
> index 07e4493..6cc4a9e 100644
> --- a/drivers/gpu/drm/radeon/radeon_drv.c
> +++ b/drivers/gpu/drm/radeon/radeon_drv.c
> @@ -156,11 +156,6 @@ void radeon_gem_prime_vunmap(struct drm_gem_object *obj, 
> void *vaddr);
>   extern long radeon_kms_compat_ioctl(struct file *filp, unsigned int cmd,
>   unsigned long arg);
>   
> -#if defined(CONFIG_DEBUG_FS)
> -int radeon_debugfs_init(struct drm_minor *minor);
> -void radeon_debugfs_cleanup(struct drm_minor *minor);
> -#endif
> -
>   /* atpx handler */
>   #if defined(CONFIG_VGA_SWITCHEROO)
>   void radeon_register_atpx_handler(void);
> diff --git a/drivers/gpu/drm/radeon/radeon_drv.h 
> b/drivers/gpu/drm/radeon/radeon_drv.h
> index afef2d9..3d35e0e 100644
> --- a/drivers/gpu/drm/radeon/radeon_drv.h
> +++ b/drivers/gpu/drm/radeon/radeon_drv.h
> @@ -119,4 +119,9 @@
>   long radeon_drm_ioctl(struct file *filp,
> unsigned int cmd, unsigned long arg);
>   
> +#if defined(CONFIG_DEBUG_FS)
> +int radeon_debugfs_init(struct drm_minor *minor);
> +void radeon_debugfs_cleanup(struct drm_minor *minor);
> +#endif
> +
>   #endif  /* __RADEON_DRV_H__ */

[PATCH] Add drmModeAddFB2WithModifiers() which takes format modifiers

[Kristian Høgsberg]

On Tue, Sep 13, 2016 at 3:59 PM, Rob Clark  wrote:
> On Tue, Sep 13, 2016 at 6:07 PM, Kristian H. Kristensen
>  wrote:
>> The only current user of this open codes the ioctl. Let's add an entry
>> point for this to libdrm.
>>
>> Signed-off-by: Kristian H. Kristensen 
>> ---
>>  xf86drmMode.c | 21 +
>>  xf86drmMode.h |  7 +++
>>  2 files changed, 24 insertions(+), 4 deletions(-)
>>
>> diff --git a/xf86drmMode.c b/xf86drmMode.c
>> index f7b5948..2907c5c 100644
>> --- a/xf86drmMode.c
>> +++ b/xf86drmMode.c
>> @@ -270,10 +270,10 @@ int drmModeAddFB(int fd, uint32_t width, uint32_t 
>> height, uint8_t depth,
>> return 0;
>>  }
>>
>> -int drmModeAddFB2(int fd, uint32_t width, uint32_t height,
>> - uint32_t pixel_format, uint32_t bo_handles[4],
>> - uint32_t pitches[4], uint32_t offsets[4],
>> - uint32_t *buf_id, uint32_t flags)
>> +int drmModeAddFB2WithModifiers(int fd, uint32_t width, uint32_t height,
>> +   uint32_t pixel_format, uint32_t 
>> bo_handles[4],
>> +   uint32_t pitches[4], uint32_t offsets[4],
>> +   uint64_t modifier[4], uint32_t *buf_id, 
>> uint32_t flags)
>>  {
>> struct drm_mode_fb_cmd2 f;
>> int ret;
>> @@ -286,6 +286,8 @@ int drmModeAddFB2(int fd, uint32_t width, uint32_t 
>> height,
>> memcpy(f.handles, bo_handles, 4 * sizeof(bo_handles[0]));
>> memcpy(f.pitches, pitches, 4 * sizeof(pitches[0]));
>> memcpy(f.offsets, offsets, 4 * sizeof(offsets[0]));
>> +if (modifier)
>> +   memcpy(f.modifier, modifier, 4 * sizeof(modifier[0]));
>
> I can't quite tell if it is my email client or not, but the
> whitespace/indentation here and below in drmModeAddFB2() looks funny..
> other than that (and with that potentially fixed if needed), lgtm

Ah, yup, there's some broken whitespace there, will fix.

> Reviewed-by: Rob Clark 

Thanks!

>
>> if ((ret = DRM_IOCTL(fd, DRM_IOCTL_MODE_ADDFB2, )))
>> return ret;
>> @@ -294,6 +296,17 @@ int drmModeAddFB2(int fd, uint32_t width, uint32_t 
>> height,
>> return 0;
>>  }
>>
>> +int drmModeAddFB2(int fd, uint32_t width, uint32_t height,
>> +  uint32_t pixel_format, uint32_t bo_handles[4],
>> +  uint32_t pitches[4], uint32_t offsets[4],
>> +  uint32_t *buf_id, uint32_t flags)
>> +{
>> +  return drmModeAddFB2WithModifiers(fd, width, height,
>> +pixel_format, bo_handles,
>> +pitches, offsets, NULL,
>> +buf_id, flags);
>> +}
>> +
>>  int drmModeRmFB(int fd, uint32_t bufferId)
>>  {
>> return DRM_IOCTL(fd, DRM_IOCTL_MODE_RMFB, );
>> diff --git a/xf86drmMode.h b/xf86drmMode.h
>> index 4de7bbb..02190ea 100644
>> --- a/xf86drmMode.h
>> +++ b/xf86drmMode.h
>> @@ -369,6 +369,13 @@ extern int drmModeAddFB2(int fd, uint32_t width, 
>> uint32_t height,
>>  uint32_t pixel_format, uint32_t bo_handles[4],
>>  uint32_t pitches[4], uint32_t offsets[4],
>>  uint32_t *buf_id, uint32_t flags);
>> +
>> +/* ...with format modifiers */
>> +int drmModeAddFB2WithModifiers(int fd, uint32_t width, uint32_t height,
>> +   uint32_t pixel_format, uint32_t 
>> bo_handles[4],
>> +   uint32_t pitches[4], uint32_t offsets[4],
>> +   uint64_t modifier[4], uint32_t *buf_id, 
>> uint32_t flags);
>> +
>>  /**
>>   * Destroies the given framebuffer.
>>   */
>> --
>> 2.8.0.rc3.226.g39d4020
>>
>> ___
>> dri-devel mailing list
>> dri-devel at lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v9 00/19] Add support for FDMA DMA controller and slim core rproc found on STi chipsets

[Patrice Chotard]

Hi Bjorn

On 09/13/2016 08:06 PM, Bjorn Andersson wrote:
> On Tue 13 Sep 02:31 PDT 2016, Peter Griffin wrote:
> 
>> Hi Vinod & Bjorn,
>>
>> [..]
>>
>> On Mon, 05 Sep 2016, Peter Griffin wrote:
>>
>>> v8 actions some review feedback from Bjorn to the slim rproc driver, and 
>>> also includes
>>> a patch which fixes a recursive Kconfig error which is triggered when 
>>> st_fdma selects
>>> slim_rproc driver. The series has also been rebased on v4.8-rc3.
>>>
>>> v9 actions some review feedback from Bjorn, Lee and Vinod. See below. 
>>> Importantly a bug
>>> was found during testing now that the platform boots without 
>>> clk_ignore_unused parameter
>>> whereby the clocks would not be enabled properly before firmware loading 
>>> was attempted.
>>>
>>> regards,
>>>
>>> Peter.
>>>
>>> Changes since v8:
>>>  - Add MODULE_ALIAS (Vinod)
>>>  - devm_kzalloc to devm_kcalloc (Vinod)
>>>  - quisce tasklet initialised by vchan_init() (Vinod)
>>>  - Don't make SLIM rproc user selectable (Bjorn)
>>>  - slim_rproc: Ensure clocks enabled before firmware load (Peter)
>>>  - Various code style nits / commit message change (Lee)
>>>  - Separate patch for '\n' kconfig removal (Vinod)
>>
>> I hate to send a ping,
> 
> Sorry about that.
> 
>> but do you think we can merge this fdma series? It has gone
>> through quite a few review rounds now.
>>
> 
> I think the remoteproc part looks good.
> 
> Vinod, I don't have any changes queued in remoteproc that should cause
> merge issues. If you want to you could take the remoteproc patch
> through your tree.
> 
> 
> I do however think that the dts patches should go through arm-soc.

I will take care about dts patches by adding them in the next STi DT pull 
request

Thanks
Patrice

> 
> Regards,
> Bjorn
> 

[Bug 97524] Invalid sampler settings cause full GPU reset

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

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

--- Comment #8 from Nicolai Hähnle  ---
Here's the output:

GL Context creation suceeded.
Mesa: User error: GL_INVALID_OPERATION in glUseProgram(program 3 not linked)
^C0:1(1): error: syntax error, unexpected $end0:1(1): error: syntax error,
unexpected $endGL_INVALID_OPERATION in glUseProgram(program 3 not linked)Shader
Stats: SGPRS: 24 VGPRS: 16 Code Size: 64 LDS: 0 Scratch: 0 Max Waves: 10
Spilled SGPRs: 0 Spilled VGPRs: 0Shader Stats: SGPRS: 16 VGPRS: 16 Code Size:
40 LDS: 0 Scratch: 0 Max Waves: 10 Spilled SGPRs: 0 Spilled VGPRs: 0Shader
Stats: SGPRS: 18 VGPRS: 8 Code Size: 252 LDS: 0 Scratch: 0 Max Waves: 10
Spilled SGPRs: 0 Spilled VGPRs: 0Shader Stats: SGPRS: 16 VGPRS: 16 Code Size:
64 LDS: 0 Scratch: 0 Max Waves: 10 Spilled SGPRs: 0 Spilled VGPRs: 0Shader
Stats: SGPRS: 16 VGPRS: 16 Code Size: 40 LDS: 0 Scratch: 0 Max Waves: 10
Spilled SGPRs: 0 Spilled VGPRs: 0

Again, this is with a debug build of Mesa, but there should be no difference in
error checking -- only the output when an error is detected is different.

-- 
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/20160914/954ad406/attachment.html>

[PATCH] dma-buf/sync_file: Always increment refcount when merging fences.

[Rafael Antognolli]

On Wed, Sep 14, 2016 at 11:04:01AM -0300, Gustavo Padovan wrote:
> 2016-09-14 Chris Wilson :
> 
> > On Tue, Sep 13, 2016 at 04:24:27PM -0700, Rafael Antognolli wrote:
> > > The refcount of a fence should be increased whenever it is added to a 
> > > merged
> > > fence, since it will later be decreased when the merged fence is 
> > > destroyed.
> > > Failing to do so will cause the original fence to be freed if the merged 
> > > fence
> > > gets freed, but other places still referencing won't know about it.
> > > 
> > > This patch fixes a kernel panic that can be triggered by creating a fence 
> > > that
> > > is expired (or increasing the timeline until it expires), then creating a
> > > merged fence out of it, and deleting the merged fence. This will make the
> > > original expired fence's refcount go to zero.
> > > 
> > > Signed-off-by: Rafael Antognolli 
> > > ---
> > > 
> > > Sample code to trigger the mentioned kernel panic (might need to be 
> > > executed a
> > > couple times before it actually breaks everything):
> > > 
> > > static void test_sync_expired_merge(void)
> > > {
> > >int iterations = 1 << 20;
> > >int timeline;
> > >int i;
> > >int fence_expired, fence_merged;
> > > 
> > >timeline = sw_sync_timeline_create();
> > > 
> > >sw_sync_timeline_inc(timeline, 100);
> > >fence_expired = sw_sync_fence_create(timeline, 1);
> > >fence_merged = sw_sync_merge(fence_expired, fence_expired);
> > >sw_sync_fence_destroy(fence_merged);
> > > 
> > >for (i = 0; i < iterations; i++) {
> > >int fence = sw_sync_merge(fence_expired, fence_expired);
> > > 
> > >igt_assert_f(sw_sync_wait(fence, -1) > 0,
> > > "Failure waiting on fence\n");
> > >sw_sync_fence_destroy(fence);
> > >}
> > > 
> > >sw_sync_fence_destroy(fence_expired);
> > > }
> > > 
> > >  drivers/dma-buf/sync_file.c | 7 ++-
> > >  1 file changed, 2 insertions(+), 5 deletions(-)
> > > 
> > > diff --git a/drivers/dma-buf/sync_file.c b/drivers/dma-buf/sync_file.c
> > > index 486d29c..6ce6b8f 100644
> > > --- a/drivers/dma-buf/sync_file.c
> > > +++ b/drivers/dma-buf/sync_file.c
> > > @@ -178,11 +178,8 @@ static struct fence **get_fences(struct sync_file 
> > > *sync_file, int *num_fences)
> > >  static void add_fence(struct fence **fences, int *i, struct fence *fence)
> > >  {
> > >   fences[*i] = fence;
> > > -
> > > - if (!fence_is_signaled(fence)) {
> > > - fence_get(fence);
> > > - (*i)++;
> > > - }
> > > + fence_get(fence);
> > > + (*i)++;
> > >  }
> > 
> > I think you'll find it's the caller:
> > 
> > if (i == 0) {
> > add_fence(fences, , a_fences[0]);
> > i++;
> > }
> > 
> > that does the unexpected.
> > 
> > This should be 
> > 
> > if (i == 0)
> > fences[i++] = fence_get(a_fences[0]);
> 
> You are right. Otherwise we would miss the extra reference. i == 0 here
> means that all fences are signalled.
> 
> > 
> > 
> > That ensures the sync_file inherits the signaled status without having
> > to keep all fences.

OK, so if you are building a merged fence out of several signaled
fences, then you only keep one of them instead? I haven't noticed that
was the intention.

> > I think there still seems to be a memory leak when calling
> > sync_file_set_fence() here with i == 1.
> 
> I think that is something we discussed already, we don't hold an extra
> ref there for i == 1 because it would leak the fence.
> 

I agree, we already increase the reference count in add_fence anyway (or
here, assuming we do what Chris suggested. But I also believe that's the
cause of confusion.

IMHO it would be better to call fence_get() inside fence_array_create(),
so it would match the fence_put in fence_array_release(). And if we have
only one fence, fence_get it inside sync_file_set_fence().

Rafael