Re: [PATCH] dim: Enforce review requirements

[Lukas Wunner]

On Wed, May 24, 2017 at 11:28:12AM +0200, Daniel Vetter wrote:
> We can't check this when applying (since r-b/a-b tags often get added
> afterwards), but we can check this when pushing. This only looks at
> patches authored by the pusher.

BTW, can we also have a rule that large drivers (i.e. with a large user
base) are required to provide at least one person at all times (or at
least outside the merge window) who is able to review fixes, push them
to the driver's repo and send a timely pull to Dave?

On multiple occasions I've seen Dave send a fixes pull with an apology
along the lines of "a bit more than usual at this time of the cycle
because it includes two weeks worth of driver XYZ fixes".

Thanks,

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

[PATCH 5/6] drm/msm: remove mdp5_cursor_plane_funcs

[Gustavo Padovan]

From: Gustavo Padovan 

After converting legacy cursor updates to atomic async commits
mdp5_cursor_plane_funcs just duplicates mdp5_plane_funcs now.

Cc: Rob Clark 
Cc: Archit Taneja 
Signed-off-by: Gustavo Padovan 
---
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c | 26 +++---
 1 file changed, 3 insertions(+), 23 deletions(-)

diff --git a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c 
b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c
index 07106c1..794ca07 100644
--- a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c
+++ b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c
@@ -247,19 +247,6 @@ static const struct drm_plane_funcs mdp5_plane_funcs = {
.atomic_print_state = mdp5_plane_atomic_print_state,
 };
 
-static const struct drm_plane_funcs mdp5_cursor_plane_funcs = {
-   .update_plane = drm_atomic_helper_update_plane,
-   .disable_plane = drm_atomic_helper_disable_plane,
-   .destroy = mdp5_plane_destroy,
-   .set_property = drm_atomic_helper_plane_set_property,
-   .atomic_set_property = mdp5_plane_atomic_set_property,
-   .atomic_get_property = mdp5_plane_atomic_get_property,
-   .reset = mdp5_plane_reset,
-   .atomic_duplicate_state = mdp5_plane_duplicate_state,
-   .atomic_destroy_state = mdp5_plane_destroy_state,
-   .atomic_print_state = mdp5_plane_atomic_print_state,
-};
-
 static int mdp5_plane_prepare_fb(struct drm_plane *plane,
 struct drm_plane_state *new_state)
 {
@@ -,16 +1098,9 @@ struct drm_plane *mdp5_plane_init(struct drm_device *dev,
 
spin_lock_init(_plane->pipe_lock);
 
-   if (type == DRM_PLANE_TYPE_CURSOR)
-   ret = drm_universal_plane_init(dev, plane, 0xff,
-   _cursor_plane_funcs,
-   mdp5_plane->formats, mdp5_plane->nformats,
-   type, NULL);
-   else
-   ret = drm_universal_plane_init(dev, plane, 0xff,
-   _plane_funcs,
-   mdp5_plane->formats, mdp5_plane->nformats,
-   type, NULL);
+   ret = drm_universal_plane_init(dev, plane, 0xff, _plane_funcs,
+  mdp5_plane->formats,
+  mdp5_plane->nformats, type, NULL);
if (ret)
goto fail;
 
-- 
2.9.4

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

[PATCH 4/6] drm/msm: update cursors asynchronously through atomic

[Gustavo Padovan]

From: Gustavo Padovan 

Add support to async updates of cursors by using the new atomic
interface for that. Basically what this commit does is do what
mdp5_update_cursor_plane_legacy() did but through atomic.

v4: add missing atomic async commit call to msm_atomic_commit(Archit Taneja)

v3: move size checks back to drivers (Ville Syrjälä)

v2: move fb setting to core and use new state (Eric Anholt)

Cc: Rob Clark 
Cc: Archit Taneja 
Signed-off-by: Gustavo Padovan 
---
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c | 151 +-
 drivers/gpu/drm/msm/msm_atomic.c  |   6 ++
 2 files changed, 69 insertions(+), 88 deletions(-)

diff --git a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c 
b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c
index a38c5fe..07106c1 100644
--- a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c
+++ b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c
@@ -33,15 +33,6 @@ static int mdp5_plane_mode_set(struct drm_plane *plane,
struct drm_crtc *crtc, struct drm_framebuffer *fb,
struct drm_rect *src, struct drm_rect *dest);
 
-static int mdp5_update_cursor_plane_legacy(struct drm_plane *plane,
-   struct drm_crtc *crtc,
-   struct drm_framebuffer *fb,
-   int crtc_x, int crtc_y,
-   unsigned int crtc_w, unsigned int crtc_h,
-   uint32_t src_x, uint32_t src_y,
-   uint32_t src_w, uint32_t src_h,
-   struct drm_modeset_acquire_ctx *ctx);
-
 static struct mdp5_kms *get_kms(struct drm_plane *plane)
 {
struct msm_drm_private *priv = plane->dev->dev_private;
@@ -257,7 +248,7 @@ static const struct drm_plane_funcs mdp5_plane_funcs = {
 };
 
 static const struct drm_plane_funcs mdp5_cursor_plane_funcs = {
-   .update_plane = mdp5_update_cursor_plane_legacy,
+   .update_plane = drm_atomic_helper_update_plane,
.disable_plane = drm_atomic_helper_disable_plane,
.destroy = mdp5_plane_destroy,
.set_property = drm_atomic_helper_plane_set_property,
@@ -484,11 +475,73 @@ static void mdp5_plane_atomic_update(struct drm_plane 
*plane,
}
 }
 
+static int mdp5_plane_atomic_async_check(struct drm_plane *plane,
+struct drm_plane_state *state)
+{
+   struct mdp5_plane_state *mdp5_state = to_mdp5_plane_state(state);
+   struct drm_crtc_state *crtc_state;
+
+   crtc_state = drm_atomic_get_existing_crtc_state(state->state,
+   state->crtc);
+   if (WARN_ON(!crtc_state))
+   return -EINVAL;
+
+   if (!crtc_state->active)
+   return -EINVAL;
+
+   mdp5_state = to_mdp5_plane_state(state);
+
+   /* don't use fast path if we don't have a hwpipe allocated yet */
+   if (!mdp5_state->hwpipe)
+   return -EINVAL;
+
+   /* only allow changing of position(crtc x/y or src x/y) in fast path */
+   if (plane->state->crtc != state->crtc ||
+   plane->state->src_w != state->src_w ||
+   plane->state->src_h != state->src_h ||
+   plane->state->crtc_w != state->crtc_w ||
+   plane->state->crtc_h != state->crtc_h ||
+   !plane->state->fb ||
+   plane->state->fb != state->fb)
+   return -EINVAL;
+
+   return 0;
+}
+
+static void mdp5_plane_atomic_async_update(struct drm_plane *plane,
+  struct drm_plane_state *new_state)
+{
+   plane->state->src_x = new_state->src_x;
+   plane->state->src_y = new_state->src_y;
+   plane->state->crtc_x = new_state->crtc_x;
+   plane->state->crtc_y = new_state->crtc_y;
+
+   if (plane_enabled(new_state)) {
+   struct mdp5_ctl *ctl;
+   struct mdp5_pipeline *pipeline =
+   mdp5_crtc_get_pipeline(plane->crtc);
+   int ret;
+
+   ret = mdp5_plane_mode_set(plane, new_state->crtc, new_state->fb,
+   _state->src, _state->dst);
+   WARN_ON(ret < 0);
+
+   ctl = mdp5_crtc_get_ctl(new_state->crtc);
+
+   mdp5_ctl_commit(ctl, pipeline, mdp5_plane_get_flush(plane));
+   }
+
+   *to_mdp5_plane_state(plane->state) =
+   *to_mdp5_plane_state(new_state);
+}
+
 static const struct drm_plane_helper_funcs mdp5_plane_helper_funcs = {
.prepare_fb = mdp5_plane_prepare_fb,
.cleanup_fb = mdp5_plane_cleanup_fb,
.atomic_check = mdp5_plane_atomic_check,
.atomic_update = mdp5_plane_atomic_update,
+   .atomic_async_check = mdp5_plane_atomic_async_check,
+   .atomic_async_update = mdp5_plane_atomic_async_update,
 };
 
 static void set_scanout_locked(struct mdp5_kms *mdp5_kms,
@@ -997,84 

[PATCH 6/6] drm/vc4: update cursors asynchronously through atomic

[Gustavo Padovan]

From: Gustavo Padovan 

Add support to async updates of cursors by using the new atomic
interface for that. Basically what this commit does is do what
vc4_update_plane() did but through atomic.

v3: move size checks back to drivers (Ville Syrjälä)

v2: move fb setting to core and use new state (Eric Anholt)

Cc: Eric Anholt 
Signed-off-by: Gustavo Padovan 
Tested-by: Robert Foss 
---
 drivers/gpu/drm/vc4/vc4_plane.c | 99 +++--
 1 file changed, 35 insertions(+), 64 deletions(-)

diff --git a/drivers/gpu/drm/vc4/vc4_plane.c b/drivers/gpu/drm/vc4/vc4_plane.c
index d34cd53..05e9f5f 100644
--- a/drivers/gpu/drm/vc4/vc4_plane.c
+++ b/drivers/gpu/drm/vc4/vc4_plane.c
@@ -735,70 +735,38 @@ void vc4_plane_async_set_fb(struct drm_plane *plane, 
struct drm_framebuffer *fb)
vc4_state->dlist[vc4_state->ptr0_offset] = addr;
 }
 
-static const struct drm_plane_helper_funcs vc4_plane_helper_funcs = {
-   .atomic_check = vc4_plane_atomic_check,
-   .atomic_update = vc4_plane_atomic_update,
-};
-
-static void vc4_plane_destroy(struct drm_plane *plane)
-{
-   drm_plane_helper_disable(plane);
-   drm_plane_cleanup(plane);
-}
-
-/* Implements immediate (non-vblank-synced) updates of the cursor
- * position, or falls back to the atomic helper otherwise.
- */
-static int
-vc4_update_plane(struct drm_plane *plane,
-struct drm_crtc *crtc,
-struct drm_framebuffer *fb,
-int crtc_x, int crtc_y,
-unsigned int crtc_w, unsigned int crtc_h,
-uint32_t src_x, uint32_t src_y,
-uint32_t src_w, uint32_t src_h,
-struct drm_modeset_acquire_ctx *ctx)
+static int vc4_plane_atomic_async_check(struct drm_plane *plane,
+   struct drm_plane_state *state)
 {
-   struct drm_plane_state *plane_state;
-   struct vc4_plane_state *vc4_state;
-
-   if (plane != crtc->cursor)
-   goto out;
-
-   plane_state = plane->state;
-   vc4_state = to_vc4_plane_state(plane_state);
+   if (plane != state->crtc->cursor)
+   return -EINVAL;
 
-   if (!plane_state)
-   goto out;
+   if (!plane->state)
+   return -EINVAL;
 
/* No configuring new scaling in the fast path. */
-   if (crtc_w != plane_state->crtc_w ||
-   crtc_h != plane_state->crtc_h ||
-   src_w != plane_state->src_w ||
-   src_h != plane_state->src_h) {
-   goto out;
+   if (state->crtc_w != plane->state->crtc_w ||
+   state->crtc_h != plane->state->crtc_h ||
+   state->src_w != plane->state->src_w ||
+   state->src_h != plane->state->src_h) {
+   return -EINVAL;
}
 
-   if (fb != plane_state->fb) {
-   drm_atomic_set_fb_for_plane(plane->state, fb);
-   vc4_plane_async_set_fb(plane, fb);
-   }
+   return 0;
+}
 
-   /* Set the cursor's position on the screen.  This is the
-* expected change from the drm_mode_cursor_universal()
-* helper.
-*/
-   plane_state->crtc_x = crtc_x;
-   plane_state->crtc_y = crtc_y;
+static void vc4_plane_atomic_async_update(struct drm_plane *plane,
+ struct drm_plane_state *new_state)
+{
+   struct vc4_plane_state *vc4_state = to_vc4_plane_state(plane->state);
 
-   /* Allow changing the start position within the cursor BO, if
-* that matters.
-*/
-   plane_state->src_x = src_x;
-   plane_state->src_y = src_y;
+   plane->state->src_x = new_state->src_x;
+   plane->state->src_y = new_state->src_y;
+   plane->state->crtc_x = new_state->crtc_x;
+   plane->state->crtc_y = new_state->crtc_y;
 
-   /* Update the display list based on the new crtc_x/y. */
-   vc4_plane_atomic_check(plane, plane_state);
+   if (plane->state->fb != new_state->fb)
+   vc4_plane_async_set_fb(plane, new_state->fb);
 
/* Note that we can't just call vc4_plane_write_dlist()
 * because that would smash the context data that the HVS is
@@ -810,20 +778,23 @@ vc4_update_plane(struct drm_plane *plane,
   _state->hw_dlist[vc4_state->pos2_offset]);
writel(vc4_state->dlist[vc4_state->ptr0_offset],
   _state->hw_dlist[vc4_state->ptr0_offset]);
+}
 
-   return 0;
+static const struct drm_plane_helper_funcs vc4_plane_helper_funcs = {
+   .atomic_check = vc4_plane_atomic_check,
+   .atomic_update = vc4_plane_atomic_update,
+   .atomic_async_check = vc4_plane_atomic_async_check,
+   .atomic_async_update = vc4_plane_atomic_async_update,
+};
 
-out:
-   return drm_atomic_helper_update_plane(plane, crtc, fb,
- crtc_x, crtc_y,
-  

[PATCH 3/6] drm/i915: remove intel_cursor_plane_funcs

[Gustavo Padovan]

From: Gustavo Padovan 

After converting legacy cursor updates to atomic async commits
intel_cursor_plane_funcs just duplicates intel_plane_funcs now.

Cc: Daniel Vetter 
Signed-off-by: Gustavo Padovan 
---
 drivers/gpu/drm/i915/intel_display.c | 13 +
 1 file changed, 1 insertion(+), 12 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 7f4c8d3..ee75165 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -13418,17 +13418,6 @@ const struct drm_plane_funcs intel_plane_funcs = {
.atomic_destroy_state = intel_plane_destroy_state,
 };
 
-static const struct drm_plane_funcs intel_cursor_plane_funcs = {
-   .update_plane = drm_atomic_helper_update_plane,
-   .disable_plane = drm_atomic_helper_disable_plane,
-   .destroy = intel_plane_destroy,
-   .set_property = drm_atomic_helper_plane_set_property,
-   .atomic_get_property = intel_plane_atomic_get_property,
-   .atomic_set_property = intel_plane_atomic_set_property,
-   .atomic_duplicate_state = intel_plane_duplicate_state,
-   .atomic_destroy_state = intel_plane_destroy_state,
-};
-
 static struct intel_plane *
 intel_primary_plane_create(struct drm_i915_private *dev_priv, enum pipe pipe)
 {
@@ -13675,7 +13664,7 @@ intel_cursor_plane_create(struct drm_i915_private 
*dev_priv, enum pipe pipe)
cursor->disable_plane = intel_disable_cursor_plane;
 
ret = drm_universal_plane_init(_priv->drm, >base,
-  0, _cursor_plane_funcs,
+  0, _plane_funcs,
   intel_cursor_formats,
   ARRAY_SIZE(intel_cursor_formats),
   DRM_PLANE_TYPE_CURSOR,
-- 
2.9.4

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

[PATCH 0/6] drm/atomic: add async plane update

[Gustavo Padovan]

From: Gustavo Padovan 

Hi,

New version of the patches after the comments from Archit. Full details
and the previous discussion can be found here:

https://www.spinics.net/lists/dri-devel/msg141337.html

I'm not including the uAPI patch here, because we don't have any userspace
for it yet.

Please review. Thanks!

Gustavo

--
Gustavo Padovan (6):
  drm/atomic: initial support for asynchronous plane update
  drm/i915: update cursors asynchronously through atomic
  drm/i915: remove intel_cursor_plane_funcs
  drm/msm: update cursors asynchronously through atomic
  drm/msm: remove mdp5_cursor_plane_funcs
  drm/vc4: update cursors asynchronously through atomic

 drivers/gpu/drm/drm_atomic.c  |  65 +++
 drivers/gpu/drm/drm_atomic_helper.c   |  35 ++
 drivers/gpu/drm/i915/intel_atomic_plane.c |  73 +
 drivers/gpu/drm/i915/intel_display.c  | 160 ---
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c | 175 +++---
 drivers/gpu/drm/msm/msm_atomic.c  |   6 +
 drivers/gpu/drm/vc4/vc4_plane.c   |  99 ++---
 include/drm/drm_atomic.h  |   2 +
 include/drm/drm_atomic_helper.h   |   2 +
 include/drm/drm_modeset_helper_vtables.h  |  48 
 10 files changed, 355 insertions(+), 310 deletions(-)

-- 
2.9.4

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

[PATCH 2/6] drm/i915: update cursors asynchronously through atomic

[Gustavo Padovan]

From: Gustavo Padovan 

Add support to async updates of cursors by using the new atomic
interface for that. Basically what this commit does is do what
intel_legacy_cursor_update() did but through atomic.

v3:
- set correct vma to new state for cleanup
- move size checks back to drivers (Ville Syrjälä)

v2:
- move fb setting to core and use new state (Eric Anholt)

Cc: Daniel Vetter 
Signed-off-by: Gustavo Padovan 
---
 drivers/gpu/drm/i915/intel_atomic_plane.c |  73 +++
 drivers/gpu/drm/i915/intel_display.c  | 149 +-
 2 files changed, 97 insertions(+), 125 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_atomic_plane.c 
b/drivers/gpu/drm/i915/intel_atomic_plane.c
index cfb4729..974c91f 100644
--- a/drivers/gpu/drm/i915/intel_atomic_plane.c
+++ b/drivers/gpu/drm/i915/intel_atomic_plane.c
@@ -246,11 +246,84 @@ static void intel_plane_atomic_update(struct drm_plane 
*plane,
}
 }
 
+static int intel_plane_atomic_async_check(struct drm_plane *plane,
+ struct drm_plane_state *state)
+{
+   struct drm_crtc *crtc = plane->state->crtc;
+   struct drm_crtc_state *crtc_state = crtc->state;
+
+   if (plane->type != DRM_PLANE_TYPE_CURSOR)
+   return -EINVAL;
+
+   /*
+* When crtc is inactive or there is a modeset pending,
+* wait for it to complete in the slowpath
+*/
+   if (!crtc_state->active || to_intel_crtc_state(crtc_state)->update_pipe)
+   return -EINVAL;
+
+   /*
+* If any parameters change that may affect watermarks,
+* take the slowpath. Only changing fb or position should be
+* in the fastpath.
+*/
+   if (plane->state->crtc != state->crtc ||
+   plane->state->src_w != state->src_w ||
+   plane->state->src_h != state->src_h ||
+   plane->state->crtc_w != state->crtc_w ||
+   plane->state->crtc_h != state->crtc_h ||
+   !plane->state->fb != !state->fb)
+   return -EINVAL;
+
+   return 0;
+}
+
+static void intel_plane_atomic_async_update(struct drm_plane *plane,
+   struct drm_plane_state *new_state)
+{
+   struct intel_plane *intel_plane = to_intel_plane(plane);
+   struct drm_crtc *crtc = plane->state->crtc;
+   struct drm_framebuffer *old_fb;
+   struct i915_vma *old_vma;
+
+   old_vma = to_intel_plane_state(plane->state)->vma;
+   old_fb = plane->state->fb;
+
+   i915_gem_track_fb(intel_fb_obj(old_fb), intel_fb_obj(new_state->fb),
+ intel_plane->frontbuffer_bit);
+
+   plane->state->src_x = new_state->src_x;
+   plane->state->src_y = new_state->src_y;
+   plane->state->crtc_x = new_state->crtc_x;
+   plane->state->crtc_y = new_state->crtc_y;
+   plane->state->fb = new_state->fb;
+   *to_intel_plane_state(plane->state) = *to_intel_plane_state(new_state);
+
+   to_intel_plane_state(new_state)->vma = old_vma;
+   new_state->fb = old_fb;
+
+   if (plane->state->visible) {
+   trace_intel_update_plane(plane, to_intel_crtc(crtc));
+   intel_plane->update_plane(plane,
+ to_intel_crtc_state(crtc->state),
+ to_intel_plane_state(plane->state));
+   } else {
+   trace_intel_disable_plane(plane, to_intel_crtc(crtc));
+   intel_plane->disable_plane(plane, crtc);
+   }
+
+   mutex_lock(>dev->struct_mutex);
+   intel_cleanup_plane_fb(plane, new_state);
+   mutex_unlock(>dev->struct_mutex);
+}
+
 const struct drm_plane_helper_funcs intel_plane_helper_funcs = {
.prepare_fb = intel_prepare_plane_fb,
.cleanup_fb = intel_cleanup_plane_fb,
.atomic_check = intel_plane_atomic_check,
.atomic_update = intel_plane_atomic_update,
+   .atomic_async_check = intel_plane_atomic_async_check,
+   .atomic_async_update = intel_plane_atomic_async_update,
 };
 
 /**
diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 207f144..7f4c8d3 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -13010,6 +13010,26 @@ static int intel_atomic_commit(struct drm_device *dev,
struct drm_i915_private *dev_priv = to_i915(dev);
int ret = 0;
 
+   /*
+* The atomic async update fast path takes care
+* of avoiding the vblank waits for simple cursor
+* movement and flips. For cursor on/off and size changes,
+* we want to perform the vblank waits so that watermark
+* updates happen during the correct frames. Gen9+ have
+* double buffered watermarks and so shouldn't need this.
+*/
+   if (state->async_update) {
+  

[PATCH 1/6] drm/atomic: initial support for asynchronous plane update

[Gustavo Padovan]

From: Gustavo Padovan 

In some cases, like cursor updates, it is interesting to update the
plane in an asynchronous fashion to avoid big delays. The current queued
update could be still waiting for a fence to signal and thus block any
subsequent update until its scan out. In cases like this if we update the
cursor synchronously through the atomic API it will cause significant
delays that would even be noticed by the final user.

This patch creates a fast path to jump ahead the current queued state and
do single planes updates without going through all atomic steps in
drm_atomic_helper_commit(). We take this path for legacy cursor updates.

For now only single plane updates are supported, but we plan to support
multiple planes updates and async PageFlips through this interface as well
in the near future.

v4:
- fix state->crtc NULL check (Archit Taneja)

v3:
- fix iteration on the wrong crtc state
- put back code to forbid updates if there is a queued update for
the same plane (Ville Syrjälä)
- move size checks back to drivers (Ville Syrjälä)
- move ASYNC_UPDATE flag addition to its own patch (Ville Syrjälä)

v2:
- allow updates even if there is a queued update for the same
plane.
- fixes on the documentation (Emil Velikov)
- unconditionally call ->atomic_async_update (Emil Velikov)
- check for ->atomic_async_update earlier (Daniel Vetter)
- make ->atomic_async_check() the last step (Daniel Vetter)
- add ASYNC_UPDATE flag (Eric Anholt)
- update state in core after ->atomic_async_update (Eric Anholt)
- update docs (Eric Anholt)

Cc: Daniel Vetter 
Cc: Rob Clark 
Cc: Eric Anholt 
Signed-off-by: Gustavo Padovan 
---
 drivers/gpu/drm/drm_atomic.c | 65 
 drivers/gpu/drm/drm_atomic_helper.c  | 35 +
 include/drm/drm_atomic.h |  2 +
 include/drm/drm_atomic_helper.h  |  2 +
 include/drm/drm_modeset_helper_vtables.h | 48 +++
 5 files changed, 152 insertions(+)

diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index be62774..2a0c297 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -631,6 +631,68 @@ static int drm_atomic_crtc_check(struct drm_crtc *crtc,
return 0;
 }
 
+static bool drm_atomic_async_check(struct drm_atomic_state *state)
+{
+   struct drm_crtc *crtc;
+   struct drm_crtc_state *crtc_state;
+   struct drm_crtc_commit *commit;
+   struct drm_plane *__plane, *plane = NULL;
+   struct drm_plane_state *__plane_state, *plane_state = NULL;
+   const struct drm_plane_helper_funcs *funcs;
+   int i, j, n_planes = 0;
+
+   for_each_new_crtc_in_state(state, crtc, crtc_state, i) {
+   if (drm_atomic_crtc_needs_modeset(crtc_state))
+   return false;
+   }
+
+   for_each_new_plane_in_state(state, __plane, __plane_state, i) {
+   n_planes++;
+   plane = __plane;
+   plane_state = __plane_state;
+   }
+
+   /* FIXME: we support only single plane updates for now */
+   if (!plane || n_planes != 1)
+   return false;
+
+   if (!plane_state->crtc)
+   return false;
+
+   funcs = plane->helper_private;
+   if (!funcs->atomic_async_update)
+   return false;
+
+   if (plane_state->fence)
+   return false;
+
+   for_each_new_crtc_in_state(state, crtc, crtc_state, i) {
+   if (plane->crtc != crtc)
+   continue;
+
+   spin_lock(>commit_lock);
+   commit = list_first_entry_or_null(>commit_list,
+ struct drm_crtc_commit,
+ commit_entry);
+   if (!commit) {
+   spin_unlock(>commit_lock);
+   continue;
+   }
+   spin_unlock(>commit_lock);
+
+   if (!crtc->state->state)
+   continue;
+
+   for_each_plane_in_state(crtc->state->state, __plane,
+   __plane_state, j) {
+   if (__plane == plane)
+   return false;
+   }
+   }
+
+   return !funcs->atomic_async_check(plane, plane_state);
+}
+
 static void drm_atomic_crtc_print_state(struct drm_printer *p,
const struct drm_crtc_state *state)
 {
@@ -1591,6 +1653,9 @@ int drm_atomic_check_only(struct drm_atomic_state *state)
}
}
 
+   if (state->legacy_cursor_update)
+   state->async_update = drm_atomic_async_check(state);
+
return ret;
 }
 

Re: [PATCH] drm/mediatek: hdmi: Filter interlaced resolutions

[CK Hu]

On Wed, 2017-05-24 at 14:24 +0200, Daniel Vetter wrote:
> On Wed, May 24, 2017 at 05:20:45PM +0800, CK Hu wrote:
> > On Tue, 2017-05-23 at 15:12 +0200, Daniel Vetter wrote:
> > > On Tue, May 23, 2017 at 05:28:15PM +0800, CK Hu wrote:
> > > > Hi, Bibby:
> > > > 
> > > > I've applied this patch to my branch mediatek-drm-fixes-4.12-rc1,
> > > > thanks.
> > > > 
> > > > Regards,
> > > > CK
> > > > 
> > > > On Tue, 2017-01-24 at 13:10 +0800, Bibby Hsieh wrote:
> > > > > Current Mediatek DRM driver does not support interlaced mode, and
> > > > > will hang if such resolution is used: Filter those to prevent
> > > > > kernel hangs, until the DRM driver is fixed properly.
> > > > > 
> > > > > Signed-off-by: Bibby Hsieh 
> > > > > ---
> > > > >  drivers/gpu/drm/mediatek/mtk_hdmi.c | 2 ++
> > > > >  1 file changed, 2 insertions(+)
> > > > > 
> > > > > diff --git a/drivers/gpu/drm/mediatek/mtk_hdmi.c 
> > > > > b/drivers/gpu/drm/mediatek/mtk_hdmi.c
> > > > > index 0e8c4d9..e33678d 100644
> > > > > --- a/drivers/gpu/drm/mediatek/mtk_hdmi.c
> > > > > +++ b/drivers/gpu/drm/mediatek/mtk_hdmi.c
> > > > > @@ -1244,6 +1244,8 @@ static int mtk_hdmi_conn_mode_valid(struct 
> > > > > drm_connector *conn,
> > > > >   return MODE_BAD;
> > > > >   }
> > > > >  
> > > > > + if (mode->flags & DRM_MODE_FLAG_INTERLACE)
> > > > > + return MODE_NO_INTERLACE;
> > > > >   if (mode->clock < 27000)
> > > > >   return MODE_CLOCK_LOW;
> > > > >   if (mode->clock > 297000)
> > > 
> > > You probably want to check out Jose's mode_valid work, since only
> > > filtering in the connector's ->mode_valid callback isn't enough. You also
> > > need to filter in ->mode_fixup (or some other place called at atomic_check
> > > time).
> > > -Daniel
> > 
> > Hi, Daniel:
> > 
> > Yes, I still need to filter in ->mode_fixup.
> > 
> > Hi, Bibby:
> > 
> > Because Jose's work plan to use mode_valid to replace mode_fixup, so
> > it's better to refine this patch after Jose's work is done. And I would
> > now remove this patch from my branch.
> 
> Btw if you have a revised version of your patch on top of Jose's series, a
> tested-by on that would be awesome. The more people find it useful, the
> faster it will land.
> -Daniel

Hi, Daniel:

I understand.

Hi Bibby:

If you have time, please help to test Jose's patches with the problem
you have met. Otherwise, it would be a long process.

Regards,
CK



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

Re: [PATCH 36/37] drm/zte: Drop drm_vblank_cleanup

[Shawn Guo]

On Wed, May 24, 2017 at 04:52:11PM +0200, Daniel Vetter wrote:
> It again looks all cargo-culted for no good reasons.

drm_vblank_cleanup() is called to release the resources allocated by
drm_vblank_init().  I think that's the reason, no?

Shawn

> 
> Cc: Shawn Guo 
> Signed-off-by: Daniel Vetter 
> ---
>  drivers/gpu/drm/zte/zx_drm_drv.c | 2 --
>  1 file changed, 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/zte/zx_drm_drv.c 
> b/drivers/gpu/drm/zte/zx_drm_drv.c
> index 490aafc99610..696836303229 100644
> --- a/drivers/gpu/drm/zte/zx_drm_drv.c
> +++ b/drivers/gpu/drm/zte/zx_drm_drv.c
> @@ -149,7 +149,6 @@ static int zx_drm_bind(struct device *dev)
>  out_poll_fini:
>   drm_kms_helper_poll_fini(drm);
>   drm_mode_config_cleanup(drm);
> - drm_vblank_cleanup(drm);
>  out_unbind:
>   component_unbind_all(dev, drm);
>  out_unregister:
> @@ -171,7 +170,6 @@ static void zx_drm_unbind(struct device *dev)
>   }
>   drm_kms_helper_poll_fini(drm);
>   drm_mode_config_cleanup(drm);
> - drm_vblank_cleanup(drm);
>   component_unbind_all(dev, drm);
>   dev_set_drvdata(dev, NULL);
>   drm->dev_private = NULL;
> -- 
> 2.11.0
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 1/2] dt/bindings: display: fix display-timing reference

[Baruch Siach]

Hi Daniel,

On Wed, May 24, 2017 at 02:23:22PM +0200, Daniel Vetter wrote:
> On Tue, May 23, 2017 at 09:47:56AM -0500, Rob Herring wrote:
> > On Tue, May 16, 2017 at 11:19:04AM +0300, Baruch Siach wrote:
> > > Fixes: 14da3ed8dd08 ("devicetree/bindings: display: Document common panel 
> > > properties")
> > > Cc: Laurent Pinchart 
> > > Cc: Rob Herring 
> > > Signed-off-by: Baruch Siach 
> > > ---
> > >  Documentation/devicetree/bindings/display/panel/panel-common.txt | 2 +-
> > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > Acked-by: Rob Herring 
> 
> We now have a pile of acks on these patches, but no one to push them.
> Seems like it's for the panel tree, but Thierry isn't on cc afaics.
> 
> Someone needs to take care of this (and no it's no going to be me).

Thanks for looking into this.

Just for the record, Thierry has been on To/Cc of all messages in this thread, 
accept yours.

baruch

-- 
 http://baruch.siach.name/blog/  ~. .~   Tk Open Systems
=}ooO--U--Ooo{=
   - bar...@tkos.co.il - tel: +972.2.679.5364, http://www.tkos.co.il -
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/i915: prevent generating unusable gvt build which no mpt module is selected

[Du, Changbin]

On Wed, May 24, 2017 at 10:21:31AM +0100, Chris Wilson wrote:
> On Wed, May 24, 2017 at 04:50:39PM +0800, changbin...@intel.com wrote:
> > From: Changbin Du 
> > 
> > At least we need one MPT module (currently only have one) selected
> > to get GVTg functional. When GVTg is enabled while no MPT selected,
> > the build just includes useless GVTg code. This doesn't make sense.
> 
> See the Kconfig "choice" directive.
> -Chris
> 
I was thought about "choice" as in mind firstly and that is good. But I think
this is better since it make it totaly impossible that GVT is enabled while no
MPT. With "choice", if we forget disable GVT after unselect all MPTs, we still
compile GVT in but will never not use it.

> -- 
> Chris Wilson, Intel Open Source Technology Centre
> ___
> intel-gvt-dev mailing list
> intel-gvt-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gvt-dev

-- 
Thanks,
Changbin Du


signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 15/37] drm/arcgpu: Drop drm_vblank_cleanup

[Alexey Brodkin]

Hi Daniel,

On Wed, 2017-05-24 at 16:51 +0200, Daniel Vetter wrote:
> CRTC don't seem to get shut down in a controlled fashion, but no one
> bothers to stop interrupts either so this races no matter what. Might
> as well remove it. A call to drm_atomic_helper_shutdown would be
> pretty sweet somewhere (and maybe getting rid of the load/unload
> callbacks while at it).
> 
> Cc: Alexey Brodkin 
> Signed-off-by: Daniel Vetter 
> ---
>  drivers/gpu/drm/arc/arcpgu_drv.c | 1 -
>  1 file changed, 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/arc/arcpgu_drv.c 
> b/drivers/gpu/drm/arc/arcpgu_drv.c
> index 1926b200e4cb..3e43a5d4fb09 100644
> --- a/drivers/gpu/drm/arc/arcpgu_drv.c
> +++ b/drivers/gpu/drm/arc/arcpgu_drv.c
> @@ -155,7 +155,6 @@ static int arcpgu_unload(struct drm_device *drm)
>   arcpgu->fbdev = NULL;
>   }
>   drm_kms_helper_poll_fini(drm);
> - drm_vblank_cleanup(drm);
>   drm_mode_config_cleanup(drm);
>  
>   return 0;

Reviewed-by: Alexey Brodkin 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/i915: prevent generating unusable gvt build which no mpt module is selected

[changbin . du]

From: Changbin Du 

At least we need one MPT module (currently only have one) selected
to get GVTg functional. When GVTg is enabled while no MPT selected,
the build just includes useless GVTg code. This doesn't make sense.

With this patch, a submenut is created under i915 as below:
  -*- Enable Intel GVT-g graphics virtualization host support
   Enable KVM/VFIO support for Intel GVT-g

If no MPT is selected, GVTg will be disabled automatically.
  < > Enable KVM/VFIO support for Intel GVT-g

Signed-off-by: Changbin Du 
---
 drivers/gpu/drm/i915/Kconfig | 16 ++--
 1 file changed, 10 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/i915/Kconfig b/drivers/gpu/drm/i915/Kconfig
index a5cd5da..e380a5d 100644
--- a/drivers/gpu/drm/i915/Kconfig
+++ b/drivers/gpu/drm/i915/Kconfig
@@ -91,12 +91,15 @@ config DRM_I915_USERPTR
 
  If in doubt, say "Y".
 
+menu "Intel GVT-g graphics virtualization host support"
+   depends on DRM_I915
+   depends on 64BIT
+
 config DRM_I915_GVT
-bool "Enable Intel GVT-g graphics virtualization host support"
-depends on DRM_I915
-depends on 64BIT
-default n
-help
+   bool "Enable Intel GVT-g graphics virtualization host support"
+   default n
+   depends on DRM_I915_GVT_KVMGT
+   help
  Choose this option if you want to enable Intel GVT-g graphics
  virtualization technology host support with integrated graphics.
  With GVT-g, it's possible to have one integrated graphics
@@ -116,13 +119,14 @@ config DRM_I915_GVT
 
 config DRM_I915_GVT_KVMGT
tristate "Enable KVM/VFIO support for Intel GVT-g"
-   depends on DRM_I915_GVT
+   select DRM_I915_GVT
depends on KVM
depends on VFIO_MDEV && VFIO_MDEV_DEVICE
default n
help
  Choose this option if you want to enable KVMGT support for
  Intel GVT-g.
+endmenu
 
 menu "drm/i915 Debugging"
 depends on DRM_I915
-- 
2.7.4

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

Re: [linux-sunxi] [RFC PATCH 10/11] ARM: sun8i: h3: add display engine pipeline for TVE

[Chen-Yu Tsai]

On Thu, May 18, 2017 at 12:43 AM, Icenowy Zheng  wrote:
> As we have already the support for the TV encoder on Allwinner H3, add
> the display engine pipeline device tree nodes to its DTSI file.
>
> The H5 pipeline has some differences and will be enabled later.
>
> The currently-unused mixer0 and tcon0 are also needed, for the
> completement of the pipeline.
>
> Signed-off-by: Icenowy Zheng 
> ---
>  arch/arm/boot/dts/sun8i-h3.dtsi | 189 
> 
>  1 file changed, 189 insertions(+)
>
> diff --git a/arch/arm/boot/dts/sun8i-h3.dtsi b/arch/arm/boot/dts/sun8i-h3.dtsi
> index b36f9f423c39..20172ef92415 100644
> --- a/arch/arm/boot/dts/sun8i-h3.dtsi
> +++ b/arch/arm/boot/dts/sun8i-h3.dtsi
> @@ -41,6 +41,8 @@
>   */
>
>  #include "sunxi-h3-h5.dtsi"
> +#include 
> +#include 
>
>  / {
> cpus {
> @@ -72,6 +74,193 @@
> };
> };
>
> +   de: display-engine {
> +   compatible = "allwinner,sun8i-h3-display-engine";
> +   allwinner,pipelines = <>,
> + <>;
> +   status = "disabled";
> +   };
> +
> +   soc {
> +   display_clocks: clock@100 {
> +   compatible = "allwinner,sun8i-a83t-de2-clk";
> +   reg = <0x0100 0x10>;
> +   clocks = < CLK_BUS_DE>,
> +< CLK_DE>;
> +   clock-names = "bus",
> + "mod";
> +   resets = < RST_BUS_DE>;
> +   #clock-cells = <1>;
> +   #reset-cells = <1>;
> +   assigned-clocks = < CLK_DE>;
> +   assigned-clock-parents = < CLK_PLL_DE>;
> +   assigned-clock-rates = <43200>;
> +   };
> +
> +   mixer0: mixer@110 {
> +   compatible = "allwinner,sun8i-h3-de2-mixer0";
> +   reg = <0x0110 0x10>;
> +   clocks = <_clocks CLK_BUS_MIXER0>,
> +<_clocks CLK_MIXER0>;
> +   clock-names = "bus",
> + "mod";
> +   resets = <_clocks RST_MIXER0>;
> +   status = "disabled";
> +
> +   ports {
> +   #address-cells = <1>;
> +   #size-cells = <0>;
> +
> +   mixer0_out: port@1 {
> +   #address-cells = <1>;
> +   #size-cells = <0>;
> +   reg = <1>;
> +
> +   mixer0_out_tcon0: endpoint@0 {
> +   reg = <0>;
> +   remote-endpoint = 
> <_in_mixer0>;
> +   };
> +
> +   mixer0_out_tcon1: endpoint@1 {
> +   reg = <1>;
> +   remote-endpoint = 
> <_in_mixer0>;
> +   };
> +   };
> +   };
> +   };
> +
> +   mixer1: mixer@120 {
> +   compatible = "allwinner,sun8i-h3-de2-mixer1";
> +   reg = <0x0120 0x10>;
> +   clocks = <_clocks CLK_BUS_MIXER1>,
> +<_clocks CLK_MIXER1>;
> +   clock-names = "bus",
> + "mod";
> +   resets = <_clocks RST_WB>;
> +
> +   ports {
> +   #address-cells = <1>;
> +   #size-cells = <0>;
> +
> +   mixer1_out: port@1 {
> +   #address-cells = <1>;
> +   #size-cells = <0>;
> +   reg = <1>;
> +
> +   mixer1_out_tcon1: endpoint@0 {
> +   reg = <0>;

I would prefer if you could stick to the numbering scheme we're using for
Display Engine 1.0, as in endpoint 0 links to component 0 of whatever type.

We're probably going to stick to that for the R40's incredibly complicated
pipeline. I don't want to have any outliers unless absolutely necessary.

ChenYu

> +   remote-endpoint = 
> <_in_mixer1>;
> +   };
> +
> +   mixer1_out_tcon0: endpoint@1 {
> +   reg = <1>;
> +   

Re: [linux-sunxi] [RFC PATCH 10/11] ARM: sun8i: h3: add display engine pipeline for TVE

[Icenowy Zheng]

于 2017年5月24日 GMT+08:00 下午1:34:58, Chen-Yu Tsai  写到:
>On Wed, May 24, 2017 at 1:28 PM, Icenowy Zheng  wrote:
>>
>>
>> 于 2017年5月24日 GMT+08:00 下午1:24:29, Chen-Yu Tsai  写到:
>>>On Thu, May 18, 2017 at 12:43 AM, Icenowy Zheng 
>>>wrote:
 As we have already the support for the TV encoder on Allwinner H3,
>>>add
 the display engine pipeline device tree nodes to its DTSI file.

 The H5 pipeline has some differences and will be enabled later.

 The currently-unused mixer0 and tcon0 are also needed, for the
 completement of the pipeline.

 Signed-off-by: Icenowy Zheng 
 ---
  arch/arm/boot/dts/sun8i-h3.dtsi | 189
>>>
  1 file changed, 189 insertions(+)

 diff --git a/arch/arm/boot/dts/sun8i-h3.dtsi
>>>b/arch/arm/boot/dts/sun8i-h3.dtsi
 index b36f9f423c39..20172ef92415 100644
 --- a/arch/arm/boot/dts/sun8i-h3.dtsi
 +++ b/arch/arm/boot/dts/sun8i-h3.dtsi
 @@ -41,6 +41,8 @@
   */

  #include "sunxi-h3-h5.dtsi"
 +#include 
 +#include 

  / {
 cpus {
 @@ -72,6 +74,193 @@
 };
 };

 +   de: display-engine {
 +   compatible = "allwinner,sun8i-h3-display-engine";
 +   allwinner,pipelines = <>,
 + <>;
 +   status = "disabled";
 +   };
 +
 +   soc {
 +   display_clocks: clock@100 {
 +   compatible =
>"allwinner,sun8i-a83t-de2-clk";
 +   reg = <0x0100 0x10>;
 +   clocks = < CLK_BUS_DE>,
 +< CLK_DE>;
 +   clock-names = "bus",
 + "mod";
 +   resets = < RST_BUS_DE>;
 +   #clock-cells = <1>;
 +   #reset-cells = <1>;
 +   assigned-clocks = < CLK_DE>;
 +   assigned-clock-parents = < CLK_PLL_DE>;
 +   assigned-clock-rates = <43200>;
 +   };
 +
 +   mixer0: mixer@110 {
 +   compatible =
>"allwinner,sun8i-h3-de2-mixer0";
 +   reg = <0x0110 0x10>;
 +   clocks = <_clocks CLK_BUS_MIXER0>,
 +<_clocks CLK_MIXER0>;
 +   clock-names = "bus",
 + "mod";
 +   resets = <_clocks RST_MIXER0>;
 +   status = "disabled";
 +
 +   ports {
 +   #address-cells = <1>;
 +   #size-cells = <0>;
 +
 +   mixer0_out: port@1 {
 +   #address-cells = <1>;
 +   #size-cells = <0>;
 +   reg = <1>;
 +
 +   mixer0_out_tcon0:
>endpoint@0
>>>{
 +   reg = <0>;
 +   remote-endpoint =
>>><_in_mixer0>;
 +   };
 +
 +   mixer0_out_tcon1:
>endpoint@1
>>>{
 +   reg = <1>;
 +   remote-endpoint =
>>><_in_mixer0>;
 +   };
 +   };
 +   };
 +   };
 +
 +   mixer1: mixer@120 {
 +   compatible =
>"allwinner,sun8i-h3-de2-mixer1";
 +   reg = <0x0120 0x10>;
 +   clocks = <_clocks CLK_BUS_MIXER1>,
 +<_clocks CLK_MIXER1>;
 +   clock-names = "bus",
 + "mod";
 +   resets = <_clocks RST_WB>;
 +
 +   ports {
 +   #address-cells = <1>;
 +   #size-cells = <0>;
 +
 +   mixer1_out: port@1 {
 +   #address-cells = <1>;
 +   #size-cells = <0>;
 +   reg = <1>;
 +
 +   mixer1_out_tcon1:
>endpoint@0
>>>{
 +   reg = <0>;
>>>
>>>I would prefer if you could stick to the numbering scheme we're using

Re: [linux-sunxi] Re: [RFC PATCH 07/11] drm: sun4i: add support for the TV encoder in H3 SoC

[Icenowy Zheng]

于 2017年5月24日 GMT+08:00 下午3:30:19, Maxime Ripard 
 写到:
>On Tue, May 23, 2017 at 09:00:59PM +0800, icen...@aosc.io wrote:
>> 在 2017-05-23 20:53，Maxime Ripard 写道：
>> > On Mon, May 22, 2017 at 07:55:56PM +0200, Jernej Škrabec wrote:
>> > > Hi,
>> > > 
>> > > Dne sobota, 20. maj 2017 ob 03:37:53 CEST je Chen-Yu Tsai
>napisal(a):
>> > > > On Sat, May 20, 2017 at 2:23 AM, Jernej Škrabec
>
>> > > wrote:
>> > > > > Hi,
>> > > > >
>> > > > > Dne petek, 19. maj 2017 ob 20:08:18 CEST je Icenowy Zheng
>napisal(a):
>> > > > >> 于 2017年5月20日 GMT+08:00 上午2:03:30, Maxime Ripard
>> > > > >
>> > > > > electrons.com> 写到:
>> > > > >> >On Thu, May 18, 2017 at 12:43:50AM +0800, Icenowy Zheng
>wrote:
>> > > > >> >> Allwinner H3 features a TV encoder similar to the one in
>earlier
>> > > > >> >
>> > > > >> >SoCs,
>> > > > >> >
>> > > > >> >> but with some different points about clocks:
>> > > > >> >> - It has a mod clock and a bus clock.
>> > > > >> >> - The mod clock must be at a fixed rate to generate
>signal.
>> > > > >> >
>> > > > >> >Why?
>> > > > >>
>> > > > >> It's experiment result by Jernej.
>> > > > >>
>> > > > >> The clock rates in BSP kernel is also specially designed
>> > > > >> (PLL_DE at 432MHz) in order to be able to feed the TVE.
>> > > > >
>> > > > > My experiments and search through BSP code showed that TVE
>seems to have
>> > > > > additional fixed predivider 8. So if you want to generate 27
>MHz clock,
>> > > > > unit has to be feed with 216 MHz.
>> > > > >
>> > > > > TVE has only one PLL source PLL_DE. And since 216 MHz is a
>bit low for
>> > > > > DE2,
>> > > > > BSP defaults to 432 MHz for PLL_DE and use divider 2 to
>generate 216 MHz.
>> > > > > This clock is then divided by 8 internaly to get final 27
>MHz.
>> > > > >
>> > > > > Please note that I don't have any hard evidence to support
>that, only
>> > > > > experimental data. However, only that explanation make sense
>to me.
>> > > > >
>> > > > > BTW, BSP H3/H5 TV driver supports only PAL and NTSC which
>both use 27 MHz
>> > > > > base clock. Further experiments are needed to check if there
>is any
>> > > > > possibility to have other resolutions by manipulating clocks
>and give
>> > > > > other proper settings. I plan to do that, but not in very
>near future.
>> > > >
>> > > > You only have composite video output, and those are the only 2
>standard
>> > > > resolutions that make any sense.
>> > > 
>> > > Right, other resolutions are for VGA.
>> > > 
>> > > Anyway, I did some more digging in A10 and R40 datasheets. I
>think
>> > > that H3 TVE
>> > > unit is something in between. R40 TVE has a setting to select "up
>> > > sample".
>> > 
>> > That might be just another translation of oversampling :)
>> > 
>> > I didn't know it could be applied to composite signals though, but
>I
>> > guess this is just another analog signal after all.
>> > 
>> > > Possible settings are 27 MHz, 54 MHz, 108 MHz and 216 MHz. BSP
>> > > driver on R40
>> > > has this setting enabled only for PAL and NTSC and it is always
>216
>> > > MHz. I
>> > > think that H3 may have this hardwired to 216 MHz and this would
>be
>> > > the reason
>> > > why 216 MHz is needed.
>> > > 
>> > > Has anyone else any better explanation?
>> > 
>> > That's already a pretty good one.
>> > 
>> > Either way, wether this is upsampling, oversampling or just a
>> > pre-divider, this can and should be dealt with in the mode_set
>> > callback, and not in the probe.
>> 
>> I got a better idea -- let TVE driver have the CLK_TVE as an
>> input and create a subclock output with divider 16, and feed this
>> subclock to TCON lcd-ch1.
>> 
>> This is a model of the real hardware -- the clock divider is in
>> TVE, not TCON.
>
>That's definitely not a good representation of the hardware. There's
>one clock, it goes to the TCON, period.

No, I still think it goes to the TVE as:

1. it's named TVE in datasheet.
2. Generating signal with such a low resolution but such
a high dotclock is not a good situation.

>
>However, the TV encoder has a constraint on that clock rate. This can
>be easily implemented using a custom encoder state where you'd set the
>multiplier to set on that clock, and the TCON will use it.
>
>Maxime
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 5/5] drm: dw-hdmi-i2s: add .get_dai_id callback for ALSA SoC

[Kuninori Morimoto]

Hi Mark
Cc: DRM maintainer

> > ALSA SoC needs to know connected DAI ID for probing.
> > It is not a big problem if device/driver was only for sound,
> > but getting DAI ID will be difficult if device includes both
> > Video/Sound, like HDMI.
> 
> As far as I understand what's going on with the graph code this seems to
> make sense to me.  How do we want to go about handling the patch?

This is comment to me ? or DRM maintainer ?

If to me, any case (pickup by Mark, or by DRM maintainer) is OK for me

Best regards
---
Kuninori Morimoto
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [linux-sunxi] [RFC PATCH 10/11] ARM: sun8i: h3: add display engine pipeline for TVE

[Icenowy Zheng]

于 2017年5月24日 GMT+08:00 下午1:24:29, Chen-Yu Tsai  写到:
>On Thu, May 18, 2017 at 12:43 AM, Icenowy Zheng 
>wrote:
>> As we have already the support for the TV encoder on Allwinner H3,
>add
>> the display engine pipeline device tree nodes to its DTSI file.
>>
>> The H5 pipeline has some differences and will be enabled later.
>>
>> The currently-unused mixer0 and tcon0 are also needed, for the
>> completement of the pipeline.
>>
>> Signed-off-by: Icenowy Zheng 
>> ---
>>  arch/arm/boot/dts/sun8i-h3.dtsi | 189
>
>>  1 file changed, 189 insertions(+)
>>
>> diff --git a/arch/arm/boot/dts/sun8i-h3.dtsi
>b/arch/arm/boot/dts/sun8i-h3.dtsi
>> index b36f9f423c39..20172ef92415 100644
>> --- a/arch/arm/boot/dts/sun8i-h3.dtsi
>> +++ b/arch/arm/boot/dts/sun8i-h3.dtsi
>> @@ -41,6 +41,8 @@
>>   */
>>
>>  #include "sunxi-h3-h5.dtsi"
>> +#include 
>> +#include 
>>
>>  / {
>> cpus {
>> @@ -72,6 +74,193 @@
>> };
>> };
>>
>> +   de: display-engine {
>> +   compatible = "allwinner,sun8i-h3-display-engine";
>> +   allwinner,pipelines = <>,
>> + <>;
>> +   status = "disabled";
>> +   };
>> +
>> +   soc {
>> +   display_clocks: clock@100 {
>> +   compatible = "allwinner,sun8i-a83t-de2-clk";
>> +   reg = <0x0100 0x10>;
>> +   clocks = < CLK_BUS_DE>,
>> +< CLK_DE>;
>> +   clock-names = "bus",
>> + "mod";
>> +   resets = < RST_BUS_DE>;
>> +   #clock-cells = <1>;
>> +   #reset-cells = <1>;
>> +   assigned-clocks = < CLK_DE>;
>> +   assigned-clock-parents = < CLK_PLL_DE>;
>> +   assigned-clock-rates = <43200>;
>> +   };
>> +
>> +   mixer0: mixer@110 {
>> +   compatible = "allwinner,sun8i-h3-de2-mixer0";
>> +   reg = <0x0110 0x10>;
>> +   clocks = <_clocks CLK_BUS_MIXER0>,
>> +<_clocks CLK_MIXER0>;
>> +   clock-names = "bus",
>> + "mod";
>> +   resets = <_clocks RST_MIXER0>;
>> +   status = "disabled";
>> +
>> +   ports {
>> +   #address-cells = <1>;
>> +   #size-cells = <0>;
>> +
>> +   mixer0_out: port@1 {
>> +   #address-cells = <1>;
>> +   #size-cells = <0>;
>> +   reg = <1>;
>> +
>> +   mixer0_out_tcon0: endpoint@0
>{
>> +   reg = <0>;
>> +   remote-endpoint =
><_in_mixer0>;
>> +   };
>> +
>> +   mixer0_out_tcon1: endpoint@1
>{
>> +   reg = <1>;
>> +   remote-endpoint =
><_in_mixer0>;
>> +   };
>> +   };
>> +   };
>> +   };
>> +
>> +   mixer1: mixer@120 {
>> +   compatible = "allwinner,sun8i-h3-de2-mixer1";
>> +   reg = <0x0120 0x10>;
>> +   clocks = <_clocks CLK_BUS_MIXER1>,
>> +<_clocks CLK_MIXER1>;
>> +   clock-names = "bus",
>> + "mod";
>> +   resets = <_clocks RST_WB>;
>> +
>> +   ports {
>> +   #address-cells = <1>;
>> +   #size-cells = <0>;
>> +
>> +   mixer1_out: port@1 {
>> +   #address-cells = <1>;
>> +   #size-cells = <0>;
>> +   reg = <1>;
>> +
>> +   mixer1_out_tcon1: endpoint@0
>{
>> +   reg = <0>;
>
>I would prefer if you could stick to the numbering scheme we're using
>for
>Display Engine 1.0, as in endpoint 0 links to component 0 of whatever
>type.

If we keep this we will need a ugly id property in mixer node,
otherwise we cannot know which TCON to be bind.

>
>We're probably going to stick to that for the R40's incredibly
>complicated
>pipeline. I don't want to have any outliers unless absolutely
>necessary.
>
>ChenYu
>
>> + 

Re: [PATCH] drm/panel: Add driver for Seiko 43WVF1G panel

[Marco Franchi]

Hi Thierry,


From: Fabio Estevam 
Sent: Monday, May 8, 2017 10:54 AM
To: Marco Franchi
Cc: DRI mailing list; Thierry Reding; robh...@kernel.org
Subject: Re: [PATCH] drm/panel: Add driver for Seiko 43WVF1G panel

On Tue, Apr 25, 2017 at 1:18 PM, Marco Franchi  wrote:
> Add driver for Seiko Instruments Inc. 4.3" WVGA (800 x RGB x 480)
> TFT with Touch-Panel.
>
> Datasheet available at:
> http://www.glyn.de/data/glyn/media/doc/43wvf1g-0.pdf
>
> Seiko 43WVF1G panel has two power supplies: AVDD and DVDD and they
> require a specific power on/down sequence.
> For this reason the simple panel driver cannot be used to drive this
> panel, so create a new one heavily based on simple panel.
>
> Based on initial patch submission from Breno Lima.
>
> Signed-off-by: Marco Franchi 

Works fine on a imx6sx-sdb board:

Tested-by: Fabio Estevam 


Any comments?
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [linux-sunxi] [RFC PATCH 10/11] ARM: sun8i: h3: add display engine pipeline for TVE

[Chen-Yu Tsai]

On Wed, May 24, 2017 at 1:28 PM, Icenowy Zheng  wrote:
>
>
> 于 2017年5月24日 GMT+08:00 下午1:24:29, Chen-Yu Tsai  写到:
>>On Thu, May 18, 2017 at 12:43 AM, Icenowy Zheng 
>>wrote:
>>> As we have already the support for the TV encoder on Allwinner H3,
>>add
>>> the display engine pipeline device tree nodes to its DTSI file.
>>>
>>> The H5 pipeline has some differences and will be enabled later.
>>>
>>> The currently-unused mixer0 and tcon0 are also needed, for the
>>> completement of the pipeline.
>>>
>>> Signed-off-by: Icenowy Zheng 
>>> ---
>>>  arch/arm/boot/dts/sun8i-h3.dtsi | 189
>>
>>>  1 file changed, 189 insertions(+)
>>>
>>> diff --git a/arch/arm/boot/dts/sun8i-h3.dtsi
>>b/arch/arm/boot/dts/sun8i-h3.dtsi
>>> index b36f9f423c39..20172ef92415 100644
>>> --- a/arch/arm/boot/dts/sun8i-h3.dtsi
>>> +++ b/arch/arm/boot/dts/sun8i-h3.dtsi
>>> @@ -41,6 +41,8 @@
>>>   */
>>>
>>>  #include "sunxi-h3-h5.dtsi"
>>> +#include 
>>> +#include 
>>>
>>>  / {
>>> cpus {
>>> @@ -72,6 +74,193 @@
>>> };
>>> };
>>>
>>> +   de: display-engine {
>>> +   compatible = "allwinner,sun8i-h3-display-engine";
>>> +   allwinner,pipelines = <>,
>>> + <>;
>>> +   status = "disabled";
>>> +   };
>>> +
>>> +   soc {
>>> +   display_clocks: clock@100 {
>>> +   compatible = "allwinner,sun8i-a83t-de2-clk";
>>> +   reg = <0x0100 0x10>;
>>> +   clocks = < CLK_BUS_DE>,
>>> +< CLK_DE>;
>>> +   clock-names = "bus",
>>> + "mod";
>>> +   resets = < RST_BUS_DE>;
>>> +   #clock-cells = <1>;
>>> +   #reset-cells = <1>;
>>> +   assigned-clocks = < CLK_DE>;
>>> +   assigned-clock-parents = < CLK_PLL_DE>;
>>> +   assigned-clock-rates = <43200>;
>>> +   };
>>> +
>>> +   mixer0: mixer@110 {
>>> +   compatible = "allwinner,sun8i-h3-de2-mixer0";
>>> +   reg = <0x0110 0x10>;
>>> +   clocks = <_clocks CLK_BUS_MIXER0>,
>>> +<_clocks CLK_MIXER0>;
>>> +   clock-names = "bus",
>>> + "mod";
>>> +   resets = <_clocks RST_MIXER0>;
>>> +   status = "disabled";
>>> +
>>> +   ports {
>>> +   #address-cells = <1>;
>>> +   #size-cells = <0>;
>>> +
>>> +   mixer0_out: port@1 {
>>> +   #address-cells = <1>;
>>> +   #size-cells = <0>;
>>> +   reg = <1>;
>>> +
>>> +   mixer0_out_tcon0: endpoint@0
>>{
>>> +   reg = <0>;
>>> +   remote-endpoint =
>><_in_mixer0>;
>>> +   };
>>> +
>>> +   mixer0_out_tcon1: endpoint@1
>>{
>>> +   reg = <1>;
>>> +   remote-endpoint =
>><_in_mixer0>;
>>> +   };
>>> +   };
>>> +   };
>>> +   };
>>> +
>>> +   mixer1: mixer@120 {
>>> +   compatible = "allwinner,sun8i-h3-de2-mixer1";
>>> +   reg = <0x0120 0x10>;
>>> +   clocks = <_clocks CLK_BUS_MIXER1>,
>>> +<_clocks CLK_MIXER1>;
>>> +   clock-names = "bus",
>>> + "mod";
>>> +   resets = <_clocks RST_WB>;
>>> +
>>> +   ports {
>>> +   #address-cells = <1>;
>>> +   #size-cells = <0>;
>>> +
>>> +   mixer1_out: port@1 {
>>> +   #address-cells = <1>;
>>> +   #size-cells = <0>;
>>> +   reg = <1>;
>>> +
>>> +   mixer1_out_tcon1: endpoint@0
>>{
>>> +   reg = <0>;
>>
>>I would prefer if you could stick to the numbering scheme we're using
>>for
>>Display Engine 1.0, as in endpoint 0 links to component 0 of whatever
>>type.
>
> If we keep this we will need a ugly id property in mixer node,
> otherwise we cannot know which TCON to be 

Re: [PATCH 2/3] drm/omap: displays: connector-hdmi: Support for hot plug detection

[Peter Ujfalusi]

On 2017-05-23 12:45, Laurent Pinchart wrote:
> Hi Peter,
> 
> Thank you for the patch.
> 
> On Monday 15 May 2017 12:03:11 Peter Ujfalusi wrote:
>> If the hpd_gpio is valid, use interrupt handler to react to HPD changes.
>> In case the hpd_gpio is not valid, try to enable hpd detection on the
>> encoder if it supports it.
>>
>> Signed-off-by: Peter Ujfalusi 
>> ---
>>  drivers/gpu/drm/omapdrm/displays/connector-hdmi.c | 104 +++
>>  1 file changed, 104 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/omapdrm/displays/connector-hdmi.c
>> b/drivers/gpu/drm/omapdrm/displays/connector-hdmi.c index
>> 1ef130641bae..3a90f89ada77 100644
>> --- a/drivers/gpu/drm/omapdrm/displays/connector-hdmi.c
>> +++ b/drivers/gpu/drm/omapdrm/displays/connector-hdmi.c
>> @@ -15,6 +15,7 @@
>>  #include 
>>  #include 
>>  #include 
>> +#include 
> 
> Did you mean linux/mutex.h ?

Oops, yes I mean linux/mutex.h.

>> +static irqreturn_t hdmic_hpd_isr(int irq, void *data)
>> +{
>> +struct panel_drv_data *ddata = data;
>> +
>> +mutex_lock(>hpd_lock);
>> +if (ddata->hpd_enabled && ddata->hpd_cb) {
>> +enum drm_connector_status status;
>> +
>> +if (hdmic_detect(>dssdev))
>> +status = connector_status_connected;
>> +else
>> +status = connector_status_disconnected;
>> +
>> +ddata->hpd_cb(ddata->hpd_cb_data, status);
>> +}
>> +mutex_unlock(>hpd_lock);
> 
> Shouldn't ddata->hpd_cb() be called without the mutex held ? I don't think 
> core code should rely on callers to handle locking in this case.

the mutex is for protecting the internal data of the driver (hpd_cb
mainly). W/o keeping the mutex there might be a chance that we are going
to get an unregister call (unlikely, but in theory it can happen) which
would NULL out the hpd_cb, if we save the hpd_cb and data while holding
the mux, it is possible that the  omap DRM driver was removed already
causing other type of crash.

> 
> 
>> +return IRQ_HANDLED;
>> +}
>> +
>>  static int hdmic_probe_of(struct platform_device *pdev)
>>  {
>>  struct panel_drv_data *ddata = platform_get_drvdata(pdev);
>> @@ -249,11 +342,22 @@ static int hdmic_probe(struct platform_device *pdev)
>>  if (r)
>>  return r;
>>
>> +mutex_init(>hpd_lock);
>> +
>>  if (gpio_is_valid(ddata->hpd_gpio)) {
>>  r = devm_gpio_request_one(>dev, ddata->hpd_gpio,
>>  GPIOF_DIR_IN, "hdmi_hpd");
>>  if (r)
>>  goto err_reg;
>> +
>> +r = devm_request_threaded_irq(>dev,
>> +gpio_to_irq(ddata->hpd_gpio),
> 
> What is hpd_gpio is valid but has no IRQ support ?
> 
>> +NULL, hdmic_hpd_isr,
>> +IRQF_TRIGGER_RISING | IRQF_TRIGGER_FALLING |
>> +IRQF_ONESHOT,
>> +"hdmic hpd", ddata);
>> +if (r)
>> +goto err_reg;
>>  }
>>
>>  ddata->vm = hdmic_default_vm;
> 

- Péter
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [linux-sunxi] Re: [RFC PATCH 07/11] drm: sun4i: add support for the TV encoder in H3 SoC

[Jernej Škrabec]

Hi,

Dne sreda, 24. maj 2017 ob 10:25:46 CEST je Icenowy Zheng napisal(a):
> 于 2017年5月24日 GMT+08:00 下午3:30:19, Maxime Ripard  写到:
> >On Tue, May 23, 2017 at 09:00:59PM +0800, icen...@aosc.io wrote:
> >> 在 2017-05-23 20:53，Maxime Ripard 写道：
> >> 
> >> > On Mon, May 22, 2017 at 07:55:56PM +0200, Jernej Škrabec wrote:
> >> > > Hi,
> >> > > 
> >> > > Dne sobota, 20. maj 2017 ob 03:37:53 CEST je Chen-Yu Tsai
> >
> >napisal(a):
> >> > > > On Sat, May 20, 2017 at 2:23 AM, Jernej Škrabec
> >
> >
> >
> >> > > wrote:
> >> > > > > Hi,
> >> > > > > 
> >> > > > > Dne petek, 19. maj 2017 ob 20:08:18 CEST je Icenowy Zheng
> >
> >napisal(a):
> >> > > > >> 于 2017年5月20日 GMT+08:00 上午2:03:30, Maxime Ripard
> >
> > >
> >> > > > > electrons.com> 写到:
> >> > > > >> >On Thu, May 18, 2017 at 12:43:50AM +0800, Icenowy Zheng
> >
> >wrote:
> >> > > > >> >> Allwinner H3 features a TV encoder similar to the one in
> >
> >earlier
> >
> >> > > > >> >SoCs,
> >> > > > >> >
> >> > > > >> >> but with some different points about clocks:
> >> > > > >> >> - It has a mod clock and a bus clock.
> >> > > > >> >> - The mod clock must be at a fixed rate to generate
> >
> >signal.
> >
> >> > > > >> >Why?
> >> > > > >> 
> >> > > > >> It's experiment result by Jernej.
> >> > > > >> 
> >> > > > >> The clock rates in BSP kernel is also specially designed
> >> > > > >> (PLL_DE at 432MHz) in order to be able to feed the TVE.
> >> > > > > 
> >> > > > > My experiments and search through BSP code showed that TVE
> >
> >seems to have
> >
> >> > > > > additional fixed predivider 8. So if you want to generate 27
> >
> >MHz clock,
> >
> >> > > > > unit has to be feed with 216 MHz.
> >> > > > > 
> >> > > > > TVE has only one PLL source PLL_DE. And since 216 MHz is a
> >
> >bit low for
> >
> >> > > > > DE2,
> >> > > > > BSP defaults to 432 MHz for PLL_DE and use divider 2 to
> >
> >generate 216 MHz.
> >
> >> > > > > This clock is then divided by 8 internaly to get final 27
> >
> >MHz.
> >
> >> > > > > Please note that I don't have any hard evidence to support
> >
> >that, only
> >
> >> > > > > experimental data. However, only that explanation make sense
> >
> >to me.
> >
> >> > > > > BTW, BSP H3/H5 TV driver supports only PAL and NTSC which
> >
> >both use 27 MHz
> >
> >> > > > > base clock. Further experiments are needed to check if there
> >
> >is any
> >
> >> > > > > possibility to have other resolutions by manipulating clocks
> >
> >and give
> >
> >> > > > > other proper settings. I plan to do that, but not in very
> >
> >near future.
> >
> >> > > > You only have composite video output, and those are the only 2
> >
> >standard
> >
> >> > > > resolutions that make any sense.
> >> > > 
> >> > > Right, other resolutions are for VGA.
> >> > > 
> >> > > Anyway, I did some more digging in A10 and R40 datasheets. I
> >
> >think
> >
> >> > > that H3 TVE
> >> > > unit is something in between. R40 TVE has a setting to select "up
> >> > > sample".
> >> > 
> >> > That might be just another translation of oversampling :)
> >> > 
> >> > I didn't know it could be applied to composite signals though, but
> >
> >I
> >
> >> > guess this is just another analog signal after all.
> >> > 
> >> > > Possible settings are 27 MHz, 54 MHz, 108 MHz and 216 MHz. BSP
> >> > > driver on R40
> >> > > has this setting enabled only for PAL and NTSC and it is always
> >
> >216
> >
> >> > > MHz. I
> >> > > think that H3 may have this hardwired to 216 MHz and this would
> >
> >be
> >
> >> > > the reason
> >> > > why 216 MHz is needed.
> >> > > 
> >> > > Has anyone else any better explanation?
> >> > 
> >> > That's already a pretty good one.
> >> > 
> >> > Either way, wether this is upsampling, oversampling or just a
> >> > pre-divider, this can and should be dealt with in the mode_set
> >> > callback, and not in the probe.
> >> 
> >> I got a better idea -- let TVE driver have the CLK_TVE as an
> >> input and create a subclock output with divider 16, and feed this
> >> subclock to TCON lcd-ch1.
> >> 
> >> This is a model of the real hardware -- the clock divider is in
> >> TVE, not TCON.

If we are talking about HW divider, it is 8 (216 / 27 = 8).

Slightly offtopic, reason why DE2 is hardcoded to 432 might be that for 4K 
resolution you need at least 297 MHz. So next dividable frequency is taken 
(432 MHz). That way you can have 4K HDMI display and composite TV connected at 
the same time, although this sounds a bit weird.

Best regards,
Jernej

> >
> >That's definitely not a good representation of the hardware. There's
> >one clock, it goes to the TCON, period.
> 
> No, I still think it goes to the TVE as:
> 
> 1. it's named TVE in datasheet.
> 2. Generating signal with such a low resolution but such
> a high dotclock is not a good situation.
> 
> >However, the TV encoder has a constraint on that clock rate. This can
> >be easily implemented using a custom encoder state where you'd set the
> >multiplier to set on 

[PATCH] drm/msm: constify irq_domain_ops

[Tobias Klauser]

struct irq_domain_ops is not modified, so it can be made const.

Signed-off-by: Tobias Klauser 
---
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_mdss.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_mdss.c 
b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_mdss.c
index f8f48d014978..9c34d7824988 100644
--- a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_mdss.c
+++ b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_mdss.c
@@ -116,7 +116,7 @@ static int mdss_hw_irqdomain_map(struct irq_domain *d, 
unsigned int irq,
return 0;
 }
 
-static struct irq_domain_ops mdss_hw_irqdomain_ops = {
+static const struct irq_domain_ops mdss_hw_irqdomain_ops = {
.map = mdss_hw_irqdomain_map,
.xlate = irq_domain_xlate_onecell,
 };
-- 
2.13.0


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

Re: linux-next: manual merge of the drm-misc tree with the drm-intel tree

[Stephen Rothwell]

Hi Dave,

Just cc'ing you as I guess you will need to fix this up at some point.

On Tue, 23 May 2017 12:00:32 +1000 Stephen Rothwell  
wrote:
>
> Hi all,
> 
> Today's linux-next merge of the drm-misc tree got a conflict in:
> 
>   drivers/gpu/drm/i915/intel_display.c
> 
> between commits:
> 
>   1cecc830e6b6 ("drm/i915: Refactor CURBASE calculation")
>   024faac7d59b ("drm/i915: Support variable cursor height on ivb+")
> 
> from the drm-intel tree and commit:
> 
>   c2c446ad2943 ("drm: Add DRM_MODE_ROTATE_ and DRM_MODE_REFLECT_ to UAPI")
> 
> from the drm-misc tree.
> 
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging.  You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.
> 
> -- 
> Cheers,
> Stephen Rothwell
> 
> diff --cc drivers/gpu/drm/i915/intel_display.c
> index 8217ed0e7132,6a037b856d96..
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@@ -9144,102 -9138,6 +9144,102 @@@ out
>   return active;
>   }
>   
>  +static u32 intel_cursor_base(const struct intel_plane_state *plane_state)
>  +{
>  +struct drm_i915_private *dev_priv =
>  +to_i915(plane_state->base.plane->dev);
>  +const struct drm_framebuffer *fb = plane_state->base.fb;
>  +const struct drm_i915_gem_object *obj = intel_fb_obj(fb);
>  +u32 base;
>  +
>  +if (INTEL_INFO(dev_priv)->cursor_needs_physical)
>  +base = obj->phys_handle->busaddr;
>  +else
>  +base = intel_plane_ggtt_offset(plane_state);
>  +
>  +base += plane_state->main.offset;
>  +
>  +/* ILK+ do this automagically */
>  +if (HAS_GMCH_DISPLAY(dev_priv) &&
> - plane_state->base.rotation & DRM_ROTATE_180)
> ++plane_state->base.rotation & DRM_MODE_ROTATE_180)
>  +base += (plane_state->base.crtc_h *
>  + plane_state->base.crtc_w - 1) * fb->format->cpp[0];
>  +
>  +return base;
>  +}
>  +
>  +static u32 intel_cursor_position(const struct intel_plane_state 
> *plane_state)
>  +{
>  +int x = plane_state->base.crtc_x;
>  +int y = plane_state->base.crtc_y;
>  +u32 pos = 0;
>  +
>  +if (x < 0) {
>  +pos |= CURSOR_POS_SIGN << CURSOR_X_SHIFT;
>  +x = -x;
>  +}
>  +pos |= x << CURSOR_X_SHIFT;
>  +
>  +if (y < 0) {
>  +pos |= CURSOR_POS_SIGN << CURSOR_Y_SHIFT;
>  +y = -y;
>  +}
>  +pos |= y << CURSOR_Y_SHIFT;
>  +
>  +return pos;
>  +}
>  +
>  +static bool intel_cursor_size_ok(const struct intel_plane_state 
> *plane_state)
>  +{
>  +const struct drm_mode_config *config =
>  +_state->base.plane->dev->mode_config;
>  +int width = plane_state->base.crtc_w;
>  +int height = plane_state->base.crtc_h;
>  +
>  +return width > 0 && width <= config->cursor_width &&
>  +height > 0 && height <= config->cursor_height;
>  +}
>  +
>  +static int intel_check_cursor(struct intel_crtc_state *crtc_state,
>  +  struct intel_plane_state *plane_state)
>  +{
>  +const struct drm_framebuffer *fb = plane_state->base.fb;
>  +int src_x, src_y;
>  +u32 offset;
>  +int ret;
>  +
>  +ret = drm_plane_helper_check_state(_state->base,
>  +   _state->clip,
>  +   DRM_PLANE_HELPER_NO_SCALING,
>  +   DRM_PLANE_HELPER_NO_SCALING,
>  +   true, true);
>  +if (ret)
>  +return ret;
>  +
>  +if (!fb)
>  +return 0;
>  +
>  +if (fb->modifier != DRM_FORMAT_MOD_LINEAR) {
>  +DRM_DEBUG_KMS("cursor cannot be tiled\n");
>  +return -EINVAL;
>  +}
>  +
>  +src_x = plane_state->base.src_x >> 16;
>  +src_y = plane_state->base.src_y >> 16;
>  +
>  +intel_add_fb_offsets(_x, _y, plane_state, 0);
>  +offset = intel_compute_tile_offset(_x, _y, plane_state, 0);
>  +
>  +if (src_x != 0 || src_y != 0) {
>  +DRM_DEBUG_KMS("Arbitrary cursor panning not supported\n");
>  +return -EINVAL;
>  +}
>  +
>  +plane_state->main.offset = offset;
>  +
>  +return 0;
>  +}
>  +
>   static u32 i845_cursor_ctl(const struct intel_crtc_state *crtc_state,
>  const struct intel_plane_state *plane_state)
>   {
> @@@ -9389,154 -9245,116 +9389,154 @@@ static u32 i9xx_cursor_ctl(const struc
>   return cntl;
>   }
>   
>  -static void i9xx_update_cursor(struct drm_crtc *crtc, u32 base,
>  -   const struct intel_plane_state *plane_state)
>  +static bool i9xx_cursor_size_ok(const struct intel_plane_state *plane_state)
>   {
> 

Re: [PATCH v5] dma-buf/sync-file: Defer creation of sync_file->name

[Gustavo Padovan]

2017-05-22 Daniel Vetter :

> On Tue, May 16, 2017 at 12:10:42PM +0100, Chris Wilson wrote:
> > Constructing the name takes the majority of the time for allocating a
> > sync_file to wrap a fence, and the name is very rarely used (only via
> > the sync_file status user interface). To reduce the impact on the common
> > path (that of creating sync_file to pass around), defer the construction
> > of the name until it is first used.
> > 
> > v2: Update kerneldoc (kbuild test robot)
> > v3: sync_debug.c was peeking at the name
> > v4: Comment upon the potential race between two users of
> > sync_file_get_name() and claim that such a race is below the level of
> > notice. However, to prevent any future nuisance, use a global spinlock
> > to serialize the assignment of the name.
> > v5: Completely avoid the read/write race by only storing the name passed
> > in from the user inside sync_file->user_name and passing in a buffer to
> > dynamically construct the name otherwise.
> > 
> > Signed-off-by: Chris Wilson 
> > Cc: Sumit Semwal 
> > Cc: Gustavo Padovan 
> > Cc: Daniel Vetter 
> > Cc: David Herrmann 
> > ---
> >  drivers/dma-buf/sync_debug.c |  4 +++-
> >  drivers/dma-buf/sync_file.c  | 39 ---
> >  include/linux/sync_file.h|  5 +++--
> >  3 files changed, 38 insertions(+), 10 deletions(-)
> > 
> > diff --git a/drivers/dma-buf/sync_debug.c b/drivers/dma-buf/sync_debug.c
> > index 4b1731ee7458..59a3b2f8ee91 100644
> > --- a/drivers/dma-buf/sync_debug.c
> > +++ b/drivers/dma-buf/sync_debug.c
> > @@ -132,9 +132,11 @@ static void sync_print_obj(struct seq_file *s, struct 
> > sync_timeline *obj)
> >  static void sync_print_sync_file(struct seq_file *s,
> >   struct sync_file *sync_file)
> >  {
> > +   char buf[128];
> > int i;
> >  
> > -   seq_printf(s, "[%p] %s: %s\n", sync_file, sync_file->name,
> > +   seq_printf(s, "[%p] %s: %s\n", sync_file,
> > +  sync_file_get_name(sync_file, buf, sizeof(buf)),
> >sync_status_str(dma_fence_get_status(sync_file->fence)));
> >  
> > if (dma_fence_is_array(sync_file->fence)) {
> > diff --git a/drivers/dma-buf/sync_file.c b/drivers/dma-buf/sync_file.c
> > index c9eb4997cfcc..d7e219d2669d 100644
> > --- a/drivers/dma-buf/sync_file.c
> > +++ b/drivers/dma-buf/sync_file.c
> > @@ -80,11 +80,6 @@ struct sync_file *sync_file_create(struct dma_fence 
> > *fence)
> >  
> > sync_file->fence = dma_fence_get(fence);
> >  
> > -   snprintf(sync_file->name, sizeof(sync_file->name), "%s-%s%llu-%d",
> > -fence->ops->get_driver_name(fence),
> > -fence->ops->get_timeline_name(fence), fence->context,
> > -fence->seqno);
> > -
> > return sync_file;
> >  }
> >  EXPORT_SYMBOL(sync_file_create);
> > @@ -129,6 +124,36 @@ struct dma_fence *sync_file_get_fence(int fd)
> >  }
> >  EXPORT_SYMBOL(sync_file_get_fence);
> >  
> > +/**
> > + * sync_file_get_name - get the name of the sync_file
> > + * @sync_file: sync_file to get the fence from
> > + * @buf:   destination buffer to copy sync_file name into
> > + * @len:   available size of destination buffer.
> > + *
> > + * Each sync_file may have a name assigned either by the user (when merging
> > + * sync_files together) or created from the fence it contains. In the 
> > latter
> > + * case construction of the name is deferred until use, and so requires
> > + * sync_file_get_name().
> > + *
> > + * Returns: a string representing the name.
> > + */
> > +char *sync_file_get_name(struct sync_file *sync_file, char *buf, int len)
> > +{
> > +   if (sync_file->user_name[0]) {
> > +   strlcpy(buf, sync_file->user_name, len);
> > +   } else {
> > +   struct dma_fence *fence = sync_file->fence;
> > +
> > +   snprintf(buf, len, "%s-%s%llu-%d",
> > +fence->ops->get_driver_name(fence),
> > +fence->ops->get_timeline_name(fence),
> > +fence->context,
> > +fence->seqno);
> > +   }
> > +
> > +   return buf;
> > +}
> > +
> >  static int sync_file_set_fence(struct sync_file *sync_file,
> >struct dma_fence **fences, int num_fences)
> >  {
> > @@ -266,7 +291,7 @@ static struct sync_file *sync_file_merge(const char 
> > *name, struct sync_file *a,
> > goto err;
> > }
> >  
> > -   strlcpy(sync_file->name, name, sizeof(sync_file->name));
> > +   strlcpy(sync_file->user_name, name, sizeof(sync_file->user_name));
> > return sync_file;
> >  
> >  err:
> > @@ -419,7 +444,7 @@ static long sync_file_ioctl_fence_info(struct sync_file 
> > *sync_file,
> > }
> >  
> >  no_fences:
> > -   strlcpy(info.name, sync_file->name, sizeof(info.name));
> > +   sync_file_get_name(sync_file, info.name, sizeof(info.name));
> > 

Re: [PATCH 20/29] sync_file.txt: standardize document format

[Gustavo Padovan]

Hi Mauro,

2017-05-18 Mauro Carvalho Chehab :

> Each text file under Documentation follows a different
> format. Some doesn't even have titles!
> 
> Change its representation to follow the adopted standard,
> using ReST markups for it to be parseable by Sphinx:
> - Use markup for document title and authorship;
> - Mark literal blocks;
> - Use a numbered list for references.
> 
> Signed-off-by: Mauro Carvalho Chehab 
> ---
>  Documentation/sync_file.txt | 23 +--
>  1 file changed, 13 insertions(+), 10 deletions(-)

We went ahead and applied this to drm-misc-next. Thanks.

Gustavo

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

Re: Maintaining small drm drivers

[Patrik Jakobsson]

On Wed, May 24, 2017 at 9:52 PM, Daniel Vetter  wrote:
> On Wed, May 24, 2017 at 6:57 PM, Patrik Jakobsson
>  wrote:
>> Hi Dave and Daniel,
>>
>> We had a little mishap this morning when I had pushed a fix for gma500
>> into drm-misc-fixes without first getting someone to review it. The
>> patch have been on the list for over a month and I don't feel like I
>> have enough karma to force someone to review it. Since I'm the only
>> one actively reviewing gma500 stuff I've effectively locked myself out
>> from submitting patches for the driver. Sure, sometimes others help
>> out and that is ofc appreciated.
>>
>> As you suggested Daniel, I could trade light-weight reviews with
>> someone else. At first it sounds reasonable but when I think about it
>> it's rather bad. Why should I sell my r-b tags cheap in order to get
>> patches into the driver I'm maintaining? This model seems broken.
>> Doing quick reviews because you trust the author is not a good idea.
>> It defeats the purpose and soils the value of your r-b tag (learned
>> from my own mistakes).
>>
>> In the case of gma500 I'm exaggerating the problem a bit but others
>> will run into the same issue at some point. So my question is, can we
>> scrap the requirements for an r-b tag in drivers with only one
>> continuously active developer or at least make it more "soft"? Other
>> ideas are welcome.
>
> I had a really long discussion about this topic in private with
> another maintainer who expressed some unhappiness about the drm-misc
> review model. Yes it looks a bit silly that you have to trade review,
> but in the end if you think it's necessary to review other
> submissions, then imo you also need to get your own patches reviewed
> or at least sanity-checked.

Thanks for replying Daniel.

I agree with your reasoning but we're looking at the problem from two
different perspectives. It's not silly to require review per se. My
patches also deserves review but the problem is that I cannot count on
getting it and I don't think I should be stealing time from others
(you included) who's time is better spent elsewhere.

Currently I get to choose between bad (patches without good review) or
worse (no patches at all). Unfortunately I cannot pick bad because of
the r-b tag requirement. Also, I review gma500 patches because it is
expected of me and because I can. Not because I think the quality is
worse than mine. I'd love to get reviews back but so far people just
drop their patches and run.

>
> That's why drm-intel, drm-misc and anything else I'll ever maintain
> will have a hard rule to never push my own stuff (or anyone else
> with commit rights) without review. No exceptions.

That works when dealing with i915 and drm core (and other bigger
drivers). You have a decent group of people who are technically
qualified with personal and professional incentives to review your
patches. It's easy to have high standards when they are not being
challenged.

On the gma500 team there's me and a bunch of frustrated users. What I
would like to do is to continue shrinking the codebase and fix up the
most obvious mistakes to make it more maintainable and let it live a
couple of more years. I will likely have some time to do that again
soon. Not because it's very important but because it's fun and makes a
small group of people happy. Adding a bunch of process to this makes
it less fun and reduces my output.

>
> In my opinion, as a maintainer of a part of the linux kernel your job
> is to be the steward of the code and contributors/community around it,
> not be the lord with special priviledges like being able to push
> unreviewed patches or nacking contributions just because you're the
> maintainer. And yes, part of the rules behind drm-misc is to make sure
> that even single-maintainer drivers do collaborate, because with most
> drivers sooner or later there will be other contributors.

Right now I'm the lord of a mess but with less privileges than the
contributors. They at least get their patches reviewed and included.
Sounds more like I'm the fool ;)

Sure, I can nack peoples patches but where's the fun in that. Nacking
is never the easy choice since it requires justification and thus more
work. I certainly don't see it as a privilege.

>
> So at least from my side, yes there's an agenda behind this all, and
> its intentional. It also seems to work reasonable well thus far, since
> worst case drm-misc maintainers serve as reviewers of last resort.

I understand there's an agenda and it makes sense from a "big drivers"
pov. After some thinking, I would prefer the "pull from layers of
trust" approach instead of "push through a very tightly tuned
process". The layers of trust model also works well (as we all know).
If maintainers feel they are getting overwhelmed with work we should
look at expanding the subsystem tree instead of inventing new ways to
handle things. Perhaps the solution to all of this is to just go back
to 

[Bug 100784] Fullscreen fade transitions in starsector run at a few frames per second

[bugzilla-daemon]

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

Jon  changed:

   What|Removed |Added

Version|17.0|17.1

--- Comment #3 from Jon  ---
Present in 17.1 too

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

Re: Maintaining small drm drivers

[Daniel Vetter]

Quick clarification.

On Wed, May 24, 2017 at 9:52 PM, Daniel Vetter  wrote:
> On Wed, May 24, 2017 at 6:57 PM, Patrik Jakobsson
>  wrote:
>> Hi Dave and Daniel,
>>
>> We had a little mishap this morning when I had pushed a fix for gma500
>> into drm-misc-fixes without first getting someone to review it. The
>> patch have been on the list for over a month and I don't feel like I
>> have enough karma to force someone to review it. Since I'm the only
>> one actively reviewing gma500 stuff I've effectively locked myself out
>> from submitting patches for the driver. Sure, sometimes others help
>> out and that is ofc appreciated.
>>
>> As you suggested Daniel, I could trade light-weight reviews with
>> someone else. At first it sounds reasonable but when I think about it
>> it's rather bad. Why should I sell my r-b tags cheap in order to get
>> patches into the driver I'm maintaining? This model seems broken.
>> Doing quick reviews because you trust the author is not a good idea.
>> It defeats the purpose and soils the value of your r-b tag (learned
>> from my own mistakes).

That's why we only require an acked-by tag for small drivers, it's not
a full review. So can't soil the value of your r-b tags. All the same
reasons still apply.
-Daniel

>> In the case of gma500 I'm exaggerating the problem a bit but others
>> will run into the same issue at some point. So my question is, can we
>> scrap the requirements for an r-b tag in drivers with only one
>> continuously active developer or at least make it more "soft"? Other
>> ideas are welcome.
>
> I had a really long discussion about this topic in private with
> another maintainer who expressed some unhappiness about the drm-misc
> review model. Yes it looks a bit silly that you have to trade review,
> but in the end if you think it's necessary to review other
> submissions, then imo you also need to get your own patches reviewed
> or at least sanity-checked.
>
> That's why drm-intel, drm-misc and anything else I'll ever maintain
> will have a hard rule to never push my own stuff (or anyone else
> with commit rights) without review. No exceptions.
>
> In my opinion, as a maintainer of a part of the linux kernel your job
> is to be the steward of the code and contributors/community around it,
> not be the lord with special priviledges like being able to push
> unreviewed patches or nacking contributions just because you're the
> maintainer. And yes, part of the rules behind drm-misc is to make sure
> that even single-maintainer drivers do collaborate, because with most
> drivers sooner or later there will be other contributors.
>
> So at least from my side, yes there's an agenda behind this all, and
> its intentional. It also seems to work reasonable well thus far, since
> worst case drm-misc maintainers serve as reviewers of last resort.
>
> Thanks, Daniel
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> +41 (0) 79 365 57 48 - http://blog.ffwll.ch



-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: Maintaining small drm drivers

[Daniel Vetter]

On Wed, May 24, 2017 at 6:57 PM, Patrik Jakobsson
 wrote:
> Hi Dave and Daniel,
>
> We had a little mishap this morning when I had pushed a fix for gma500
> into drm-misc-fixes without first getting someone to review it. The
> patch have been on the list for over a month and I don't feel like I
> have enough karma to force someone to review it. Since I'm the only
> one actively reviewing gma500 stuff I've effectively locked myself out
> from submitting patches for the driver. Sure, sometimes others help
> out and that is ofc appreciated.
>
> As you suggested Daniel, I could trade light-weight reviews with
> someone else. At first it sounds reasonable but when I think about it
> it's rather bad. Why should I sell my r-b tags cheap in order to get
> patches into the driver I'm maintaining? This model seems broken.
> Doing quick reviews because you trust the author is not a good idea.
> It defeats the purpose and soils the value of your r-b tag (learned
> from my own mistakes).
>
> In the case of gma500 I'm exaggerating the problem a bit but others
> will run into the same issue at some point. So my question is, can we
> scrap the requirements for an r-b tag in drivers with only one
> continuously active developer or at least make it more "soft"? Other
> ideas are welcome.

I had a really long discussion about this topic in private with
another maintainer who expressed some unhappiness about the drm-misc
review model. Yes it looks a bit silly that you have to trade review,
but in the end if you think it's necessary to review other
submissions, then imo you also need to get your own patches reviewed
or at least sanity-checked.

That's why drm-intel, drm-misc and anything else I'll ever maintain
will have a hard rule to never push my own stuff (or anyone else
with commit rights) without review. No exceptions.

In my opinion, as a maintainer of a part of the linux kernel your job
is to be the steward of the code and contributors/community around it,
not be the lord with special priviledges like being able to push
unreviewed patches or nacking contributions just because you're the
maintainer. And yes, part of the rules behind drm-misc is to make sure
that even single-maintainer drivers do collaborate, because with most
drivers sooner or later there will be other contributors.

So at least from my side, yes there's an agenda behind this all, and
its intentional. It also seems to work reasonable well thus far, since
worst case drm-misc maintainers serve as reviewers of last resort.

Thanks, Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 101160] Venus PRO R9 M265X amdgpu: ring 0 test failed

[bugzilla-daemon]

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

--- Comment #4 from mercuriete  ---
Created attachment 131473
  --> https://bugs.freedesktop.org/attachment.cgi?id=131473=edit
detail of addresses

I see some differences between radeon and amdgpu in the addreses
gpu addr cpu addr.

not sure if this is important.


another difference is "radeon: MSI limited to 32-bit"
this message doenst appear on amdgpu

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

[Bug 101160] Venus PRO R9 M265X amdgpu: ring 0 test failed

[bugzilla-daemon]

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

--- Comment #3 from mercuriete  ---
Created attachment 131472
  --> https://bugs.freedesktop.org/attachment.cgi?id=131472=edit
radeonsi dmesg

Only for comparison this is the dmesg when using radeonsi kernel driver.

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

Re: [PATCH v2 0/3] Cleanup evergreen/si IRQ handling code

[Alex Deucher]

On Sat, May 20, 2017 at 7:39 AM, Christian König
 wrote:
> Am 20.05.2017 um 01:48 schrieb Lyude:
>>
>> This is the first part of me going through and cleaning up the IRQ
>> handling
>> code for radeon, since after taking a look at it the other day while
>> trying to
>> debug something I realized basically all of the code was copy pasted
>> everywhere, and quite difficult to actually read through.
>>
>> Will come up with something for r600 and cik once I've got the chipsets on
>> hand
>> to test with.
>>
>> Lyude (3):
>>drm/radeon: Cleanup display interrupt handling for evergreen, si
>>drm/radeon: Cleanup HDMI audio interrupt handling for evergreen
>>drm/radeon: Cleanup pageflipping IRQ handling for evergreen, si
>
>
> I don't have time to do a line by line review, but what I saw looked very
> good to me.
>
> So the whole seres is Acked-by: Christian König .

Applied.  thanks!

Alex


>
> BTW: You don't want to take a look at the other hw generations as well?
>
> Regards,
> Christian.
>
>>
>>   drivers/gpu/drm/radeon/evergreen.c  | 943
>> ++--
>>   drivers/gpu/drm/radeon/radeon.h |  27 +-
>>   drivers/gpu/drm/radeon/radeon_irq_kms.c |  35 ++
>>   drivers/gpu/drm/radeon/si.c | 655 +-
>>   4 files changed, 344 insertions(+), 1316 deletions(-)
>>
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/radeon: Unbreak HPD handling for r600+

[Alex Deucher]

On Fri, May 12, 2017 at 2:56 AM, Christian König
 wrote:
> Am 12.05.2017 um 01:31 schrieb Lyude:
>>
>> We end up reading the interrupt register for HPD5, and then writing it
>> to HPD6 which on systems without anything using HPD5 results in
>> permanently disabling hotplug on one of the display outputs after the
>> first time we acknowledge a hotplug interrupt from the GPU.
>>
>> This code is really bad. But for now, let's just fix this. I will
>> hopefully have a large patch series to refactor all of this soon.
>>
>> Signed-off-by: Lyude 
>> Cc: sta...@vger.kernel.org
>
>
> Really nice catch! And yes I agree the copy code in HPD handling
> always scared me as well.
>
> Patch is Reviewed-by: Christian König .

Applied.  thanks!

Alex

>
> Christian.
>
>
>> ---
>>   drivers/gpu/drm/radeon/cik.c   | 4 ++--
>>   drivers/gpu/drm/radeon/evergreen.c | 4 ++--
>>   drivers/gpu/drm/radeon/r600.c  | 2 +-
>>   drivers/gpu/drm/radeon/si.c| 4 ++--
>>   4 files changed, 7 insertions(+), 7 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/radeon/cik.c b/drivers/gpu/drm/radeon/cik.c
>> index 53710dd..cfc917c 100644
>> --- a/drivers/gpu/drm/radeon/cik.c
>> +++ b/drivers/gpu/drm/radeon/cik.c
>> @@ -7401,7 +7401,7 @@ static inline void cik_irq_ack(struct radeon_device
>> *rdev)
>> WREG32(DC_HPD5_INT_CONTROL, tmp);
>> }
>> if (rdev->irq.stat_regs.cik.disp_int_cont5 & DC_HPD6_INTERRUPT) {
>> -   tmp = RREG32(DC_HPD5_INT_CONTROL);
>> +   tmp = RREG32(DC_HPD6_INT_CONTROL);
>> tmp |= DC_HPDx_INT_ACK;
>> WREG32(DC_HPD6_INT_CONTROL, tmp);
>> }
>> @@ -7431,7 +7431,7 @@ static inline void cik_irq_ack(struct radeon_device
>> *rdev)
>> WREG32(DC_HPD5_INT_CONTROL, tmp);
>> }
>> if (rdev->irq.stat_regs.cik.disp_int_cont5 & DC_HPD6_RX_INTERRUPT)
>> {
>> -   tmp = RREG32(DC_HPD5_INT_CONTROL);
>> +   tmp = RREG32(DC_HPD6_INT_CONTROL);
>> tmp |= DC_HPDx_RX_INT_ACK;
>> WREG32(DC_HPD6_INT_CONTROL, tmp);
>> }
>> diff --git a/drivers/gpu/drm/radeon/evergreen.c
>> b/drivers/gpu/drm/radeon/evergreen.c
>> index d1b1e0c..c48d19e 100644
>> --- a/drivers/gpu/drm/radeon/evergreen.c
>> +++ b/drivers/gpu/drm/radeon/evergreen.c
>> @@ -4933,7 +4933,7 @@ static void evergreen_irq_ack(struct radeon_device
>> *rdev)
>> WREG32(DC_HPD5_INT_CONTROL, tmp);
>> }
>> if (rdev->irq.stat_regs.evergreen.disp_int_cont5 &
>> DC_HPD6_INTERRUPT) {
>> -   tmp = RREG32(DC_HPD5_INT_CONTROL);
>> +   tmp = RREG32(DC_HPD6_INT_CONTROL);
>> tmp |= DC_HPDx_INT_ACK;
>> WREG32(DC_HPD6_INT_CONTROL, tmp);
>> }
>> @@ -4964,7 +4964,7 @@ static void evergreen_irq_ack(struct radeon_device
>> *rdev)
>> WREG32(DC_HPD5_INT_CONTROL, tmp);
>> }
>> if (rdev->irq.stat_regs.evergreen.disp_int_cont5 &
>> DC_HPD6_RX_INTERRUPT) {
>> -   tmp = RREG32(DC_HPD5_INT_CONTROL);
>> +   tmp = RREG32(DC_HPD6_INT_CONTROL);
>> tmp |= DC_HPDx_RX_INT_ACK;
>> WREG32(DC_HPD6_INT_CONTROL, tmp);
>> }
>> diff --git a/drivers/gpu/drm/radeon/r600.c b/drivers/gpu/drm/radeon/r600.c
>> index 0a08517..e06e2d8 100644
>> --- a/drivers/gpu/drm/radeon/r600.c
>> +++ b/drivers/gpu/drm/radeon/r600.c
>> @@ -3988,7 +3988,7 @@ static void r600_irq_ack(struct radeon_device *rdev)
>> WREG32(DC_HPD5_INT_CONTROL, tmp);
>> }
>> if (rdev->irq.stat_regs.r600.disp_int_cont2 &
>> DC_HPD6_INTERRUPT) {
>> -   tmp = RREG32(DC_HPD5_INT_CONTROL);
>> +   tmp = RREG32(DC_HPD6_INT_CONTROL);
>> tmp |= DC_HPDx_INT_ACK;
>> WREG32(DC_HPD6_INT_CONTROL, tmp);
>> }
>> diff --git a/drivers/gpu/drm/radeon/si.c b/drivers/gpu/drm/radeon/si.c
>> index 528e5a4..bfeb774 100644
>> --- a/drivers/gpu/drm/radeon/si.c
>> +++ b/drivers/gpu/drm/radeon/si.c
>> @@ -6330,7 +6330,7 @@ static inline void si_irq_ack(struct radeon_device
>> *rdev)
>> WREG32(DC_HPD5_INT_CONTROL, tmp);
>> }
>> if (rdev->irq.stat_regs.evergreen.disp_int_cont5 &
>> DC_HPD6_INTERRUPT) {
>> -   tmp = RREG32(DC_HPD5_INT_CONTROL);
>> +   tmp = RREG32(DC_HPD6_INT_CONTROL);
>> tmp |= DC_HPDx_INT_ACK;
>> WREG32(DC_HPD6_INT_CONTROL, tmp);
>> }
>> @@ -6361,7 +6361,7 @@ static inline void si_irq_ack(struct radeon_device
>> *rdev)
>> WREG32(DC_HPD5_INT_CONTROL, tmp);
>> }
>> if (rdev->irq.stat_regs.evergreen.disp_int_cont5 &
>> DC_HPD6_RX_INTERRUPT) {
>> -   tmp = RREG32(DC_HPD5_INT_CONTROL);
>> +   tmp = RREG32(DC_HPD6_INT_CONTROL);
>> 

[Bug 101160] Venus PRO R9 M265X amdgpu: ring 0 test failed

[bugzilla-daemon]

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

--- Comment #2 from mercuriete  ---
Created attachment 131471
  --> https://bugs.freedesktop.org/attachment.cgi?id=131471=edit
dmesg photo

Sorry I will upload a photo because the system freezes before init starts and
my disk being mounted.

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

Applied "ASoC: hdmi-codec: add .get_dai_id support" to the asoc tree

[Mark Brown]

The patch

   ASoC: hdmi-codec: add .get_dai_id support

has been applied to the asoc tree at

   git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git 

All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.  

You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.

If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.

Please add any relevant lists and maintainers to the CCs when replying
to this mail.

Thanks,
Mark

From 96203fb4237bf70f0fd0fa307ca2975077db3ceb Mon Sep 17 00:00:00 2001
From: Kuninori Morimoto 
Date: Thu, 18 May 2017 01:40:20 +
Subject: [PATCH] ASoC: hdmi-codec: add .get_dai_id support

ALSA SoC needs to know connected DAI ID for probing.
It is not a big problem if device/driver was only for sound,
but getting DAI ID will be difficult if device includes both
Video/Sound, like HDMI.
To solve this issue, this patch adds new .get_dai_id callback
on hdmi_codec_ops

Signed-off-by: Kuninori Morimoto 
Signed-off-by: Mark Brown 
---
 include/sound/hdmi-codec.h|  9 +
 sound/soc/codecs/hdmi-codec.c | 13 +
 2 files changed, 22 insertions(+)

diff --git a/include/sound/hdmi-codec.h b/include/sound/hdmi-codec.h
index 915c4357945c..9483c55f871b 100644
--- a/include/sound/hdmi-codec.h
+++ b/include/sound/hdmi-codec.h
@@ -18,9 +18,11 @@
 #ifndef __HDMI_CODEC_H__
 #define __HDMI_CODEC_H__
 
+#include 
 #include 
 #include 
 #include 
+#include 
 #include 
 
 /*
@@ -87,6 +89,13 @@ struct hdmi_codec_ops {
 */
int (*get_eld)(struct device *dev, void *data,
   uint8_t *buf, size_t len);
+
+   /*
+* Getting DAI ID
+* Optional
+*/
+   int (*get_dai_id)(struct snd_soc_component *comment,
+ struct device_node *endpoint);
 };
 
 /* HDMI codec initalization data */
diff --git a/sound/soc/codecs/hdmi-codec.c b/sound/soc/codecs/hdmi-codec.c
index 8659b76b066a..6d05161b625d 100644
--- a/sound/soc/codecs/hdmi-codec.c
+++ b/sound/soc/codecs/hdmi-codec.c
@@ -719,6 +719,18 @@ static const struct snd_soc_dai_driver hdmi_spdif_dai = {
.pcm_new = hdmi_codec_pcm_new,
 };
 
+static int hdmi_of_xlate_dai_id(struct snd_soc_component *component,
+struct device_node *endpoint)
+{
+   struct hdmi_codec_priv *hcp = snd_soc_component_get_drvdata(component);
+   int ret = -ENOTSUPP; /* see snd_soc_get_dai_id() */
+
+   if (hcp->hcd.ops->get_dai_id)
+   ret = hcp->hcd.ops->get_dai_id(component, endpoint);
+
+   return ret;
+}
+
 static struct snd_soc_codec_driver hdmi_codec = {
.component_driver = {
.controls   = hdmi_controls,
@@ -727,6 +739,7 @@ static struct snd_soc_codec_driver hdmi_codec = {
.num_dapm_widgets   = ARRAY_SIZE(hdmi_widgets),
.dapm_routes= hdmi_routes,
.num_dapm_routes= ARRAY_SIZE(hdmi_routes),
+   .of_xlate_dai_id= hdmi_of_xlate_dai_id,
},
 };
 
-- 
2.11.0

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

Applied "ASoC: hdmi-codec: remove multi detection support" to the asoc tree

[Mark Brown]

The patch

   ASoC: hdmi-codec: remove multi detection support

has been applied to the asoc tree at

   git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git 

All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.  

You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.

If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.

Please add any relevant lists and maintainers to the CCs when replying
to this mail.

Thanks,
Mark

From 24069b589b02cc1292761b0f72623dd50ad1e19c Mon Sep 17 00:00:00 2001
From: Kuninori Morimoto 
Date: Thu, 18 May 2017 01:40:02 +
Subject: [PATCH] ASoC: hdmi-codec: remove multi detection support

DesignWare HDMI driver (= dw-hdmi) is supporting HDMI sound, and its
probe function was calling sound binding function multiple times as
same HDMI device different port.

Because of this behavior, commit 9731f82d601 ("ASoC: hdmi-codec: enable
multi probe for ...") was added for multi detection case.
But, this DesignWare HDMI detection/bind code was exchanged/adjusted by
commit 69497eb9234 ("drm: bridge: dw-hdmi: Implement DRM bridge...").
Now, all DesignWare HDMI sound ports are detected as 1 bindng function.

Because of this, hdmi-codec multi detection support is no longer needed.
Thus, this patch removes
commit 9731f82d601 ("ASoC: hdmi-codec: enable multi probe for ..."),
and its related
commit 340327a62c4 ("ASoC: hdmi-codec: Fix hdmi_of_xlate_dai_name...")
commit 8480ac56795 ("ASoC: hdmi-codec: remove HDMI device unregister")
commit 0c343a35bfe ("ASoC: hdmi-codec: fix spelling mistake: ...)

Signed-off-by: Kuninori Morimoto 
Signed-off-by: Mark Brown 
---
 sound/soc/codecs/hdmi-codec.c | 88 ++-
 1 file changed, 3 insertions(+), 85 deletions(-)

diff --git a/sound/soc/codecs/hdmi-codec.c b/sound/soc/codecs/hdmi-codec.c
index a3f15149afcf..8659b76b066a 100644
--- a/sound/soc/codecs/hdmi-codec.c
+++ b/sound/soc/codecs/hdmi-codec.c
@@ -25,17 +25,6 @@
 
 #include  /* This is only to get MAX_ELD_BYTES */
 
-struct hdmi_device {
-   struct device *dev;
-   struct list_head list;
-   int cnt;
-};
-#define pos_to_hdmi_device(pos)container_of((pos), struct hdmi_device, 
list)
-LIST_HEAD(hdmi_device_list);
-static DEFINE_MUTEX(hdmi_mutex);
-
-#define DAI_NAME_SIZE 16
-
 #define HDMI_CODEC_CHMAP_IDX_UNKNOWN  -1
 
 struct hdmi_codec_channel_map_table {
@@ -702,6 +691,7 @@ static int hdmi_codec_pcm_new(struct snd_soc_pcm_runtime 
*rtd,
 }
 
 static struct snd_soc_dai_driver hdmi_i2s_dai = {
+   .name = "i2s-hifi",
.id = DAI_ID_I2S,
.playback = {
.stream_name = "Playback",
@@ -716,6 +706,7 @@ static struct snd_soc_dai_driver hdmi_i2s_dai = {
 };
 
 static const struct snd_soc_dai_driver hdmi_spdif_dai = {
+   .name = "spdif-hifi",
.id = DAI_ID_SPDIF,
.playback = {
.stream_name = "Playback",
@@ -728,32 +719,6 @@ static const struct snd_soc_dai_driver hdmi_spdif_dai = {
.pcm_new = hdmi_codec_pcm_new,
 };
 
-static char hdmi_dai_name[][DAI_NAME_SIZE] = {
-   "hdmi-hifi.0",
-   "hdmi-hifi.1",
-   "hdmi-hifi.2",
-   "hdmi-hifi.3",
-};
-
-static int hdmi_of_xlate_dai_name(struct snd_soc_component *component,
- struct of_phandle_args *args,
- const char **dai_name)
-{
-   int id;
-
-   if (args->args_count)
-   id = args->args[0];
-   else
-   id = 0;
-
-   if (id < ARRAY_SIZE(hdmi_dai_name)) {
-   *dai_name = hdmi_dai_name[id];
-   return 0;
-   }
-
-   return -EAGAIN;
-}
-
 static struct snd_soc_codec_driver hdmi_codec = {
.component_driver = {
.controls   = hdmi_controls,
@@ -762,7 +727,6 @@ static struct snd_soc_codec_driver hdmi_codec = {
.num_dapm_widgets   = ARRAY_SIZE(hdmi_widgets),
.dapm_routes= hdmi_routes,
.num_dapm_routes= ARRAY_SIZE(hdmi_routes),
-   .of_xlate_dai_name  = hdmi_of_xlate_dai_name,
},
 };
 
@@ -771,8 +735,6 @@ static int hdmi_codec_probe(struct platform_device *pdev)
struct hdmi_codec_pdata *hcd = pdev->dev.platform_data;
struct device *dev = >dev;
struct hdmi_codec_priv *hcp;
-   struct hdmi_device *hd;
-   struct list_head *pos;
int 

Applied "ASoC: simple-card-utils: support snd_soc_get_dai_id()" to the asoc tree

[Mark Brown]

The patch

   ASoC: simple-card-utils: support snd_soc_get_dai_id()

has been applied to the asoc tree at

   git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git 

All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.  

You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.

If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.

Please add any relevant lists and maintainers to the CCs when replying
to this mail.

Thanks,
Mark

From 73b17f1a65c881fcf97109d77056006da2d40152 Mon Sep 17 00:00:00 2001
From: Kuninori Morimoto 
Date: Thu, 18 May 2017 01:39:44 +
Subject: [PATCH] ASoC: simple-card-utils: support snd_soc_get_dai_id()

ALSA SoC needs to know connected DAI ID for detecting.
It is not a big problem if device/driver was only for sound,
but getting DAI ID will be difficult if device includes both
Video/Sound, like HDMI.
To solve this issue, this patch adds new snd_soc_get_dai_id() and
its related .of_xlate_dai_id callback on component driver.
In below case, we can handle Sound port (= port@2) as ID = 0
if .of_xlate_dai_id has its support.

hdmi {
port@0 { /* VIDEO */ };
port@1 { /* VIDEO */ };
port@2 { /* SOUND */ };
};

Signed-off-by: Kuninori Morimoto 
Signed-off-by: Mark Brown 
---
 sound/soc/generic/simple-card-utils.c | 9 +
 1 file changed, 9 insertions(+)

diff --git a/sound/soc/generic/simple-card-utils.c 
b/sound/soc/generic/simple-card-utils.c
index 5a3d51e45938..fe726e83d0bd 100644
--- a/sound/soc/generic/simple-card-utils.c
+++ b/sound/soc/generic/simple-card-utils.c
@@ -177,9 +177,18 @@ static int asoc_simple_card_get_dai_id(struct device_node 
*ep)
struct device_node *node;
struct device_node *endpoint;
int i, id;
+   int ret;
+
+   ret = snd_soc_get_dai_id(ep);
+   if (ret != -ENOTSUPP)
+   return ret;
 
node = of_graph_get_port_parent(ep);
 
+   /*
+* Non HDMI sound case, counting port/endpoint on its DT
+* is enough. Let's count it.
+*/
i = 0;
id = -1;
for_each_endpoint_of_node(node, endpoint) {
-- 
2.11.0

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

Applied "ASoC: add snd_soc_get_dai_id() function" to the asoc tree

[Mark Brown]

The patch

   ASoC: add snd_soc_get_dai_id() function

has been applied to the asoc tree at

   git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git 

All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.  

You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.

If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.

Please add any relevant lists and maintainers to the CCs when replying
to this mail.

Thanks,
Mark

From a180e8b988437b3e84a1b501ac4d073467602ca6 Mon Sep 17 00:00:00 2001
From: Kuninori Morimoto 
Date: Thu, 18 May 2017 01:39:25 +
Subject: [PATCH] ASoC: add snd_soc_get_dai_id() function

ALSA SoC needs to know connected DAI ID for detecting.
It is not a big problem if device/driver was only for sound,
but getting DAI ID will be difficult if device includes both
Video/Sound, like HDMI.
To solve this issue, this patch adds new snd_soc_get_dai_id() and
its related .of_xlate_dai_id callback on component driver.
In below case, we can handle Sound port (= port@2) as ID = 0
if .of_xlate_dai_id has its support.

hdmi {
port@0 { /* VIDEO */ };
port@1 { /* VIDEO */ };
port@2 { /* SOUND */ };
};

Signed-off-by: Kuninori Morimoto 
Signed-off-by: Mark Brown 
---
 include/sound/soc.h  |  3 +++
 sound/soc/soc-core.c | 37 +
 2 files changed, 40 insertions(+)

diff --git a/include/sound/soc.h b/include/sound/soc.h
index 5170fd81e1fd..9c94b97c17f8 100644
--- a/include/sound/soc.h
+++ b/include/sound/soc.h
@@ -803,6 +803,8 @@ struct snd_soc_component_driver {
int (*of_xlate_dai_name)(struct snd_soc_component *component,
 struct of_phandle_args *args,
 const char **dai_name);
+   int (*of_xlate_dai_id)(struct snd_soc_component *comment,
+  struct device_node *endpoint);
void (*seq_notifier)(struct snd_soc_component *, enum snd_soc_dapm_type,
int subseq);
int (*stream_event)(struct snd_soc_component *, int event);
@@ -1676,6 +1678,7 @@ unsigned int snd_soc_of_parse_daifmt(struct device_node 
*np,
 const char *prefix,
 struct device_node **bitclkmaster,
 struct device_node **framemaster);
+int snd_soc_get_dai_id(struct device_node *ep);
 int snd_soc_get_dai_name(struct of_phandle_args *args,
 const char **dai_name);
 int snd_soc_of_get_dai_name(struct device_node *of_node,
diff --git a/sound/soc/soc-core.c b/sound/soc/soc-core.c
index aae099c0e502..b0fb17082691 100644
--- a/sound/soc/soc-core.c
+++ b/sound/soc/soc-core.c
@@ -34,6 +34,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -4044,6 +4045,42 @@ unsigned int snd_soc_of_parse_daifmt(struct device_node 
*np,
 }
 EXPORT_SYMBOL_GPL(snd_soc_of_parse_daifmt);
 
+int snd_soc_get_dai_id(struct device_node *ep)
+{
+   struct snd_soc_component *pos;
+   struct device_node *node;
+   int ret;
+
+   node = of_graph_get_port_parent(ep);
+
+   /*
+* For example HDMI case, HDMI has video/sound port,
+* but ALSA SoC needs sound port number only.
+* Thus counting HDMI DT port/endpoint doesn't work.
+* Then, it should have .of_xlate_dai_id
+*/
+   ret = -ENOTSUPP;
+   mutex_lock(_mutex);
+   list_for_each_entry(pos, _list, list) {
+   struct device_node *component_of_node = pos->dev->of_node;
+
+   if (!component_of_node && pos->dev->parent)
+   component_of_node = pos->dev->parent->of_node;
+
+   if (component_of_node != node)
+   continue;
+
+   if (pos->driver->of_xlate_dai_id)
+   ret = pos->driver->of_xlate_dai_id(pos, ep);
+
+   break;
+   }
+   mutex_unlock(_mutex);
+
+   return ret;
+}
+EXPORT_SYMBOL_GPL(snd_soc_get_dai_id);
+
 int snd_soc_get_dai_name(struct of_phandle_args *args,
const char **dai_name)
 {
-- 
2.11.0

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

Re: [PATCH 5/5] drm: dw-hdmi-i2s: add .get_dai_id callback for ALSA SoC

[Mark Brown]

On Thu, May 18, 2017 at 01:40:47AM +, Kuninori Morimoto wrote:

> ALSA SoC needs to know connected DAI ID for probing.
> It is not a big problem if device/driver was only for sound,
> but getting DAI ID will be difficult if device includes both
> Video/Sound, like HDMI.

As far as I understand what's going on with the graph code this seems to
make sense to me.  How do we want to go about handling the patch?


signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 3/5] drm/syncobj: add sync_file interaction.

[Jason Ekstrand]

Yes, I believe this is the proper way for sync_file and syncobj to
interact.  Again, I can't really review for all of the kernel details
(though the seem ok to me) so this mostly applies to the API:

Reviewed-by: Jason Ekstrand 

On Wed, May 24, 2017 at 12:06 AM, Dave Airlie  wrote:

> From: Dave Airlie 
>
> This interface allows importing the fence from a sync_file into
> an existing drm sync object, or exporting the fence attached to
> an existing drm sync object into a new sync file object.
>
> This should only be used to interact with sync files where necessary.
>
> Reviewed-by: Sean Paul 
> Signed-off-by: Dave Airlie 
> ---
>  drivers/gpu/drm/drm_syncobj.c | 64 ++
> +++--
>  include/uapi/drm/drm.h|  2 ++
>  2 files changed, 64 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_syncobj.c b/drivers/gpu/drm/drm_syncobj.c
> index 8b87594..54d751e 100644
> --- a/drivers/gpu/drm/drm_syncobj.c
> +++ b/drivers/gpu/drm/drm_syncobj.c
> @@ -50,6 +50,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>
>  #include "drm_internal.h"
>  #include 
> @@ -276,6 +277,48 @@ static int drm_syncobj_fd_to_handle(struct drm_file
> *file_private,
> return 0;
>  }
>
> +int drm_syncobj_import_sync_file_fence(struct drm_file *file_private,
> +  int fd, int handle)
> +{
> +   struct dma_fence *fence = sync_file_get_fence(fd);
> +   if (!fence)
> +   return -EINVAL;
> +
> +   return drm_syncobj_replace_fence(file_private, handle, fence);
> +}
> +
> +int drm_syncobj_export_sync_file(struct drm_file *file_private,
> +int handle, int *p_fd)
> +{
> +   int ret;
> +   struct dma_fence *fence;
> +   struct sync_file *sync_file;
> +   int fd = get_unused_fd_flags(O_CLOEXEC);
> +
> +   if (fd < 0)
> +   return fd;
> +
> +   ret = drm_syncobj_fence_get(file_private, handle, );
> +   if (ret)
> +   goto err_put_fd;
> +
> +   sync_file = sync_file_create(fence);
> +   if (!sync_file) {
> +   ret = -EINVAL;
> +   goto err_fence_put;
> +   }
> +
> +   fd_install(fd, sync_file->file);
> +
> +   dma_fence_put(fence);
> +   *p_fd = fd;
> +   return 0;
> +err_fence_put:
> +   dma_fence_put(fence);
> +err_put_fd:
> +   put_unused_fd(fd);
> +   return ret;
> +}
>  /**
>   * drm_syncobj_open - initalizes syncobj file-private structures at
> devnode open time
>   * @dev: drm_device which is being opened by userspace
> @@ -358,9 +401,17 @@ drm_syncobj_handle_to_fd_ioctl(struct drm_device
> *dev, void *data,
> if (!drm_core_check_feature(dev, DRIVER_SYNCOBJ))
> return -ENODEV;
>
> -   if (args->pad || args->flags)
> +   if (args->pad)
> +   return -EINVAL;
> +
> +   if (args->flags != 0 &&
> +   args->flags != DRM_SYNCOBJ_HANDLE_TO_FD_
> FLAGS_EXPORT_FENCE_SYNC_FILE)
> return -EINVAL;
>
> +   if (args->flags & DRM_SYNCOBJ_HANDLE_TO_FD_
> FLAGS_EXPORT_FENCE_SYNC_FILE)
> +   return drm_syncobj_export_sync_file(file_private,
> args->handle,
> +   >fd);
> +
> return drm_syncobj_handle_to_fd(file_private, args->handle,
> >fd);
>  }
> @@ -374,9 +425,18 @@ drm_syncobj_fd_to_handle_ioctl(struct drm_device
> *dev, void *data,
> if (!drm_core_check_feature(dev, DRIVER_SYNCOBJ))
> return -ENODEV;
>
> -   if (args->pad || args->flags)
> +   if (args->pad)
> return -EINVAL;
>
> +   if (args->flags != 0 &&
> +   args->flags != DRM_SYNCOBJ_FD_TO_HANDLE_
> FLAGS_IMPORT_SYNC_FILE_FENCE)
> +   return -EINVAL;
> +
> +   if (args->flags & DRM_SYNCOBJ_FD_TO_HANDLE_
> FLAGS_IMPORT_SYNC_FILE_FENCE)
> +   return drm_syncobj_import_sync_file_fence(file_private,
> + args->fd,
> + args->handle);
> +
> return drm_syncobj_fd_to_handle(file_private, args->fd,
> >handle);
>  }
> diff --git a/include/uapi/drm/drm.h b/include/uapi/drm/drm.h
> index d6e2f62..94c75be 100644
> --- a/include/uapi/drm/drm.h
> +++ b/include/uapi/drm/drm.h
> @@ -708,6 +708,8 @@ struct drm_syncobj_destroy {
> __u32 pad;
>  };
>
> +#define DRM_SYNCOBJ_FD_TO_HANDLE_FLAGS_IMPORT_SYNC_FILE_FENCE (1 << 0)
> +#define DRM_SYNCOBJ_HANDLE_TO_FD_FLAGS_EXPORT_FENCE_SYNC_FILE (1 << 0)
>  struct drm_syncobj_handle {
> __u32 handle;
> __u32 flags;
> --
> 2.9.4
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> 

Re: [PATCH 1/5] drm: introduce sync objects (v3)

[Jason Ekstrand]

I can't really review for all of the kernel details (though the seem ok to
me) so this mostly applies to the API:

Reviewed-by: Jason Ekstrand 

On Wed, May 24, 2017 at 12:06 AM, Dave Airlie  wrote:

> From: Dave Airlie 
>
> Sync objects are new toplevel drm object, that contain a
> pointer to a fence. This fence can be updated via command
> submission ioctls via drivers.
>
> There is also a generic wait obj API modelled on the vulkan
> wait API (with code modelled on some amdgpu code).
>
> These objects can be converted to an opaque fd that can be
> passes between processes.
>
> v2: rename reference/unreference to put/get (Chris)
> fix leaked reference (David Zhou)
> drop mutex in favour of cmpxchg (Chris)
> v3: cleanups from danvet, rebase on drm_fops rename
> check fd_flags is 0 in ioctls.
>
> Reviewed-by: Sean Paul 
> Signed-off-by: Dave Airlie 
> ---
>  Documentation/gpu/drm-internals.rst |   3 +
>  Documentation/gpu/drm-mm.rst|  12 ++
>  drivers/gpu/drm/Makefile|   2 +-
>  drivers/gpu/drm/drm_file.c  |   8 +
>  drivers/gpu/drm/drm_internal.h  |  13 ++
>  drivers/gpu/drm/drm_ioctl.c |  12 ++
>  drivers/gpu/drm/drm_syncobj.c   | 377 ++
> ++
>  include/drm/drmP.h  |   1 -
>  include/drm/drm_drv.h   |   1 +
>  include/drm/drm_file.h  |   5 +
>  include/drm/drm_syncobj.h   |  87 +
>  include/uapi/drm/drm.h  |  24 +++
>  12 files changed, 543 insertions(+), 2 deletions(-)
>  create mode 100644 drivers/gpu/drm/drm_syncobj.c
>  create mode 100644 include/drm/drm_syncobj.h
>
> diff --git a/Documentation/gpu/drm-internals.rst b/Documentation/gpu/drm-
> internals.rst
> index babfb61..2b23d78 100644
> --- a/Documentation/gpu/drm-internals.rst
> +++ b/Documentation/gpu/drm-internals.rst
> @@ -98,6 +98,9 @@ DRIVER_ATOMIC
>  implement appropriate obj->atomic_get_property() vfuncs for any
>  modeset objects with driver specific properties.
>
> +DRIVER_SYNCOBJ
> +Driver support drm sync objects.
> +
>  Major, Minor and Patchlevel
>  ~~~
>
> diff --git a/Documentation/gpu/drm-mm.rst b/Documentation/gpu/drm-mm.rst
> index 96b9c34..9412798 100644
> --- a/Documentation/gpu/drm-mm.rst
> +++ b/Documentation/gpu/drm-mm.rst
> @@ -484,3 +484,15 @@ DRM Cache Handling
>
>  .. kernel-doc:: drivers/gpu/drm/drm_cache.c
> :export:
> +
> +DRM Sync Objects
> +===
> +
> +.. kernel-doc:: drivers/gpu/drm/drm_syncobj.c
> +   :doc: Overview
> +
> +.. kernel-doc:: include/drm/drm_syncobj.h
> +   :export:
> +
> +.. kernel-doc:: drivers/gpu/drm/drm_syncobj.c
> +   :export:
> diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
> index 59f0f9b..6f42188 100644
> --- a/drivers/gpu/drm/Makefile
> +++ b/drivers/gpu/drm/Makefile
> @@ -16,7 +16,7 @@ drm-y   :=drm_auth.o drm_bufs.o drm_cache.o \
> drm_framebuffer.o drm_connector.o drm_blend.o \
> drm_encoder.o drm_mode_object.o drm_property.o \
> drm_plane.o drm_color_mgmt.o drm_print.o \
> -   drm_dumb_buffers.o drm_mode_config.o
> +   drm_dumb_buffers.o drm_mode_config.o drm_syncobj.o
>
>  drm-$(CONFIG_DRM_LIB_RANDOM) += lib/drm_random.o
>  drm-$(CONFIG_DRM_VM) += drm_vm.o
> diff --git a/drivers/gpu/drm/drm_file.c b/drivers/gpu/drm/drm_file.c
> index 3783b65..a20d6a9 100644
> --- a/drivers/gpu/drm/drm_file.c
> +++ b/drivers/gpu/drm/drm_file.c
> @@ -229,6 +229,9 @@ static int drm_open_helper(struct file *filp, struct
> drm_minor *minor)
> if (drm_core_check_feature(dev, DRIVER_GEM))
> drm_gem_open(dev, priv);
>
> +   if (drm_core_check_feature(dev, DRIVER_SYNCOBJ))
> +   drm_syncobj_open(priv);
> +
> if (drm_core_check_feature(dev, DRIVER_PRIME))
> drm_prime_init_file_private(>prime);
>
> @@ -276,6 +279,8 @@ static int drm_open_helper(struct file *filp, struct
> drm_minor *minor)
>  out_prime_destroy:
> if (drm_core_check_feature(dev, DRIVER_PRIME))
> drm_prime_destroy_file_private(>prime);
> +   if (drm_core_check_feature(dev, DRIVER_SYNCOBJ))
> +   drm_syncobj_release(priv);
> if (drm_core_check_feature(dev, DRIVER_GEM))
> drm_gem_release(dev, priv);
> put_pid(priv->pid);
> @@ -398,6 +403,9 @@ int drm_release(struct inode *inode, struct file *filp)
> drm_property_destroy_user_blobs(dev, file_priv);
> }
>
> +   if (drm_core_check_feature(dev, DRIVER_SYNCOBJ))
> +   drm_syncobj_release(file_priv);
> +
> if (drm_core_check_feature(dev, DRIVER_GEM))
> drm_gem_release(dev, file_priv);
>
> diff --git a/drivers/gpu/drm/drm_internal.h b/drivers/gpu/drm/drm_
> internal.h
> index 3d8e8f8..3fdef2c 100644
> --- 

Re: [PATCH 2/5] drm/syncobj: add sync obj wait interface. (v3)

[Jason Ekstrand]

On Wed, May 24, 2017 at 10:25 AM, Jason Ekstrand 
wrote:

> On Wed, May 24, 2017 at 12:06 AM, Dave Airlie  wrote:
>
>> From: Dave Airlie 
>>
>> This interface will allow sync object to be used to back
>> Vulkan fences. This API is pretty much the vulkan fence waiting
>> API, and I've ported the code from amdgpu.
>>
>> v2: accept relative timeout, pass remaining time back
>> to userspace.
>> v3: return to absolute timeouts.
>>
>> Signed-off-by: Dave Airlie 
>> ---
>>  drivers/gpu/drm/drm_internal.h |   2 +
>>  drivers/gpu/drm/drm_ioctl.c|   2 +
>>  drivers/gpu/drm/drm_syncobj.c  | 164 ++
>> +++
>>  include/uapi/drm/drm.h |  14 
>>  4 files changed, 182 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/drm_internal.h
>> b/drivers/gpu/drm/drm_internal.h
>> index 3fdef2c..53e3f6b 100644
>> --- a/drivers/gpu/drm/drm_internal.h
>> +++ b/drivers/gpu/drm/drm_internal.h
>> @@ -156,3 +156,5 @@ int drm_syncobj_handle_to_fd_ioctl(struct drm_device
>> *dev, void *data,
>>struct drm_file *file_private);
>>  int drm_syncobj_fd_to_handle_ioctl(struct drm_device *dev, void *data,
>>struct drm_file *file_private);
>> +int drm_syncobj_wait_ioctl(struct drm_device *dev, void *data,
>> +  struct drm_file *file_private);
>> diff --git a/drivers/gpu/drm/drm_ioctl.c b/drivers/gpu/drm/drm_ioctl.c
>> index f1e5681..385ce74 100644
>> --- a/drivers/gpu/drm/drm_ioctl.c
>> +++ b/drivers/gpu/drm/drm_ioctl.c
>> @@ -657,6 +657,8 @@ static const struct drm_ioctl_desc drm_ioctls[] = {
>>   DRM_UNLOCKED|DRM_RENDER_ALLOW),
>> DRM_IOCTL_DEF(DRM_IOCTL_SYNCOBJ_FD_TO_HANDLE,
>> drm_syncobj_fd_to_handle_ioctl,
>>   DRM_UNLOCKED|DRM_RENDER_ALLOW),
>> +   DRM_IOCTL_DEF(DRM_IOCTL_SYNCOBJ_WAIT, drm_syncobj_wait_ioctl,
>> + DRM_UNLOCKED|DRM_RENDER_ALLOW),
>>  };
>>
>>  #define DRM_CORE_IOCTL_COUNT   ARRAY_SIZE( drm_ioctls )
>> diff --git a/drivers/gpu/drm/drm_syncobj.c b/drivers/gpu/drm/drm_syncobj.
>> c
>> index b611480..8b87594 100644
>> --- a/drivers/gpu/drm/drm_syncobj.c
>> +++ b/drivers/gpu/drm/drm_syncobj.c
>> @@ -1,5 +1,7 @@
>>  /*
>>   * Copyright 2017 Red Hat
>> + * Parts ported from amdgpu (fence wait code).
>> + * Copyright 2016 Advanced Micro Devices, Inc.
>>   *
>>   * Permission is hereby granted, free of charge, to any person obtaining
>> a
>>   * copy of this software and associated documentation files (the
>> "Software"),
>> @@ -31,6 +33,9 @@
>>   * that contain an optional fence. The fence can be updated with a new
>>   * fence, or be NULL.
>>   *
>> + * syncobj's can be waited upon, where it will wait for the underlying
>> + * fence.
>> + *
>>   * syncobj's can be export to fd's and back, these fd's are opaque and
>>   * have no other use case, except passing the syncobj between processes.
>>   *
>> @@ -375,3 +380,162 @@ drm_syncobj_fd_to_handle_ioctl(struct drm_device
>> *dev, void *data,
>> return drm_syncobj_fd_to_handle(file_private, args->fd,
>> >handle);
>>  }
>> +
>> +
>> +/**
>> + * drm_timeout_abs_to_jiffies - calculate jiffies timeout from absolute
>> value
>> + *
>> + * @timeout_ns: timeout in ns
>> + *
>> + * Calculate the timeout in jiffies from an absolute timeout in ns.
>> + */
>> +unsigned long drm_timeout_abs_to_jiffies(uint64_t timeout_ns)
>> +{
>> +   unsigned long timeout_jiffies;
>> +   ktime_t timeout;
>> +
>> +   /* clamp timeout if it's to large */
>> +   if (((int64_t)timeout_ns) < 0)
>> +   return MAX_SCHEDULE_TIMEOUT;
>> +
>> +   timeout = ktime_sub(ns_to_ktime(timeout_ns), ktime_get());
>> +   if (ktime_to_ns(timeout) < 0)
>> +   return 0;
>> +
>> +   timeout_jiffies = nsecs_to_jiffies(ktime_to_ns(timeout));
>> +   /*  clamp timeout to avoid unsigned-> signed overflow */
>> +   if (timeout_jiffies > MAX_SCHEDULE_TIMEOUT )
>> +   return MAX_SCHEDULE_TIMEOUT - 1;
>> +
>> +   return timeout_jiffies;
>> +}
>> +
>> +static int drm_syncobj_wait_all_fences(struct drm_device *dev,
>> +  struct drm_file *file_private,
>> +  struct drm_syncobj_wait *wait,
>> +  uint32_t *handles)
>> +{
>> +   uint32_t i;
>> +   int ret;
>> +   unsigned long timeout = drm_timeout_abs_to_jiffies(wai
>> t->timeout_ns);
>> +
>> +   for (i = 0; i < wait->count_handles; i++) {
>> +   struct dma_fence *fence;
>> +
>> +   ret = drm_syncobj_fence_get(file_private, handles[i],
>> +   );
>> +   if (ret)
>> +   return ret;
>> +
>> +   if (!fence)
>> +   continue;
>> +
>> + 

Re: [PATCH 2/5] drm/syncobj: add sync obj wait interface. (v3)

[Jason Ekstrand]

On Wed, May 24, 2017 at 12:06 AM, Dave Airlie  wrote:

> From: Dave Airlie 
>
> This interface will allow sync object to be used to back
> Vulkan fences. This API is pretty much the vulkan fence waiting
> API, and I've ported the code from amdgpu.
>
> v2: accept relative timeout, pass remaining time back
> to userspace.
> v3: return to absolute timeouts.
>
> Signed-off-by: Dave Airlie 
> ---
>  drivers/gpu/drm/drm_internal.h |   2 +
>  drivers/gpu/drm/drm_ioctl.c|   2 +
>  drivers/gpu/drm/drm_syncobj.c  | 164 ++
> +++
>  include/uapi/drm/drm.h |  14 
>  4 files changed, 182 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_internal.h b/drivers/gpu/drm/drm_
> internal.h
> index 3fdef2c..53e3f6b 100644
> --- a/drivers/gpu/drm/drm_internal.h
> +++ b/drivers/gpu/drm/drm_internal.h
> @@ -156,3 +156,5 @@ int drm_syncobj_handle_to_fd_ioctl(struct drm_device
> *dev, void *data,
>struct drm_file *file_private);
>  int drm_syncobj_fd_to_handle_ioctl(struct drm_device *dev, void *data,
>struct drm_file *file_private);
> +int drm_syncobj_wait_ioctl(struct drm_device *dev, void *data,
> +  struct drm_file *file_private);
> diff --git a/drivers/gpu/drm/drm_ioctl.c b/drivers/gpu/drm/drm_ioctl.c
> index f1e5681..385ce74 100644
> --- a/drivers/gpu/drm/drm_ioctl.c
> +++ b/drivers/gpu/drm/drm_ioctl.c
> @@ -657,6 +657,8 @@ static const struct drm_ioctl_desc drm_ioctls[] = {
>   DRM_UNLOCKED|DRM_RENDER_ALLOW),
> DRM_IOCTL_DEF(DRM_IOCTL_SYNCOBJ_FD_TO_HANDLE,
> drm_syncobj_fd_to_handle_ioctl,
>   DRM_UNLOCKED|DRM_RENDER_ALLOW),
> +   DRM_IOCTL_DEF(DRM_IOCTL_SYNCOBJ_WAIT, drm_syncobj_wait_ioctl,
> + DRM_UNLOCKED|DRM_RENDER_ALLOW),
>  };
>
>  #define DRM_CORE_IOCTL_COUNT   ARRAY_SIZE( drm_ioctls )
> diff --git a/drivers/gpu/drm/drm_syncobj.c b/drivers/gpu/drm/drm_syncobj.c
> index b611480..8b87594 100644
> --- a/drivers/gpu/drm/drm_syncobj.c
> +++ b/drivers/gpu/drm/drm_syncobj.c
> @@ -1,5 +1,7 @@
>  /*
>   * Copyright 2017 Red Hat
> + * Parts ported from amdgpu (fence wait code).
> + * Copyright 2016 Advanced Micro Devices, Inc.
>   *
>   * Permission is hereby granted, free of charge, to any person obtaining a
>   * copy of this software and associated documentation files (the
> "Software"),
> @@ -31,6 +33,9 @@
>   * that contain an optional fence. The fence can be updated with a new
>   * fence, or be NULL.
>   *
> + * syncobj's can be waited upon, where it will wait for the underlying
> + * fence.
> + *
>   * syncobj's can be export to fd's and back, these fd's are opaque and
>   * have no other use case, except passing the syncobj between processes.
>   *
> @@ -375,3 +380,162 @@ drm_syncobj_fd_to_handle_ioctl(struct drm_device
> *dev, void *data,
> return drm_syncobj_fd_to_handle(file_private, args->fd,
> >handle);
>  }
> +
> +
> +/**
> + * drm_timeout_abs_to_jiffies - calculate jiffies timeout from absolute
> value
> + *
> + * @timeout_ns: timeout in ns
> + *
> + * Calculate the timeout in jiffies from an absolute timeout in ns.
> + */
> +unsigned long drm_timeout_abs_to_jiffies(uint64_t timeout_ns)
> +{
> +   unsigned long timeout_jiffies;
> +   ktime_t timeout;
> +
> +   /* clamp timeout if it's to large */
> +   if (((int64_t)timeout_ns) < 0)
> +   return MAX_SCHEDULE_TIMEOUT;
> +
> +   timeout = ktime_sub(ns_to_ktime(timeout_ns), ktime_get());
> +   if (ktime_to_ns(timeout) < 0)
> +   return 0;
> +
> +   timeout_jiffies = nsecs_to_jiffies(ktime_to_ns(timeout));
> +   /*  clamp timeout to avoid unsigned-> signed overflow */
> +   if (timeout_jiffies > MAX_SCHEDULE_TIMEOUT )
> +   return MAX_SCHEDULE_TIMEOUT - 1;
> +
> +   return timeout_jiffies;
> +}
> +
> +static int drm_syncobj_wait_all_fences(struct drm_device *dev,
> +  struct drm_file *file_private,
> +  struct drm_syncobj_wait *wait,
> +  uint32_t *handles)
> +{
> +   uint32_t i;
> +   int ret;
> +   unsigned long timeout = drm_timeout_abs_to_jiffies(
> wait->timeout_ns);
> +
> +   for (i = 0; i < wait->count_handles; i++) {
> +   struct dma_fence *fence;
> +
> +   ret = drm_syncobj_fence_get(file_private, handles[i],
> +   );
> +   if (ret)
> +   return ret;
> +
> +   if (!fence)
> +   continue;
> +
> +   ret = dma_fence_wait_timeout(fence, true, timeout);
> +
> +   dma_fence_put(fence);
> +   if (ret < 0)
> +   return ret;
> +   if (ret == 0)
> + 

Maintaining small drm drivers

[Patrik Jakobsson]

Hi Dave and Daniel,

We had a little mishap this morning when I had pushed a fix for gma500
into drm-misc-fixes without first getting someone to review it. The
patch have been on the list for over a month and I don't feel like I
have enough karma to force someone to review it. Since I'm the only
one actively reviewing gma500 stuff I've effectively locked myself out
from submitting patches for the driver. Sure, sometimes others help
out and that is ofc appreciated.

As you suggested Daniel, I could trade light-weight reviews with
someone else. At first it sounds reasonable but when I think about it
it's rather bad. Why should I sell my r-b tags cheap in order to get
patches into the driver I'm maintaining? This model seems broken.
Doing quick reviews because you trust the author is not a good idea.
It defeats the purpose and soils the value of your r-b tag (learned
from my own mistakes).

In the case of gma500 I'm exaggerating the problem a bit but others
will run into the same issue at some point. So my question is, can we
scrap the requirements for an r-b tag in drivers with only one
continuously active developer or at least make it more "soft"? Other
ideas are welcome.

Cheers
Patrik
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Intel-gfx] [PATCH 00/37] drm: more doc work, mostly vblank related

[Daniel Vetter]

On Wed, May 24, 2017 at 04:19:31PM +0100, Chris Wilson wrote:
> On Wed, May 24, 2017 at 04:51:35PM +0200, Daniel Vetter wrote:
> > Hi all,
> > 
> > So the first part of this patch series is the usual deal of decrufting some 
> > part
> > of drm and attempting to improve the docs. Mostly around vblank. I seem to 
> > be
> > the ever constant 5% of finally being able to document drm_driver/device
> > properly, oh well.
> > 
> > By patch count the bigger part is trying to get rid of drm_vblank_cleanup. 
> > That
> > was initially exported to drivers for a radeon ums irq failover hack, and 
> > then
> > seems to have been cargo-culted all over the place. It's a bit of churn, 
> > but it
> > will get us one step closer to tracking vblanks as part of drm_crtc. The 
> > other
> > bit would be to get rid of drm_vblank_init, and instead auto-setup the 
> > relevant
> > vblank stuff in drm_crtc_init (iff the driver supports vblanks ofc).
> 
> Whilst I laud the motive, afaict drm_vblank_cleanup() is still required
> after drm_vblank_init(), if only to kfree(dev->vblank). I didn't see
> that change in the earlier patches...

drm_dev_release -> drm_dev_fini -> drm_vblank_cleanup, and has been there
even before drm_vblank_cleanup was exported to drivers (which only
happened recent-ish, see the last patch).

I should probably dump some of the history digging into the earlier
patches, atm the patch series reads a bit backwards :-/

Or did I miss something in my auditing?
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/pl111: add ARM_AMBA dependency

[Arnd Bergmann]

On Tue, May 23, 2017 at 12:08 AM, Eric Anholt  wrote:

>
> Oh, yeah, we've eliminated the amba_request_regions() that used to be
> why the probe had to be under the #ifdef, so your solution would get us
> better coverage and simpler code.  If you could send that patch to
> dri-devel today, I'll get it applied.

Sent now. I'll also send the oneline patch for s3c64xx separately, in case
we hit the same circular dependency another time.

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

Re: [PATCH 1/2] dt/bindings: display: fix display-timing reference

[Daniel Vetter]

On Wed, May 24, 2017 at 03:37:36PM +0300, Baruch Siach wrote:
> Hi Daniel,
> 
> On Wed, May 24, 2017 at 02:23:22PM +0200, Daniel Vetter wrote:
> > On Tue, May 23, 2017 at 09:47:56AM -0500, Rob Herring wrote:
> > > On Tue, May 16, 2017 at 11:19:04AM +0300, Baruch Siach wrote:
> > > > Fixes: 14da3ed8dd08 ("devicetree/bindings: display: Document common 
> > > > panel properties")
> > > > Cc: Laurent Pinchart 
> > > > Cc: Rob Herring 
> > > > Signed-off-by: Baruch Siach 
> > > > ---
> > > >  Documentation/devicetree/bindings/display/panel/panel-common.txt | 2 +-
> > > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > > 
> > > Acked-by: Rob Herring 
> > 
> > We now have a pile of acks on these patches, but no one to push them.
> > Seems like it's for the panel tree, but Thierry isn't on cc afaics.
> > 
> > Someone needs to take care of this (and no it's no going to be me).
> 
> Thanks for looking into this.
> 
> Just for the record, Thierry has been on To/Cc of all messages in this 
> thread, 
> accept yours.

Ah, that might be his dri-devel settings, there's a mailman option to
remove the cc if you're subscribed. And I got the mails through the m-l.

I think this wasn't the first time this happened either ...
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 25/37] drm/meson: Drop drm_vblank_cleanup

[Neil Armstrong]

On 05/24/2017 04:52 PM, Daniel Vetter wrote:
> Again seems just cargo-culted.
> 
> Cc: Neil Armstrong 
> Signed-off-by: Daniel Vetter 
> ---
>  drivers/gpu/drm/meson/meson_drv.c | 1 -
>  1 file changed, 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/meson/meson_drv.c 
> b/drivers/gpu/drm/meson/meson_drv.c
> index 75382f5f0fce..2c605a406ad5 100644
> --- a/drivers/gpu/drm/meson/meson_drv.c
> +++ b/drivers/gpu/drm/meson/meson_drv.c
> @@ -285,7 +285,6 @@ static void meson_drv_unbind(struct device *dev)
>   drm_kms_helper_poll_fini(drm);
>   drm_fbdev_cma_fini(priv->fbdev);
>   drm_mode_config_cleanup(drm);
> - drm_vblank_cleanup(drm);
>   drm_dev_unref(drm);
>  
>  }
> 

Acked-by: Neil Armstrong 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 17/37] drm/atmel: Drop drm_vblank_cleanup

[Boris Brezillon]

On Wed, 24 May 2017 16:51:52 +0200
Daniel Vetter  wrote:

> Again almost correct, but since interrupts are shut down after vblank
> still a race. Proper cleanup would call drm_atomic_helper_shutdown to
> make sure this really is safe.
> 
> v2: Remove misplace malidp hunk (Liviu).
> 
> Cc: Boris Brezillon 
> Signed-off-by: Daniel Vetter 

Acked-by: Boris Brezillon 

> ---
>  drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c | 1 -
>  1 file changed, 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c 
> b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
> index f4a3065f7f51..288dd4b70126 100644
> --- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
> +++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
> @@ -678,7 +678,6 @@ static void atmel_hlcdc_dc_unload(struct drm_device *dev)
>   flush_workqueue(dc->wq);
>   drm_kms_helper_poll_fini(dev);
>   drm_mode_config_cleanup(dev);
> - drm_vblank_cleanup(dev);
>  
>   pm_runtime_get_sync(dev->dev);
>   drm_irq_uninstall(dev);

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

Re: [Intel-gfx] [PATCH 00/37] drm: more doc work, mostly vblank related

[Chris Wilson]

On Wed, May 24, 2017 at 04:51:35PM +0200, Daniel Vetter wrote:
> Hi all,
> 
> So the first part of this patch series is the usual deal of decrufting some 
> part
> of drm and attempting to improve the docs. Mostly around vblank. I seem to be
> the ever constant 5% of finally being able to document drm_driver/device
> properly, oh well.
> 
> By patch count the bigger part is trying to get rid of drm_vblank_cleanup. 
> That
> was initially exported to drivers for a radeon ums irq failover hack, and then
> seems to have been cargo-culted all over the place. It's a bit of churn, but 
> it
> will get us one step closer to tracking vblanks as part of drm_crtc. The other
> bit would be to get rid of drm_vblank_init, and instead auto-setup the 
> relevant
> vblank stuff in drm_crtc_init (iff the driver supports vblanks ofc).

Whilst I laud the motive, afaict drm_vblank_cleanup() is still required
after drm_vblank_init(), if only to kfree(dev->vblank). I didn't see
that change in the earlier patches...
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[ANNOUNCE] libdrm 2.4.81

[Marek Olšák]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1


Adam Jackson (3):
  Export drmDevicesEqual
  configure: Fix the  check
  Fix stray caller of drmCompareDevices

Edward O'Callaghan (2):
  amdgpu/: concisely && consistently check null ptrs in canonical form
  amdgpu: Use the canonical form in branch predicate

Eric Anholt (2):
  Add pl111 as a KMS driver for utils.
  Add the DPI encoder/connector types to KMS utils.

Hawking Zhang (1):
  amdgpu: add raven family id

Ilia Mirkin (1):
  modetest: fix printing of fourcc on BE machines

Leo Liu (2):
  amdgpu/drm: add AMDGPU_HW_IP_VCN_DEC
  amdgpu/drm: add AMDGPU_HW_IP_VCN_ENC

Marek Olšák (1):
  Bump version to 2.4.81

Nicolai Hähnle (3):
  amdgpu: add the interface of waiting multiple fences
  amdgpu: add a test for amdgpu_cs_wait_fences
  amdgpu: add missing extern "C" headers

Rob Clark (1):
  freedreno: fix double-free on exit

git tag: libdrm-2.4.81

https://dri.freedesktop.org/libdrm/libdrm-2.4.81.tar.bz2
MD5:  d04f3567f0a812188d06f860fded5ab7  libdrm-2.4.81.tar.bz2
SHA1: 40f0994b5fb9992e6f55d3a14537def21719d896  libdrm-2.4.81.tar.bz2
SHA256: 8cc05c195ac8708199979a94c4e4d1a928c14ec338ecbcb38ead09f54dae11ae  
libdrm-2.4.81.tar.bz2
SHA512: 
5f7a1524acad59890d3f890bed90a660a424e18a88d587ca356223bde4a7446d1c540f97ec11cb10d2e7ed1b4ae86127957634354a1be6d04199295ab24782e5
  libdrm-2.4.81.tar.bz2
PGP:  https://dri.freedesktop.org/libdrm/libdrm-2.4.81.tar.bz2.sig

https://dri.freedesktop.org/libdrm/libdrm-2.4.81.tar.gz
MD5:  dc575dd661a082390e9f1366ca5734b0  libdrm-2.4.81.tar.gz
SHA1: 429bfca69addee93a59c7d74be017ef20d6a0634  libdrm-2.4.81.tar.gz
SHA256: 64036c5e0668fdc2b820dcc0ebab712f44fd2c2147d23dc5a6e003b19f0d3e9f  
libdrm-2.4.81.tar.gz
SHA512: 
d22657f35c4c0b1dc49a8f71e217db3ff4b8cdeb83b3aed66448c4da9d6a1e2a76ebeff552b6a3cf6d8e486de99db612bd3a50430d22bb057bb9afdb299d
  libdrm-2.4.81.tar.gz
PGP:  https://dri.freedesktop.org/libdrm/libdrm-2.4.81.tar.gz.sig

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAEBAgAGBQJZJaM8AAoJEP3RXVrO8PKxLJsIAMCdEnA14oJHAhbkbCevAyhc
+ZUaXOkbvl7pVsHj1kI34GVIlU33YdcZ95LsuK4/HBBnGyOnL63TAhn4LczoqlHq
zKD1ZkdDkviqF26OAI+QRFu6WuUf3ikmSYfI+QuO+Xz1P+CFv5qnHbHrNnhLXOHr
rqZg9QJHmpRqPAKvIA/9LDJF4M/NBewu4EfrTKXhS+J8zrwvK5e7C3e27+EAEzlM
R7KAswM+eb6guGLFCR4AtGC2JQbzFVsPjvSYeapDnOHu8wNwrgviqjIRlcL99amE
kBDNjYOJ+i6krgalehg097QA1W5JJctRnba7hh9E10CW8eRNJ+OTsl15wnZ5rZY=
=HyXu
-END PGP SIGNATURE-
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 96868] AMDGPU Tonga only does 2560x1440 at 120hz, switching to 144hz causes display errors, same thing used to happen with fglrx.

[bugzilla-daemon]

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

--- Comment #27 from Jonas  ---
(In reply to Alex Deucher from comment #26)
> Created attachment 131453 [details] [review]
> possible fix 4/4

This time the issue seems to be completely fixed, at least for me. Even @144Hz
the screen works perfectly fine, no flickering whatsoever, and the GPU
temperature doesn't rise more than 1ºC, so I guess that it is not "high
profile" all the time.

Thank you very much for your hard work, it is really appreciated.

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

[Bug 99349] Failed to build shader (translation from TGSI)

[bugzilla-daemon]

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

--- Comment #4 from Gert Wollny  ---
The same problem also seems to be discussed in these mails 

http://mesa-dev.freedesktop.narkive.com/cHAXj1eT/bug-50338-radeon-tgsi-takes-more-than-two-cfiles-from-r600-shader

It is very likely that this is actually a duplicated of #50338.

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

[PATCH 37/37] drm/vblank: Unexport drm_vblank_cleanup

[Daniel Vetter]

There's no reason for drivers to call this, and all the ones I've
removed looked very fishy:
- Proper quiescenting of the vblank machinery should be done by
  calling drm_crtc_vblank_off(), which is best done by shutting down
  the entire display engine with drm_atomic_helper_shutdown.

- Releasing of allocated memory is done by the core already, it calls
  drm_vblank_cleanup as a fallback.

- drm_vblank_cleanup also has checks for drivers which forget to clean
  up vblank interrupts.

This essentially reverts

commit e77cef9c2d87db835ad9d70cde4a9b00b0ca2262
Author: Jerome Glisse 
Date:   Thu Jan 7 15:39:13 2010 +0100

drm: Avoid calling vblank function is vblank wasn't initialized

which was done to fix a bug in radeon code with msi interrupts:

commit 003e69f9862bcda89a75c27750efdbc17ac02945
Author: Jerome Glisse 
Date:   Thu Jan 7 15:39:14 2010 +0100

drm/radeon/kms: Don't try to enable IRQ if we have no handler installed

Afaict from digging around in old code, this was needed to avoid
blowing up in the ums fallback, and has stopped serving it's purpose
long ago - if irq init fails, the driver fails to load, and there's
really no way to blow up anymore.

Long story short, this was most likely a small ums compat/fallback
hack that became a thing of it's own and got cargo-cult duplicated all
over the drm codebase for essentially no gain at all.

Cc: Jerome Glisse 
Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/drm_internal.h |  1 +
 drivers/gpu/drm/drm_vblank.c   | 16 
 include/drm/drm_vblank.h   |  1 -
 3 files changed, 1 insertion(+), 17 deletions(-)

diff --git a/drivers/gpu/drm/drm_internal.h b/drivers/gpu/drm/drm_internal.h
index 116de27cf8f3..61666e669b43 100644
--- a/drivers/gpu/drm/drm_internal.h
+++ b/drivers/gpu/drm/drm_internal.h
@@ -57,6 +57,7 @@ int drm_gem_name_info(struct seq_file *m, void *data);
 /* drm_vblank.c */
 extern unsigned int drm_timestamp_monotonic;
 void drm_vblank_disable_and_save(struct drm_device *dev, unsigned int pipe);
+void drm_vblank_cleanup(struct drm_device *dev);
 
 /* IOCTLS */
 int drm_wait_vblank_ioctl(struct drm_device *dev, void *data,
diff --git a/drivers/gpu/drm/drm_vblank.c b/drivers/gpu/drm/drm_vblank.c
index 9263bacb6ebd..b387814da47d 100644
--- a/drivers/gpu/drm/drm_vblank.c
+++ b/drivers/gpu/drm/drm_vblank.c
@@ -394,19 +394,6 @@ static void vblank_disable_fn(unsigned long arg)
spin_unlock_irqrestore(>vbl_lock, irqflags);
 }
 
-/**
- * drm_vblank_cleanup - cleanup vblank support
- * @dev: DRM device
- *
- * This function cleans up any resources allocated in drm_vblank_init(). It is
- * called by the DRM core when @dev is finalized.
- *
- * Drivers can call drm_vblank_cleanup() if they need to quiescent the vblank
- * interrupt in their unload code. But in general this should be handled by
- * disabling all active _crtc through e.g. drm_atomic_helper_shutdown, 
which
- * should end up calling drm_crtc_vblank_off().
- *
- */
 void drm_vblank_cleanup(struct drm_device *dev)
 {
unsigned int pipe;
@@ -428,7 +415,6 @@ void drm_vblank_cleanup(struct drm_device *dev)
 
dev->num_crtcs = 0;
 }
-EXPORT_SYMBOL(drm_vblank_cleanup);
 
 /**
  * drm_vblank_init - initialize vblank support
@@ -436,8 +422,6 @@ EXPORT_SYMBOL(drm_vblank_cleanup);
  * @num_crtcs: number of CRTCs supported by @dev
  *
  * This function initializes vblank support for @num_crtcs display pipelines.
- * Drivers do not need to call drm_vblank_cleanup(), cleanup is already handled
- * by the DRM core.
  *
  * Returns:
  * Zero on success or a negative error code on failure.
diff --git a/include/drm/drm_vblank.h b/include/drm/drm_vblank.h
index 4ceef128582f..7fba9efe4951 100644
--- a/include/drm/drm_vblank.h
+++ b/include/drm/drm_vblank.h
@@ -168,7 +168,6 @@ void drm_crtc_wait_one_vblank(struct drm_crtc *crtc);
 void drm_crtc_vblank_off(struct drm_crtc *crtc);
 void drm_crtc_vblank_reset(struct drm_crtc *crtc);
 void drm_crtc_vblank_on(struct drm_crtc *crtc);
-void drm_vblank_cleanup(struct drm_device *dev);
 u32 drm_crtc_accurate_vblank_count(struct drm_crtc *crtc);
 
 bool drm_calc_vbltimestamp_from_scanoutpos(struct drm_device *dev,
-- 
2.11.0

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

Re: [PATCH 13/37] drm: better document how to send out the crtc disable event

[Boris Brezillon]

On Wed, 24 May 2017 16:51:48 +0200
Daniel Vetter  wrote:

> The kernel doc explained what needs to happen, but not how to most
> easily accomplish that using the functions. Fix that.
> 
> Cc: Boris Brezillon 
> Signed-off-by: Daniel Vetter 

Reviewed-by: Boris Brezillon 

> ---
>  include/drm/drm_crtc.h | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
> index 5f5d53973ca5..3a911a64c257 100644
> --- a/include/drm/drm_crtc.h
> +++ b/include/drm/drm_crtc.h
> @@ -214,7 +214,9 @@ struct drm_crtc_state {
>*atomic commit. In that case the event can be send out any time
>*after the hardware has stopped scanning out the current
>*framebuffers. It should contain the timestamp and counter for the
> -  *last vblank before the display pipeline was shut off.
> +  *last vblank before the display pipeline was shut off. The simplest
> +  *way to achieve that is calling drm_crtc_send_vblank_event()
> +  *somewhen after drm_crtc_vblank_off() has been called.
>*
>*  - For a CRTC which is enabled at the end of the commit (even when it
>*undergoes an full modeset) the vblank timestamp and counter must

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

[PATCH 36/37] drm/zte: Drop drm_vblank_cleanup

[Daniel Vetter]

It again looks all cargo-culted for no good reasons.

Cc: Shawn Guo 
Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/zte/zx_drm_drv.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/gpu/drm/zte/zx_drm_drv.c b/drivers/gpu/drm/zte/zx_drm_drv.c
index 490aafc99610..696836303229 100644
--- a/drivers/gpu/drm/zte/zx_drm_drv.c
+++ b/drivers/gpu/drm/zte/zx_drm_drv.c
@@ -149,7 +149,6 @@ static int zx_drm_bind(struct device *dev)
 out_poll_fini:
drm_kms_helper_poll_fini(drm);
drm_mode_config_cleanup(drm);
-   drm_vblank_cleanup(drm);
 out_unbind:
component_unbind_all(dev, drm);
 out_unregister:
@@ -171,7 +170,6 @@ static void zx_drm_unbind(struct device *dev)
}
drm_kms_helper_poll_fini(drm);
drm_mode_config_cleanup(drm);
-   drm_vblank_cleanup(drm);
component_unbind_all(dev, drm);
dev_set_drvdata(dev, NULL);
drm->dev_private = NULL;
-- 
2.11.0

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

[PATCH 22/37] drm/i915: Drop drm_vblank_cleanup

[Daniel Vetter]

On the load error path we can't have pending vblank interrupts, and on
unload we already call drm_atomic_helper_shutdown beforehand! So all
good to nuke it.

Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/i915/i915_drv.c | 6 +-
 1 file changed, 1 insertion(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index cd0bbec36853..6052798bb626 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -1278,7 +1278,7 @@ int i915_driver_load(struct pci_dev *pdev, const struct 
pci_device_id *ent)
 
ret = i915_load_modeset_init(_priv->drm);
if (ret < 0)
-   goto out_cleanup_vblank;
+   goto out_cleanup_hw;
 
i915_driver_register(dev_priv);
 
@@ -1295,8 +1295,6 @@ int i915_driver_load(struct pci_dev *pdev, const struct 
pci_device_id *ent)
 
return 0;
 
-out_cleanup_vblank:
-   drm_vblank_cleanup(_priv->drm);
 out_cleanup_hw:
i915_driver_cleanup_hw(dev_priv);
 out_cleanup_mmio:
@@ -1332,8 +1330,6 @@ void i915_driver_unload(struct drm_device *dev)
 
i915_driver_unregister(dev_priv);
 
-   drm_vblank_cleanup(dev);
-
intel_modeset_cleanup(dev);
 
/*
-- 
2.11.0

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

[PATCH 32/37] drm/sun4i: Drop drm_vblank_cleanup

[Daniel Vetter]

Again seems just cargo-culted ... It's not ordered against any
irq/vblank/modeset shutdown.

Cc: Maxime Ripard  
Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/sun4i/sun4i_drv.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/gpu/drm/sun4i/sun4i_drv.c 
b/drivers/gpu/drm/sun4i/sun4i_drv.c
index 8ddd72cd5873..c26d5888f8e1 100644
--- a/drivers/gpu/drm/sun4i/sun4i_drv.c
+++ b/drivers/gpu/drm/sun4i/sun4i_drv.c
@@ -138,7 +138,6 @@ static int sun4i_drv_bind(struct device *dev)
sun4i_framebuffer_free(drm);
 cleanup_mode_config:
drm_mode_config_cleanup(drm);
-   drm_vblank_cleanup(drm);
 free_mem_region:
of_reserved_mem_device_release(dev);
 free_drm:
@@ -154,7 +153,6 @@ static void sun4i_drv_unbind(struct device *dev)
drm_kms_helper_poll_fini(drm);
sun4i_framebuffer_free(drm);
drm_mode_config_cleanup(drm);
-   drm_vblank_cleanup(drm);
of_reserved_mem_device_release(dev);
drm_dev_unref(drm);
 }
-- 
2.11.0

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

[PATCH 30/37] drm/sti: Drop drm_vblank_cleanup

[Daniel Vetter]

Seems entirely cargo-culted.

Cc: Benjamin Gaignard 
Cc: Vincent Abriou 
Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/sti/sti_drv.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/gpu/drm/sti/sti_drv.c b/drivers/gpu/drm/sti/sti_drv.c
index a4b574283269..06ef1e3886cf 100644
--- a/drivers/gpu/drm/sti/sti_drv.c
+++ b/drivers/gpu/drm/sti/sti_drv.c
@@ -237,7 +237,6 @@ static void sti_cleanup(struct drm_device *ddev)
}
 
drm_kms_helper_poll_fini(ddev);
-   drm_vblank_cleanup(ddev);
component_unbind_all(ddev->dev, ddev);
kfree(private);
ddev->dev_private = NULL;
-- 
2.11.0

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

[PATCH 31/37] drm/stm: Drop drm_vblank_cleanup

[Daniel Vetter]

Again seems just cargo-culted.

Cc: Yannick Fertre 
Cc: Philippe Cornu 
Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/stm/ltdc.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/gpu/drm/stm/ltdc.c b/drivers/gpu/drm/stm/ltdc.c
index 700cc0800e51..1b9483d4f2a4 100644
--- a/drivers/gpu/drm/stm/ltdc.c
+++ b/drivers/gpu/drm/stm/ltdc.c
@@ -1144,8 +1144,6 @@ void ltdc_unload(struct drm_device *ddev)
 
DRM_DEBUG_DRIVER("\n");
 
-   drm_vblank_cleanup(ddev);
-
if (ldev->panel)
drm_panel_detach(ldev->panel);
 
-- 
2.11.0

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

[PATCH 26/37] drm/mxsfb: Drop drm_vblank_cleanup

[Daniel Vetter]

Almost right but still racy, it's called before the interrupts are
uninstalled. So let's just drop it.

Cc: Marek Vasut 
Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/mxsfb/mxsfb_drv.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/gpu/drm/mxsfb/mxsfb_drv.c 
b/drivers/gpu/drm/mxsfb/mxsfb_drv.c
index d1b9c34c7c00..1853557fef46 100644
--- a/drivers/gpu/drm/mxsfb/mxsfb_drv.c
+++ b/drivers/gpu/drm/mxsfb/mxsfb_drv.c
@@ -256,7 +256,6 @@ static void mxsfb_unload(struct drm_device *drm)
 
drm_kms_helper_poll_fini(drm);
drm_mode_config_cleanup(drm);
-   drm_vblank_cleanup(drm);
 
pm_runtime_get_sync(drm->dev);
drm_irq_uninstall(drm);
-- 
2.11.0

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

[PATCH 18/37] drm/exynos: Drop drm_vblank_cleanup

[Daniel Vetter]

Only in the load failure path, where the hardware is quiet anyway.

Cc: Inki Dae 
Cc: Joonyoung Shim 
Cc: Seung-Woo Kim 
Cc: Kyungmin Park 
Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/exynos/exynos_drm_drv.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c 
b/drivers/gpu/drm/exynos/exynos_drm_drv.c
index 50294a7bd29d..1c814b9342af 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
@@ -376,7 +376,7 @@ static int exynos_drm_bind(struct device *dev)
/* Probe non kms sub drivers and virtual display driver. */
ret = exynos_drm_device_subdrv_probe(drm);
if (ret)
-   goto err_cleanup_vblank;
+   goto err_unbind_all;
 
drm_mode_config_reset(drm);
 
@@ -407,8 +407,6 @@ static int exynos_drm_bind(struct device *dev)
exynos_drm_fbdev_fini(drm);
drm_kms_helper_poll_fini(drm);
exynos_drm_device_subdrv_remove(drm);
-err_cleanup_vblank:
-   drm_vblank_cleanup(drm);
 err_unbind_all:
component_unbind_all(drm->dev, drm);
 err_mode_config_cleanup:
-- 
2.11.0

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

[PATCH 13/37] drm: better document how to send out the crtc disable event

[Daniel Vetter]

The kernel doc explained what needs to happen, but not how to most
easily accomplish that using the functions. Fix that.

Cc: Boris Brezillon 
Signed-off-by: Daniel Vetter 
---
 include/drm/drm_crtc.h | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index 5f5d53973ca5..3a911a64c257 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -214,7 +214,9 @@ struct drm_crtc_state {
 *atomic commit. In that case the event can be send out any time
 *after the hardware has stopped scanning out the current
 *framebuffers. It should contain the timestamp and counter for the
-*last vblank before the display pipeline was shut off.
+*last vblank before the display pipeline was shut off. The simplest
+*way to achieve that is calling drm_crtc_send_vblank_event()
+*somewhen after drm_crtc_vblank_off() has been called.
 *
 *  - For a CRTC which is enabled at the end of the commit (even when it
 *undergoes an full modeset) the vblank timestamp and counter must
-- 
2.11.0

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

[PATCH 06/37] drm/doc: Improve ioctl/fops docs a bit more

[Daniel Vetter]

I spotted a markup issue, plus adding the descriptions in drm_driver.
Plus a few more links while at it.

I'm still mildly unhappy with the split between fops and ioctls, but I
still think having the ioctls in the uapi chapter makes more sense. Oh
well ...

v2: Rebase.

Signed-off-by: Daniel Vetter 
---
 Documentation/gpu/drm-internals.rst |  2 ++
 Documentation/gpu/drm-uapi.rst  |  2 ++
 drivers/gpu/drm/Makefile|  2 +-
 drivers/gpu/drm/drm_file.c  |  7 ++-
 drivers/gpu/drm/drm_internal.h  |  3 ++-
 drivers/gpu/drm/drm_ioctl.c |  5 -
 include/drm/drm_drv.h   | 18 ++
 7 files changed, 35 insertions(+), 4 deletions(-)

diff --git a/Documentation/gpu/drm-internals.rst 
b/Documentation/gpu/drm-internals.rst
index babfb6143bd9..d218dd29221a 100644
--- a/Documentation/gpu/drm-internals.rst
+++ b/Documentation/gpu/drm-internals.rst
@@ -243,6 +243,8 @@ drivers.
 Open/Close, File Operations and IOCTLs
 ==
 
+.. _drm_driver_fops:
+
 File Operations
 ---
 
diff --git a/Documentation/gpu/drm-uapi.rst b/Documentation/gpu/drm-uapi.rst
index 858457567d3d..679373b4a03f 100644
--- a/Documentation/gpu/drm-uapi.rst
+++ b/Documentation/gpu/drm-uapi.rst
@@ -160,6 +160,8 @@ other hand, a driver requires shared state between clients 
which is
 visible to user-space and accessible beyond open-file boundaries, they
 cannot support render nodes.
 
+.. _drm_driver_ioctl:
+
 IOCTL Support on Device Nodes
 =
 
diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index c156fecfb362..acc88942c2e5 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -16,7 +16,7 @@ drm-y   :=drm_auth.o drm_bufs.o drm_cache.o \
drm_framebuffer.o drm_connector.o drm_blend.o \
drm_encoder.o drm_mode_object.o drm_property.o \
drm_plane.o drm_color_mgmt.o drm_print.o \
-   drm_dumb_buffers.o drm_mode_config.o
+   drm_dumb_buffers.o drm_mode_config.o drm_vblank.o
 
 drm-$(CONFIG_DRM_LIB_RANDOM) += lib/drm_random.o
 drm-$(CONFIG_DRM_VM) += drm_vm.o
diff --git a/drivers/gpu/drm/drm_file.c b/drivers/gpu/drm/drm_file.c
index caad93dab54b..6631f61b66ca 100644
--- a/drivers/gpu/drm/drm_file.c
+++ b/drivers/gpu/drm/drm_file.c
@@ -75,7 +75,7 @@ DEFINE_MUTEX(drm_global_mutex);
  * for drivers which use the CMA GEM helpers it's drm_gem_cma_mmap().
  *
  * No other file operations are supported by the DRM userspace API. Overall the
- * following is an example #file_operations structure::
+ * following is an example _operations structure::
  *
  * static const example_drm_fops = {
  * .owner = THIS_MODULE,
@@ -92,6 +92,11 @@ DEFINE_MUTEX(drm_global_mutex);
  * For plain GEM based drivers there is the DEFINE_DRM_GEM_FOPS() macro, and 
for
  * CMA based drivers there is the DEFINE_DRM_GEM_CMA_FOPS() macro to make this
  * simpler.
+ *
+ * The driver's _operations must be stored in _driver.fops.
+ *
+ * For driver-private IOCTL handling see the more detailed discussion in
+ * :ref:`IOCTL support in the userland interfaces chapter`.
  */
 
 static int drm_open_helper(struct file *filp, struct drm_minor *minor);
diff --git a/drivers/gpu/drm/drm_internal.h b/drivers/gpu/drm/drm_internal.h
index bca2c66c5d28..6a0cbcc84534 100644
--- a/drivers/gpu/drm/drm_internal.h
+++ b/drivers/gpu/drm/drm_internal.h
@@ -54,8 +54,9 @@ int drm_name_info(struct seq_file *m, void *data);
 int drm_clients_info(struct seq_file *m, void* data);
 int drm_gem_name_info(struct seq_file *m, void *data);
 
-/* drm_irq.c */
+/* drm_vblank.c */
 extern unsigned int drm_timestamp_monotonic;
+void drm_vblank_disable_and_save(struct drm_device *dev, unsigned int pipe);
 
 /* IOCTLS */
 int drm_wait_vblank(struct drm_device *dev, void *data,
diff --git a/drivers/gpu/drm/drm_ioctl.c b/drivers/gpu/drm/drm_ioctl.c
index a423bf60e230..3690706f051d 100644
--- a/drivers/gpu/drm/drm_ioctl.c
+++ b/drivers/gpu/drm/drm_ioctl.c
@@ -683,7 +683,7 @@ static const struct drm_ioctl_desc drm_ioctls[] = {
  * 
  * DRM driver private IOCTL must be in the range from DRM_COMMAND_BASE to
  * DRM_COMMAND_END. Finally you need an array of  drm_ioctl_desc to wire
- * up the handlers and set the access rights:
+ * up the handlers and set the access rights::
  *
  * static const struct drm_ioctl_desc my_driver_ioctls[] = {
  * DRM_IOCTL_DEF_DRV(MY_DRIVER_OPERATION, my_driver_operation,
@@ -692,6 +692,9 @@ static const struct drm_ioctl_desc drm_ioctls[] = {
  *
  * And then assign this to the _driver.ioctls field in your driver
  * structure.
+ *
+ * See the separate chapter on :ref:`file operations` for how
+ * the driver-specific IOCTLs are wired up.
  */
 
 /**
diff --git a/include/drm/drm_drv.h b/include/drm/drm_drv.h
index 5d06c68bb00b..ebb41688581b 100644
--- a/include/drm/drm_drv.h
+++ b/include/drm/drm_drv.h
@@ -486,8 

[PATCH 14/37] drm/amd|radeon: Drop drm_vblank_cleanup

[Daniel Vetter]

Both drivers shut down all crtc beforehand already, which will shut up
any pending vblank (the only thing vblank_cleanup really does is
disable the disable timer). Hence we don't need this here and can
remove it.

Cc: Alex Deucher 
Cc: Christian König 
Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_irq.c | 1 -
 drivers/gpu/drm/radeon/radeon_irq_kms.c | 1 -
 2 files changed, 2 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_irq.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_irq.c
index a6b7e367a860..4a15be658935 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_irq.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_irq.c
@@ -262,7 +262,6 @@ void amdgpu_irq_fini(struct amdgpu_device *adev)
 {
unsigned i, j;
 
-   drm_vblank_cleanup(adev->ddev);
if (adev->irq.installed) {
drm_irq_uninstall(adev->ddev);
adev->irq.installed = false;
diff --git a/drivers/gpu/drm/radeon/radeon_irq_kms.c 
b/drivers/gpu/drm/radeon/radeon_irq_kms.c
index 1b7528df7f7f..3efe07f3e3db 100644
--- a/drivers/gpu/drm/radeon/radeon_irq_kms.c
+++ b/drivers/gpu/drm/radeon/radeon_irq_kms.c
@@ -324,7 +324,6 @@ int radeon_irq_kms_init(struct radeon_device *rdev)
  */
 void radeon_irq_kms_fini(struct radeon_device *rdev)
 {
-   drm_vblank_cleanup(rdev->ddev);
if (rdev->irq.installed) {
drm_irq_uninstall(rdev->ddev);
rdev->irq.installed = false;
-- 
2.11.0

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

[PATCH 10/37] drm/doc: vblank cleanup

[Daniel Vetter]

Unify and review everything, plus make sure it's all correct markup.
Drop the kernel-doc for internal functions. Also rework the overview
section, it's become rather outdated.

Unfortuantely the kernel-doc in drm_driver isn't rendered yet, but
that will change as soon as drm_driver is kernel-docified properly.

Also document properly that drm_vblank_cleanup is optional, the core
calls this already.

Signed-off-by: Daniel Vetter 
---
 Documentation/gpu/drm-kms.rst |  56 +--
 drivers/gpu/drm/drm_vblank.c  | 157 --
 include/drm/drmP.h|  37 --
 include/drm/drm_crtc.h|   3 +
 4 files changed, 112 insertions(+), 141 deletions(-)

diff --git a/Documentation/gpu/drm-kms.rst b/Documentation/gpu/drm-kms.rst
index 0749000ab3d7..307284125d7a 100644
--- a/Documentation/gpu/drm-kms.rst
+++ b/Documentation/gpu/drm-kms.rst
@@ -551,60 +551,8 @@ various modules/drivers.
 Vertical Blanking
 =
 
-Vertical blanking plays a major role in graphics rendering. To achieve
-tear-free display, users must synchronize page flips and/or rendering to
-vertical blanking. The DRM API offers ioctls to perform page flips
-synchronized to vertical blanking and wait for vertical blanking.
-
-The DRM core handles most of the vertical blanking management logic,
-which involves filtering out spurious interrupts, keeping race-free
-blanking counters, coping with counter wrap-around and resets and
-keeping use counts. It relies on the driver to generate vertical
-blanking interrupts and optionally provide a hardware vertical blanking
-counter. Drivers must implement the following operations.
-
--  int (\*enable_vblank) (struct drm_device \*dev, int crtc); void
-   (\*disable_vblank) (struct drm_device \*dev, int crtc);
-   Enable or disable vertical blanking interrupts for the given CRTC.
-
--  u32 (\*get_vblank_counter) (struct drm_device \*dev, int crtc);
-   Retrieve the value of the vertical blanking counter for the given
-   CRTC. If the hardware maintains a vertical blanking counter its value
-   should be returned. Otherwise drivers can use the
-   :c:func:`drm_vblank_count()` helper function to handle this
-   operation.
-
-Drivers must initialize the vertical blanking handling core with a call
-to :c:func:`drm_vblank_init()` in their load operation.
-
-Vertical blanking interrupts can be enabled by the DRM core or by
-drivers themselves (for instance to handle page flipping operations).
-The DRM core maintains a vertical blanking use count to ensure that the
-interrupts are not disabled while a user still needs them. To increment
-the use count, drivers call :c:func:`drm_vblank_get()`. Upon
-return vertical blanking interrupts are guaranteed to be enabled.
-
-To decrement the use count drivers call
-:c:func:`drm_vblank_put()`. Only when the use count drops to zero
-will the DRM core disable the vertical blanking interrupts after a delay
-by scheduling a timer. The delay is accessible through the
-vblankoffdelay module parameter or the ``drm_vblank_offdelay`` global
-variable and expressed in milliseconds. Its default value is 5000 ms.
-Zero means never disable, and a negative value means disable
-immediately. Drivers may override the behaviour by setting the
-:c:type:`struct drm_device `
-vblank_disable_immediate flag, which when set causes vblank interrupts
-to be disabled immediately regardless of the drm_vblank_offdelay
-value. The flag should only be set if there's a properly working
-hardware vblank counter present.
-
-When a vertical blanking interrupt occurs drivers only need to call the
-:c:func:`drm_handle_vblank()` function to account for the
-interrupt.
-
-Resources allocated by :c:func:`drm_vblank_init()` must be freed
-with a call to :c:func:`drm_vblank_cleanup()` in the driver unload
-operation handler.
+.. kernel-doc:: drivers/gpu/drm/drm_vblank.c
+   :doc: vblank handling
 
 Vertical Blanking and Interrupt Handling Functions Reference
 
diff --git a/drivers/gpu/drm/drm_vblank.c b/drivers/gpu/drm/drm_vblank.c
index 463e4d81fb0d..73023d463dc7 100644
--- a/drivers/gpu/drm/drm_vblank.c
+++ b/drivers/gpu/drm/drm_vblank.c
@@ -31,6 +31,41 @@
 #include "drm_trace.h"
 #include "drm_internal.h"
 
+/**
+ * DOC: vblank handling
+ *
+ * Vertical blanking plays a major role in graphics rendering. To achieve
+ * tear-free display, users must synchronize page flips and/or rendering to
+ * vertical blanking. The DRM API offers ioctls to perform page flips
+ * synchronized to vertical blanking and wait for vertical blanking.
+ *
+ * The DRM core handles most of the vertical blanking management logic, which
+ * involves filtering out spurious interrupts, keeping race-free blanking
+ * counters, coping with counter wrap-around and resets and keeping use counts.
+ * It relies on the driver to generate vertical blanking interrupts and
+ * optionally provide a 

[PATCH 35/37] drm/vmwgfx: Drop drm_vblank_cleanup

[Daniel Vetter]

Again stopping the vblank before uninstalling the irq handler is kinda
the wrong way round, but the fb_off stuff should take care of
disabling the dsiplay at least in most cases. So drop the
drm_vblank_cleanup code since it's not really doing anything, it looks
all cargo-culted.

v2: Appease gcc better.

Cc: Sinclair Yeh 
Cc: Thomas Hellstrom 
Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/vmwgfx/vmwgfx_kms.c  |  9 +++--
 drivers/gpu/drm/vmwgfx/vmwgfx_kms.h  |  2 --
 drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c  |  4 
 drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c |  9 -
 drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c | 27 +--
 5 files changed, 4 insertions(+), 47 deletions(-)

diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c 
b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
index a8876b070168..d1f742478b03 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
@@ -1771,7 +1771,7 @@ int vmw_kms_init(struct vmw_private *dev_priv)
 
 int vmw_kms_close(struct vmw_private *dev_priv)
 {
-   int ret;
+   int ret = 0;
 
/*
 * Docs says we should take the lock before calling this function
@@ -1779,11 +1779,8 @@ int vmw_kms_close(struct vmw_private *dev_priv)
 * drm_encoder_cleanup which takes the lock we deadlock.
 */
drm_mode_config_cleanup(dev_priv->dev);
-   if (dev_priv->active_display_unit == vmw_du_screen_object)
-   ret = vmw_kms_sou_close_display(dev_priv);
-   else if (dev_priv->active_display_unit == vmw_du_screen_target)
-   ret = vmw_kms_stdu_close_display(dev_priv);
-   else
+   if (dev_priv->active_display_unit != vmw_du_screen_object &&
+   dev_priv->active_display_unit != vmw_du_screen_target)
ret = vmw_kms_ldu_close_display(dev_priv);
 
return ret;
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.h 
b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.h
index 13f2f1d2818a..f94b4ca38ab2 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.h
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.h
@@ -405,7 +405,6 @@ int vmw_kms_update_proxy(struct vmw_resource *res,
  * Screen Objects display functions - vmwgfx_scrn.c
  */
 int vmw_kms_sou_init_display(struct vmw_private *dev_priv);
-int vmw_kms_sou_close_display(struct vmw_private *dev_priv);
 int vmw_kms_sou_do_surface_dirty(struct vmw_private *dev_priv,
 struct vmw_framebuffer *framebuffer,
 struct drm_clip_rect *clips,
@@ -433,7 +432,6 @@ int vmw_kms_sou_readback(struct vmw_private *dev_priv,
  * Screen Target Display Unit functions - vmwgfx_stdu.c
  */
 int vmw_kms_stdu_init_display(struct vmw_private *dev_priv);
-int vmw_kms_stdu_close_display(struct vmw_private *dev_priv);
 int vmw_kms_stdu_surface_dirty(struct vmw_private *dev_priv,
   struct vmw_framebuffer *framebuffer,
   struct drm_clip_rect *clips,
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c 
b/drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c
index d3987bcf53f8..449ed4fba0f2 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c
@@ -582,13 +582,9 @@ int vmw_kms_ldu_init_display(struct vmw_private *dev_priv)
 
 int vmw_kms_ldu_close_display(struct vmw_private *dev_priv)
 {
-   struct drm_device *dev = dev_priv->dev;
-
if (!dev_priv->ldu_priv)
return -ENOSYS;
 
-   drm_vblank_cleanup(dev);
-
BUG_ON(!list_empty(_priv->ldu_priv->active));
 
kfree(dev_priv->ldu_priv);
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c 
b/drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c
index 8d7dc9def7c2..3b917c9b0c21 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c
@@ -746,15 +746,6 @@ int vmw_kms_sou_init_display(struct vmw_private *dev_priv)
return 0;
 }
 
-int vmw_kms_sou_close_display(struct vmw_private *dev_priv)
-{
-   struct drm_device *dev = dev_priv->dev;
-
-   drm_vblank_cleanup(dev);
-
-   return 0;
-}
-
 static int do_dmabuf_define_gmrfb(struct vmw_private *dev_priv,
  struct vmw_framebuffer *framebuffer)
 {
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c 
b/drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c
index bad31bdf09b6..b4d4074c0ae0 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c
@@ -1634,36 +1634,11 @@ int vmw_kms_stdu_init_display(struct vmw_private 
*dev_priv)
 
if (unlikely(ret != 0)) {
DRM_ERROR("Failed to initialize STDU %d", i);
-   goto err_vblank_cleanup;
+   return ret;
}
}
 
DRM_INFO("Screen Target Display device initialized\n");
 
return 0;
-
-err_vblank_cleanup:
-   drm_vblank_cleanup(dev);
-   return ret;
-}
-
-
-
-/**
- * vmw_kms_stdu_close_display - Cleans 

[PATCH 29/37] drm/shmob: Drop drm_vblank_cleanup

[Daniel Vetter]

It doesn't do anything in the driver load error paths that the drm
core doesn't also do.

Cc: Laurent Pinchart 
Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/shmobile/shmob_drm_drv.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/shmobile/shmob_drm_drv.c 
b/drivers/gpu/drm/shmobile/shmob_drm_drv.c
index 800d1d2c435d..c2ca07357aac 100644
--- a/drivers/gpu/drm/shmobile/shmob_drm_drv.c
+++ b/drivers/gpu/drm/shmobile/shmob_drm_drv.c
@@ -277,7 +277,7 @@ static int shmob_drm_probe(struct platform_device *pdev)
ret = drm_irq_install(ddev, platform_get_irq(pdev, 0));
if (ret < 0) {
dev_err(>dev, "failed to install IRQ handler\n");
-   goto err_vblank_cleanup;
+   goto err_modeset_cleanup;
}
 
/*
@@ -292,8 +292,6 @@ static int shmob_drm_probe(struct platform_device *pdev)
 
 err_irq_uninstall:
drm_irq_uninstall(ddev);
-err_vblank_cleanup:
-   drm_vblank_cleanup(ddev);
 err_modeset_cleanup:
drm_kms_helper_poll_fini(ddev);
drm_mode_config_cleanup(ddev);
-- 
2.11.0

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

[PATCH 25/37] drm/meson: Drop drm_vblank_cleanup

[Daniel Vetter]

Again seems just cargo-culted.

Cc: Neil Armstrong 
Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/meson/meson_drv.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/gpu/drm/meson/meson_drv.c 
b/drivers/gpu/drm/meson/meson_drv.c
index 75382f5f0fce..2c605a406ad5 100644
--- a/drivers/gpu/drm/meson/meson_drv.c
+++ b/drivers/gpu/drm/meson/meson_drv.c
@@ -285,7 +285,6 @@ static void meson_drv_unbind(struct device *dev)
drm_kms_helper_poll_fini(drm);
drm_fbdev_cma_fini(priv->fbdev);
drm_mode_config_cleanup(drm);
-   drm_vblank_cleanup(drm);
drm_dev_unref(drm);
 
 }
-- 
2.11.0

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

[PATCH 27/37] drm/nouveau: Drop drm_vblank_cleanup

[Daniel Vetter]

nouveau_display_vblank_fini is called in the load error path (where it
doesn't matter) and module unload (where vblanks have been shut down
correctly already through drm_vblank_off), we can drop it.

Cc: Ben Skeggs 
Cc: nouv...@lists.freedesktop.org
Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/nouveau/nouveau_display.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/nouveau_display.c 
b/drivers/gpu/drm/nouveau/nouveau_display.c
index 8d1df5678eaa..b9a109be989c 100644
--- a/drivers/gpu/drm/nouveau/nouveau_display.c
+++ b/drivers/gpu/drm/nouveau/nouveau_display.c
@@ -159,8 +159,6 @@ nouveau_display_vblank_fini(struct drm_device *dev)
 {
struct drm_crtc *crtc;
 
-   drm_vblank_cleanup(dev);
-
list_for_each_entry(crtc, >mode_config.crtc_list, head) {
struct nouveau_crtc *nv_crtc = nouveau_crtc(crtc);
nvif_notify_fini(_crtc->vblank);
-- 
2.11.0

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

[PATCH 33/37] drm/tegra: Drop drm_vblank_cleanup

[Daniel Vetter]

Again, doesn't seem to serve a purpose.

Cc: Thierry Reding 
Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/tegra/drm.c | 5 +
 1 file changed, 1 insertion(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/tegra/drm.c b/drivers/gpu/drm/tegra/drm.c
index 51c48a8e00ec..0d8839244c3a 100644
--- a/drivers/gpu/drm/tegra/drm.c
+++ b/drivers/gpu/drm/tegra/drm.c
@@ -213,12 +213,10 @@ static int tegra_drm_load(struct drm_device *drm, 
unsigned long flags)
 
err = tegra_drm_fb_init(drm);
if (err < 0)
-   goto vblank;
+   goto device;
 
return 0;
 
-vblank:
-   drm_vblank_cleanup(drm);
 device:
host1x_device_exit(device);
 fbdev:
@@ -247,7 +245,6 @@ static void tegra_drm_unload(struct drm_device *drm)
drm_kms_helper_poll_fini(drm);
tegra_drm_fb_exit(drm);
drm_mode_config_cleanup(drm);
-   drm_vblank_cleanup(drm);
 
err = host1x_device_exit(device);
if (err < 0)
-- 
2.11.0

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

[PATCH 11/37] drm/vblank: _ioctl posfix for ioctl handler

[Daniel Vetter]

I alwasy get confused about drm_wait_vblank for a split second until I
realize it's the ioctl handler. Unconfuse me, and do it for the legacy
modeset vblank control ioctl too.

While at it also noticed that I misplaced the irq ioctl handler in the
internal header file.

Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/drm_internal.h | 12 
 drivers/gpu/drm/drm_ioctl.c|  4 ++--
 drivers/gpu/drm/drm_vblank.c   | 22 --
 3 files changed, 14 insertions(+), 24 deletions(-)

diff --git a/drivers/gpu/drm/drm_internal.h b/drivers/gpu/drm/drm_internal.h
index 6a0cbcc84534..116de27cf8f3 100644
--- a/drivers/gpu/drm/drm_internal.h
+++ b/drivers/gpu/drm/drm_internal.h
@@ -59,12 +59,16 @@ extern unsigned int drm_timestamp_monotonic;
 void drm_vblank_disable_and_save(struct drm_device *dev, unsigned int pipe);
 
 /* IOCTLS */
-int drm_wait_vblank(struct drm_device *dev, void *data,
-   struct drm_file *filp);
+int drm_wait_vblank_ioctl(struct drm_device *dev, void *data,
+ struct drm_file *filp);
+int drm_legacy_modeset_ctl_ioctl(struct drm_device *dev, void *data,
+struct drm_file *file_priv);
+
+/* drm_irq.c */
+
+/* IOCTLS */
 int drm_legacy_irq_control(struct drm_device *dev, void *data,
   struct drm_file *file_priv);
-int drm_legacy_modeset_ctl(struct drm_device *dev, void *data,
-  struct drm_file *file_priv);
 
 /* drm_auth.c */
 int drm_getmagic(struct drm_device *dev, void *data,
diff --git a/drivers/gpu/drm/drm_ioctl.c b/drivers/gpu/drm/drm_ioctl.c
index 3690706f051d..306c29bd0eb1 100644
--- a/drivers/gpu/drm/drm_ioctl.c
+++ b/drivers/gpu/drm/drm_ioctl.c
@@ -600,9 +600,9 @@ static const struct drm_ioctl_desc drm_ioctls[] = {
DRM_IOCTL_DEF(DRM_IOCTL_SG_ALLOC, drm_legacy_sg_alloc, 
DRM_AUTH|DRM_MASTER|DRM_ROOT_ONLY),
DRM_IOCTL_DEF(DRM_IOCTL_SG_FREE, drm_legacy_sg_free, 
DRM_AUTH|DRM_MASTER|DRM_ROOT_ONLY),
 
-   DRM_IOCTL_DEF(DRM_IOCTL_WAIT_VBLANK, drm_wait_vblank, 
DRM_MASTER|DRM_UNLOCKED),
+   DRM_IOCTL_DEF(DRM_IOCTL_WAIT_VBLANK, drm_wait_vblank_ioctl, 
DRM_MASTER|DRM_UNLOCKED),
 
-   DRM_IOCTL_DEF(DRM_IOCTL_MODESET_CTL, drm_legacy_modeset_ctl, 0),
+   DRM_IOCTL_DEF(DRM_IOCTL_MODESET_CTL, drm_legacy_modeset_ctl_ioctl, 0),
 
DRM_IOCTL_DEF(DRM_IOCTL_UPDATE_DRAW, drm_noop, 
DRM_AUTH|DRM_MASTER|DRM_ROOT_ONLY),
 
diff --git a/drivers/gpu/drm/drm_vblank.c b/drivers/gpu/drm/drm_vblank.c
index 73023d463dc7..7883f3218105 100644
--- a/drivers/gpu/drm/drm_vblank.c
+++ b/drivers/gpu/drm/drm_vblank.c
@@ -1292,8 +1292,8 @@ static void drm_legacy_vblank_post_modeset(struct 
drm_device *dev,
}
 }
 
-int drm_legacy_modeset_ctl(struct drm_device *dev, void *data,
-  struct drm_file *file_priv)
+int drm_legacy_modeset_ctl_ioctl(struct drm_device *dev, void *data,
+struct drm_file *file_priv)
 {
struct drm_modeset_ctl *modeset = data;
unsigned int pipe;
@@ -1412,22 +1412,8 @@ static bool drm_wait_vblank_is_query(union 
drm_wait_vblank *vblwait)
  _DRM_VBLANK_NEXTONMISS));
 }
 
-/*
- * Wait for VBLANK.
- *
- * \param inode device inode.
- * \param file_priv DRM file private.
- * \param cmd command.
- * \param data user argument, pointing to a drm_wait_vblank structure.
- * \return zero on success or a negative number on failure.
- *
- * This function enables the vblank interrupt on the pipe requested, then
- * sleeps waiting for the requested sequence number to occur, and drops
- * the vblank interrupt refcount afterwards. (vblank IRQ disable follows that
- * after a timeout with no further vblank waits scheduled).
- */
-int drm_wait_vblank(struct drm_device *dev, void *data,
-   struct drm_file *file_priv)
+int drm_wait_vblank_ioctl(struct drm_device *dev, void *data,
+ struct drm_file *file_priv)
 {
struct drm_vblank_crtc *vblank;
union drm_wait_vblank *vblwait = data;
-- 
2.11.0

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

[PATCH 34/37] drm/udl: Drop drm_vblank_cleanup

[Daniel Vetter]

udl doesn't shut down the display, so stopping the vblank isn't going
to do much good either. Just drop it.

Cc: Dave Airlie 
Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/udl/udl_main.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/gpu/drm/udl/udl_main.c b/drivers/gpu/drm/udl/udl_main.c
index a9d93b871a15..0328b2c7b210 100644
--- a/drivers/gpu/drm/udl/udl_main.c
+++ b/drivers/gpu/drm/udl/udl_main.c
@@ -371,8 +371,6 @@ void udl_driver_unload(struct drm_device *dev)
 {
struct udl_device *udl = dev->dev_private;
 
-   drm_vblank_cleanup(dev);
-
if (udl->urbs.count)
udl_free_urb_list(dev);
 
-- 
2.11.0

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

[PATCH 24/37] drm/mtk: Drop drm_vblank_cleanup

[Daniel Vetter]

Seems entirely cargo-culted.

Cc: CK Hu 
Cc: Philipp Zabel 
Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/mediatek/mtk_drm_drv.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/gpu/drm/mediatek/mtk_drm_drv.c 
b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
index f6c8ec4c7dbc..56f802d0a51c 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_drv.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
@@ -266,7 +266,6 @@ static void mtk_drm_kms_deinit(struct drm_device *drm)
 {
drm_kms_helper_poll_fini(drm);
 
-   drm_vblank_cleanup(drm);
component_unbind_all(drm->dev, drm);
drm_mode_config_cleanup(drm);
 }
-- 
2.11.0

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

[PATCH 21/37] drm/kirin: Drop drm_vblank_cleanup

[Daniel Vetter]

Again we probably want a drm_atomic_helper_shutdown somewhere, but
that's a bit more analysis.

Cc: Xinliang Liu 
Cc: Rongrong Zou 
Cc: Xinwei Kong 
Cc: Chen Feng 
Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c 
b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c
index 9c903672f582..8065d6cb1d7f 100644
--- a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c
+++ b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c
@@ -41,7 +41,6 @@ static int kirin_drm_kms_cleanup(struct drm_device *dev)
}
 #endif
drm_kms_helper_poll_fini(dev);
-   drm_vblank_cleanup(dev);
dc_ops->cleanup(to_platform_device(dev->dev));
drm_mode_config_cleanup(dev);
devm_kfree(dev->dev, priv);
-- 
2.11.0

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

[PATCH 19/37] drm/fsl: Drop drm_vblank_cleanup

[Daniel Vetter]

Again cleanup before irq disabling doesn't really stop the races,
so just drop it. Proper fix would be to put drm_atomic_helper_shutdown
before everything gets cleaned up.

Cc: Stefan Agner 
Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c 
b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c
index 6e00f4b267f1..b34d09b59eee 100644
--- a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c
+++ b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c
@@ -109,7 +109,6 @@ static int fsl_dcu_load(struct drm_device *dev, unsigned 
long flags)
drm_fbdev_cma_fini(fsl_dev->fbdev);
 
drm_mode_config_cleanup(dev);
-   drm_vblank_cleanup(dev);
drm_irq_uninstall(dev);
dev->dev_private = NULL;
 
@@ -127,7 +126,6 @@ static void fsl_dcu_unload(struct drm_device *dev)
drm_fbdev_cma_fini(fsl_dev->fbdev);
 
drm_mode_config_cleanup(dev);
-   drm_vblank_cleanup(dev);
drm_irq_uninstall(dev);
 
dev->dev_private = NULL;
-- 
2.11.0

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

[PATCH 28/37] drm/rockchip: Drop drm_vblank_cleanup

[Daniel Vetter]

Either not relevant (in the load error paths) or done better already
(in the unload code, by calling drm_atomic_helper_shutdown). Drop it.

Cc: Mark Yao 
Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/rockchip/rockchip_drm_drv.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_drv.c 
b/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
index c6b1b7f3a2a3..b9fbf4b1e8f0 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
@@ -177,7 +177,6 @@ static int rockchip_drm_bind(struct device *dev)
rockchip_drm_fbdev_fini(drm_dev);
 err_kms_helper_poll_fini:
drm_kms_helper_poll_fini(drm_dev);
-   drm_vblank_cleanup(drm_dev);
 err_unbind_all:
component_unbind_all(dev, drm_dev);
 err_mode_config_cleanup:
@@ -200,7 +199,6 @@ static void rockchip_drm_unbind(struct device *dev)
drm_kms_helper_poll_fini(drm_dev);
 
drm_atomic_helper_shutdown(drm_dev);
-   drm_vblank_cleanup(drm_dev);
component_unbind_all(dev, drm_dev);
drm_mode_config_cleanup(drm_dev);
rockchip_iommu_cleanup(drm_dev);
-- 
2.11.0

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

[PATCH 23/37] drm/imx: Drop drm_vblank_cleanup

[Daniel Vetter]

It's only done in the driver load error path, where vblanks don't need
to be quiescent anyway. And that's all drm_vblank_cleanup does, since
the core will release the vblank allocations on its own already. So
drop it.

Cc: Philipp Zabel 
Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/imx/imx-drm-core.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/imx/imx-drm-core.c 
b/drivers/gpu/drm/imx/imx-drm-core.c
index 50add2f9e250..95e2181963d9 100644
--- a/drivers/gpu/drm/imx/imx-drm-core.c
+++ b/drivers/gpu/drm/imx/imx-drm-core.c
@@ -278,7 +278,7 @@ static int imx_drm_bind(struct device *dev)
/* Now try and bind all our sub-components */
ret = component_bind_all(dev, drm);
if (ret)
-   goto err_vblank;
+   goto err_kms;
 
drm_mode_config_reset(drm);
 
@@ -316,8 +316,6 @@ static int imx_drm_bind(struct device *dev)
 err_unbind:
 #endif
component_unbind_all(drm->dev, drm);
-err_vblank:
-   drm_vblank_cleanup(drm);
 err_kms:
drm_mode_config_cleanup(drm);
 err_unref:
-- 
2.11.0

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

[PATCH 09/37] drm/doc: Drop empty include for drm_color_mgmt.h

[Daniel Vetter]

I'm fed up staring at the error message from kernel-doc that
it can't find anything.

Signed-off-by: Daniel Vetter 
---
 Documentation/gpu/drm-kms.rst | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/Documentation/gpu/drm-kms.rst b/Documentation/gpu/drm-kms.rst
index 2d77c9580164..0749000ab3d7 100644
--- a/Documentation/gpu/drm-kms.rst
+++ b/Documentation/gpu/drm-kms.rst
@@ -523,9 +523,6 @@ Color Management Properties
 .. kernel-doc:: drivers/gpu/drm/drm_color_mgmt.c
:doc: overview
 
-.. kernel-doc:: include/drm/drm_color_mgmt.h
-   :internal:
-
 .. kernel-doc:: drivers/gpu/drm/drm_color_mgmt.c
:export:
 
-- 
2.11.0

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

[PATCH 20/37] drm/hibmc: Drop drm_vblank_cleanup

[Daniel Vetter]

So this seems to be the first driver that does it the right way round,
so fix it up by calling drm_atomic_helper_shutdown instead. We need to
do that before the last kms user is gone (fbdev emulation), but before
we start shutting down hw stuff like interrupts.

Cc: Xinliang Liu 
Cc: Rongrong Zou 
Cc: Xinwei Kong 
Cc: Chen Feng 
Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c 
b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
index 2ffdbf9801bd..4d018ca98581 100644
--- a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
+++ b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
@@ -276,11 +276,12 @@ static int hibmc_unload(struct drm_device *dev)
 
hibmc_fbdev_fini(priv);
 
+   drm_atomic_helper_shutdown(dev);
+
if (dev->irq_enabled)
drm_irq_uninstall(dev);
if (priv->msi_enabled)
pci_disable_msi(dev->pdev);
-   drm_vblank_cleanup(dev);
 
hibmc_kms_fini(priv);
hibmc_mm_fini(priv);
-- 
2.11.0

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

[PATCH 17/37] drm/atmel: Drop drm_vblank_cleanup

[Daniel Vetter]

Again almost correct, but since interrupts are shut down after vblank
still a race. Proper cleanup would call drm_atomic_helper_shutdown to
make sure this really is safe.

v2: Remove misplace malidp hunk (Liviu).

Cc: Boris Brezillon 
Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c 
b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
index f4a3065f7f51..288dd4b70126 100644
--- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
+++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
@@ -678,7 +678,6 @@ static void atmel_hlcdc_dc_unload(struct drm_device *dev)
flush_workqueue(dc->wq);
drm_kms_helper_poll_fini(dev);
drm_mode_config_cleanup(dev);
-   drm_vblank_cleanup(dev);
 
pm_runtime_get_sync(dev->dev);
drm_irq_uninstall(dev);
-- 
2.11.0

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

[PATCH 16/37] drm/hdlcd|mali: Drop drm_vblank_cleanup

[Daniel Vetter]

IRQs are properly shut down, so it almost works as race-free shutdown.
Except the irq is stopped after the vblank stuff, so boom anyway.
Proper way would be to call drm_atomic_helper_shutdown before any of
the kms things gets stopped. So no harm in removing the
drm_vblank_cleanup here really.

Same story for both hdlcd and mali.

v2: Move misplaced malidp hunk to this patch (Liviu).

Cc: Liviu Dudau 
Cc: Brian Starkey 
Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/arm/hdlcd_drv.c  | 2 --
 drivers/gpu/drm/arm/malidp_drv.c | 2 --
 2 files changed, 4 deletions(-)

diff --git a/drivers/gpu/drm/arm/hdlcd_drv.c b/drivers/gpu/drm/arm/hdlcd_drv.c
index 0f49c4b12772..345c8357b273 100644
--- a/drivers/gpu/drm/arm/hdlcd_drv.c
+++ b/drivers/gpu/drm/arm/hdlcd_drv.c
@@ -340,7 +340,6 @@ static int hdlcd_drm_bind(struct device *dev)
}
 err_fbdev:
drm_kms_helper_poll_fini(drm);
-   drm_vblank_cleanup(drm);
 err_vblank:
pm_runtime_disable(drm->dev);
 err_pm_active:
@@ -368,7 +367,6 @@ static void hdlcd_drm_unbind(struct device *dev)
}
drm_kms_helper_poll_fini(drm);
component_unbind_all(dev, drm);
-   drm_vblank_cleanup(drm);
pm_runtime_get_sync(drm->dev);
drm_irq_uninstall(drm);
pm_runtime_put_sync(drm->dev);
diff --git a/drivers/gpu/drm/arm/malidp_drv.c b/drivers/gpu/drm/arm/malidp_drv.c
index 0d3eb537d08b..01b13d219917 100644
--- a/drivers/gpu/drm/arm/malidp_drv.c
+++ b/drivers/gpu/drm/arm/malidp_drv.c
@@ -652,7 +652,6 @@ static int malidp_bind(struct device *dev)
drm_kms_helper_poll_fini(drm);
 fbdev_fail:
pm_runtime_get_sync(dev);
-   drm_vblank_cleanup(drm);
 vblank_fail:
malidp_se_irq_fini(drm);
malidp_de_irq_fini(drm);
@@ -692,7 +691,6 @@ static void malidp_unbind(struct device *dev)
}
drm_kms_helper_poll_fini(drm);
pm_runtime_get_sync(dev);
-   drm_vblank_cleanup(drm);
malidp_se_irq_fini(drm);
malidp_de_irq_fini(drm);
component_unbind_all(dev, drm);
-- 
2.11.0

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

[PATCH 12/37] drm/vblank: Consistent drm_crtc_ prefix

[Daniel Vetter]

We use drm_crtc_ for all the new-style vblank functions which directly
take a struct drm_crtc *. drm_accurate_vblank_count was the odd one
out, correct this to appease my OCD.

Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/drm_vblank.c   | 8 
 drivers/gpu/drm/i915/i915_irq.c| 2 +-
 drivers/gpu/drm/i915/intel_display.c   | 2 +-
 drivers/gpu/drm/nouveau/nv50_display.c | 2 +-
 include/drm/drm_vblank.h   | 2 +-
 5 files changed, 8 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/drm_vblank.c b/drivers/gpu/drm/drm_vblank.c
index 7883f3218105..9263bacb6ebd 100644
--- a/drivers/gpu/drm/drm_vblank.c
+++ b/drivers/gpu/drm/drm_vblank.c
@@ -294,7 +294,7 @@ static u32 drm_vblank_count(struct drm_device *dev, 
unsigned int pipe)
 }
 
 /**
- * drm_accurate_vblank_count - retrieve the master vblank counter
+ * drm_crtc_accurate_vblank_count - retrieve the master vblank counter
  * @crtc: which counter to retrieve
  *
  * This function is similar to drm_crtc_vblank_count() but this function
@@ -304,7 +304,7 @@ static u32 drm_vblank_count(struct drm_device *dev, 
unsigned int pipe)
  * This is mostly useful for hardware that can obtain the scanout position, but
  * doesn't have a hardware frame counter.
  */
-u32 drm_accurate_vblank_count(struct drm_crtc *crtc)
+u32 drm_crtc_accurate_vblank_count(struct drm_crtc *crtc)
 {
struct drm_device *dev = crtc->dev;
unsigned int pipe = drm_crtc_index(crtc);
@@ -323,7 +323,7 @@ u32 drm_accurate_vblank_count(struct drm_crtc *crtc)
 
return vblank;
 }
-EXPORT_SYMBOL(drm_accurate_vblank_count);
+EXPORT_SYMBOL(drm_crtc_accurate_vblank_count);
 
 static void __disable_vblank(struct drm_device *dev, unsigned int pipe)
 {
@@ -771,7 +771,7 @@ drm_get_last_vbltimestamp(struct drm_device *dev, unsigned 
int pipe,
  * vblank events since the system was booted, including lost events due to
  * modesetting activity. Note that this timer isn't correct against a racing
  * vblank interrupt (since it only reports the software vblank counter), see
- * drm_accurate_vblank_count() for such use-cases.
+ * drm_crtc_accurate_vblank_count() for such use-cases.
  *
  * Returns:
  * The software vblank counter.
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 69400ee928e5..912905fa6e3b 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -1603,7 +1603,7 @@ static void display_pipe_crc_irq_handler(struct 
drm_i915_private *dev_priv,
crcs[3] = crc3;
crcs[4] = crc4;
drm_crtc_add_crc_entry(>base, true,
-  drm_accurate_vblank_count(>base),
+  
drm_crtc_accurate_vblank_count(>base),
   crcs);
}
 }
diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 7fa21df5bcd7..eeb766fd4a16 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -12753,7 +12753,7 @@ u32 intel_crtc_get_vblank_counter(struct intel_crtc 
*crtc)
struct drm_device *dev = crtc->base.dev;
 
if (!dev->max_vblank_count)
-   return drm_accurate_vblank_count(>base);
+   return drm_crtc_accurate_vblank_count(>base);
 
return dev->driver->get_vblank_counter(dev, crtc->pipe);
 }
diff --git a/drivers/gpu/drm/nouveau/nv50_display.c 
b/drivers/gpu/drm/nouveau/nv50_display.c
index 9303daa79aba..0ea17ad97819 100644
--- a/drivers/gpu/drm/nouveau/nv50_display.c
+++ b/drivers/gpu/drm/nouveau/nv50_display.c
@@ -4029,7 +4029,7 @@ nv50_disp_atomic_commit_tail(struct drm_atomic_state 
*state)
if (crtc->state->event) {
unsigned long flags;
/* Get correct count/ts if racing with vblank irq */
-   drm_accurate_vblank_count(crtc);
+   drm_crtc_accurate_vblank_count(crtc);
spin_lock_irqsave(>dev->event_lock, flags);
drm_crtc_send_vblank_event(crtc, crtc->state->event);
spin_unlock_irqrestore(>dev->event_lock, flags);
diff --git a/include/drm/drm_vblank.h b/include/drm/drm_vblank.h
index 4cde47332dfa..4ceef128582f 100644
--- a/include/drm/drm_vblank.h
+++ b/include/drm/drm_vblank.h
@@ -169,7 +169,7 @@ void drm_crtc_vblank_off(struct drm_crtc *crtc);
 void drm_crtc_vblank_reset(struct drm_crtc *crtc);
 void drm_crtc_vblank_on(struct drm_crtc *crtc);
 void drm_vblank_cleanup(struct drm_device *dev);
-u32 drm_accurate_vblank_count(struct drm_crtc *crtc);
+u32 drm_crtc_accurate_vblank_count(struct drm_crtc *crtc);
 
 bool drm_calc_vbltimestamp_from_scanoutpos(struct drm_device *dev,
   unsigned int pipe, int *max_error,
-- 
2.11.0

___
dri-devel mailing list

[PATCH 15/37] drm/arcgpu: Drop drm_vblank_cleanup

[Daniel Vetter]

CRTC don't seem to get shut down in a controlled fashion, but no one
bothers to stop interrupts either so this races no matter what. Might
as well remove it. A call to drm_atomic_helper_shutdown would be
pretty sweet somewhere (and maybe getting rid of the load/unload
callbacks while at it).

Cc: Alexey Brodkin 
Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/arc/arcpgu_drv.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/gpu/drm/arc/arcpgu_drv.c b/drivers/gpu/drm/arc/arcpgu_drv.c
index 1926b200e4cb..3e43a5d4fb09 100644
--- a/drivers/gpu/drm/arc/arcpgu_drv.c
+++ b/drivers/gpu/drm/arc/arcpgu_drv.c
@@ -155,7 +155,6 @@ static int arcpgu_unload(struct drm_device *drm)
arcpgu->fbdev = NULL;
}
drm_kms_helper_poll_fini(drm);
-   drm_vblank_cleanup(drm);
drm_mode_config_cleanup(drm);
 
return 0;
-- 
2.11.0

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

[PATCH 08/37] drm/doc: Polish irq helper documentation

[Daniel Vetter]

Pull a (much shorter) overview into drm_irq.c, and instead put the
callback documentation into in-line comments in drm_drv.h.

Signed-off-by: Daniel Vetter 
---
 Documentation/gpu/drm-internals.rst | 62 +
 drivers/gpu/drm/drm_irq.c   | 30 +++---
 drivers/gpu/drm/drm_vblank.c|  3 ++
 include/drm/drmP.h  |  9 --
 include/drm/drm_drv.h   | 33 ++--
 5 files changed, 74 insertions(+), 63 deletions(-)

diff --git a/Documentation/gpu/drm-internals.rst 
b/Documentation/gpu/drm-internals.rst
index d218dd29221a..82b406d3d377 100644
--- a/Documentation/gpu/drm-internals.rst
+++ b/Documentation/gpu/drm-internals.rst
@@ -149,60 +149,14 @@ Device Instance and Driver Handling
 Driver Load
 ---
 
-IRQ Registration
-
-
-The DRM core tries to facilitate IRQ handler registration and
-unregistration by providing :c:func:`drm_irq_install()` and
-:c:func:`drm_irq_uninstall()` functions. Those functions only
-support a single interrupt per device, devices that use more than one
-IRQs need to be handled manually.
-
-Managed IRQ Registration
-
-
-:c:func:`drm_irq_install()` starts by calling the irq_preinstall
-driver operation. The operation is optional and must make sure that the
-interrupt will not get fired by clearing all pending interrupt flags or
-disabling the interrupt.
-
-The passed-in IRQ will then be requested by a call to
-:c:func:`request_irq()`. If the DRIVER_IRQ_SHARED driver feature
-flag is set, a shared (IRQF_SHARED) IRQ handler will be requested.
-
-The IRQ handler function must be provided as the mandatory irq_handler
-driver operation. It will get passed directly to
-:c:func:`request_irq()` and thus has the same prototype as all IRQ
-handlers. It will get called with a pointer to the DRM device as the
-second argument.
-
-Finally the function calls the optional irq_postinstall driver
-operation. The operation usually enables interrupts (excluding the
-vblank interrupt, which is enabled separately), but drivers may choose
-to enable/disable interrupts at a different time.
-
-:c:func:`drm_irq_uninstall()` is similarly used to uninstall an
-IRQ handler. It starts by waking up all processes waiting on a vblank
-interrupt to make sure they don't hang, and then calls the optional
-irq_uninstall driver operation. The operation must disable all hardware
-interrupts. Finally the function frees the IRQ by calling
-:c:func:`free_irq()`.
-
-Manual IRQ Registration
-'''
-
-Drivers that require multiple interrupt handlers can't use the managed
-IRQ registration functions. In that case IRQs must be registered and
-unregistered manually (usually with the :c:func:`request_irq()` and
-:c:func:`free_irq()` functions, or their :c:func:`devm_request_irq()` and
-:c:func:`devm_free_irq()` equivalents).
-
-When manually registering IRQs, drivers must not set the
-DRIVER_HAVE_IRQ driver feature flag, and must not provide the
-irq_handler driver operation. They must set the :c:type:`struct
-drm_device ` irq_enabled field to 1 upon
-registration of the IRQs, and clear it to 0 after unregistering the
-IRQs.
+IRQ Helper Library
+~~
+
+.. kernel-doc:: drivers/gpu/drm/drm_irq.c
+   :doc: irq helpers
+
+.. kernel-doc:: drivers/gpu/drm/drm_irq.c
+   :export:
 
 Memory Manager Initialization
 ~
diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
index 28d736c3fcb4..3b04c25100ae 100644
--- a/drivers/gpu/drm/drm_irq.c
+++ b/drivers/gpu/drm/drm_irq.c
@@ -62,19 +62,39 @@
 #include "drm_internal.h"
 
 /**
+ * DOC: irq helpers
+ *
+ * The DRM core provides very simple support helpers to enable IRQ handling on 
a
+ * device through the drm_irq_install() and drm_irq_uninstall() functions. This
+ * only supports devices with a single interrupt on the main device stored in
+ * _device.dev and set as the device paramter in drm_dev_alloc().
+ *
+ * These IRQ helpers are strictly optional. Drivers which roll their own only
+ * need to set _device.irq_enabled to signal the DRM core that vblank
+ * interrupts are working. Since these helpers don't automatically clean up the
+ * requested interrupt like e.g. devm_request_irq() they're not really
+ * recommended.
+ */
+
+/**
  * drm_irq_install - install IRQ handler
  * @dev: DRM device
  * @irq: IRQ number to install the handler for
  *
  * Initializes the IRQ related data. Installs the handler, calling the driver
- * irq_preinstall() and irq_postinstall() functions before and after the
- * installation.
+ * _driver.irq_preinstall and _driver.irq_postinstall functions before
+ * and after the installation.
  *
  * This is the simplified helper interface provided for drivers with no special
  * needs. Drivers which need to install interrupt handlers for multiple
  * interrupts must instead set _device.irq_enabled to signal the DRM core
  * that 

[PATCH 04/37] drm: Remove drm_driver->set_busid hook

[Daniel Vetter]

The only special-case is pci devices, and we can easily handle this in
the core. Do so and drop a pile of boilerplate from drivers.

Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 1 -
 drivers/gpu/drm/ast/ast_drv.c   | 1 -
 drivers/gpu/drm/bochs/bochs_drv.c   | 1 -
 drivers/gpu/drm/cirrus/cirrus_drv.c | 1 -
 drivers/gpu/drm/drm_internal.h  | 1 +
 drivers/gpu/drm/drm_ioctl.c | 4 ++--
 drivers/gpu/drm/drm_pci.c   | 1 -
 drivers/gpu/drm/gma500/psb_drv.c| 1 -
 drivers/gpu/drm/i810/i810_drv.c | 1 -
 drivers/gpu/drm/i915/i915_drv.c | 1 -
 drivers/gpu/drm/mga/mga_drv.c   | 1 -
 drivers/gpu/drm/mgag200/mgag200_drv.c   | 1 -
 drivers/gpu/drm/nouveau/nouveau_drm.c   | 1 -
 drivers/gpu/drm/qxl/qxl_drv.c   | 2 --
 drivers/gpu/drm/r128/r128_drv.c | 1 -
 drivers/gpu/drm/radeon/radeon_drv.c | 1 -
 drivers/gpu/drm/savage/savage_drv.c | 1 -
 drivers/gpu/drm/sis/sis_drv.c   | 1 -
 drivers/gpu/drm/tdfx/tdfx_drv.c | 1 -
 drivers/gpu/drm/via/via_drv.c   | 1 -
 drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 1 -
 include/drm/drm_drv.h   | 2 --
 include/drm/drm_pci.h   | 7 ---
 23 files changed, 3 insertions(+), 31 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
index 31eddd85eb40..e7a4bce6358d 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
@@ -734,7 +734,6 @@ static struct drm_driver kms_driver = {
.open = amdgpu_driver_open_kms,
.postclose = amdgpu_driver_postclose_kms,
.lastclose = amdgpu_driver_lastclose_kms,
-   .set_busid = drm_pci_set_busid,
.unload = amdgpu_driver_unload_kms,
.get_vblank_counter = amdgpu_get_vblank_counter_kms,
.enable_vblank = amdgpu_enable_vblank_kms,
diff --git a/drivers/gpu/drm/ast/ast_drv.c b/drivers/gpu/drm/ast/ast_drv.c
index fd7c9eec92e4..f6794745a024 100644
--- a/drivers/gpu/drm/ast/ast_drv.c
+++ b/drivers/gpu/drm/ast/ast_drv.c
@@ -197,7 +197,6 @@ static struct drm_driver driver = {
 
.load = ast_driver_load,
.unload = ast_driver_unload,
-   .set_busid = drm_pci_set_busid,
 
.fops = _fops,
.name = DRIVER_NAME,
diff --git a/drivers/gpu/drm/bochs/bochs_drv.c 
b/drivers/gpu/drm/bochs/bochs_drv.c
index aa342515ddf4..8fccd3cf000d 100644
--- a/drivers/gpu/drm/bochs/bochs_drv.c
+++ b/drivers/gpu/drm/bochs/bochs_drv.c
@@ -84,7 +84,6 @@ static struct drm_driver bochs_driver = {
.driver_features= DRIVER_GEM | DRIVER_MODESET,
.load   = bochs_load,
.unload = bochs_unload,
-   .set_busid  = drm_pci_set_busid,
.fops   = _fops,
.name   = "bochs-drm",
.desc   = "bochs dispi vga interface (qemu stdvga)",
diff --git a/drivers/gpu/drm/cirrus/cirrus_drv.c 
b/drivers/gpu/drm/cirrus/cirrus_drv.c
index d893ea21a359..c48b9eb76712 100644
--- a/drivers/gpu/drm/cirrus/cirrus_drv.c
+++ b/drivers/gpu/drm/cirrus/cirrus_drv.c
@@ -132,7 +132,6 @@ static struct drm_driver driver = {
.driver_features = DRIVER_MODESET | DRIVER_GEM,
.load = cirrus_driver_load,
.unload = cirrus_driver_unload,
-   .set_busid = drm_pci_set_busid,
.fops = _driver_fops,
.name = DRIVER_NAME,
.desc = DRIVER_DESC,
diff --git a/drivers/gpu/drm/drm_internal.h b/drivers/gpu/drm/drm_internal.h
index 3d8e8f878924..bca2c66c5d28 100644
--- a/drivers/gpu/drm/drm_internal.h
+++ b/drivers/gpu/drm/drm_internal.h
@@ -32,6 +32,7 @@ void drm_lastclose(struct drm_device *dev);
 int drm_irq_by_busid(struct drm_device *dev, void *data,
 struct drm_file *file_priv);
 void drm_pci_agp_destroy(struct drm_device *dev);
+int drm_pci_set_busid(struct drm_device *dev, struct drm_master *master);
 
 /* drm_prime.c */
 int drm_prime_handle_to_fd_ioctl(struct drm_device *dev, void *data,
diff --git a/drivers/gpu/drm/drm_ioctl.c b/drivers/gpu/drm/drm_ioctl.c
index 505c0eda2551..a423bf60e230 100644
--- a/drivers/gpu/drm/drm_ioctl.c
+++ b/drivers/gpu/drm/drm_ioctl.c
@@ -143,8 +143,8 @@ static int drm_set_busid(struct drm_device *dev, struct 
drm_file *file_priv)
if (master->unique != NULL)
drm_unset_busid(dev, master);
 
-   if (dev->driver->set_busid) {
-   ret = dev->driver->set_busid(dev, master);
+   if (dev_is_pci(dev->dev)) {
+   ret = drm_pci_set_busid(dev, master);
if (ret) {
drm_unset_busid(dev, master);
return ret;
diff --git a/drivers/gpu/drm/drm_pci.c b/drivers/gpu/drm/drm_pci.c
index 1eb4fc3eee20..ad31d95e77c9 100644
--- a/drivers/gpu/drm/drm_pci.c
+++ b/drivers/gpu/drm/drm_pci.c
@@ -149,7 +149,6 @@ int 

[PATCH 02/37] drm: Remove drm_device->virtdev

[Daniel Vetter]

This is a leftover from the drm_bus days, where we've had a
bus-specific device type for every bus type in drm_device. Except for
pci (which we can't remove because dri1 drivers) this is all gone. And
the virt driver also doesn't really need it, dev_to_virtio works
perfectly fine.

Cc: David Airlie 
Cc: Gerd Hoffmann 
Cc: virtualizat...@lists.linux-foundation.org
Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/virtio/virtgpu_drm_bus.c | 1 -
 drivers/gpu/drm/virtio/virtgpu_kms.c | 4 ++--
 include/drm/drmP.h   | 2 --
 3 files changed, 2 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/virtio/virtgpu_drm_bus.c 
b/drivers/gpu/drm/virtio/virtgpu_drm_bus.c
index 43e1d5916c6c..7df8d0c9026a 100644
--- a/drivers/gpu/drm/virtio/virtgpu_drm_bus.c
+++ b/drivers/gpu/drm/virtio/virtgpu_drm_bus.c
@@ -56,7 +56,6 @@ int drm_virtio_init(struct drm_driver *driver, struct 
virtio_device *vdev)
dev = drm_dev_alloc(driver, >dev);
if (IS_ERR(dev))
return PTR_ERR(dev);
-   dev->virtdev = vdev;
vdev->priv = dev;
 
if (strcmp(vdev->dev.parent->bus->name, "pci") == 0) {
diff --git a/drivers/gpu/drm/virtio/virtgpu_kms.c 
b/drivers/gpu/drm/virtio/virtgpu_kms.c
index 1e1c90b30d4a..6400506a06b0 100644
--- a/drivers/gpu/drm/virtio/virtgpu_kms.c
+++ b/drivers/gpu/drm/virtio/virtgpu_kms.c
@@ -138,7 +138,7 @@ int virtio_gpu_driver_load(struct drm_device *dev, unsigned 
long flags)
u32 num_scanouts, num_capsets;
int ret;
 
-   if (!virtio_has_feature(dev->virtdev, VIRTIO_F_VERSION_1))
+   if (!virtio_has_feature(dev_to_virtio(dev->dev), VIRTIO_F_VERSION_1))
return -ENODEV;
 
vgdev = kzalloc(sizeof(struct virtio_gpu_device), GFP_KERNEL);
@@ -147,7 +147,7 @@ int virtio_gpu_driver_load(struct drm_device *dev, unsigned 
long flags)
 
vgdev->ddev = dev;
dev->dev_private = vgdev;
-   vgdev->vdev = dev->virtdev;
+   vgdev->vdev = dev_to_virtio(dev->dev);
vgdev->dev = dev->dev;
 
spin_lock_init(>display_info_lock);
diff --git a/include/drm/drmP.h b/include/drm/drmP.h
index 575b29b47811..c363f2fdff31 100644
--- a/include/drm/drmP.h
+++ b/include/drm/drmP.h
@@ -412,8 +412,6 @@ struct drm_device {
struct pci_controller *hose;
 #endif
 
-   struct virtio_device *virtdev;
-
struct drm_sg_mem *sg;  /**< Scatter gather memory */
unsigned int num_crtcs;  /**< Number of CRTCs on this 
device */
 
-- 
2.11.0

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

[PATCH 03/37] drm/udl: Remove dummy busid callback

[Daniel Vetter]

Since

commit ca8e2ad71013049bc88a10b11d83712bfe56cdd4
Author: Thierry Reding 
Date:   Fri Apr 11 15:23:00 2014 +0200

drm: Introduce drm_dev_set_unique()

the ->set_busid callback is optional. On top of that the udl one isn't
really fully compliant with the drm uabi, but since only modesetting
ever binds to it (there's no 3d accel on udl) it doesn't matter.

Still, can't harm to aling and use the default used by everyone else.

Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/udl/udl_drv.c | 6 --
 1 file changed, 6 deletions(-)

diff --git a/drivers/gpu/drm/udl/udl_drv.c b/drivers/gpu/drm/udl/udl_drv.c
index cd8b01727734..0f02e1acf0ba 100644
--- a/drivers/gpu/drm/udl/udl_drv.c
+++ b/drivers/gpu/drm/udl/udl_drv.c
@@ -11,11 +11,6 @@
 #include 
 #include "udl_drv.h"
 
-static int udl_driver_set_busid(struct drm_device *d, struct drm_master *m)
-{
-   return 0;
-}
-
 static int udl_usb_suspend(struct usb_interface *interface,
   pm_message_t message)
 {
@@ -52,7 +47,6 @@ static struct drm_driver driver = {
.driver_features = DRIVER_MODESET | DRIVER_GEM | DRIVER_PRIME,
.load = udl_driver_load,
.unload = udl_driver_unload,
-   .set_busid = udl_driver_set_busid,
 
/* gem hooks */
.gem_free_object = udl_gem_free_object,
-- 
2.11.0

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

[PATCH 01/37] drm/doc: move printf helpers out of drmP.h

[Daniel Vetter]

And document them lightly. Unfortunately kernel-doc isn't the most
awesome for documenting #defines that don't look like functions, it
makes functions out of them :-/

Signed-off-by: Daniel Vetter 
---
 include/drm/drmP.h  | 17 -
 include/drm/drm_modes.h | 17 +
 include/drm/drm_rect.h  | 27 +++
 3 files changed, 44 insertions(+), 17 deletions(-)

diff --git a/include/drm/drmP.h b/include/drm/drmP.h
index b9b5566acfe6..575b29b47811 100644
--- a/include/drm/drmP.h
+++ b/include/drm/drmP.h
@@ -292,23 +292,6 @@ struct pci_controller;
 /* Format strings and argument splitters to simplify printing
  * various "complex" objects
  */
-#define DRM_MODE_FMT"%d:\"%s\" %d %d %d %d %d %d %d %d %d %d 0x%x 0x%x"
-#define DRM_MODE_ARG(m) \
-   (m)->base.id, (m)->name, (m)->vrefresh, (m)->clock, \
-   (m)->hdisplay, (m)->hsync_start, (m)->hsync_end, (m)->htotal, \
-   (m)->vdisplay, (m)->vsync_start, (m)->vsync_end, (m)->vtotal, \
-   (m)->type, (m)->flags
-
-#define DRM_RECT_FMT"%dx%d%+d%+d"
-#define DRM_RECT_ARG(r) drm_rect_width(r), drm_rect_height(r), (r)->x1, (r)->y1
-
-/* for rect's in fixed-point format: */
-#define DRM_RECT_FP_FMT "%d.%06ux%d.%06u%+d.%06u%+d.%06u"
-#define DRM_RECT_FP_ARG(r) \
-   drm_rect_width(r) >> 16, ((drm_rect_width(r) & 0x) * 15625) 
>> 10, \
-   drm_rect_height(r) >> 16, ((drm_rect_height(r) & 0x) * 
15625) >> 10, \
-   (r)->x1 >> 16, (((r)->x1 & 0x) * 15625) >> 10, \
-   (r)->y1 >> 16, (((r)->y1 & 0x) * 15625) >> 10
 
 /*@}*/
 
diff --git a/include/drm/drm_modes.h b/include/drm/drm_modes.h
index 6dd34280e892..94ac771fe460 100644
--- a/include/drm/drm_modes.h
+++ b/include/drm/drm_modes.h
@@ -197,6 +197,8 @@ enum drm_mode_status {
  * there's the hardware timings, which are corrected for interlacing,
  * double-clocking and similar things. They are provided as a convenience, and
  * can be appropriately computed using drm_mode_set_crtcinfo().
+ *
+ * For printing you can use %DRM_MODE_FMT and DRM_MODE_ARG().
  */
 struct drm_display_mode {
/**
@@ -407,6 +409,21 @@ struct drm_display_mode {
enum hdmi_picture_aspect picture_aspect_ratio;
 };
 
+/**
+ * DRM_MODE_FMT - printf string for  drm_display_mode
+ */
+#define DRM_MODE_FMT"%d:\"%s\" %d %d %d %d %d %d %d %d %d %d 0x%x 0x%x"
+
+/**
+ * DRM_MODE_ARG - printf arguments for  drm_display_mode
+ * @m: display mode
+ */
+#define DRM_MODE_ARG(m) \
+   (m)->base.id, (m)->name, (m)->vrefresh, (m)->clock, \
+   (m)->hdisplay, (m)->hsync_start, (m)->hsync_end, (m)->htotal, \
+   (m)->vdisplay, (m)->vsync_start, (m)->vsync_end, (m)->vtotal, \
+   (m)->type, (m)->flags
+
 #define obj_to_mode(x) container_of(x, struct drm_display_mode, base)
 
 /**
diff --git a/include/drm/drm_rect.h b/include/drm/drm_rect.h
index 83bb156d4356..44bc122b9ee0 100644
--- a/include/drm/drm_rect.h
+++ b/include/drm/drm_rect.h
@@ -43,6 +43,33 @@ struct drm_rect {
 };
 
 /**
+ * DRM_RECT_FMT - printf string for  drm_rect
+ */
+#define DRM_RECT_FMT"%dx%d%+d%+d"
+/**
+ * DRM_RECT_ARG - printf arguments for  drm_rect
+ * @r: rectangle struct
+ */
+#define DRM_RECT_ARG(r) drm_rect_width(r), drm_rect_height(r), (r)->x1, (r)->y1
+
+/**
+ * DRM_RECT_FP_FMT - printf string for  drm_rect in 16.16 fixed point
+ */
+#define DRM_RECT_FP_FMT "%d.%06ux%d.%06u%+d.%06u%+d.%06u"
+/**
+ * DRM_RECT_FP_ARG - printf arguments for  drm_rect in 16.16 fixed point
+ * @r: rectangle struct
+ *
+ * This is useful for e.g. printing plane source rectangles, which are in 16.16
+ * fixed point.
+ */
+#define DRM_RECT_FP_ARG(r) \
+   drm_rect_width(r) >> 16, ((drm_rect_width(r) & 0x) * 15625) 
>> 10, \
+   drm_rect_height(r) >> 16, ((drm_rect_height(r) & 0x) * 
15625) >> 10, \
+   (r)->x1 >> 16, (((r)->x1 & 0x) * 15625) >> 10, \
+   (r)->y1 >> 16, (((r)->y1 & 0x) * 15625) >> 10
+
+/**
  * drm_rect_adjust_size - adjust the size of the rectangle
  * @r: rectangle to be adjusted
  * @dw: horizontal adjustment
-- 
2.11.0

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

[PATCH 05/37] drm/pci: Deprecate drm_pci_init/exit completely

[Daniel Vetter]

The magic switching between proper pci driver and shadow-attach isn't
useful anymore since there's no ums+kms drivers left. Let's split this
up properly, calling pci_register_driver for kms drivers and renaming
the shadow-attach init to drm_legacy_pci_init/exit.

Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c |  4 ++--
 drivers/gpu/drm/ast/ast_drv.c   |  4 ++--
 drivers/gpu/drm/bochs/bochs_drv.c   |  4 ++--
 drivers/gpu/drm/cirrus/cirrus_drv.c |  4 ++--
 drivers/gpu/drm/drm_pci.c   | 39 ++---
 drivers/gpu/drm/gma500/psb_drv.c|  4 ++--
 drivers/gpu/drm/i810/i810_drv.c |  4 ++--
 drivers/gpu/drm/mga/mga_drv.c   |  4 ++--
 drivers/gpu/drm/mgag200/mgag200_drv.c   |  5 +++--
 drivers/gpu/drm/nouveau/nouveau_drm.c   | 11 --
 drivers/gpu/drm/qxl/qxl_drv.c   |  4 ++--
 drivers/gpu/drm/r128/r128_drv.c |  4 ++--
 drivers/gpu/drm/radeon/radeon_drv.c |  5 ++---
 drivers/gpu/drm/savage/savage_drv.c |  4 ++--
 drivers/gpu/drm/sis/sis_drv.c   |  4 ++--
 drivers/gpu/drm/tdfx/tdfx_drv.c |  4 ++--
 drivers/gpu/drm/via/via_drv.c   |  4 ++--
 drivers/gpu/drm/vmwgfx/vmwgfx_drv.c |  4 ++--
 include/drm/drm_pci.h   |  4 ++--
 19 files changed, 56 insertions(+), 64 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
index e7a4bce6358d..4911d304d8b9 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
@@ -816,7 +816,7 @@ static int __init amdgpu_init(void)
driver->num_ioctls = amdgpu_max_kms_ioctl;
amdgpu_register_atpx_handler();
/* let modprobe override vga console setting */
-   return drm_pci_init(driver, pdriver);
+   return pci_register_driver(pdriver);
 
 error_sched:
amdgpu_fence_slab_fini();
@@ -831,7 +831,7 @@ static int __init amdgpu_init(void)
 static void __exit amdgpu_exit(void)
 {
amdgpu_amdkfd_fini();
-   drm_pci_exit(driver, pdriver);
+   pci_unregister_driver(pdriver);
amdgpu_unregister_atpx_handler();
amdgpu_sync_fini();
amd_sched_fence_slab_fini();
diff --git a/drivers/gpu/drm/ast/ast_drv.c b/drivers/gpu/drm/ast/ast_drv.c
index f6794745a024..3022b39c00f3 100644
--- a/drivers/gpu/drm/ast/ast_drv.c
+++ b/drivers/gpu/drm/ast/ast_drv.c
@@ -220,11 +220,11 @@ static int __init ast_init(void)
 
if (ast_modeset == 0)
return -EINVAL;
-   return drm_pci_init(, _pci_driver);
+   return pci_register_driver(_pci_driver);
 }
 static void __exit ast_exit(void)
 {
-   drm_pci_exit(, _pci_driver);
+   pci_unregister_driver(_pci_driver);
 }
 
 module_init(ast_init);
diff --git a/drivers/gpu/drm/bochs/bochs_drv.c 
b/drivers/gpu/drm/bochs/bochs_drv.c
index 8fccd3cf000d..a1d28845da5f 100644
--- a/drivers/gpu/drm/bochs/bochs_drv.c
+++ b/drivers/gpu/drm/bochs/bochs_drv.c
@@ -223,12 +223,12 @@ static int __init bochs_init(void)
if (bochs_modeset == 0)
return -EINVAL;
 
-   return drm_pci_init(_driver, _pci_driver);
+   return pci_register_driver(_pci_driver);
 }
 
 static void __exit bochs_exit(void)
 {
-   drm_pci_exit(_driver, _pci_driver);
+   pci_unregister_driver(_pci_driver);
 }
 
 module_init(bochs_init);
diff --git a/drivers/gpu/drm/cirrus/cirrus_drv.c 
b/drivers/gpu/drm/cirrus/cirrus_drv.c
index c48b9eb76712..910c300f5c37 100644
--- a/drivers/gpu/drm/cirrus/cirrus_drv.c
+++ b/drivers/gpu/drm/cirrus/cirrus_drv.c
@@ -165,12 +165,12 @@ static int __init cirrus_init(void)
 
if (cirrus_modeset == 0)
return -EINVAL;
-   return drm_pci_init(, _pci_driver);
+   return pci_register_driver(_pci_driver);
 }
 
 static void __exit cirrus_exit(void)
 {
-   drm_pci_exit(, _pci_driver);
+   pci_unregister_driver(_pci_driver);
 }
 
 module_init(cirrus_init);
diff --git a/drivers/gpu/drm/drm_pci.c b/drivers/gpu/drm/drm_pci.c
index ad31d95e77c9..1235c9877d6f 100644
--- a/drivers/gpu/drm/drm_pci.c
+++ b/drivers/gpu/drm/drm_pci.c
@@ -280,20 +280,15 @@ int drm_get_pci_dev(struct pci_dev *pdev, const struct 
pci_device_id *ent,
 EXPORT_SYMBOL(drm_get_pci_dev);
 
 /**
- * drm_pci_init - Register matching PCI devices with the DRM subsystem
+ * drm_legacy_pci_init - shadow-attach a legacy DRM PCI driver
  * @driver: DRM device driver
  * @pdriver: PCI device driver
  *
- * Initializes a drm_device structures, registering the stubs and initializing
- * the AGP device.
- *
- * NOTE: This function is deprecated. Modern modesetting drm drivers should use
- * pci_register_driver() directly, this function only provides shadow-binding
- * support for old legacy drivers on top of that core pci function.
+ * This is only used by legacy dri1 drivers and deprecated.
  *
  * Return: 0 on success or a negative error code on failure.
  */
-int 

[PATCH 00/37] drm: more doc work, mostly vblank related

[Daniel Vetter]

Hi all,

So the first part of this patch series is the usual deal of decrufting some part
of drm and attempting to improve the docs. Mostly around vblank. I seem to be
the ever constant 5% of finally being able to document drm_driver/device
properly, oh well.

By patch count the bigger part is trying to get rid of drm_vblank_cleanup. That
was initially exported to drivers for a radeon ums irq failover hack, and then
seems to have been cargo-culted all over the place. It's a bit of churn, but it
will get us one step closer to tracking vblanks as part of drm_crtc. The other
bit would be to get rid of drm_vblank_init, and instead auto-setup the relevant
vblank stuff in drm_crtc_init (iff the driver supports vblanks ofc).

I'd also like to cleanup the vblank locking a bit, I think switching to per-pipe
locks from the current nested scheme will be both easier to understand and more
concurrent than what we have right now.

Anyway, stuff was getting out of hand so want to flush this out.

Review, comments and testing very much welcome.

Thanks, Daniel

Daniel Vetter (37):
  drm/doc: move printf helpers out of drmP.h
  drm: Remove drm_device->virtdev
  drm/udl: Remove dummy busid callback
  drm: Remove drm_driver->set_busid hook
  drm/pci: Deprecate drm_pci_init/exit completely
  drm/doc: Improve ioctl/fops docs a bit more
  drm: Extract drm_vblank.[hc]
  drm/doc: Polish irq helper documentation
  drm/doc: Drop empty include for drm_color_mgmt.h
  drm/doc: vblank cleanup
  drm/vblank: _ioctl posfix for ioctl handler
  drm/vblank: Consistent drm_crtc_ prefix
  drm: better document how to send out the crtc disable event
  drm/amd|radeon: Drop drm_vblank_cleanup
  drm/arcgpu: Drop drm_vblank_cleanup
  drm/hdlcd|mali: Drop drm_vblank_cleanup
  drm/atmel: Drop drm_vblank_cleanup
  drm/exynos: Drop drm_vblank_cleanup
  drm/fsl: Drop drm_vblank_cleanup
  drm/hibmc: Drop drm_vblank_cleanup
  drm/kirin: Drop drm_vblank_cleanup
  drm/i915: Drop drm_vblank_cleanup
  drm/imx: Drop drm_vblank_cleanup
  drm/mtk: Drop drm_vblank_cleanup
  drm/meson: Drop drm_vblank_cleanup
  drm/mxsfb: Drop drm_vblank_cleanup
  drm/nouveau: Drop drm_vblank_cleanup
  drm/rockchip: Drop drm_vblank_cleanup
  drm/shmob: Drop drm_vblank_cleanup
  drm/sti: Drop drm_vblank_cleanup
  drm/stm: Drop drm_vblank_cleanup
  drm/sun4i: Drop drm_vblank_cleanup
  drm/tegra: Drop drm_vblank_cleanup
  drm/udl: Drop drm_vblank_cleanup
  drm/vmwgfx: Drop drm_vblank_cleanup
  drm/zte: Drop drm_vblank_cleanup
  drm/vblank: Unexport drm_vblank_cleanup

 Documentation/gpu/drm-internals.rst |   64 +-
 Documentation/gpu/drm-kms.rst   |   63 +-
 Documentation/gpu/drm-uapi.rst  |2 +
 drivers/gpu/drm/Makefile|2 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c |5 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_irq.c |1 -
 drivers/gpu/drm/arc/arcpgu_drv.c|1 -
 drivers/gpu/drm/arm/hdlcd_drv.c |2 -
 drivers/gpu/drm/arm/malidp_drv.c|2 -
 drivers/gpu/drm/ast/ast_drv.c   |5 +-
 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c|1 -
 drivers/gpu/drm/bochs/bochs_drv.c   |5 +-
 drivers/gpu/drm/cirrus/cirrus_drv.c |5 +-
 drivers/gpu/drm/drm_file.c  |7 +-
 drivers/gpu/drm/drm_internal.h  |   17 +-
 drivers/gpu/drm/drm_ioctl.c |   13 +-
 drivers/gpu/drm/drm_irq.c   | 1643 +--
 drivers/gpu/drm/drm_pci.c   |   40 +-
 drivers/gpu/drm/drm_vblank.c| 1611 ++
 drivers/gpu/drm/exynos/exynos_drm_drv.c |4 +-
 drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c   |2 -
 drivers/gpu/drm/gma500/psb_drv.c|5 +-
 drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c |3 +-
 drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c |1 -
 drivers/gpu/drm/i810/i810_drv.c |5 +-
 drivers/gpu/drm/i915/i915_drv.c |7 +-
 drivers/gpu/drm/i915/i915_irq.c |2 +-
 drivers/gpu/drm/i915/intel_display.c|2 +-
 drivers/gpu/drm/imx/imx-drm-core.c  |4 +-
 drivers/gpu/drm/mediatek/mtk_drm_drv.c  |1 -
 drivers/gpu/drm/meson/meson_drv.c   |1 -
 drivers/gpu/drm/mga/mga_drv.c   |5 +-
 drivers/gpu/drm/mgag200/mgag200_drv.c   |6 +-
 drivers/gpu/drm/mxsfb/mxsfb_drv.c   |1 -
 drivers/gpu/drm/nouveau/nouveau_display.c   |2 -
 drivers/gpu/drm/nouveau/nouveau_drm.c   |   12 +-
 drivers/gpu/drm/nouveau/nv50_display.c  |2 +-
 drivers/gpu/drm/qxl/qxl_drv.c   |6 +-
 drivers/gpu/drm/r128/r128_drv.c |5 +-
 drivers/gpu/drm/radeon/radeon_drv.c |6 +-
 drivers/gpu/drm/radeon/radeon_irq_kms.c |1 -
 

Re: i915 4.9 regression: DP AUX CH sanitization no longer working on Asus desktops

[Daniel Drake]

On Fri, May 5, 2017 at 4:29 AM, Ville Syrjälä
 wrote:
> On Thu, May 04, 2017 at 02:52:09PM -0600, Daniel Drake wrote:
>> On Thu, May 4, 2017 at 2:37 PM, Ville Syrjälä
>>  wrote:
>> > Please check if commit bb1d132935c2 ("drm/i915/vbt: split out defaults
>> > that are set when there is no VBT") fixes things for you.
>>
>> I think this is not going to help. This would only make a difference
>> when there is no VBT at all at which point we would see this message
>> in the logs:
>>
>> DRM_INFO("Failed to find VBIOS tables (VBT)\n");
>
> No, the patch will in fact make a difference only when there is a VBT.

We confirmed the mentioned patch fixes the issue. Apologies for doubting you :)

Thanks!
Daniel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

RE: [PATCH] dim: Enforce review requirements

[Deucher, Alexander]

> -Original Message-
> From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch]
> Sent: Wednesday, May 24, 2017 5:28 AM
> To: DRI Development
> Cc: Intel Graphics Development; Daniel Vetter; Patrik Jakobsson; Lukas
> Wunner; Deucher, Alexander; Christian König; Sean Paul; Daniel Vetter
> Subject: [PATCH] dim: Enforce review requirements
> 
> We can't check this when applying (since r-b/a-b tags often get added
> afterwards), but we can check this when pushing. This only looks at
> patches authored by the pusher.
> 
> Also update the docs to highlight that review requirements hold
> especially also for bugfixes.
> 
> Cc: Patrik Jakobsson 
> Cc: Lukas Wunner 
> Cc: Alex Deucher 
> Cc: Christian König 
> Cc: Sean Paul 
> Signed-off-by: Daniel Vetter 

Acked-by: Alex Deucher 

> ---
>  dim  | 42 ++
>  drm-misc.rst |  4 +++-
>  2 files changed, 41 insertions(+), 5 deletions(-)
> 
> diff --git a/dim b/dim
> index baa0b3832314..79738a1b37a0 100755
> --- a/dim
> +++ b/dim
> @@ -340,6 +340,15 @@ function git_branch_exists # branch
>   fi
>  }
> 
> +function git_committer_email
> +{
> + if ! commiter_email=$(git config --get user.email) ; then
> + commiter_email=$EMAIL
> + fi
> +
> + echo $commiter_email
> +}
> +
>  # get message id from file
>  # $1 = file
>  message_get_id ()
> @@ -632,11 +641,32 @@ function dim_rebuild_tip
>   exit 1
>   fi
>  }
> +
> +# additional patch checks before pushing, e.g. for r-b tags
> +function checkpatch_commit_push
> +{
> + local sha1
> +
> + sha1=$1
> +
> + # check for a-b/r-b tag
> + if git show -s $sha1 | grep -qi '\(reviewed\|acked\)\S*-by:'  ; then
> + return
> + fi
> +
> + # check for commiter != author
> + if [[ $(git show -s $sha1 --format="format:%ce") != $(git show -s
> $sha1 --format="format:%ae") ]]; then
> + return
> + fi
> +
> + warn_or_fail "$sha1 is lacking mandatory review"
> +}
> +
>  # push branch $1, rebuild drm-tip. the rest of the arguments are passed to
> git
>  # push.
>  function dim_push_branch
>  {
> - local branch remote
> + local branch remote commiter_email
> 
>   branch=${1:?$usage}
>   shift
> @@ -645,6 +675,12 @@ function dim_push_branch
> 
>   remote=$(branch_to_remote $branch)
> 
> + commiter_email=$(git_committer_email)
> +
> + for sha1 in $(git rev-list $branch@{u}..$branch --
> committer="$commiter_email" --no-merges) ; do
> + checkpatch_commit_push $sha1
> + done
> +
>   git push $DRY_RUN $remote $branch "$@"
> 
>   update_linux_next $branch drm-intel-next-queued drm-intel-next-
> fixes drm-intel-fixes
> @@ -690,9 +726,7 @@ function dim_apply_branch
> 
>   message_id=$(message_get_id $file)
> 
> - if ! commiter_email=$(git config --get user.email) ; then
> - commiter_email=$EMAIL
> - fi
> + commiter_email=$(git_committer_email)
> 
>   patch_from=$(grep "From:" "$file" | head -1)
>   if [[ "$patch_from" != *"$commiter_email"* ]] ; then
> diff --git a/drm-misc.rst b/drm-misc.rst
> index caba8dc77696..d56c3c7f92a3 100644
> --- a/drm-misc.rst
> +++ b/drm-misc.rst
> @@ -90,7 +90,9 @@ Merge Criteria
>  Right now the only hard merge criteria are:
> 
>  * Patch is properly reviewed or at least Ack, i.e. don't just push your own
> -  stuff directly.
> +  stuff directly. This rule holds even more for bugfix patches - it would be
> +  embarrassing if the bugfix contains a small gotcha that review would have
> +  caught.
> 
>  * drm-misc is for drm core (non-driver) patches, subsystem-wide
> refactorings,
>and small trivial patches all over (including drivers). For a detailed 
> list of
> --
> 2.11.0

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

[Bug 99349] Failed to build shader (translation from TGSI)

[bugzilla-daemon]

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

--- Comment #3 from Gert Wollny  ---
I've had the same error output when I was playing with the Unreal Editor with
an HD6850  (BARTS) using the latest mesa-git.  

In order to track it down I added some debugging to mesa and could get the 
following trace that leads to the error:

r600/r600_asm.c:615 
  check_and_set_bank_swizzle - Couldn't find a working swizzle

drivers/r600/r600_shader.c:3975 
  tgsi_op2_s - Error in tgsi_op2_s, i = 3, r600_bytecode_add_alu returned  -1

r600/r600_shader.c:3332 
r600_shader_from_tgsi - Failed to build shader at ctx.inst_info->process, 
   chip class: 6, opcode: 7 result: -1

Since I added output for every "return -1" in r600/r600_asm.c I also get a lots
of other messages, but I guess that these are normal. 

Debugging the code I also found  that check_and_set_bank_swizzle exiting with
"Couldn't find a working swizzle" is not necessarily an error, which means that
I'm now a bit lost, because I'm not sure about how continue debugging this
problem.

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

[Bug 194761] amdgpu driver breaks on Oland (SI)

[bugzilla-daemon]

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

--- Comment #19 from Berg (b...@uralmail.com) ---
I confirm:
Checkerboard effect when using amdgpu on Oland is back.

On amdgpu-pro the same effect has been for a long time (despite the fact that
my R7 240 is in the list of supported devices), but archlinux is not supported
as a distro, there is only a user package in AUR, so here it is difficult to
make claims

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

Re: [PATCH 04/16] drm/omap: ratelimit OCP error

[Laurent Pinchart]

Hi Tomi,

Thank you for the patch.

On Thursday 04 May 2017 13:23:20 Tomi Valkeinen wrote:
> Use dev_err_ratelimited() when an OCP error happens, to slightly easen
> the flood.
> 
> Signed-off-by: Tomi Valkeinen 

Reviewed-by: Laurent Pinchart 

> ---
>  drivers/gpu/drm/omapdrm/omap_irq.c | 7 ---
>  1 file changed, 4 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/omapdrm/omap_irq.c
> b/drivers/gpu/drm/omapdrm/omap_irq.c index 7afe4b90befd..013b0bba712f
> 100644
> --- a/drivers/gpu/drm/omapdrm/omap_irq.c
> +++ b/drivers/gpu/drm/omapdrm/omap_irq.c
> @@ -182,12 +182,13 @@ static void omap_irq_fifo_underflow(struct
> omap_drm_private *priv, pr_cont("(0x%08x)\n", irqstatus);
>  }
> 
> -static void omap_irq_ocp_error_handler(u32 irqstatus)
> +static void omap_irq_ocp_error_handler(struct drm_device *dev,
> + u32 irqstatus)
>  {
>   if (!(irqstatus & DISPC_IRQ_OCP_ERR))
>   return;
> 
> - DRM_ERROR("OCP error\n");
> + dev_err_ratelimited(dev->dev, "OCP error\n");
>  }
> 
>  static irqreturn_t omap_irq_handler(int irq, void *arg)
> @@ -218,7 +219,7 @@ static irqreturn_t omap_irq_handler(int irq, void *arg)
>   omap_crtc_error_irq(crtc, irqstatus);
>   }
> 
> - omap_irq_ocp_error_handler(irqstatus);
> + omap_irq_ocp_error_handler(dev, irqstatus);
>   omap_irq_fifo_underflow(priv, irqstatus);
> 
>   spin_lock_irqsave(>wait_lock, flags);

-- 
Regards,

Laurent Pinchart

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

Re: [PATCH 03/16] drm/omap: remove CLUT

[Laurent Pinchart]

Hi Tomi,

Thank you for the patch.

On Thursday 04 May 2017 13:23:19 Tomi Valkeinen wrote:
> DSS IP versions 2 and 3 support CLUT modes (color lookup table), but the
> driver has never supported those. We still have had some code for CLUT
> modes. As the newer DSS IP versions have dropped CLUT support, we might
> as well clean up the driver by removing the CLUT related code.
> 
> Signed-off-by: Tomi Valkeinen 

Reviewed-by: Laurent Pinchart 

> ---
>  drivers/gpu/drm/omapdrm/dss/dispc.c| 57 ++
>  drivers/gpu/drm/omapdrm/dss/dss_features.c |  6 
>  drivers/gpu/drm/omapdrm/dss/omapdss.h  |  4 ---
>  3 files changed, 2 insertions(+), 65 deletions(-)

-- 
Regards,

Laurent Pinchart

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

Re: [PATCH 02/16] drm/omap: fix setting & clearing DOUBLESTRIDE

[Laurent Pinchart]

Hi Tomi,

Thank you for the patch.

On Thursday 04 May 2017 13:23:18 Tomi Valkeinen wrote:
> The code that sets and clears DOUBLESTRIDE is only ran when using NV12.
> This is not correct, as we might first set the bith when using NV12, but
> never clear it when using other formats.
> 
> Fix it so that when the bit is available (when the HW supports NV12) we
> always either set or clear the bit.
> 
> Signed-off-by: Tomi Valkeinen 

Reviewed-by: Laurent Pinchart 

> ---
>  drivers/gpu/drm/omapdrm/dss/dispc.c | 11 ++-
>  1 file changed, 6 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/gpu/drm/omapdrm/dss/dispc.c
> b/drivers/gpu/drm/omapdrm/dss/dispc.c index 352fad583571..079ec5d0b624
> 100644
> --- a/drivers/gpu/drm/omapdrm/dss/dispc.c
> +++ b/drivers/gpu/drm/omapdrm/dss/dispc.c
> @@ -1864,14 +1864,15 @@ static void dispc_ovl_set_rotation_attrs(enum
> omap_plane_id plane, u8 rotation, REG_FLD_MOD(DISPC_OVL_ATTRIBUTES(plane),
>   row_repeat ? 1 : 0, 18, 18);
> 
> - if (color_mode == OMAP_DSS_COLOR_NV12) {
> - bool doublestride = (rotation_type == OMAP_DSS_ROT_TILER) &&
> - (rotation == OMAP_DSS_ROT_0 ||
> - rotation == OMAP_DSS_ROT_180);
> + if (dss_feat_color_mode_supported(plane, OMAP_DSS_COLOR_NV12)) {
> + bool doublestride =
> + color_mode == OMAP_DSS_COLOR_NV12 &&
> + rotation_type == OMAP_DSS_ROT_TILER &&
> + (rotation == OMAP_DSS_ROT_0 || rotation == 
OMAP_DSS_ROT_180);
> +
>   /* DOUBLESTRIDE */
>   REG_FLD_MOD(DISPC_OVL_ATTRIBUTES(plane), doublestride, 22, 
22);
>   }
> -
>  }
> 
>  static int color_mode_to_bpp(enum omap_color_mode color_mode)

-- 
Regards,

Laurent Pinchart

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