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

[Boris Brezillon]

From: Gustavo Padovan 

Add support for 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.

v7: Place the drm_atomic_set_fb_for_plane() call after the new
FB has been applied to the HW to avoid possible use-after-free
issues

v6: add missing drm_atomic_set_fb_for_plane() in
vc4_plane_atomic_async_update() (Boris Brezillon)

v5: add missing call to vc4_plane_atomic_check() (Eric Anholt)

v4: add drm_atomic_helper_async() commit (Eric Anholt)

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 
Reviewed-by: Eric Anholt 
Signed-off-by: Eric Anholt 
Signed-off-by: Boris Brezillon 
---
 drivers/gpu/drm/vc4/vc4_kms.c   |  20 ++
 drivers/gpu/drm/vc4/vc4_plane.c | 131 +---
 2 files changed, 74 insertions(+), 77 deletions(-)

diff --git a/drivers/gpu/drm/vc4/vc4_kms.c b/drivers/gpu/drm/vc4/vc4_kms.c
index ba60153dddb5..e791e498a3dd 100644
--- a/drivers/gpu/drm/vc4/vc4_kms.c
+++ b/drivers/gpu/drm/vc4/vc4_kms.c
@@ -90,6 +90,26 @@ static int vc4_atomic_commit(struct drm_device *dev,
struct vc4_dev *vc4 = to_vc4_dev(dev);
int ret;
 
+   if (state->async_update) {
+   ret = down_interruptible(>async_modeset);
+   if (ret)
+   return ret;
+
+   ret = drm_atomic_helper_prepare_planes(dev, state);
+   if (ret) {
+   up(>async_modeset);
+   return ret;
+   }
+
+   drm_atomic_helper_async_commit(dev, state);
+
+   drm_atomic_helper_cleanup_planes(dev, state);
+
+   up(>async_modeset);
+
+   return 0;
+   }
+
ret = drm_atomic_helper_setup_commit(state, nonblock);
if (ret)
return ret;
diff --git a/drivers/gpu/drm/vc4/vc4_plane.c b/drivers/gpu/drm/vc4/vc4_plane.c
index ce39390be389..c3a37a99e601 100644
--- a/drivers/gpu/drm/vc4/vc4_plane.c
+++ b/drivers/gpu/drm/vc4/vc4_plane.c
@@ -741,6 +741,57 @@ void vc4_plane_async_set_fb(struct drm_plane *plane, 
struct drm_framebuffer *fb)
vc4_state->dlist[vc4_state->ptr0_offset] = addr;
 }
 
+static void vc4_plane_atomic_async_update(struct drm_plane *plane,
+ struct drm_plane_state *state)
+{
+   struct vc4_plane_state *vc4_state = to_vc4_plane_state(plane->state);
+
+   if (plane->state->fb != state->fb) {
+   vc4_plane_async_set_fb(plane, state->fb);
+   drm_atomic_set_fb_for_plane(plane->state, state->fb);
+   }
+
+   /* Set the cursor's position on the screen.  This is the
+* expected change from the drm_mode_cursor_universal()
+* helper.
+*/
+   plane->state->crtc_x = state->crtc_x;
+   plane->state->crtc_y = state->crtc_y;
+
+   /* Allow changing the start position within the cursor BO, if
+* that matters.
+*/
+   plane->state->src_x = state->src_x;
+   plane->state->src_y = state->src_y;
+
+   /* Update the display list based on the new crtc_x/y. */
+   vc4_plane_atomic_check(plane, plane->state);
+
+   /* Note that we can't just call vc4_plane_write_dlist()
+* because that would smash the context data that the HVS is
+* currently using.
+*/
+   writel(vc4_state->dlist[vc4_state->pos0_offset],
+  _state->hw_dlist[vc4_state->pos0_offset]);
+   writel(vc4_state->dlist[vc4_state->pos2_offset],
+  _state->hw_dlist[vc4_state->pos2_offset]);
+   writel(vc4_state->dlist[vc4_state->ptr0_offset],
+  _state->hw_dlist[vc4_state->ptr0_offset]);
+}
+
+static int vc4_plane_atomic_async_check(struct drm_plane *plane,
+   struct drm_plane_state *state)
+{
+   /* No configuring new scaling in the fast path. */
+   if (plane->state->crtc_w != state->crtc_w ||
+   plane->state->crtc_h != state->crtc_h ||
+   plane->state->src_w != state->src_w ||
+   plane->state->src_h != state->src_h)
+   return -EINVAL;
+
+   return 0;
+}
+
 static int vc4_prepare_fb(struct drm_plane *plane,
  struct drm_plane_state *state)
 {
@@ -780,6 +831,8 @@ static const struct drm_plane_helper_funcs 
vc4_plane_helper_funcs = {
.atomic_update = vc4_plane_atomic_update,
.prepare_fb = vc4_prepare_fb,
.cleanup_fb = vc4_cleanup_fb,
+   .atomic_async_check = vc4_plane_atomic_async_check,
+   .atomic_async_update = vc4_plane_atomic_async_update,
 };
 
 static void vc4_plane_destroy(struct drm_plane *plane)
@@ -788,82 +841,6 @@ static void 

[Bug 199101] AMDGPU Fury X random screen flicker on Linux kernel 4.16rc5

[bugzilla-daemon]

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

--- Comment #8 from Thorsten Leemhuis (regressi...@leemhuis.info) ---
@Michel Dänzer: Any progress with this? It's on the list of regressions for
4.16

-- 
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

[Bug 100400] [Solved] Game Valhalla Hills crash on startup

[bugzilla-daemon]

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

Timothy Arceri  changed:

   What|Removed |Added

Version|17.0|git
 Status|RESOLVED|REOPENED
 Resolution|FIXED   |---

--- Comment #14 from Timothy Arceri  ---
Game is crashing again with current git mesa/llvm reopening.

mesa 18.0.0 / LLVM 6.0.0 has been reported as failing also.

-- 
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 105218] Regresion in 847d0a393d7f0f967f39302900d5330f32b804c8

[bugzilla-daemon]

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

--- Comment #1 from Timothy Arceri  ---
To complete the bug report can you report which LLVM are you testing with?

You can find it easily with:

glxinfo | grep OpenGL

-- 
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 2/8] PCI: Add pci_find_common_upstream_dev()

[Christoph Hellwig]

On Thu, Mar 29, 2018 at 09:58:54PM -0400, Jerome Glisse wrote:
> dma_map_resource() is the right API (thought its current implementation
> is fill with x86 assumptions). So i would argue that arch can decide to
> implement it or simply return dma error address which trigger fallback
> path into the caller (at least for GPU drivers). SG variant can be added
> on top.

It isn't in general.  It doesn't integrate with scatterlists (see my
comment to page one), and it doesn't integrate with all the subsystems
that also need a kernel virtual address.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 3/3] drm/omap: remove unused function

[Tomi Valkeinen]

On 29/03/18 17:44, Sebastian Reichel wrote:

>>   * omap_fb.c:326: condition 0 is always false
>>   * omap_fb.c:326: condition 0 is always false
>>   * omap_fb.c:327: condition connector!=from is always false
> 
> Looks like list_for_each_entry_from() is not properly understood
> by the static checker?

I've seen a bunch of false positives from the checker, but this one is
the first where it indeed looks like the checker is confused. Or
alternatively it's too clever for us =).

 Tomi

-- 
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH libdrm 2/2] headers: Update README

[Daniel Stone]

Nouveau has made a very deliberate choice to hide its actual kernel ABI
behind libdrm. i915 is no longer out of date.

Signed-off-by: Daniel Stone 
---
 include/drm/README | 6 +-
 1 file changed, 1 insertion(+), 5 deletions(-)

diff --git a/include/drm/README b/include/drm/README
index 5b518ddf..b4658dd7 100644
--- a/include/drm/README
+++ b/include/drm/README
@@ -91,14 +91,10 @@ Most UMS headers:
 Status: ?
 Promote to fixed size ints, which match the current (32bit) ones.
 
-i915_drm.h
- - Missing PARAMS - HAS_POOLED_EU, MIN_EU_IN_POOL 
CONTEXT_PARAM_NO_ERROR_CAPTURE
-Status: Trivial.
-
 nouveau_drm.h
  - Missing macros NOUVEAU_GETPARAM*, NOUVEAU_DRM_HEADER_PATCHLEVEL, structs,
 enums
-Status: ?
+Status: Deliberate UABI choice; nouveau hides the exact kernel ABI behind 
libdrm
 
 r128_drm.h
  - Broken compat ioctls.
-- 
2.16.2

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

[PATCH libdrm 1/2] headers: Sync with drm-next

[Daniel Stone]

Taken from the drm-next pull for 4.17-rc1 (694f54f680f7), and manually
reconciled:

  core:
- Dropped DRM_MODE_TYPE_ALL and DRM_MODE_FLAG_ALL; these are purely
  internal details of the bits accepted by the currently running
  kernel, and can not be generally relied on by userspace
- Add HDCP flags
- Note CTM entry representation is sign-magnitude format, not
  two's-complement
  amdgpu:
- Add QUERY_STATE2 context op
- Add VCN firmware version query
  etnaviv:
- Add more GPU feature flags
  i915:
- Add caps, params and ioctls for PMU / perf-stream
- Add support for explicit fencing
  nouveau:
- Add TILE_COMP layout
  vc4:
- Add perfmon ioctls
  virtgpu:
- Add capset-fix param
  vmware:
- Add handle-close ioctl and explicit-fencing support

Signed-off-by: Daniel Stone 
---
 etnaviv/etnaviv_drm.h |   7 +
 include/drm/amdgpu_drm.h  |  11 ++
 include/drm/drm_mode.h|  25 ++--
 include/drm/i915_drm.h| 321 --
 include/drm/nouveau_drm.h |   1 +
 include/drm/vc4_drm.h |  76 +++
 include/drm/virtgpu_drm.h |   1 +
 include/drm/vmwgfx_drm.h  |  35 -
 8 files changed, 451 insertions(+), 26 deletions(-)

diff --git a/etnaviv/etnaviv_drm.h b/etnaviv/etnaviv_drm.h
index 110cc73b..0d5c49dc 100644
--- a/etnaviv/etnaviv_drm.h
+++ b/etnaviv/etnaviv_drm.h
@@ -1,3 +1,4 @@
+/* SPDX-License-Identifier: GPL-2.0 WITH Linux-syscall-note */
 /*
  * Copyright (C) 2015 Etnaviv Project
  *
@@ -54,6 +55,12 @@ struct drm_etnaviv_timespec {
 #define ETNAVIV_PARAM_GPU_FEATURES_40x07
 #define ETNAVIV_PARAM_GPU_FEATURES_50x08
 #define ETNAVIV_PARAM_GPU_FEATURES_60x09
+#define ETNAVIV_PARAM_GPU_FEATURES_70x0a
+#define ETNAVIV_PARAM_GPU_FEATURES_80x0b
+#define ETNAVIV_PARAM_GPU_FEATURES_90x0c
+#define ETNAVIV_PARAM_GPU_FEATURES_10   0x0d
+#define ETNAVIV_PARAM_GPU_FEATURES_11   0x0e
+#define ETNAVIV_PARAM_GPU_FEATURES_12   0x0f
 
 #define ETNAVIV_PARAM_GPU_STREAM_COUNT  0x10
 #define ETNAVIV_PARAM_GPU_REGISTER_MAX  0x11
diff --git a/include/drm/amdgpu_drm.h b/include/drm/amdgpu_drm.h
index f784f248..c363b67f 100644
--- a/include/drm/amdgpu_drm.h
+++ b/include/drm/amdgpu_drm.h
@@ -160,6 +160,7 @@ union drm_amdgpu_bo_list {
 #define AMDGPU_CTX_OP_ALLOC_CTX1
 #define AMDGPU_CTX_OP_FREE_CTX 2
 #define AMDGPU_CTX_OP_QUERY_STATE  3
+#define AMDGPU_CTX_OP_QUERY_STATE2 4
 
 /* GPU reset status */
 #define AMDGPU_CTX_NO_RESET0
@@ -170,6 +171,13 @@ union drm_amdgpu_bo_list {
 /* unknown cause */
 #define AMDGPU_CTX_UNKNOWN_RESET   3
 
+/* indicate gpu reset occured after ctx created */
+#define AMDGPU_CTX_QUERY2_FLAGS_RESET(1<<0)
+/* indicate vram lost occured after ctx created */
+#define AMDGPU_CTX_QUERY2_FLAGS_VRAMLOST (1<<1)
+/* indicate some job from this context once cause gpu hang */
+#define AMDGPU_CTX_QUERY2_FLAGS_GUILTY   (1<<2)
+
 /* Context priority level */
 #define AMDGPU_CTX_PRIORITY_UNSET   -2048
 #define AMDGPU_CTX_PRIORITY_VERY_LOW-1023
@@ -610,6 +618,8 @@ struct drm_amdgpu_cs_chunk_data {
#define AMDGPU_INFO_FW_SOS  0x0c
/* Subquery id: Query PSP ASD firmware version */
#define AMDGPU_INFO_FW_ASD  0x0d
+   /* Subquery id: Query VCN firmware version */
+   #define AMDGPU_INFO_FW_VCN  0x0e
 /* number of bytes moved for TTM migration */
 #define AMDGPU_INFO_NUM_BYTES_MOVED0x0f
 /* the used VRAM size */
@@ -798,6 +808,7 @@ struct drm_amdgpu_info_firmware {
 #define AMDGPU_VRAM_TYPE_GDDR5 5
 #define AMDGPU_VRAM_TYPE_HBM   6
 #define AMDGPU_VRAM_TYPE_DDR3  7
+#define AMDGPU_VRAM_TYPE_DDR4  8
 
 struct drm_amdgpu_info_device {
/** PCI Device ID */
diff --git a/include/drm/drm_mode.h b/include/drm/drm_mode.h
index 5597a871..5f9fadbd 100644
--- a/include/drm/drm_mode.h
+++ b/include/drm/drm_mode.h
@@ -38,11 +38,11 @@ extern "C" {
 #define DRM_DISPLAY_MODE_LEN   32
 #define DRM_PROP_NAME_LEN  32
 
-#define DRM_MODE_TYPE_BUILTIN  (1<<0)
-#define DRM_MODE_TYPE_CLOCK_C  ((1<<1) | DRM_MODE_TYPE_BUILTIN)
-#define DRM_MODE_TYPE_CRTC_C   ((1<<2) | DRM_MODE_TYPE_BUILTIN)
+#define DRM_MODE_TYPE_BUILTIN  (1<<0) /* deprecated */
+#define DRM_MODE_TYPE_CLOCK_C  ((1<<1) | DRM_MODE_TYPE_BUILTIN) /* deprecated 
*/
+#define DRM_MODE_TYPE_CRTC_C   ((1<<2) | DRM_MODE_TYPE_BUILTIN) /* deprecated 
*/
 #define DRM_MODE_TYPE_PREFERRED(1<<3)
-#define DRM_MODE_TYPE_DEFAULT  (1<<4)
+#define DRM_MODE_TYPE_DEFAULT  (1<<4) /* deprecated */
 #define DRM_MODE_TYPE_USERDEF  (1<<5)
 #define DRM_MODE_TYPE_DRIVER   (1<<6)
 
@@ -66,8 +66,8 @@ extern "C" {
 #define DRM_MODE_FLAG_PCSYNC   (1<<7)
 #define DRM_MODE_FLAG_NCSYNC   (1<<8)
 #define DRM_MODE_FLAG_HSKEW(1<<9) /* hskew 

[PATCH 09/24] drm/mtk: Move GEM BO to drm_framebuffer

[Daniel Stone]

Since drm_framebuffer can now store GEM objects directly, place them
there rather than in our own subclass. As this makes the framebuffer
create_handle and destroy functions the same as the GEM framebuffer
helper, we can reuse those.

Signed-off-by: Daniel Stone 
Cc: CK Hu 
Cc: Philipp Zabel 
---
 drivers/gpu/drm/mediatek/mtk_drm_fb.c| 38 +---
 drivers/gpu/drm/mediatek/mtk_drm_fb.h|  1 -
 drivers/gpu/drm/mediatek/mtk_drm_plane.c |  4 ++--
 3 files changed, 7 insertions(+), 36 deletions(-)

diff --git a/drivers/gpu/drm/mediatek/mtk_drm_fb.c 
b/drivers/gpu/drm/mediatek/mtk_drm_fb.c
index 0d8d506695f9..f130e37123b5 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_fb.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_fb.c
@@ -15,6 +15,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
@@ -30,42 +31,13 @@
  */
 struct mtk_drm_fb {
struct drm_framebuffer  base;
-   /* For now we only support a single plane */
-   struct drm_gem_object   *gem_obj;
 };
 
 #define to_mtk_fb(x) container_of(x, struct mtk_drm_fb, base)
 
-struct drm_gem_object *mtk_fb_get_gem_obj(struct drm_framebuffer *fb)
-{
-   struct mtk_drm_fb *mtk_fb = to_mtk_fb(fb);
-
-   return mtk_fb->gem_obj;
-}
-
-static int mtk_drm_fb_create_handle(struct drm_framebuffer *fb,
-   struct drm_file *file_priv,
-   unsigned int *handle)
-{
-   struct mtk_drm_fb *mtk_fb = to_mtk_fb(fb);
-
-   return drm_gem_handle_create(file_priv, mtk_fb->gem_obj, handle);
-}
-
-static void mtk_drm_fb_destroy(struct drm_framebuffer *fb)
-{
-   struct mtk_drm_fb *mtk_fb = to_mtk_fb(fb);
-
-   drm_framebuffer_cleanup(fb);
-
-   drm_gem_object_put_unlocked(mtk_fb->gem_obj);
-
-   kfree(mtk_fb);
-}
-
 static const struct drm_framebuffer_funcs mtk_drm_fb_funcs = {
-   .create_handle = mtk_drm_fb_create_handle,
-   .destroy = mtk_drm_fb_destroy,
+   .create_handle = drm_gem_fb_create_handle,
+   .destroy = drm_gem_fb_destroy,
 };
 
 static struct mtk_drm_fb *mtk_drm_framebuffer_init(struct drm_device *dev,
@@ -84,7 +56,7 @@ static struct mtk_drm_fb *mtk_drm_framebuffer_init(struct 
drm_device *dev,
 
drm_helper_mode_fill_fb_struct(dev, _fb->base, mode);
 
-   mtk_fb->gem_obj = obj;
+   mtk_fb->base.obj[0] = obj;
 
ret = drm_framebuffer_init(dev, _fb->base, _drm_fb_funcs);
if (ret) {
@@ -110,7 +82,7 @@ int mtk_fb_wait(struct drm_framebuffer *fb)
if (!fb)
return 0;
 
-   gem = mtk_fb_get_gem_obj(fb);
+   gem = fb->obj[0];
if (!gem || !gem->dma_buf || !gem->dma_buf->resv)
return 0;
 
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_fb.h 
b/drivers/gpu/drm/mediatek/mtk_drm_fb.h
index 9b2ae345a4e9..7f976b196a15 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_fb.h
+++ b/drivers/gpu/drm/mediatek/mtk_drm_fb.h
@@ -14,7 +14,6 @@
 #ifndef MTK_DRM_FB_H
 #define MTK_DRM_FB_H
 
-struct drm_gem_object *mtk_fb_get_gem_obj(struct drm_framebuffer *fb);
 int mtk_fb_wait(struct drm_framebuffer *fb);
 struct drm_framebuffer *mtk_drm_mode_fb_create(struct drm_device *dev,
   struct drm_file *file,
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_plane.c 
b/drivers/gpu/drm/mediatek/mtk_drm_plane.c
index ac010365d88b..5370f926e63d 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_plane.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_plane.c
@@ -95,7 +95,7 @@ static int mtk_plane_atomic_check(struct drm_plane *plane,
if (!fb)
return 0;
 
-   WARN_ON(!mtk_fb_get_gem_obj(fb));
+   WARN_ON(!fb->obj[0]);
 
if (!state->crtc)
return 0;
@@ -124,7 +124,7 @@ static void mtk_plane_atomic_update(struct drm_plane *plane,
if (!crtc || WARN_ON(!fb))
return;
 
-   gem = mtk_fb_get_gem_obj(fb);
+   gem = fb->obj[0];
mtk_gem = to_mtk_gem_obj(gem);
addr = mtk_gem->dma_addr;
pitch = fb->pitches[0];
-- 
2.16.2

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

[PATCH 06/24] drm/omap: Move GEM BO to drm_framebuffer

[Daniel Stone]

Since drm_framebuffer can now store GEM objects directly, place them
there rather than in our own subclass. As this makes the framebuffer
create_handle and destroy functions the same as the GEM framebuffer
helper, we can reuse those.

Signed-off-by: Daniel Stone 
Cc: Tomi Valkeinen 
---
 drivers/gpu/drm/omapdrm/omap_fb.c | 60 ++-
 1 file changed, 15 insertions(+), 45 deletions(-)

diff --git a/drivers/gpu/drm/omapdrm/omap_fb.c 
b/drivers/gpu/drm/omapdrm/omap_fb.c
index 5fd22ca73913..3d6b6f3d6808 100644
--- a/drivers/gpu/drm/omapdrm/omap_fb.c
+++ b/drivers/gpu/drm/omapdrm/omap_fb.c
@@ -19,6 +19,7 @@
 
 #include 
 #include 
+#include 
 
 #include "omap_dmm_tiler.h"
 #include "omap_drv.h"
@@ -51,7 +52,6 @@ static const u32 formats[] = {
 
 /* per-plane info for the fb: */
 struct plane {
-   struct drm_gem_object *bo;
u32 pitch;
u32 offset;
dma_addr_t dma_addr;
@@ -68,36 +68,9 @@ struct omap_framebuffer {
struct mutex lock;
 };
 
-static int omap_framebuffer_create_handle(struct drm_framebuffer *fb,
-   struct drm_file *file_priv,
-   unsigned int *handle)
-{
-   struct omap_framebuffer *omap_fb = to_omap_framebuffer(fb);
-   return drm_gem_handle_create(file_priv,
-   omap_fb->planes[0].bo, handle);
-}
-
-static void omap_framebuffer_destroy(struct drm_framebuffer *fb)
-{
-   struct omap_framebuffer *omap_fb = to_omap_framebuffer(fb);
-   int i, n = fb->format->num_planes;
-
-   DBG("destroy: FB ID: %d (%p)", fb->base.id, fb);
-
-   drm_framebuffer_cleanup(fb);
-
-   for (i = 0; i < n; i++) {
-   struct plane *plane = _fb->planes[i];
-
-   drm_gem_object_unreference_unlocked(plane->bo);
-   }
-
-   kfree(omap_fb);
-}
-
 static const struct drm_framebuffer_funcs omap_framebuffer_funcs = {
-   .create_handle = omap_framebuffer_create_handle,
-   .destroy = omap_framebuffer_destroy,
+   .create_handle = drm_gem_fb_create_handle,
+   .destroy = drm_gem_fb_destroy,
 };
 
 static u32 get_linear_addr(struct plane *plane,
@@ -114,10 +87,7 @@ static u32 get_linear_addr(struct plane *plane,
 
 bool omap_framebuffer_supports_rotation(struct drm_framebuffer *fb)
 {
-   struct omap_framebuffer *omap_fb = to_omap_framebuffer(fb);
-   struct plane *plane = _fb->planes[0];
-
-   return omap_gem_flags(plane->bo) & OMAP_BO_TILED;
+   return omap_gem_flags(fb->obj[0]) & OMAP_BO_TILED;
 }
 
 /* Note: DRM rotates counter-clockwise, TILER & DSS rotates clockwise */
@@ -176,7 +146,7 @@ void omap_framebuffer_update_scanout(struct drm_framebuffer 
*fb,
x = state->src_x >> 16;
y = state->src_y >> 16;
 
-   if (omap_gem_flags(plane->bo) & OMAP_BO_TILED) {
+   if (omap_gem_flags(fb->obj[0]) & OMAP_BO_TILED) {
u32 w = state->src_w >> 16;
u32 h = state->src_h >> 16;
 
@@ -201,12 +171,12 @@ void omap_framebuffer_update_scanout(struct 
drm_framebuffer *fb,
x += w - 1;
 
/* Note: x and y are in TILER units, not pixels */
-   omap_gem_rotated_dma_addr(plane->bo, orient, x, y,
+   omap_gem_rotated_dma_addr(fb->obj[0], orient, x, y,
  >paddr);
info->rotation_type = OMAP_DSS_ROT_TILER;
info->rotation = state->rotation ?: DRM_MODE_ROTATE_0;
/* Note: stride in TILER units, not pixels */
-   info->screen_width  = omap_gem_tiled_stride(plane->bo, orient);
+   info->screen_width  = omap_gem_tiled_stride(fb->obj[0], orient);
} else {
switch (state->rotation & DRM_MODE_ROTATE_MASK) {
case 0:
@@ -234,8 +204,8 @@ void omap_framebuffer_update_scanout(struct drm_framebuffer 
*fb,
plane = _fb->planes[1];
 
if (info->rotation_type == OMAP_DSS_ROT_TILER) {
-   WARN_ON(!(omap_gem_flags(plane->bo) & OMAP_BO_TILED));
-   omap_gem_rotated_dma_addr(plane->bo, orient, x/2, y/2,
+   WARN_ON(!(omap_gem_flags(fb->obj[1]) & OMAP_BO_TILED));
+   omap_gem_rotated_dma_addr(fb->obj[1], orient, x/2, y/2,
  >p_uv_addr);
} else {
info->p_uv_addr = get_linear_addr(plane, format, 1, x, 
y);
@@ -261,10 +231,10 @@ int omap_framebuffer_pin(struct drm_framebuffer *fb)
 
for (i = 0; i < n; i++) {
struct plane *plane = _fb->planes[i];
-   ret = omap_gem_pin(plane->bo, >dma_addr);
+   ret = omap_gem_pin(fb->obj[i], >dma_addr);
if (ret)
goto fail;
-   omap_gem_dma_sync_buffer(plane->bo, DMA_TO_DEVICE);
+   omap_gem_dma_sync_buffer(fb->obj[i], DMA_TO_DEVICE);

[PATCH 15/24] drm/tegra: Use drm_gem_fb_destroy

[Daniel Stone]

Now that our destroy function is the same as the helper, use that
directly.

Signed-off-by: Daniel Stone 
Cc: Thierry Reding 
Cc: linux-te...@vger.kernel.org
---
 drivers/gpu/drm/tegra/fb.c | 17 +
 1 file changed, 1 insertion(+), 16 deletions(-)

diff --git a/drivers/gpu/drm/tegra/fb.c b/drivers/gpu/drm/tegra/fb.c
index 709aa6ef171a..4c22cdded3c2 100644
--- a/drivers/gpu/drm/tegra/fb.c
+++ b/drivers/gpu/drm/tegra/fb.c
@@ -92,23 +92,8 @@ int tegra_fb_get_tiling(struct drm_framebuffer *framebuffer,
return 0;
 }
 
-static void tegra_fb_destroy(struct drm_framebuffer *framebuffer)
-{
-   unsigned int i;
-
-   for (i = 0; i < framebuffer->format->num_planes; i++) {
-   struct tegra_bo *bo = tegra_fb_get_plane(framebuffer, i);
-
-   if (bo)
-   drm_gem_object_put_unlocked(>gem);
-   }
-
-   drm_framebuffer_cleanup(framebuffer);
-   kfree(framebuffer);
-}
-
 static const struct drm_framebuffer_funcs tegra_fb_funcs = {
-   .destroy = tegra_fb_destroy,
+   .destroy = drm_gem_fb_destroy,
.create_handle = drm_gem_fb_create_handle,
 };
 
-- 
2.16.2

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

[PATCH 07/24] drm/omap: Move buffer pitch/offset to drm_framebuffer

[Daniel Stone]

drm_framebuffer already holds per-plane pitch and offsets, which is
filled out for us when we create the framebuffer. Nuke our local copy in
the plane struct.

Signed-off-by: Daniel Stone 
Cc: Tomi Valkeinen 
---
 drivers/gpu/drm/omapdrm/omap_fb.c | 22 +-
 1 file changed, 9 insertions(+), 13 deletions(-)

diff --git a/drivers/gpu/drm/omapdrm/omap_fb.c 
b/drivers/gpu/drm/omapdrm/omap_fb.c
index 3d6b6f3d6808..9d75eab0d164 100644
--- a/drivers/gpu/drm/omapdrm/omap_fb.c
+++ b/drivers/gpu/drm/omapdrm/omap_fb.c
@@ -52,8 +52,6 @@ static const u32 formats[] = {
 
 /* per-plane info for the fb: */
 struct plane {
-   u32 pitch;
-   u32 offset;
dma_addr_t dma_addr;
 };
 
@@ -73,14 +71,16 @@ static const struct drm_framebuffer_funcs 
omap_framebuffer_funcs = {
.destroy = drm_gem_fb_destroy,
 };
 
-static u32 get_linear_addr(struct plane *plane,
+static u32 get_linear_addr(struct drm_framebuffer *fb,
const struct drm_format_info *format, int n, int x, int y)
 {
+   struct omap_framebuffer *omap_fb = to_omap_framebuffer(fb);
+   struct plane *plane = _fb->planes[n];
u32 offset;
 
-   offset = plane->offset
+   offset = fb->offsets[n]
   + (x * format->cpp[n] / (n == 0 ? 1 : format->hsub))
-  + (y * plane->pitch / (n == 0 ? 1 : format->vsub));
+  + (y * fb->pitches[n] / (n == 0 ? 1 : format->vsub));
 
return plane->dma_addr + offset;
 }
@@ -191,10 +191,10 @@ void omap_framebuffer_update_scanout(struct 
drm_framebuffer *fb,
break;
}
 
-   info->paddr = get_linear_addr(plane, format, 0, x, y);
+   info->paddr = get_linear_addr(fb, format, 0, x, y);
info->rotation_type = OMAP_DSS_ROT_NONE;
info->rotation  = DRM_MODE_ROTATE_0;
-   info->screen_width  = plane->pitch;
+   info->screen_width  = fb->pitches[0];
}
 
/* convert to pixels: */
@@ -208,7 +208,7 @@ void omap_framebuffer_update_scanout(struct drm_framebuffer 
*fb,
omap_gem_rotated_dma_addr(fb->obj[1], orient, x/2, y/2,
  >p_uv_addr);
} else {
-   info->p_uv_addr = get_linear_addr(plane, format, 1, x, 
y);
+   info->p_uv_addr = get_linear_addr(fb, format, 1, x, y);
}
} else {
info->p_uv_addr = 0;
@@ -309,16 +309,14 @@ struct drm_connector *omap_framebuffer_get_next_connector(
 #ifdef CONFIG_DEBUG_FS
 void omap_framebuffer_describe(struct drm_framebuffer *fb, struct seq_file *m)
 {
-   struct omap_framebuffer *omap_fb = to_omap_framebuffer(fb);
int i, n = fb->format->num_planes;
 
seq_printf(m, "fb: %dx%d@%4.4s\n", fb->width, fb->height,
(char *)>format->format);
 
for (i = 0; i < n; i++) {
-   struct plane *plane = _fb->planes[i];
seq_printf(m, "   %d: offset=%d pitch=%d, obj: ",
-   i, plane->offset, plane->pitch);
+   i, fb->offsets[n], fb->pitches[i]);
omap_gem_describe(fb->obj[i], m);
}
 }
@@ -425,8 +423,6 @@ struct drm_framebuffer *omap_framebuffer_init(struct 
drm_device *dev,
}
 
fb->obj[i]= bos[i];
-   plane->offset = mode_cmd->offsets[i];
-   plane->pitch  = pitch;
plane->dma_addr  = 0;
}
 
-- 
2.16.2

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

[PATCH 24/24] drm/amdgpu: Move GEM BO to drm_framebuffer

[Daniel Stone]

Since drm_framebuffer can now store GEM objects directly, place them
there rather than in our own subclass. As this makes the framebuffer
create_handle and destroy functions the same as the GEM framebuffer
helper, we can reuse those.

Signed-off-by: Daniel Stone 
Cc: Alex Deucher 
Cc: Christian König 
Cc: David (ChunMing) Zhou 
Cc: amd-...@lists.freedesktop.org
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_device.c|  6 ++--
 drivers/gpu/drm/amd/amdgpu/amdgpu_display.c   | 36 +--
 drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c| 10 +++
 drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h  |  1 -
 drivers/gpu/drm/amd/amdgpu/dce_v10_0.c| 17 ---
 drivers/gpu/drm/amd/amdgpu/dce_v11_0.c| 17 ---
 drivers/gpu/drm/amd/amdgpu/dce_v6_0.c | 17 ---
 drivers/gpu/drm/amd/amdgpu/dce_v8_0.c | 17 ---
 drivers/gpu/drm/amd/amdgpu/dce_virtual.c  |  4 +--
 drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 11 +++
 10 files changed, 40 insertions(+), 96 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
index 34af664b9f93..fbc0676c6bcc 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
@@ -2539,7 +2539,7 @@ int amdgpu_device_suspend(struct drm_device *dev, bool 
suspend, bool fbcon)
/* unpin the front buffers and cursors */
list_for_each_entry(crtc, >mode_config.crtc_list, head) {
struct amdgpu_crtc *amdgpu_crtc = to_amdgpu_crtc(crtc);
-   struct amdgpu_framebuffer *rfb = 
to_amdgpu_framebuffer(crtc->primary->fb);
+   struct drm_framebuffer *fb = crtc->primary->fb;
struct amdgpu_bo *robj;
 
if (amdgpu_crtc->cursor_bo) {
@@ -2551,10 +2551,10 @@ int amdgpu_device_suspend(struct drm_device *dev, bool 
suspend, bool fbcon)
}
}
 
-   if (rfb == NULL || rfb->obj == NULL) {
+   if (fb == NULL || fb->obj[0] == NULL) {
continue;
}
-   robj = gem_to_amdgpu_bo(rfb->obj);
+   robj = gem_to_amdgpu_bo(fb->obj[0]);
/* don't unpin kernel fb objects */
if (!amdgpu_fbdev_robj_is_fb(adev, robj)) {
r = amdgpu_bo_reserve(robj, true);
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
index 93f700ab1bfb..b83ae998fe27 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
@@ -35,6 +35,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 static void amdgpu_display_flip_callback(struct dma_fence *f,
@@ -151,8 +152,6 @@ int amdgpu_display_crtc_page_flip_target(struct drm_crtc 
*crtc,
struct drm_device *dev = crtc->dev;
struct amdgpu_device *adev = dev->dev_private;
struct amdgpu_crtc *amdgpu_crtc = to_amdgpu_crtc(crtc);
-   struct amdgpu_framebuffer *old_amdgpu_fb;
-   struct amdgpu_framebuffer *new_amdgpu_fb;
struct drm_gem_object *obj;
struct amdgpu_flip_work *work;
struct amdgpu_bo *new_abo;
@@ -174,15 +173,13 @@ int amdgpu_display_crtc_page_flip_target(struct drm_crtc 
*crtc,
work->async = (page_flip_flags & DRM_MODE_PAGE_FLIP_ASYNC) != 0;
 
/* schedule unpin of the old buffer */
-   old_amdgpu_fb = to_amdgpu_framebuffer(crtc->primary->fb);
-   obj = old_amdgpu_fb->obj;
+   obj = crtc->primary->fb->obj[0];
 
/* take a reference to the old object */
work->old_abo = gem_to_amdgpu_bo(obj);
amdgpu_bo_ref(work->old_abo);
 
-   new_amdgpu_fb = to_amdgpu_framebuffer(fb);
-   obj = new_amdgpu_fb->obj;
+   obj = fb->obj[0];
new_abo = gem_to_amdgpu_bo(obj);
 
/* pin the new buffer */
@@ -482,28 +479,9 @@ bool amdgpu_display_ddc_probe(struct amdgpu_connector 
*amdgpu_connector,
return true;
 }
 
-static void amdgpu_display_user_framebuffer_destroy(struct drm_framebuffer *fb)
-{
-   struct amdgpu_framebuffer *amdgpu_fb = to_amdgpu_framebuffer(fb);
-
-   drm_gem_object_put_unlocked(amdgpu_fb->obj);
-   drm_framebuffer_cleanup(fb);
-   kfree(amdgpu_fb);
-}
-
-static int amdgpu_display_user_framebuffer_create_handle(
-   struct drm_framebuffer *fb,
-   struct drm_file *file_priv,
-   unsigned int *handle)
-{
-   struct amdgpu_framebuffer *amdgpu_fb = to_amdgpu_framebuffer(fb);
-
-   return drm_gem_handle_create(file_priv, amdgpu_fb->obj, handle);
-}
-
 static const struct drm_framebuffer_funcs amdgpu_fb_funcs = {
-   .destroy = amdgpu_display_user_framebuffer_destroy,
-   .create_handle = 

[PATCH 04/24] drm/rockchip: Place GEM BOs in drm_framebuffer

[Daniel Stone]

Since drm_framebuffer can now store GEM objects directly, place them
there rather than in our own subclass. As this makes the framebuffer
create_handle and destroy functions the same as the GEM framebuffer
helper, we can reuse those.

Signed-off-by: Daniel Stone 
Cc: Sandy Huang 
Cc: Heiko Stübner 
---
 drivers/gpu/drm/rockchip/rockchip_drm_fb.c | 36 +-
 1 file changed, 6 insertions(+), 30 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_fb.c 
b/drivers/gpu/drm/rockchip/rockchip_drm_fb.c
index e266539e04e5..d7083c07c294 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_fb.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_fb.c
@@ -18,6 +18,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "rockchip_drm_drv.h"
 #include "rockchip_drm_fb.h"
@@ -28,40 +29,15 @@
 
 struct rockchip_drm_fb {
struct drm_framebuffer fb;
-   struct drm_gem_object *obj[ROCKCHIP_MAX_FB_BUFFER];
 };
 
 struct drm_gem_object *rockchip_fb_get_gem_obj(struct drm_framebuffer *fb,
   unsigned int plane)
 {
-   struct rockchip_drm_fb *rk_fb = to_rockchip_fb(fb);
-
if (plane >= ROCKCHIP_MAX_FB_BUFFER)
return NULL;
 
-   return rk_fb->obj[plane];
-}
-
-static void rockchip_drm_fb_destroy(struct drm_framebuffer *fb)
-{
-   struct rockchip_drm_fb *rockchip_fb = to_rockchip_fb(fb);
-   int i;
-
-   for (i = 0; i < ROCKCHIP_MAX_FB_BUFFER; i++)
-   drm_gem_object_put_unlocked(rockchip_fb->obj[i]);
-
-   drm_framebuffer_cleanup(fb);
-   kfree(rockchip_fb);
-}
-
-static int rockchip_drm_fb_create_handle(struct drm_framebuffer *fb,
-struct drm_file *file_priv,
-unsigned int *handle)
-{
-   struct rockchip_drm_fb *rockchip_fb = to_rockchip_fb(fb);
-
-   return drm_gem_handle_create(file_priv,
-rockchip_fb->obj[0], handle);
+   return fb->obj[plane];
 }
 
 static int rockchip_drm_fb_dirty(struct drm_framebuffer *fb,
@@ -75,9 +51,9 @@ static int rockchip_drm_fb_dirty(struct drm_framebuffer *fb,
 }
 
 static const struct drm_framebuffer_funcs rockchip_drm_fb_funcs = {
-   .destroy= rockchip_drm_fb_destroy,
-   .create_handle  = rockchip_drm_fb_create_handle,
-   .dirty  = rockchip_drm_fb_dirty,
+   .destroy   = drm_gem_fb_destroy,
+   .create_handle = drm_gem_fb_create_handle,
+   .dirty = rockchip_drm_fb_dirty,
 };
 
 static struct rockchip_drm_fb *
@@ -95,7 +71,7 @@ rockchip_fb_alloc(struct drm_device *dev, const struct 
drm_mode_fb_cmd2 *mode_cm
drm_helper_mode_fill_fb_struct(dev, _fb->fb, mode_cmd);
 
for (i = 0; i < num_planes; i++)
-   rockchip_fb->obj[i] = obj[i];
+   rockchip_fb->fb.obj[i] = obj[i];
 
ret = drm_framebuffer_init(dev, _fb->fb,
   _drm_fb_funcs);
-- 
2.16.2

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

[PATCH 11/24] drm/tegra: Remove duplicate framebuffer num_planes

[Daniel Stone]

drm_framebuffer already stores num_planes for us.

Signed-off-by: Daniel Stone 
Cc: Thierry Reding 
Cc: linux-te...@vger.kernel.org
---
 drivers/gpu/drm/tegra/drm.h | 1 -
 drivers/gpu/drm/tegra/fb.c  | 6 ++
 2 files changed, 2 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/tegra/drm.h b/drivers/gpu/drm/tegra/drm.h
index 4f41aaec8530..79340fb1de43 100644
--- a/drivers/gpu/drm/tegra/drm.h
+++ b/drivers/gpu/drm/tegra/drm.h
@@ -32,7 +32,6 @@ struct reset_control;
 struct tegra_fb {
struct drm_framebuffer base;
struct tegra_bo **planes;
-   unsigned int num_planes;
 };
 
 #ifdef CONFIG_DRM_FBDEV_EMULATION
diff --git a/drivers/gpu/drm/tegra/fb.c b/drivers/gpu/drm/tegra/fb.c
index e69434909a42..75badf371721 100644
--- a/drivers/gpu/drm/tegra/fb.c
+++ b/drivers/gpu/drm/tegra/fb.c
@@ -107,7 +107,7 @@ static void tegra_fb_destroy(struct drm_framebuffer 
*framebuffer)
struct tegra_fb *fb = to_tegra_fb(framebuffer);
unsigned int i;
 
-   for (i = 0; i < fb->num_planes; i++) {
+   for (i = 0; i < framebuffer->format->num_planes; i++) {
struct tegra_bo *bo = fb->planes[i];
 
if (bo) {
@@ -155,11 +155,9 @@ static struct tegra_fb *tegra_fb_alloc(struct drm_device 
*drm,
return ERR_PTR(-ENOMEM);
}
 
-   fb->num_planes = num_planes;
-
drm_helper_mode_fill_fb_struct(drm, >base, mode_cmd);
 
-   for (i = 0; i < fb->num_planes; i++)
+   for (i = 0; i < fb->base.format->num_planes; i++)
fb->planes[i] = planes[i];
 
err = drm_framebuffer_init(drm, >base, _fb_funcs);
-- 
2.16.2

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

[PATCH 22/24] drm/radeon: Move GEM BO to drm_framebuffer

[Daniel Stone]

Since drm_framebuffer can now store GEM objects directly, place them
there rather than in our own subclass. As this makes the framebuffer
create_handle and destroy functions the same as the GEM framebuffer
helper, we can reuse those.

Signed-off-by: Daniel Stone 
Cc: Alex Deucher 
Cc: Christian König 
Cc: David (ChunMing) Zhou 
Cc: amd-...@lists.freedesktop.org
---
 drivers/gpu/drm/radeon/atombios_crtc.c  | 10 +-
 drivers/gpu/drm/radeon/radeon_device.c  |  4 ++--
 drivers/gpu/drm/radeon/radeon_display.c | 31 +++--
 drivers/gpu/drm/radeon/radeon_fb.c  |  8 
 drivers/gpu/drm/radeon/radeon_legacy_crtc.c | 11 --
 drivers/gpu/drm/radeon/radeon_mode.h|  1 -
 6 files changed, 22 insertions(+), 43 deletions(-)

diff --git a/drivers/gpu/drm/radeon/atombios_crtc.c 
b/drivers/gpu/drm/radeon/atombios_crtc.c
index 02baaaf20e9d..028a811c1462 100644
--- a/drivers/gpu/drm/radeon/atombios_crtc.c
+++ b/drivers/gpu/drm/radeon/atombios_crtc.c
@@ -1176,7 +1176,7 @@ static int dce4_crtc_do_set_base(struct drm_crtc *crtc,
/* If atomic, assume fb object is pinned & idle & fenced and
 * just update base pointers
 */
-   obj = radeon_fb->obj;
+   obj = radeon_fb->base.obj[0];
rbo = gem_to_radeon_bo(obj);
r = radeon_bo_reserve(rbo, false);
if (unlikely(r != 0))
@@ -1442,7 +1442,7 @@ static int dce4_crtc_do_set_base(struct drm_crtc *crtc,
 
if (!atomic && fb && fb != crtc->primary->fb) {
radeon_fb = to_radeon_framebuffer(fb);
-   rbo = gem_to_radeon_bo(radeon_fb->obj);
+   rbo = gem_to_radeon_bo(radeon_fb->base.obj[0]);
r = radeon_bo_reserve(rbo, false);
if (unlikely(r != 0))
return r;
@@ -1490,7 +1490,7 @@ static int avivo_crtc_do_set_base(struct drm_crtc *crtc,
target_fb = crtc->primary->fb;
}
 
-   obj = radeon_fb->obj;
+   obj = radeon_fb->base.obj[0];
rbo = gem_to_radeon_bo(obj);
r = radeon_bo_reserve(rbo, false);
if (unlikely(r != 0))
@@ -1642,7 +1642,7 @@ static int avivo_crtc_do_set_base(struct drm_crtc *crtc,
 
if (!atomic && fb && fb != crtc->primary->fb) {
radeon_fb = to_radeon_framebuffer(fb);
-   rbo = gem_to_radeon_bo(radeon_fb->obj);
+   rbo = gem_to_radeon_bo(radeon_fb->base.obj[0]);
r = radeon_bo_reserve(rbo, false);
if (unlikely(r != 0))
return r;
@@ -2153,7 +2153,7 @@ static void atombios_crtc_disable(struct drm_crtc *crtc)
struct radeon_bo *rbo;
 
radeon_fb = to_radeon_framebuffer(crtc->primary->fb);
-   rbo = gem_to_radeon_bo(radeon_fb->obj);
+   rbo = gem_to_radeon_bo(radeon_fb->base.obj[0]);
r = radeon_bo_reserve(rbo, false);
if (unlikely(r))
DRM_ERROR("failed to reserve rbo before unpin\n");
diff --git a/drivers/gpu/drm/radeon/radeon_device.c 
b/drivers/gpu/drm/radeon/radeon_device.c
index e415d2c097a7..30c5bc20a60b 100644
--- a/drivers/gpu/drm/radeon/radeon_device.c
+++ b/drivers/gpu/drm/radeon/radeon_device.c
@@ -1599,10 +1599,10 @@ int radeon_suspend_kms(struct drm_device *dev, bool 
suspend,
}
}
 
-   if (rfb == NULL || rfb->obj == NULL) {
+   if (rfb == NULL || rfb->base.obj[0] == NULL) {
continue;
}
-   robj = gem_to_radeon_bo(rfb->obj);
+   robj = gem_to_radeon_bo(rfb->base.obj[0]);
/* don't unpin kernel fb objects */
if (!radeon_fbdev_robj_is_fb(rdev, robj)) {
r = radeon_bo_reserve(robj, false);
diff --git a/drivers/gpu/drm/radeon/radeon_display.c 
b/drivers/gpu/drm/radeon/radeon_display.c
index 26129b2b082d..dc300128283d 100644
--- a/drivers/gpu/drm/radeon/radeon_display.c
+++ b/drivers/gpu/drm/radeon/radeon_display.c
@@ -32,6 +32,7 @@
 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -502,14 +503,14 @@ static int radeon_crtc_page_flip_target(struct drm_crtc 
*crtc,
 
/* schedule unpin of the old buffer */
old_radeon_fb = to_radeon_framebuffer(crtc->primary->fb);
-   obj = old_radeon_fb->obj;
+   obj = old_radeon_fb->base.obj[0];
 
/* take a reference to the old object */
drm_gem_object_get(obj);
work->old_rbo = gem_to_radeon_bo(obj);
 
new_radeon_fb = to_radeon_framebuffer(fb);
-   obj = new_radeon_fb->obj;
+   obj = new_radeon_fb->base.obj[0];
new_rbo = gem_to_radeon_bo(obj);
 
/* pin the new buffer */
@@ -1285,27 +1286,9 @@ void radeon_compute_pll_legacy(struct radeon_pll *pll,
 
 }
 
-static void 

[PATCH 03/24] drm/virtio: Place GEM BOs in drm_framebuffer

[Daniel Stone]

Since drm_framebuffer can now store GEM objects directly, place them
there rather than in our own subclass. As this makes the framebuffer
create_handle and destroy functions the same as the GEM framebuffer
helper, we can reuse those.

Signed-off-by: Daniel Stone 
Cc: Dave Airlie 
Cc: Gerd Hoffmann 
Cc: virtualizat...@lists.linux-foundation.org
---
 drivers/gpu/drm/virtio/virtgpu_display.c | 30 +-
 drivers/gpu/drm/virtio/virtgpu_drv.h |  1 -
 drivers/gpu/drm/virtio/virtgpu_fb.c  |  8 
 drivers/gpu/drm/virtio/virtgpu_plane.c   |  4 ++--
 4 files changed, 11 insertions(+), 32 deletions(-)

diff --git a/drivers/gpu/drm/virtio/virtgpu_display.c 
b/drivers/gpu/drm/virtio/virtgpu_display.c
index 8cc8c34d67f5..af542f1216f9 100644
--- a/drivers/gpu/drm/virtio/virtgpu_display.c
+++ b/drivers/gpu/drm/virtio/virtgpu_display.c
@@ -28,6 +28,7 @@
 #include "virtgpu_drv.h"
 #include 
 #include 
+#include 
 
 #define XRES_MIN32
 #define YRES_MIN32
@@ -48,16 +49,6 @@ static const struct drm_crtc_funcs virtio_gpu_crtc_funcs = {
.atomic_destroy_state   = drm_atomic_helper_crtc_destroy_state,
 };
 
-static void virtio_gpu_user_framebuffer_destroy(struct drm_framebuffer *fb)
-{
-   struct virtio_gpu_framebuffer *virtio_gpu_fb
-   = to_virtio_gpu_framebuffer(fb);
-
-   drm_gem_object_put_unlocked(virtio_gpu_fb->obj);
-   drm_framebuffer_cleanup(fb);
-   kfree(virtio_gpu_fb);
-}
-
 static int
 virtio_gpu_framebuffer_surface_dirty(struct drm_framebuffer *fb,
 struct drm_file *file_priv,
@@ -71,20 +62,9 @@ virtio_gpu_framebuffer_surface_dirty(struct drm_framebuffer 
*fb,
return virtio_gpu_surface_dirty(virtio_gpu_fb, clips, num_clips);
 }
 
-static int
-virtio_gpu_framebuffer_create_handle(struct drm_framebuffer *fb,
-struct drm_file *file_priv,
-unsigned int *handle)
-{
-   struct virtio_gpu_framebuffer *virtio_gpu_fb =
-   to_virtio_gpu_framebuffer(fb);
-
-   return drm_gem_handle_create(file_priv, virtio_gpu_fb->obj, handle);
-}
-
 static const struct drm_framebuffer_funcs virtio_gpu_fb_funcs = {
-   .create_handle = virtio_gpu_framebuffer_create_handle,
-   .destroy = virtio_gpu_user_framebuffer_destroy,
+   .create_handle = drm_gem_fb_create_handle,
+   .destroy = drm_gem_fb_destroy,
.dirty = virtio_gpu_framebuffer_surface_dirty,
 };
 
@@ -97,7 +77,7 @@ virtio_gpu_framebuffer_init(struct drm_device *dev,
int ret;
struct virtio_gpu_object *bo;
 
-   vgfb->obj = obj;
+   vgfb->base.obj[0] = obj;
 
bo = gem_to_virtio_gpu_obj(obj);
 
@@ -105,7 +85,7 @@ virtio_gpu_framebuffer_init(struct drm_device *dev,
 
ret = drm_framebuffer_init(dev, >base, _gpu_fb_funcs);
if (ret) {
-   vgfb->obj = NULL;
+   vgfb->base.obj[0] = NULL;
return ret;
}
 
diff --git a/drivers/gpu/drm/virtio/virtgpu_drv.h 
b/drivers/gpu/drm/virtio/virtgpu_drv.h
index d25c8ca224aa..65605e207bbe 100644
--- a/drivers/gpu/drm/virtio/virtgpu_drv.h
+++ b/drivers/gpu/drm/virtio/virtgpu_drv.h
@@ -124,7 +124,6 @@ struct virtio_gpu_output {
 
 struct virtio_gpu_framebuffer {
struct drm_framebuffer base;
-   struct drm_gem_object *obj;
int x1, y1, x2, y2; /* dirty rect */
spinlock_t dirty_lock;
uint32_t hw_res_handle;
diff --git a/drivers/gpu/drm/virtio/virtgpu_fb.c 
b/drivers/gpu/drm/virtio/virtgpu_fb.c
index 8af69ab58b89..a121b1c79522 100644
--- a/drivers/gpu/drm/virtio/virtgpu_fb.c
+++ b/drivers/gpu/drm/virtio/virtgpu_fb.c
@@ -46,7 +46,7 @@ static int virtio_gpu_dirty_update(struct 
virtio_gpu_framebuffer *fb,
int bpp = fb->base.format->cpp[0];
int x2, y2;
unsigned long flags;
-   struct virtio_gpu_object *obj = gem_to_virtio_gpu_obj(fb->obj);
+   struct virtio_gpu_object *obj = gem_to_virtio_gpu_obj(fb->base.obj[0]);
 
if ((width <= 0) ||
(x + width > fb->base.width) ||
@@ -121,7 +121,7 @@ int virtio_gpu_surface_dirty(struct virtio_gpu_framebuffer 
*vgfb,
 unsigned int num_clips)
 {
struct virtio_gpu_device *vgdev = vgfb->base.dev->dev_private;
-   struct virtio_gpu_object *obj = gem_to_virtio_gpu_obj(vgfb->obj);
+   struct virtio_gpu_object *obj = 
gem_to_virtio_gpu_obj(vgfb->base.obj[0]);
struct drm_clip_rect norect;
struct drm_clip_rect *clips_ptr;
int left, right, top, bottom;
@@ -305,8 +305,8 @@ static int virtio_gpu_fbdev_destroy(struct drm_device *dev,
 
drm_fb_helper_unregister_fbi(>helper);
 
-   if (vgfb->obj)
-   vgfb->obj = NULL;
+   if (vgfb->base.obj[0])
+   vgfb->base.obj[0] = NULL;
drm_fb_helper_fini(>helper);
drm_framebuffer_cleanup(>base);
 
diff 

[PATCH] drm/atomic: Add sanity checks to drm_atomic_helper_async_commit()

[Boris Brezillon]

->atomic_async_update() requires that drivers update the plane->state
object before returning. Make sure at least common properties have been
updated.

Cc: Gustavo Padovan 
Signed-off-by: Boris Brezillon 
---
Hello,

This is a problem I had when debugging the VC4 ->atomic_async_update()
implementation. The function was not updating plane->fb as it's
supposed thus leaving plane->state->fb in an inconsistent state after
each async update.

Not sure if such WARN_ON_ONCE() are accepted in the core though, so
I'll maintainers decide whether this is relevant or not and whether
they prefer to have WARN_ON() or DRM_ERROR() messages.

Regards,

Boris
---
 drivers/gpu/drm/drm_atomic_helper.c | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
b/drivers/gpu/drm/drm_atomic_helper.c
index c35654591c12..d2b2583487ee 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -1561,6 +1561,17 @@ void drm_atomic_helper_async_commit(struct drm_device 
*dev,
for_each_new_plane_in_state(state, plane, plane_state, i) {
funcs = plane->helper_private;
funcs->atomic_async_update(plane, plane_state);
+
+   /*
+* ->atomic_async_update() is supposed to update the
+* plane->state in-place, make sure at least common
+* properties have been properly updated.
+*/
+   WARN_ON_ONCE(plane->state->fb != plane_state->fb);
+   WARN_ON_ONCE(plane->state->crtc_x != plane_state->crtc_x);
+   WARN_ON_ONCE(plane->state->crtc_y != plane_state->crtc_y);
+   WARN_ON_ONCE(plane->state->src_x != plane_state->src_x);
+   WARN_ON_ONCE(plane->state->src_y != plane_state->src_y);
}
 }
 EXPORT_SYMBOL(drm_atomic_helper_async_commit);
-- 
2.14.1

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

Re: [PATCH 00/24] drm_framebuffer boilerplate removal

[Daniel Stone]

Hi Alex,

On 30 March 2018 at 15:47, Alex Deucher  wrote:
> On Fri, Mar 30, 2018 at 10:11 AM, Daniel Stone  wrote:
>> I intend to remove create_handle when all drivers are converted over
>> to placing BOs directly inside drm_framebuffer. For most drivers
>> there's a relatively easy conversion to using the helpers for
>> basically all framebuffer handling and fbdev emulation as well, though
>> that's a bit further than I was willing to go without hardware to test
>> on ...
>
> Series is:
> Acked-by: Alex Deucher 

Thanks a lot for the review! Are you taking the radeon/amdgpu patches
through your tree? They don't have any dependencies on core code.

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

[PATCH] drm/i915: Do NOT skip the first 4k of stolen memory for pre-allocated buffers

[Hans de Goede]

Before this commit the WaSkipStolenMemoryFirstPage workaround code was
skipping the first 4k by passing 4096 as start of the address range passed
to drm_mm_init(). This means that calling drm_mm_reserve_node() to try and
reserve the firmware framebuffer so that we can inherit it would always
fail, as the firmware framebuffer starts at address 0.

Commit d43537610470 ("drm/i915: skip the first 4k of stolen memory on
everything >= gen8") says in its commit message: "This is confirmed to fix
Skylake screen flickering issues (probably caused by the fact that we
initialized a ring in the first page of stolen, but I didn't 100% confirm
this theory)."

Which suggests that it is safe to use the first page for a linear
framebuffer as the firmware is doing.

This commit always passes 0 as start to drm_mm_init() and works around
WaSkipStolenMemoryFirstPage in i915_gem_stolen_insert_node_in_range()
by insuring the start address passed by to drm_mm_insert_node_in_range()
is always 4k or more. All entry points to i915_gem_stolen.c go through
i915_gem_stolen_insert_node_in_range(), so that any newly allocated
objects such as ring-buffers will not be allocated in the first 4k.

The one exception is i915_gem_object_create_stolen_for_preallocated()
which directly calls drm_mm_reserve_node() which now will be able to
use the first 4k.

This fixes the i915 driver no longer being able to inherit the firmware
framebuffer on gen8+, which fixes the video output changing from the
vendor logo to a black screen as soon as the i915 driver is loaded
(on systems without fbcon).

Signed-off-by: Hans de Goede 
---
 drivers/gpu/drm/i915/i915_gem_stolen.c | 15 ++-
 1 file changed, 6 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem_stolen.c 
b/drivers/gpu/drm/i915/i915_gem_stolen.c
index af915d041281..ad949cc30928 100644
--- a/drivers/gpu/drm/i915/i915_gem_stolen.c
+++ b/drivers/gpu/drm/i915/i915_gem_stolen.c
@@ -51,6 +51,10 @@ int i915_gem_stolen_insert_node_in_range(struct 
drm_i915_private *dev_priv,
if (!drm_mm_initialized(_priv->mm.stolen))
return -ENODEV;
 
+   /* WaSkipStolenMemoryFirstPage:bdw+ */
+   if (INTEL_GEN(dev_priv) >= 8 && start < 4096)
+   start = 4096;
+
mutex_lock(_priv->mm.stolen_lock);
ret = drm_mm_insert_node_in_range(_priv->mm.stolen, node,
  size, alignment, 0,
@@ -343,7 +347,6 @@ int i915_gem_init_stolen(struct drm_i915_private *dev_priv)
 {
resource_size_t reserved_base, stolen_top;
resource_size_t reserved_total, reserved_size;
-   resource_size_t stolen_usable_start;
 
mutex_init(_priv->mm.stolen_lock);
 
@@ -435,17 +438,11 @@ int i915_gem_init_stolen(struct drm_i915_private 
*dev_priv)
 (u64)resource_size(_priv->dsm) >> 10,
 ((u64)resource_size(_priv->dsm) - reserved_total) 
>> 10);
 
-   stolen_usable_start = 0;
-   /* WaSkipStolenMemoryFirstPage:bdw+ */
-   if (INTEL_GEN(dev_priv) >= 8)
-   stolen_usable_start = 4096;
-
dev_priv->stolen_usable_size =
-   resource_size(_priv->dsm) - reserved_total - 
stolen_usable_start;
+   resource_size(_priv->dsm) - reserved_total;
 
/* Basic memrange allocator for stolen space. */
-   drm_mm_init(_priv->mm.stolen, stolen_usable_start,
-   dev_priv->stolen_usable_size);
+   drm_mm_init(_priv->mm.stolen, 0, dev_priv->stolen_usable_size);
 
return 0;
 }
-- 
2.17.0.rc2

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

[PATCH] drm/imx: Remove last traces of struct imx_drm_crtc

[Leonard Crestez]

When the definition of this struct was removed a forward declaration and an
unused struct member were still left around. Remove them because they serve
no purpose.

Fixes 44b460cfe554 ("drm: imx: remove struct imx_drm_crtc and 
imx_drm_crtc_helper_funcs")

Signed-off-by: Leonard Crestez 
---
 drivers/gpu/drm/imx/imx-drm.h| 1 -
 drivers/gpu/drm/imx/ipuv3-crtc.c | 1 -
 2 files changed, 2 deletions(-)

diff --git a/drivers/gpu/drm/imx/imx-drm.h b/drivers/gpu/drm/imx/imx-drm.h
index 15c2bec..ab9c6f7 100644
--- a/drivers/gpu/drm/imx/imx-drm.h
+++ b/drivers/gpu/drm/imx/imx-drm.h
@@ -10,7 +10,6 @@ struct drm_display_mode;
 struct drm_encoder;
 struct drm_framebuffer;
 struct drm_plane;
-struct imx_drm_crtc;
 struct platform_device;
 
 struct imx_crtc_state {
diff --git a/drivers/gpu/drm/imx/ipuv3-crtc.c b/drivers/gpu/drm/imx/ipuv3-crtc.c
index e83af0f..50d9f2bb 100644
--- a/drivers/gpu/drm/imx/ipuv3-crtc.c
+++ b/drivers/gpu/drm/imx/ipuv3-crtc.c
@@ -35,7 +35,6 @@
 struct ipu_crtc {
struct device   *dev;
struct drm_crtc base;
-   struct imx_drm_crtc *imx_crtc;
 
/* plane[0] is the full plane, plane[1] is the partial plane */
struct ipu_plane*plane[2];
-- 
2.7.4

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

Re: [PATCH 2/8] PCI: Add pci_find_common_upstream_dev()

[Logan Gunthorpe]

On 28/03/18 10:02 AM, Christian König wrote:
> Yeah, that looks very similar to what I picked up from the older 
> patches, going to read up on that after my vacation.

Yeah, I was just reading through your patchset and there are a lot of
similarities. Though, I'm not sure what you're trying to accomplish as I
could not find a cover letter and it seems to only enable one driver. Is
it meant to enable DMA transactions only between two AMD GPUs?

I also don't see where you've taken into account the PCI bus address. On
some architectures this is not the same as the CPU physical address.

> Just in general why are you interested in the "distance" of the devices?

We've taken a general approach where some drivers may provide p2p memory
(ie. an NVMe card or an RDMA NIC) and other drivers make use of it (ie.
the NVMe-of driver). The orchestrator driver needs to find the most
applicable provider device for a transaction in a situation that may
have multiple providers and multiple clients. So the most applicable
provider is the one that's closest ("distance"-wise) to all the clients
for the P2P transaction.

> And BTW: At least for writes that Peer 2 Peer transactions between 
> different root complexes work is actually more common than the other way 
> around.

Maybe on x86 with hardware made in the last few years. But on PowerPC,
ARM64, and likely a lot more the chance of support is *much* less. Also,
hardware that only supports P2P stores is hardly full support and is
insufficient for our needs.

> So I'm a bit torn between using a blacklist or a whitelist. A whitelist 
> is certainly more conservative approach, but that could get a bit long.

I think a whitelist approach is correct. Given old hardware and other
architectures, a black list is going to be too long and too difficult to
comprehensively populate.

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

Re: [PATCH] drm/atmel-hlcdc: add command line option to specify preferred depth

[Peter Rosin]

On 2018-03-28 09:34, Boris Brezillon wrote:
> Hi Peter,
> 
> On Mon, 26 Mar 2018 09:35:02 +0200
> Peter Rosin  wrote:
> 
>> I have an sama5d31-based system with 64MB of memory and a 1920x1080
>> LVDS display wired for 16-bpp. When I enable legacy fbdev support,
>> the contiguous memory allocator invariably fails with the order-11
>> allocation for a 1920x1080@24-bpp buffer (~6MB). But this HW can never
>> make any good use of RGB888, so that is a wasted attempt anyway that
>> would also waste precious memory should it succeed.
>>
>> Sure, I could rewrite user-space to go directly to KMS etc, and that
>> makes the (attempted) order-11 allocation go away, replacing it with
>> one order-10 allocation per application restart for a 1920x1080@16-bpp
>> buffer (<4MB). But after a few restarts, order-10 allocations start to
>> fail as well, which is only to be expected AFAIU.
>>
>> So, I'd rather not change user-space (which was originally written
>> to target a smaller display) so that I at the same time get the
>> benefit of an early pre-allocated fbdev frame-buffer that can be
>> reused over and over. But to do that I need to tell the driver that
>> 16-bpp is the preferred depth. Add a module parameter to do just that.
>>
>> Signed-off-by: Peter Rosin 
>> ---
>>  drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c | 18 +-
>>  1 file changed, 17 insertions(+), 1 deletion(-)
>>
>> I found some inspiration regarding naming and implementation here:
>> https://patchwork.kernel.org/patch/9848631/
>>
>> I have found no feedback on that patch though, which makes me wonder if
>> I'm perhaps barking up the wronig tree?
> 
> Hm, isn't that something you can already overload with the video=
> parameter?
> 
>   video=:[-]

Heh, you are right...

> AFAIR,  encodes the color depth, so what is the benefit of adding
> this new property to overload the default depth?

...but hhhmmm, I think I will have to have to encode the display size
in the bootargs so I will have to use distinct barebox environments
depending on the panel, but that's no biggie.

Splendid, please throw away the patch!

Cheers,
Peter

> Maybe I'm wrong and the default depth param is actually useful, but in
> this case we should probably make it generic since other drivers seems
> to need it too, and we might want to attach it to a specific display
> engine instance.
> 
> Thanks,
> 
> Boris
> 
>>
>> Cheers,
>> Peter
>>
>> diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c 
>> b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
>> index c1ea5c36b006..f0148627c221 100644
>> --- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
>> +++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
>> @@ -29,6 +29,11 @@
>>  
>>  #define ATMEL_HLCDC_LAYER_IRQS_OFFSET   8
>>  
>> +static int atmel_hlcdc_preferred_depth __read_mostly;
>> +
>> +MODULE_PARM_DESC(preferreddepth, "Set preferred bpp");
>> +module_param_named(preferreddepth, atmel_hlcdc_preferred_depth, int, 0400);
>> +
>>  static const struct atmel_hlcdc_layer_desc atmel_hlcdc_at91sam9n12_layers[] 
>> = {
>>  {
>>  .name = "base",
>> @@ -590,6 +595,7 @@ static int atmel_hlcdc_dc_modeset_init(struct drm_device 
>> *dev)
>>  dev->mode_config.min_height = dc->desc->min_height;
>>  dev->mode_config.max_width = dc->desc->max_width;
>>  dev->mode_config.max_height = dc->desc->max_height;
>> +dev->mode_config.preferred_depth = 24;
>>  dev->mode_config.funcs = _config_funcs;
>>  
>>  return 0;
>> @@ -658,7 +664,7 @@ static int atmel_hlcdc_dc_load(struct drm_device *dev)
>>  
>>  platform_set_drvdata(pdev, dev);
>>  
>> -drm_fb_cma_fbdev_init(dev, 24, 0);
>> +drm_fb_cma_fbdev_init(dev, atmel_hlcdc_preferred_depth, 0);
>>  
>>  drm_kms_helper_poll_init(dev);
>>  
>> @@ -756,6 +762,16 @@ static int atmel_hlcdc_dc_drm_probe(struct 
>> platform_device *pdev)
>>  struct drm_device *ddev;
>>  int ret;
>>  
>> +switch (atmel_hlcdc_preferred_depth) {
>> +case 0: /* driver default */
>> +case 8:
>> +case 16:
>> +case 24:
>> +break;
>> +default:
>> +return -EINVAL;
>> +}
>> +
>>  ddev = drm_dev_alloc(_hlcdc_dc_driver, >dev);
>>  if (IS_ERR(ddev))
>>  return PTR_ERR(ddev);
> 
> 
> 

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

[PATCH v3 2/2] drivers: remove force dma flag from buses

[Nipun Gupta]

With each bus implementing its own DMA configuration callback,
there is no need for bus to explicitly have force_dma in its
global structure. This patch modifies of_dma_configure API to
accept an input parameter which specifies if implicit DMA
configuration is required even when it is not described by the
firmware.

Signed-off-by: Nipun Gupta 
---
Changes in v2:
  - This is a new change suggested by Robin and Christoph
and is added to the series.

Changes in v3:
  - Rebase and changes corresponding to the changes in patch 1/2

 drivers/amba/bus.c| 1 -
 drivers/base/platform.c   | 3 +--
 drivers/bcma/main.c   | 2 +-
 drivers/dma/qcom/hidma_mgmt.c | 2 +-
 drivers/gpu/host1x/bus.c  | 5 ++---
 drivers/of/device.c   | 6 --
 drivers/of/of_reserved_mem.c  | 2 +-
 drivers/pci/pci-driver.c  | 3 +--
 include/linux/device.h| 4 
 include/linux/of_device.h | 8 ++--
 10 files changed, 17 insertions(+), 19 deletions(-)

diff --git a/drivers/amba/bus.c b/drivers/amba/bus.c
index 867dc2b..abe73c4 100644
--- a/drivers/amba/bus.c
+++ b/drivers/amba/bus.c
@@ -199,7 +199,6 @@ struct bus_type amba_bustype = {
.uevent = amba_uevent,
.dma_configure  = platform_dma_configure,
.pm = _pm,
-   .force_dma  = true,
 };
 
 static int __init amba_init(void)
diff --git a/drivers/base/platform.c b/drivers/base/platform.c
index 72fdbf6..cfbc569 100644
--- a/drivers/base/platform.c
+++ b/drivers/base/platform.c
@@ -1136,7 +1136,7 @@ int platform_dma_configure(struct device *dev)
int ret = 0;
 
if (dev->of_node) {
-   ret = of_dma_configure(dev, dev->of_node);
+   ret = of_dma_configure(dev, dev->of_node, true);
} else if (has_acpi_companion(dev)) {
attr = acpi_get_dma_attr(to_acpi_device_node(dev->fwnode));
if (attr != DEV_DMA_NOT_SUPPORTED)
@@ -1159,7 +1159,6 @@ struct bus_type platform_bus_type = {
.uevent = platform_uevent,
.dma_configure  = platform_dma_configure,
.pm = _dev_pm_ops,
-   .force_dma  = true,
 };
 EXPORT_SYMBOL_GPL(platform_bus_type);
 
diff --git a/drivers/bcma/main.c b/drivers/bcma/main.c
index e6986c7..fc1f4ac 100644
--- a/drivers/bcma/main.c
+++ b/drivers/bcma/main.c
@@ -207,7 +207,7 @@ static void bcma_of_fill_device(struct device *parent,
 
core->irq = bcma_of_get_irq(parent, core, 0);
 
-   of_dma_configure(>dev, node);
+   of_dma_configure(>dev, node, false);
 }
 
 unsigned int bcma_core_irq(struct bcma_device *core, int num)
diff --git a/drivers/dma/qcom/hidma_mgmt.c b/drivers/dma/qcom/hidma_mgmt.c
index 000c7019..d64edeb 100644
--- a/drivers/dma/qcom/hidma_mgmt.c
+++ b/drivers/dma/qcom/hidma_mgmt.c
@@ -398,7 +398,7 @@ static int __init hidma_mgmt_of_populate_channels(struct 
device_node *np)
}
of_node_get(child);
new_pdev->dev.of_node = child;
-   of_dma_configure(_pdev->dev, child);
+   of_dma_configure(_pdev->dev, child, true);
/*
 * It is assumed that calling of_msi_configure is safe on
 * platforms with or without MSI support.
diff --git a/drivers/gpu/host1x/bus.c b/drivers/gpu/host1x/bus.c
index a9ec99d..b39c1e9 100644
--- a/drivers/gpu/host1x/bus.c
+++ b/drivers/gpu/host1x/bus.c
@@ -317,7 +317,7 @@ static int host1x_device_match(struct device *dev, struct 
device_driver *drv)
 static int host1x_dma_configure(struct device *dev)
 {
if (dev->of_node)
-   return of_dma_configure(dev, dev->of_node);
+   return of_dma_configure(dev, dev->of_node, true);
return 0;
 }
 
@@ -335,7 +335,6 @@ struct bus_type host1x_bus_type = {
.match = host1x_device_match,
.dma_configure  = host1x_dma_configure,
.pm = _device_pm_ops,
-   .force_dma = true,
 };
 
 static void __host1x_device_del(struct host1x_device *device)
@@ -424,7 +423,7 @@ static int host1x_device_add(struct host1x *host1x,
device->dev.bus = _bus_type;
device->dev.parent = host1x->dev;
 
-   of_dma_configure(>dev, host1x->dev->of_node);
+   of_dma_configure(>dev, host1x->dev->of_node, true);
 
err = host1x_device_parse_dt(device, driver);
if (err < 0) {
diff --git a/drivers/of/device.c b/drivers/of/device.c
index 064c818..33d8551 100644
--- a/drivers/of/device.c
+++ b/drivers/of/device.c
@@ -76,6 +76,8 @@ int of_device_add(struct platform_device *ofdev)
  * of_dma_configure - Setup DMA configuration
  * @dev:   Device to apply DMA configuration
  * @np:Pointer to OF node having DMA configuration
+ * @force_dma:  Whether device is to be set up by of_dma_configure() even if
+ * DMA capability is not explicitly described by firmware.
  *
  * Try to get devices's DMA configuration from DT and update it
  * accordingly.
@@ -84,7 

Re: [PATCH 3/3] drm/omap: remove unused function

[Sebastian Reichel]

Hi,

On Thu, Mar 29, 2018 at 02:24:40PM +0100, Emil Velikov wrote:
> On 29 March 2018 at 13:31, Sebastian Reichel
>  wrote:
> > Hi,
> >
> > On Thu, Mar 29, 2018 at 12:00:18PM +0100, Emil Velikov wrote:
> >> On 29 March 2018 at 11:40, Tomi Valkeinen  wrote:
> >> > omap_framebuffer_get_next_connector() is not used, remove it.
> >> >
> >> Seems to have been unused for a few years now.
> >> Namely since commit 5a35876e2830511cb8110667fc426c6a6165a593
> >>
> >> Reviewed-by: Emil Velikov 
> >
> > I have a pending patch using that function to basically restore the
> > functionality from the referenced commit:
> >
> > https://patchwork.kernel.org/patch/10207759/
> >
> Hmm I can see very few users of dirtyfb - modesetting, opentegra,
> vmgfx, intel (sna only)  + the odd IGT test.
>
> Wondering if that's because it doesn't provide that much of a benefit...
> Although it might be because DRM drivers don't fully implement the
> functionality ;-)
> 
> Just thinking out loud ^^.

Most DRM drivers don't implement DSI's command mode. That's not
surprising, if you consider that the typical development boards
don't have panels supporting DSI command mode. A quick grep
from me suggested, that rockchip supports DSI command mode and
they also use dirtyfb.

Also the benefit of panel self refresh seems to be big enough,
that intel tries to enable it by default since quite some time
:)

Note, that in mobile phones DSI command mode panels are not as
rare as on the development boards. Nokia N950, N9 and Droid 4
each have one of those displays.

-- Sebastian


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

[PATCH -next] drm/tegra: dc: Using NULL instead of plain integer

[Wei Yongjun]

Fixes the following sparse warnings:

drivers/gpu/drm/tegra/dc.c:2181:69: warning:
  Using plain integer as NULL pointer

Signed-off-by: Wei Yongjun 
---
 drivers/gpu/drm/tegra/dc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/tegra/dc.c b/drivers/gpu/drm/tegra/dc.c
index 616c963..910125c 100644
--- a/drivers/gpu/drm/tegra/dc.c
+++ b/drivers/gpu/drm/tegra/dc.c
@@ -2178,7 +2178,7 @@ static int tegra_dc_couple(struct tegra_dc *dc)
struct device_link *link;
struct device *partner;
 
-   partner = driver_find_device(dc->dev->driver, NULL, 0,
+   partner = driver_find_device(dc->dev->driver, NULL, NULL,
 tegra_dc_match_by_pipe);
if (!partner)
return -EPROBE_DEFER;

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

[PATCH v3 1/2] dma-mapping: move dma configuration to bus infrastructure

[Nipun Gupta]

It is bus specific aspect to map a given device on the bus and
relevant firmware description of its DMA configuration.
So, this change introduces 'dma_configure' as bus callback
giving flexibility to busses for implementing its own dma
configuration function.

The change eases the addition of new busses w.r.t. adding the dma
configuration functionality.

This patch also updates the PCI, Platform, ACPI and host1x bus to
use new introduced callbacks.

Suggested-by: Christoph Hellwig 
Signed-off-by: Nipun Gupta 
Reviewed-by: Greg Kroah-Hartman 
---
 - The patches are based on the comments on:
   https://patchwork.kernel.org/patch/10259087/

Changes in v2:
  - Do not have dma_deconfigure callback
  - Have '/dma_common_configure/' API to provide a common DMA
configuration which can be used by busses if it suits them.
  - Platform and ACPI bus to use '/dma_common_configure/' in
'/dma_configure/' callback.
  - Updated commit message
  - Updated pci_dma_configure API with changes suggested by Robin

Changes in v3
  - Move dma_common_configure() within platform_dma_configure() and
reuse platofrm_dma_configure() for AMBA bus too
  - Declare 'attr' in pci_dma_configure() inside the else statement
where it is used.

 drivers/amba/bus.c  |  4 
 drivers/base/dma-mapping.c  | 31 ---
 drivers/base/platform.c | 17 +
 drivers/gpu/host1x/bus.c|  8 
 drivers/pci/pci-driver.c| 32 
 include/linux/device.h  |  4 
 include/linux/platform_device.h |  2 ++
 7 files changed, 71 insertions(+), 27 deletions(-)

diff --git a/drivers/amba/bus.c b/drivers/amba/bus.c
index 594c228..867dc2b 100644
--- a/drivers/amba/bus.c
+++ b/drivers/amba/bus.c
@@ -20,6 +20,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 
@@ -188,12 +189,15 @@ static int amba_pm_runtime_resume(struct device *dev)
 /*
  * Primecells are part of the Advanced Microcontroller Bus Architecture,
  * so we call the bus "amba".
+ * DMA configuration for platform and AMBA bus is same. So here we reuse
+ * platform's DMA config routine.
  */
 struct bus_type amba_bustype = {
.name   = "amba",
.dev_groups = amba_dev_groups,
.match  = amba_match,
.uevent = amba_uevent,
+   .dma_configure  = platform_dma_configure,
.pm = _pm,
.force_dma  = true,
 };
diff --git a/drivers/base/dma-mapping.c b/drivers/base/dma-mapping.c
index 3b11835..fdc1502 100644
--- a/drivers/base/dma-mapping.c
+++ b/drivers/base/dma-mapping.c
@@ -331,36 +331,13 @@ void dma_common_free_remap(void *cpu_addr, size_t size, 
unsigned long vm_flags)
 #endif
 
 /*
- * Common configuration to enable DMA API use for a device
+ * enables DMA API use for a device
  */
-#include 
-
 int dma_configure(struct device *dev)
 {
-   struct device *bridge = NULL, *dma_dev = dev;
-   enum dev_dma_attr attr;
-   int ret = 0;
-
-   if (dev_is_pci(dev)) {
-   bridge = pci_get_host_bridge_device(to_pci_dev(dev));
-   dma_dev = bridge;
-   if (IS_ENABLED(CONFIG_OF) && dma_dev->parent &&
-   dma_dev->parent->of_node)
-   dma_dev = dma_dev->parent;
-   }
-
-   if (dma_dev->of_node) {
-   ret = of_dma_configure(dev, dma_dev->of_node);
-   } else if (has_acpi_companion(dma_dev)) {
-   attr = acpi_get_dma_attr(to_acpi_device_node(dma_dev->fwnode));
-   if (attr != DEV_DMA_NOT_SUPPORTED)
-   ret = acpi_dma_configure(dev, attr);
-   }
-
-   if (bridge)
-   pci_put_host_bridge_device(bridge);
-
-   return ret;
+   if (dev->bus->dma_configure)
+   return dev->bus->dma_configure(dev);
+   return 0;
 }
 
 void dma_deconfigure(struct device *dev)
diff --git a/drivers/base/platform.c b/drivers/base/platform.c
index f1bf7b3..72fdbf6 100644
--- a/drivers/base/platform.c
+++ b/drivers/base/platform.c
@@ -1130,6 +1130,22 @@ int platform_pm_restore(struct device *dev)
 
 #endif /* CONFIG_HIBERNATE_CALLBACKS */
 
+int platform_dma_configure(struct device *dev)
+{
+   enum dev_dma_attr attr;
+   int ret = 0;
+
+   if (dev->of_node) {
+   ret = of_dma_configure(dev, dev->of_node);
+   } else if (has_acpi_companion(dev)) {
+   attr = acpi_get_dma_attr(to_acpi_device_node(dev->fwnode));
+   if (attr != DEV_DMA_NOT_SUPPORTED)
+   ret = acpi_dma_configure(dev, attr);
+   }
+
+   return ret;
+}
+
 static const struct dev_pm_ops platform_dev_pm_ops = {
.runtime_suspend = pm_generic_runtime_suspend,
.runtime_resume = pm_generic_runtime_resume,
@@ -1141,6 +1157,7 @@ struct bus_type platform_bus_type = {
.dev_groups = platform_dev_groups,
 

Re: [PATCH 3/3] drm/omap: remove unused function

[Sebastian Reichel]

Hi,

On Thu, Mar 29, 2018 at 03:49:08PM +0300, Tomi Valkeinen wrote:
> On 29/03/18 15:31, Sebastian Reichel wrote:
> > Hi,
> > 
> > On Thu, Mar 29, 2018 at 12:00:18PM +0100, Emil Velikov wrote:
> >> On 29 March 2018 at 11:40, Tomi Valkeinen  wrote:
> >>> omap_framebuffer_get_next_connector() is not used, remove it.
> >>>
> >> Seems to have been unused for a few years now.
> >> Namely since commit 5a35876e2830511cb8110667fc426c6a6165a593
> >>
> >> Reviewed-by: Emil Velikov 
> > 
> > I have a pending patch using that function to basically restore the
> > functionality from the referenced commit:
> 
> Oh, ok. I'll drop this patch.

Thanks.

> These was a Klocwork warning for this function, so the easiest fix
> was to remove it.
> 
> drivers/gpu/drm/omapdrm/omap_fb.c:326 INFINITE_LOOP.LOCAL (2:Error) Analyze
> Infinite loop
>   * omap_fb.c:326: Entering loop with precondition (from!=0) &&
> (connector!=0) && from == connector

This makes sense to me, since the code initializes connector to from
and returns early if from is NULL.

>   * omap_fb.c:326: condition 0 is always false
>   * omap_fb.c:326: condition 0 is always false
>   * omap_fb.c:327: condition connector!=from is always false

Looks like list_for_each_entry_from() is not properly understood
by the static checker?

-- Sebastian


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

Re: [PATCH 2/8] PCI: Add pci_find_common_upstream_dev()

[Logan Gunthorpe]

On 28/03/18 09:07 AM, Christian König wrote:
> Am 28.03.2018 um 14:38 schrieb Christoph Hellwig:
>> On Sun, Mar 25, 2018 at 12:59:54PM +0200, Christian König wrote:
>>> From: "wda...@nvidia.com" 
>>>
>>> Add an interface to find the first device which is upstream of both
>>> devices.
>> Please work with Logan and base this on top of the outstanding peer
>> to peer patchset.
> 
> Can you point me to that? The last code I could find about that was from 
> 2015.

The latest posted series is here:

https://lkml.org/lkml/2018/3/12/830

However, we've made some significant changes to the area that's similar
to what you are doing. You can find lasted un-posted here:

https://github.com/sbates130272/linux-p2pmem/tree/pci-p2p-v4-pre2

Specifically this function would be of interest to you:

https://github.com/sbates130272/linux-p2pmem/blob/0e9468ae2a5a5198513dd12990151e09105f0351/drivers/pci/p2pdma.c#L239

However, the difference between what we are doing is that we are
interested in the distance through the common upstream device and you
appear to be finding the actual common device.

Thanks,

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

Re: [PATCH] drm/mxsfb: add poll_changed event handler to set_par on startup

[Michael Grzeschik]

On Tue, Mar 27, 2018 at 01:30:04PM +0200, Michael Grzeschik wrote:
> On Mon, Mar 26, 2018 at 06:17:44PM +0200, Michael Grzeschik wrote:
> > We move drm_kms_helper_poll_init behind the drm_fbdev_cma_init so the
> > set_par will be called and fb will be active.
> > 
> 
> As this commit message is not very informative and digging deeper into
> the stubs I came up with another Idea.
> 
> By default drm_kms_helper_hotplug_event could call
> drm_fb_helper_output_poll_changed if no other output_poll_changed was
> registered.

After a internal discussion, this seems not the prefered solution,
as many connectors don't need polling anymore but still call
drm_kms_helper_hotplug_event.

I will send v2 of the initial patch.

-- 
Pengutronix e.K.   | |
Industrial Linux Solutions | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686   | Fax:   +49-5121-206917- |


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/3] drm/omap: remove unused function

[Sebastian Reichel]

Hi,

On Thu, Mar 29, 2018 at 12:00:18PM +0100, Emil Velikov wrote:
> On 29 March 2018 at 11:40, Tomi Valkeinen  wrote:
> > omap_framebuffer_get_next_connector() is not used, remove it.
> >
> Seems to have been unused for a few years now.
> Namely since commit 5a35876e2830511cb8110667fc426c6a6165a593
> 
> Reviewed-by: Emil Velikov 

I have a pending patch using that function to basically restore the
functionality from the referenced commit:

https://patchwork.kernel.org/patch/10207759/

-- Sebastian


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

Re: [PATCH 2/8] PCI: Add pci_find_common_upstream_dev()

[Logan Gunthorpe]

On 28/03/18 12:28 PM, Christian König wrote:
> I'm just using amdgpu as blueprint because I'm the co-maintainer of it 
> and know it mostly inside out.

Ah, I see.

> The resource addresses are translated using dma_map_resource(). As far 
> as I know that should be sufficient to offload all the architecture 
> specific stuff to the DMA subsystem.

It's not. The dma_map infrastructure currently has no concept of
peer-to-peer mappings and is designed for system memory only. No
architecture I'm aware of will translate PCI CPU addresses into PCI Bus
addresses which is necessary for any transfer that doesn't go through
the root complex (though on arches like x86 the CPU and Bus address
happen to be the same). There's a lot of people that would like to see
this change but it's likely going to be a long road before it does.

Furthermore, one of the reasons our patch-set avoids going through the
root complex at all is that IOMMU drivers will need to be made aware
that it is operating on P2P memory and do arch-specific things
accordingly. There will also need to be flags that indicate whether a
given IOMMU driver supports this. None of this work is done or easy.

> Yeah, but not for ours. See if you want to do real peer 2 peer you need 
> to keep both the operation as well as the direction into account.

Not sure what you are saying here... I'm pretty sure we are doing "real"
peer 2 peer...

> For example when you can do writes between A and B that doesn't mean 
> that writes between B and A work. And reads are generally less likely to 
> work than writes. etc...

If both devices are behind a switch then the PCI spec guarantees that A
can both read and write B and vice versa. Only once you involve root
complexes do you have this problem. Ie. you have unknown support which
may be no support, or partial support (stores but not loads); or
sometimes bad performance; or a combination of both... and you need some
way to figure out all this mess and that is hard. Whoever tries to
implement a white list will have to sort all this out.

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

[Bug 105170] Radeon R9 Nano failed testing IB on GFX ring (-110). [amd64, kernel 4.15.4]

[bugzilla-daemon]

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

--- Comment #6 from erhar...@mailbox.org ---
Created attachment 138443
  --> https://bugs.freedesktop.org/attachment.cgi?id=138443=edit
journalctl -k (kernel 4.16_rc7)

-- 
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 libdrm 1/2] headers: Sync with drm-next

[Daniel Stone]

On 30 March 2018 at 14:30, Alex Deucher  wrote:
> On Fri, Mar 30, 2018 at 8:28 AM, Daniel Stone  wrote:
>> Taken from the drm-next pull for 4.17-rc1 (694f54f680f7), and manually
>
> Reviewed-by: Alex Deucher 

Both pushed, thanks a lot Alex!

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

Re: [RFC 1/2] drm/vc4: Handle async page flips in the atomic_commit() path

[Boris Brezillon]

On Fri, 30 Mar 2018 17:09:03 +0200
Boris Brezillon  wrote:

> Rework the atomic commit logic to handle async page flip requests in
> the atomic update path.
> 
> Async page flips are a bit more complicated than async cursor updates
> (already handled in the vc4_atomic_commit() function) in that you need
> to wait for fences on the new framebuffers to be signaled before doing
> the flip. In order to ensure that, we schedule a commit_work work to do
> the async update (note that the existing implementation already uses a
> work to wait for fences to be signaled, so, the latency shouldn't
> change that much).
> 
> Of course, we have to modify a bit the atomic_complete_commit()
> implementation to avoid waiting for things we don't care about when
> doing an async page flip:
> 
> * drm_atomic_helper_wait_for_dependencies() waits for flip_done which
>   we don't care about when doing async page flips. Instead we replace
>   that call by a loop that waits for hw_done only
> * drm_atomic_helper_commit_modeset_disables() and
>   drm_atomic_helper_commit_modeset_enables() are not needed because
>   nothing except the planes' FBs are updated in async page flips
> * drm_atomic_helper_commit_planes() is replaced by
>   vc4_plane_async_set_fb() which is doing only the FB update and is
>   thus much simpler
> * drm_atomic_helper_wait_for_vblanks() is not needed because we don't
>   wait for the next VBLANK period to apply the new state, and flip
>   events are signaled manually just after the HW has been updated
> 
> Thanks to this rework, we can get rid of the custom vc4_page_flip()
> implementation and its dependencies and use
> drm_atomic_helper_page_flip() instead.

Another good reason for moving async page flip to the atomic commit
path is that is fixes a bug we had:
drm_atomic_helper_prepare/cleanup_planes() were not called in the async
page flip path, which can lead to unbalanced vc4_inc/dec_usecnt()
in some situations (when the plane is updated once with an async page
flip and then with a regular update) or trigger a use after free if the
BO passed to the plane is marked purgeable and the kernel decides to
purge its cache.

> 
> Signed-off-by: Boris Brezillon 
> ---
>  drivers/gpu/drm/vc4/vc4_crtc.c | 103 
> +
>  drivers/gpu/drm/vc4/vc4_kms.c  | 101 +---
>  2 files changed, 86 insertions(+), 118 deletions(-)
> 
> diff --git a/drivers/gpu/drm/vc4/vc4_crtc.c b/drivers/gpu/drm/vc4/vc4_crtc.c
> index bf4667481935..3843c39dce61 100644
> --- a/drivers/gpu/drm/vc4/vc4_crtc.c
> +++ b/drivers/gpu/drm/vc4/vc4_crtc.c
> @@ -757,107 +757,6 @@ static irqreturn_t vc4_crtc_irq_handler(int irq, void 
> *data)
>   return ret;
>  }
>  
> -struct vc4_async_flip_state {
> - struct drm_crtc *crtc;
> - struct drm_framebuffer *fb;
> - struct drm_pending_vblank_event *event;
> -
> - struct vc4_seqno_cb cb;
> -};
> -
> -/* Called when the V3D execution for the BO being flipped to is done, so that
> - * we can actually update the plane's address to point to it.
> - */
> -static void
> -vc4_async_page_flip_complete(struct vc4_seqno_cb *cb)
> -{
> - struct vc4_async_flip_state *flip_state =
> - container_of(cb, struct vc4_async_flip_state, cb);
> - struct drm_crtc *crtc = flip_state->crtc;
> - struct drm_device *dev = crtc->dev;
> - struct vc4_dev *vc4 = to_vc4_dev(dev);
> - struct drm_plane *plane = crtc->primary;
> -
> - vc4_plane_async_set_fb(plane, flip_state->fb);
> - if (flip_state->event) {
> - unsigned long flags;
> -
> - spin_lock_irqsave(>event_lock, flags);
> - drm_crtc_send_vblank_event(crtc, flip_state->event);
> - spin_unlock_irqrestore(>event_lock, flags);
> - }
> -
> - drm_crtc_vblank_put(crtc);
> - drm_framebuffer_put(flip_state->fb);
> - kfree(flip_state);
> -
> - up(>async_modeset);
> -}
> -
> -/* Implements async (non-vblank-synced) page flips.
> - *
> - * The page flip ioctl needs to return immediately, so we grab the
> - * modeset semaphore on the pipe, and queue the address update for
> - * when V3D is done with the BO being flipped to.
> - */
> -static int vc4_async_page_flip(struct drm_crtc *crtc,
> -struct drm_framebuffer *fb,
> -struct drm_pending_vblank_event *event,
> -uint32_t flags)
> -{
> - struct drm_device *dev = crtc->dev;
> - struct vc4_dev *vc4 = to_vc4_dev(dev);
> - struct drm_plane *plane = crtc->primary;
> - int ret = 0;
> - struct vc4_async_flip_state *flip_state;
> - struct drm_gem_cma_object *cma_bo = drm_fb_cma_get_gem_obj(fb, 0);
> - struct vc4_bo *bo = to_vc4_bo(_bo->base);
> -
> - flip_state = kzalloc(sizeof(*flip_state), GFP_KERNEL);
> - if (!flip_state)
> - return -ENOMEM;
> -
> - 

Re: [PATCH 2/8] PCI: Add pci_find_common_upstream_dev()

[Logan Gunthorpe]

On 29/03/18 05:44 AM, Christian König wrote:
> Am 28.03.2018 um 21:53 schrieb Logan Gunthorpe:
>>
>> On 28/03/18 01:44 PM, Christian König wrote:
>>> Well, isn't that exactly what dma_map_resource() is good for? As far as
>>> I can see it makes sure IOMMU is aware of the access route and
>>> translates a CPU address into a PCI Bus address.
>>> I'm using that with the AMD IOMMU driver and at least there it works
>>> perfectly fine.
>> Yes, it would be nice, but no arch has implemented this yet. We are just
>> lucky in the x86 case because that arch is simple and doesn't need to do
>> anything for P2P (partially due to the Bus and CPU addresses being the
>> same). But in the general case, you can't rely on it.
> 
> Well, that an arch hasn't implemented it doesn't mean that we don't have 
> the right interface to do it.

Yes, but right now we don't have a performant way to check if we are
doing P2P or not in the dma_map_X() wrappers. And this is necessary to
check if the DMA ops in use support it or not. We can't have the
dma_map_X() functions do the wrong thing because they don't support it yet.

> Devices integrated in the CPU usually only "claim" to be PCIe devices. 
> In reality their memory request path go directly through the integrated 
> north bridge. The reason for this is simple better throughput/latency.

These are just more reasons why our patchset restricts to devices behind
a switch. And more mess for someone to deal with if they need to relax
that restriction.

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

[Bug 199101] AMDGPU Fury X random screen flicker on Linux kernel 4.16rc5

[bugzilla-daemon]

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

Alex Deucher (alexdeuc...@gmail.com) changed:

   What|Removed |Added

 CC||alexdeuc...@gmail.com

--- Comment #9 from Alex Deucher (alexdeuc...@gmail.com) ---
Can you bisect?

-- 
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 libdrm 2/2] headers: Update README

[Alex Deucher]

On Fri, Mar 30, 2018 at 8:28 AM, Daniel Stone  wrote:
> Nouveau has made a very deliberate choice to hide its actual kernel ABI
> behind libdrm. i915 is no longer out of date.
>
> Signed-off-by: Daniel Stone 

Acked-by: Alex Deucher 

> ---
>  include/drm/README | 6 +-
>  1 file changed, 1 insertion(+), 5 deletions(-)
>
> diff --git a/include/drm/README b/include/drm/README
> index 5b518ddf..b4658dd7 100644
> --- a/include/drm/README
> +++ b/include/drm/README
> @@ -91,14 +91,10 @@ Most UMS headers:
>  Status: ?
>  Promote to fixed size ints, which match the current (32bit) ones.
>
> -i915_drm.h
> - - Missing PARAMS - HAS_POOLED_EU, MIN_EU_IN_POOL 
> CONTEXT_PARAM_NO_ERROR_CAPTURE
> -Status: Trivial.
> -
>  nouveau_drm.h
>   - Missing macros NOUVEAU_GETPARAM*, NOUVEAU_DRM_HEADER_PATCHLEVEL, structs,
>  enums
> -Status: ?
> +Status: Deliberate UABI choice; nouveau hides the exact kernel ABI behind 
> libdrm
>
>  r128_drm.h
>   - Broken compat ioctls.
> --
> 2.16.2
>
> ___
> 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: [Intel-gfx] [PATCH] drm/i915: Do NOT skip the first 4k of stolen memory for pre-allocated buffers

[Chris Wilson]

Quoting Hans de Goede (2018-03-30 13:37:40)
> Hi,
> 
> On 30-03-18 14:30, Chris Wilson wrote:
> > Quoting Hans de Goede (2018-03-30 13:27:15)
> >> Before this commit the WaSkipStolenMemoryFirstPage workaround code was
> >> skipping the first 4k by passing 4096 as start of the address range passed
> >> to drm_mm_init(). This means that calling drm_mm_reserve_node() to try and
> >> reserve the firmware framebuffer so that we can inherit it would always
> >> fail, as the firmware framebuffer starts at address 0.
> >>
> >> Commit d43537610470 ("drm/i915: skip the first 4k of stolen memory on
> >> everything >= gen8") says in its commit message: "This is confirmed to fix
> >> Skylake screen flickering issues (probably caused by the fact that we
> >> initialized a ring in the first page of stolen, but I didn't 100% confirm
> >> this theory)."
> >>
> >> Which suggests that it is safe to use the first page for a linear
> >> framebuffer as the firmware is doing.
> >>
> >> This commit always passes 0 as start to drm_mm_init() and works around
> >> WaSkipStolenMemoryFirstPage in i915_gem_stolen_insert_node_in_range()
> >> by insuring the start address passed by to drm_mm_insert_node_in_range()
> >> is always 4k or more. All entry points to i915_gem_stolen.c go through
> >> i915_gem_stolen_insert_node_in_range(), so that any newly allocated
> >> objects such as ring-buffers will not be allocated in the first 4k.
> >>
> >> The one exception is i915_gem_object_create_stolen_for_preallocated()
> >> which directly calls drm_mm_reserve_node() which now will be able to
> >> use the first 4k.
> >>
> >> This fixes the i915 driver no longer being able to inherit the firmware
> >> framebuffer on gen8+, which fixes the video output changing from the
> >> vendor logo to a black screen as soon as the i915 driver is loaded
> >> (on systems without fbcon).
> > 
> > We've been told by the HW guys not to use the first page. (That's my
> > understanding from every time this gets questioned.)
> 
> Yet the GOP is happily using the first page. I think we may need to make
> a difference here between the GPU not using the first page and the
> display engine/pipeline not using the first page. Note that my patch
> only influences the inheriting of the initial framebuffer as allocated
> by the GOP. It does not influence any other allocations from the
> reserved range, those will still all avoid the first page.
> 
> Without this patch fastboot / flickerfree support is essentially broken
> on any gen8+ hardware given that one of the goals of atomic is to be
> able to do flickerfree transitions I think that this warrants a closer
> look then just simply saying never use the first page.

The concern is what else (i.e. nothing that we allocated ourselves) that
may be in the first page...
-Chris
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 105218] Regresion in 847d0a393d7f0f967f39302900d5330f32b804c8

[bugzilla-daemon]

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

--- Comment #2 from Timothy Arceri  ---
I built from source and for me the Terrain sample crashes with:

An exception has occured: OGRE EXCEPTION(5:ItemIdentityException): Compute Job
with name Terra/ShadowGenerator not found in HlmsCompute::findComputeJob at
/home/tarceri/merc/Ogre/OgreMain/src/OgreHlmsCompute.cpp (line 570)

Tested with Mesa/LLVM master.

-- 
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] drm/tilcdc: Defer probe if there are no connectors

[Sjoerd Simons]

During probe there may not be any connectors yet if e.g. the panel
failed or hasn't been probed yet. I hitting this in practice the panels
probing was being delayed due to using a gpio backlight.

Fix this by returning -EPROBE_DEFER so the probing will be retried.

Signed-off-by: Sjoerd Simons 

---

 drivers/gpu/drm/tilcdc/tilcdc_drv.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/tilcdc/tilcdc_drv.c 
b/drivers/gpu/drm/tilcdc/tilcdc_drv.c
index 1afde61f1247..59f0a44bb6e3 100644
--- a/drivers/gpu/drm/tilcdc/tilcdc_drv.c
+++ b/drivers/gpu/drm/tilcdc/tilcdc_drv.c
@@ -380,7 +380,7 @@ static int tilcdc_init(struct drm_driver *ddrv, struct 
device *dev)
if (!priv->external_connector &&
((priv->num_encoders == 0) || (priv->num_connectors == 0))) {
dev_err(dev, "no encoders/connectors found\n");
-   ret = -ENXIO;
+   ret = -EPROBE_DEFER;
goto init_failed;
}
 
-- 
2.16.3

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

[Bug 105170] Radeon R9 Nano failed testing IB on GFX ring (-110). [amd64, kernel 4.15.4]

[bugzilla-daemon]

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

Alex Deucher  changed:

   What|Removed |Added

 Attachment #137452|text/x-log  |text/plain
  mime type||

-- 
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 00/24] drm_framebuffer boilerplate removal

[Alex Deucher]

On Fri, Mar 30, 2018 at 11:00 AM, Daniel Stone  wrote:
> Hi Alex,
>
> On 30 March 2018 at 15:47, Alex Deucher  wrote:
>> On Fri, Mar 30, 2018 at 10:11 AM, Daniel Stone  wrote:
>>> I intend to remove create_handle when all drivers are converted over
>>> to placing BOs directly inside drm_framebuffer. For most drivers
>>> there's a relatively easy conversion to using the helpers for
>>> basically all framebuffer handling and fbdev emulation as well, though
>>> that's a bit further than I was willing to go without hardware to test
>>> on ...
>>
>> Series is:
>> Acked-by: Alex Deucher 
>
> Thanks a lot for the review! Are you taking the radeon/amdgpu patches
> through your tree? They don't have any dependencies on core code.

Sure.  I'll grab them now.

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

Re: [Intel-gfx] [PATCH] drm/i915: Do NOT skip the first 4k of stolen memory for pre-allocated buffers

[Hans de Goede]

Hi,

On 30-03-18 14:44, Chris Wilson wrote:

Quoting Hans de Goede (2018-03-30 13:37:40)

Hi,

On 30-03-18 14:30, Chris Wilson wrote:

Quoting Hans de Goede (2018-03-30 13:27:15)

Before this commit the WaSkipStolenMemoryFirstPage workaround code was
skipping the first 4k by passing 4096 as start of the address range passed
to drm_mm_init(). This means that calling drm_mm_reserve_node() to try and
reserve the firmware framebuffer so that we can inherit it would always
fail, as the firmware framebuffer starts at address 0.

Commit d43537610470 ("drm/i915: skip the first 4k of stolen memory on
everything >= gen8") says in its commit message: "This is confirmed to fix
Skylake screen flickering issues (probably caused by the fact that we
initialized a ring in the first page of stolen, but I didn't 100% confirm
this theory)."

Which suggests that it is safe to use the first page for a linear
framebuffer as the firmware is doing.

This commit always passes 0 as start to drm_mm_init() and works around
WaSkipStolenMemoryFirstPage in i915_gem_stolen_insert_node_in_range()
by insuring the start address passed by to drm_mm_insert_node_in_range()
is always 4k or more. All entry points to i915_gem_stolen.c go through
i915_gem_stolen_insert_node_in_range(), so that any newly allocated
objects such as ring-buffers will not be allocated in the first 4k.

The one exception is i915_gem_object_create_stolen_for_preallocated()
which directly calls drm_mm_reserve_node() which now will be able to
use the first 4k.

This fixes the i915 driver no longer being able to inherit the firmware
framebuffer on gen8+, which fixes the video output changing from the
vendor logo to a black screen as soon as the i915 driver is loaded
(on systems without fbcon).


We've been told by the HW guys not to use the first page. (That's my
understanding from every time this gets questioned.)


Yet the GOP is happily using the first page. I think we may need to make
a difference here between the GPU not using the first page and the
display engine/pipeline not using the first page. Note that my patch
only influences the inheriting of the initial framebuffer as allocated
by the GOP. It does not influence any other allocations from the
reserved range, those will still all avoid the first page.

Without this patch fastboot / flickerfree support is essentially broken
on any gen8+ hardware given that one of the goals of atomic is to be
able to do flickerfree transitions I think that this warrants a closer
look then just simply saying never use the first page.


The concern is what else (i.e. nothing that we allocated ourselves) that
may be in the first page...


Given that the GOP has put its framebuffer there at least at boot there
is nothing there, otherwise it would show up on the display.

We have a whole bunch of code to inherit the BIOS fb in intel_display.c
and AFAIK that code is there because this inheriting the BIOS fb is
deemed an important feature. So I'm not happy at all with the handwavy
best to not touch it answer I'm getting to this patch.

Unless there are some clear answer from the hardware folks which specifically
say we cannot put a framebuffer there (and then why is the GOP doing it?)
then I believe that the best way forward here is to get various people to
test with this patch and the best way to do that is probably to put it
in next. Note I deliberately did not add a Cc stable.

Regards,

Hans



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

[Bug 105170] Radeon R9 Nano failed testing IB on GFX ring (-110). [amd64, kernel 4.15.4]

[bugzilla-daemon]

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

--- Comment #5 from erhar...@mailbox.org ---
Still no luck with kernel 4.15.14 or 4.16_rc7.

The 2nd card in this system got no problems with the ring test (R9 290).

# lspci | grep -i vga
01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI]
Hawaii PRO [Radeon R9 290/390]
02:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Fiji
[Radeon R9 FURY / NANO Series] (rev ca)

-- 
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 21/24] drm/msm: Move GEM BOs to drm_framebuffer

[Daniel Stone]

Since drm_framebuffer can now store GEM objects directly, place them
there rather than in our own subclass. As this makes the framebuffer
create_handle function the same as the GEM framebuffer helper, we
can reuse that.

Signed-off-by: Daniel Stone 
Cc: Rob Clark 
Cc: linux-arm-...@vger.kernel.org
---
 drivers/gpu/drm/msm/msm_fb.c | 54 +---
 1 file changed, 11 insertions(+), 43 deletions(-)

diff --git a/drivers/gpu/drm/msm/msm_fb.c b/drivers/gpu/drm/msm/msm_fb.c
index 0e0c87252ab0..dfa0e05b21b8 100644
--- a/drivers/gpu/drm/msm/msm_fb.c
+++ b/drivers/gpu/drm/msm/msm_fb.c
@@ -17,6 +17,7 @@
 
 #include 
 #include 
+#include 
 
 #include "msm_drv.h"
 #include "msm_kms.h"
@@ -25,49 +26,20 @@
 struct msm_framebuffer {
struct drm_framebuffer base;
const struct msm_format *format;
-   struct drm_gem_object *planes[MAX_PLANE];
 };
 #define to_msm_framebuffer(x) container_of(x, struct msm_framebuffer, base)
 
 static struct drm_framebuffer *msm_framebuffer_init(struct drm_device *dev,
const struct drm_mode_fb_cmd2 *mode_cmd, struct drm_gem_object 
**bos);
 
-static int msm_framebuffer_create_handle(struct drm_framebuffer *fb,
-   struct drm_file *file_priv,
-   unsigned int *handle)
-{
-   struct msm_framebuffer *msm_fb = to_msm_framebuffer(fb);
-   return drm_gem_handle_create(file_priv,
-   msm_fb->planes[0], handle);
-}
-
-static void msm_framebuffer_destroy(struct drm_framebuffer *fb)
-{
-   struct msm_framebuffer *msm_fb = to_msm_framebuffer(fb);
-   int i, n = fb->format->num_planes;
-
-   DBG("destroy: FB ID: %d (%p)", fb->base.id, fb);
-
-   drm_framebuffer_cleanup(fb);
-
-   for (i = 0; i < n; i++) {
-   struct drm_gem_object *bo = msm_fb->planes[i];
-
-   drm_gem_object_put_unlocked(bo);
-   }
-
-   kfree(msm_fb);
-}
-
 static const struct drm_framebuffer_funcs msm_framebuffer_funcs = {
-   .create_handle = msm_framebuffer_create_handle,
-   .destroy = msm_framebuffer_destroy,
+   .create_handle = drm_gem_fb_create_handle,
+   .destroy = drm_gem_fb_destroy,
 };
 
 #ifdef CONFIG_DEBUG_FS
 void msm_framebuffer_describe(struct drm_framebuffer *fb, struct seq_file *m)
 {
-   struct msm_framebuffer *msm_fb = to_msm_framebuffer(fb);
int i, n = fb->format->num_planes;
 
seq_printf(m, "fb: %dx%d@%4.4s (%2d, ID:%d)\n",
@@ -77,7 +49,7 @@ void msm_framebuffer_describe(struct drm_framebuffer *fb, 
struct seq_file *m)
for (i = 0; i < n; i++) {
seq_printf(m, "   %d: offset=%d pitch=%d, obj: ",
i, fb->offsets[i], fb->pitches[i]);
-   msm_gem_describe(msm_fb->planes[i], m);
+   msm_gem_describe(fb->obj[i], m);
}
 }
 #endif
@@ -90,12 +62,11 @@ void msm_framebuffer_describe(struct drm_framebuffer *fb, 
struct seq_file *m)
 int msm_framebuffer_prepare(struct drm_framebuffer *fb,
struct msm_gem_address_space *aspace)
 {
-   struct msm_framebuffer *msm_fb = to_msm_framebuffer(fb);
int ret, i, n = fb->format->num_planes;
uint64_t iova;
 
for (i = 0; i < n; i++) {
-   ret = msm_gem_get_iova(msm_fb->planes[i], aspace, );
+   ret = msm_gem_get_iova(fb->obj[i], aspace, );
DBG("FB[%u]: iova[%d]: %08llx (%d)", fb->base.id, i, iova, ret);
if (ret)
return ret;
@@ -107,26 +78,23 @@ int msm_framebuffer_prepare(struct drm_framebuffer *fb,
 void msm_framebuffer_cleanup(struct drm_framebuffer *fb,
struct msm_gem_address_space *aspace)
 {
-   struct msm_framebuffer *msm_fb = to_msm_framebuffer(fb);
int i, n = fb->format->num_planes;
 
for (i = 0; i < n; i++)
-   msm_gem_put_iova(msm_fb->planes[i], aspace);
+   msm_gem_put_iova(fb->obj[i], aspace);
 }
 
 uint32_t msm_framebuffer_iova(struct drm_framebuffer *fb,
struct msm_gem_address_space *aspace, int plane)
 {
-   struct msm_framebuffer *msm_fb = to_msm_framebuffer(fb);
-   if (!msm_fb->planes[plane])
+   if (!fb->obj[plane])
return 0;
-   return msm_gem_iova(msm_fb->planes[plane], aspace) + fb->offsets[plane];
+   return msm_gem_iova(fb->obj[plane], aspace) + fb->offsets[plane];
 }
 
 struct drm_gem_object *msm_framebuffer_bo(struct drm_framebuffer *fb, int 
plane)
 {
-   struct msm_framebuffer *msm_fb = to_msm_framebuffer(fb);
-   return msm_fb->planes[plane];
+   return drm_gem_fb_get_obj(fb, plane);
 }
 
 const struct msm_format *msm_framebuffer_format(struct drm_framebuffer *fb)
@@ -201,7 +169,7 @@ static struct drm_framebuffer *msm_framebuffer_init(struct 
drm_device *dev,
 
msm_fb->format = format;
 
-   if (n > ARRAY_SIZE(msm_fb->planes)) {
+   if (n > ARRAY_SIZE(fb->obj)) {
  

[PATCH 16/24] drm/exynos: Move GEM BOs to drm_framebuffer

[Daniel Stone]

Since drm_framebuffer can now store GEM objects directly, place them
there rather than in our own subclass. As this makes the framebuffer
create_handle and destroy functions the same as the GEM framebuffer
helper, we can reuse those.

Signed-off-by: Daniel Stone 
Cc: Inki Dae 
Cc: Joonyoung Shim 
Cc: Seung-Woo Kim 
Cc: Kyungmin Park 
---
 drivers/gpu/drm/exynos/exynos_drm_fb.c | 39 --
 1 file changed, 4 insertions(+), 35 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_fb.c 
b/drivers/gpu/drm/exynos/exynos_drm_fb.c
index 2379d732da67..d874c2d50ab6 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fb.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fb.c
@@ -18,6 +18,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 #include "exynos_drm_drv.h"
@@ -36,7 +37,6 @@
  */
 struct exynos_drm_fb {
struct drm_framebuffer  fb;
-   struct exynos_drm_gem   *exynos_gem[MAX_FB_BUFFER];
dma_addr_t  dma_addr[MAX_FB_BUFFER];
 };
 
@@ -66,40 +66,9 @@ static int check_fb_gem_memory_type(struct drm_device 
*drm_dev,
return 0;
 }
 
-static void exynos_drm_fb_destroy(struct drm_framebuffer *fb)
-{
-   struct exynos_drm_fb *exynos_fb = to_exynos_fb(fb);
-   unsigned int i;
-
-   drm_framebuffer_cleanup(fb);
-
-   for (i = 0; i < ARRAY_SIZE(exynos_fb->exynos_gem); i++) {
-   struct drm_gem_object *obj;
-
-   if (exynos_fb->exynos_gem[i] == NULL)
-   continue;
-
-   obj = _fb->exynos_gem[i]->base;
-   drm_gem_object_unreference_unlocked(obj);
-   }
-
-   kfree(exynos_fb);
-   exynos_fb = NULL;
-}
-
-static int exynos_drm_fb_create_handle(struct drm_framebuffer *fb,
-   struct drm_file *file_priv,
-   unsigned int *handle)
-{
-   struct exynos_drm_fb *exynos_fb = to_exynos_fb(fb);
-
-   return drm_gem_handle_create(file_priv,
-_fb->exynos_gem[0]->base, handle);
-}
-
 static const struct drm_framebuffer_funcs exynos_drm_fb_funcs = {
-   .destroy= exynos_drm_fb_destroy,
-   .create_handle  = exynos_drm_fb_create_handle,
+   .destroy= drm_gem_fb_destroy,
+   .create_handle  = drm_gem_fb_create_handle,
 };
 
 struct drm_framebuffer *
@@ -121,7 +90,7 @@ exynos_drm_framebuffer_init(struct drm_device *dev,
if (ret < 0)
goto err;
 
-   exynos_fb->exynos_gem[i] = exynos_gem[i];
+   exynos_fb->fb.obj[i] = _gem[i]->base;
exynos_fb->dma_addr[i] = exynos_gem[i]->dma_addr
+ mode_cmd->offsets[i];
}
-- 
2.16.2

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

[PATCH 17/24] drm/exynos: Move dma_addr out of exynos_drm_fb

[Daniel Stone]

This can be calculated from the GEM BO DMA address as well as the offset
stored in the base framebuffer.

Signed-off-by: Daniel Stone 
Cc: Inki Dae 
Cc: Joonyoung Shim 
Cc: Seung-Woo Kim 
Cc: Kyungmin Park 
---
 drivers/gpu/drm/exynos/exynos_drm_fb.c | 8 +++-
 1 file changed, 3 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_fb.c 
b/drivers/gpu/drm/exynos/exynos_drm_fb.c
index d874c2d50ab6..8be6263929b7 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fb.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fb.c
@@ -37,7 +37,6 @@
  */
 struct exynos_drm_fb {
struct drm_framebuffer  fb;
-   dma_addr_t  dma_addr[MAX_FB_BUFFER];
 };
 
 static int check_fb_gem_memory_type(struct drm_device *drm_dev,
@@ -91,8 +90,6 @@ exynos_drm_framebuffer_init(struct drm_device *dev,
goto err;
 
exynos_fb->fb.obj[i] = _gem[i]->base;
-   exynos_fb->dma_addr[i] = exynos_gem[i]->dma_addr
-   + mode_cmd->offsets[i];
}
 
drm_helper_mode_fill_fb_struct(dev, _fb->fb, mode_cmd);
@@ -160,12 +157,13 @@ exynos_user_fb_create(struct drm_device *dev, struct 
drm_file *file_priv,
 
 dma_addr_t exynos_drm_fb_dma_addr(struct drm_framebuffer *fb, int index)
 {
-   struct exynos_drm_fb *exynos_fb = to_exynos_fb(fb);
+   struct exynos_drm_gem *exynos_gem;
 
if (WARN_ON_ONCE(index >= MAX_FB_BUFFER))
return 0;
 
-   return exynos_fb->dma_addr[index];
+   exynos_gem = to_exynos_gem(fb->obj[index]);
+   return exynos_gem->dma_addr + fb->offsets[index];
 }
 
 static struct drm_mode_config_helper_funcs exynos_drm_mode_config_helpers = {
-- 
2.16.2

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

[PATCH 05/24] drm/rockchip: rockchip_drm_fb -> drm_framebuffer

[Daniel Stone]

Now that rockchip_drm_fb is just a wrapper around drm_framebuffer, we
can remove it.

Signed-off-by: Daniel Stone 
Cc: Sandy Huang 
Cc: Heiko Stübner 
---
 drivers/gpu/drm/rockchip/rockchip_drm_fb.c  | 54 ++---
 drivers/gpu/drm/rockchip/rockchip_drm_fb.h  |  3 --
 drivers/gpu/drm/rockchip/rockchip_drm_vop.c |  4 +--
 3 files changed, 21 insertions(+), 40 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_fb.c 
b/drivers/gpu/drm/rockchip/rockchip_drm_fb.c
index d7083c07c294..a4d0a00abcd9 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_fb.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_fb.c
@@ -25,21 +25,6 @@
 #include "rockchip_drm_gem.h"
 #include "rockchip_drm_psr.h"
 
-#define to_rockchip_fb(x) container_of(x, struct rockchip_drm_fb, fb)
-
-struct rockchip_drm_fb {
-   struct drm_framebuffer fb;
-};
-
-struct drm_gem_object *rockchip_fb_get_gem_obj(struct drm_framebuffer *fb,
-  unsigned int plane)
-{
-   if (plane >= ROCKCHIP_MAX_FB_BUFFER)
-   return NULL;
-
-   return fb->obj[plane];
-}
-
 static int rockchip_drm_fb_dirty(struct drm_framebuffer *fb,
 struct drm_file *file,
 unsigned int flags, unsigned int color,
@@ -56,41 +41,40 @@ static const struct drm_framebuffer_funcs 
rockchip_drm_fb_funcs = {
.dirty = rockchip_drm_fb_dirty,
 };
 
-static struct rockchip_drm_fb *
+static struct drm_framebuffer *
 rockchip_fb_alloc(struct drm_device *dev, const struct drm_mode_fb_cmd2 
*mode_cmd,
  struct drm_gem_object **obj, unsigned int num_planes)
 {
-   struct rockchip_drm_fb *rockchip_fb;
+   struct drm_framebuffer *fb;
int ret;
int i;
 
-   rockchip_fb = kzalloc(sizeof(*rockchip_fb), GFP_KERNEL);
-   if (!rockchip_fb)
+   fb = kzalloc(sizeof(*fb), GFP_KERNEL);
+   if (!fb)
return ERR_PTR(-ENOMEM);
 
-   drm_helper_mode_fill_fb_struct(dev, _fb->fb, mode_cmd);
+   drm_helper_mode_fill_fb_struct(dev, fb, mode_cmd);
 
for (i = 0; i < num_planes; i++)
-   rockchip_fb->fb.obj[i] = obj[i];
+   fb->obj[i] = obj[i];
 
-   ret = drm_framebuffer_init(dev, _fb->fb,
-  _drm_fb_funcs);
+   ret = drm_framebuffer_init(dev, fb, _drm_fb_funcs);
if (ret) {
DRM_DEV_ERROR(dev->dev,
  "Failed to initialize framebuffer: %d\n",
  ret);
-   kfree(rockchip_fb);
+   kfree(fb);
return ERR_PTR(ret);
}
 
-   return rockchip_fb;
+   return fb;
 }
 
 static struct drm_framebuffer *
 rockchip_user_fb_create(struct drm_device *dev, struct drm_file *file_priv,
const struct drm_mode_fb_cmd2 *mode_cmd)
 {
-   struct rockchip_drm_fb *rockchip_fb;
+   struct drm_framebuffer *fb;
struct drm_gem_object *objs[ROCKCHIP_MAX_FB_BUFFER];
struct drm_gem_object *obj;
unsigned int hsub;
@@ -129,13 +113,13 @@ rockchip_user_fb_create(struct drm_device *dev, struct 
drm_file *file_priv,
objs[i] = obj;
}
 
-   rockchip_fb = rockchip_fb_alloc(dev, mode_cmd, objs, i);
-   if (IS_ERR(rockchip_fb)) {
-   ret = PTR_ERR(rockchip_fb);
+   fb = rockchip_fb_alloc(dev, mode_cmd, objs, i);
+   if (IS_ERR(fb)) {
+   ret = PTR_ERR(fb);
goto err_gem_object_unreference;
}
 
-   return _fb->fb;
+   return fb;
 
 err_gem_object_unreference:
for (i--; i >= 0; i--)
@@ -159,13 +143,13 @@ rockchip_drm_framebuffer_init(struct drm_device *dev,
  const struct drm_mode_fb_cmd2 *mode_cmd,
  struct drm_gem_object *obj)
 {
-   struct rockchip_drm_fb *rockchip_fb;
+   struct drm_framebuffer *fb;
 
-   rockchip_fb = rockchip_fb_alloc(dev, mode_cmd, , 1);
-   if (IS_ERR(rockchip_fb))
-   return ERR_CAST(rockchip_fb);
+   fb = rockchip_fb_alloc(dev, mode_cmd, , 1);
+   if (IS_ERR(fb))
+   return ERR_CAST(fb);
 
-   return _fb->fb;
+   return fb;
 }
 
 void rockchip_drm_mode_config_init(struct drm_device *dev)
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_fb.h 
b/drivers/gpu/drm/rockchip/rockchip_drm_fb.h
index 2fe47f1ee98f..f1265cb1aee8 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_fb.h
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_fb.h
@@ -22,7 +22,4 @@ rockchip_drm_framebuffer_init(struct drm_device *dev,
 void rockchip_drm_framebuffer_fini(struct drm_framebuffer *fb);
 
 void rockchip_drm_mode_config_init(struct drm_device *dev);
-
-struct drm_gem_object *rockchip_fb_get_gem_obj(struct drm_framebuffer *fb,
-  unsigned int plane);
 #endif /* 

[PATCH 19/24] drm/armada: Move GEM BO to drm_framebuffer

[Daniel Stone]

Since drm_framebuffer can now store GEM objects directly, place them
there rather than in our own subclass. As this makes the framebuffer
create_handle and destroy functions the same as the GEM framebuffer
helper, we can reuse those.

Signed-off-by: Daniel Stone 
Cc: Russell King 
---
 drivers/gpu/drm/armada/armada_fb.c | 23 ---
 drivers/gpu/drm/armada/armada_fb.h |  3 +--
 2 files changed, 5 insertions(+), 21 deletions(-)

diff --git a/drivers/gpu/drm/armada/armada_fb.c 
b/drivers/gpu/drm/armada/armada_fb.c
index ac92bce07ecd..edd15126bde9 100644
--- a/drivers/gpu/drm/armada/armada_fb.c
+++ b/drivers/gpu/drm/armada/armada_fb.c
@@ -7,30 +7,15 @@
  */
 #include 
 #include 
+#include 
 #include "armada_drm.h"
 #include "armada_fb.h"
 #include "armada_gem.h"
 #include "armada_hw.h"
 
-static void armada_fb_destroy(struct drm_framebuffer *fb)
-{
-   struct armada_framebuffer *dfb = drm_fb_to_armada_fb(fb);
-
-   drm_framebuffer_cleanup(>fb);
-   drm_gem_object_put_unlocked(>obj->obj);
-   kfree(dfb);
-}
-
-static int armada_fb_create_handle(struct drm_framebuffer *fb,
-   struct drm_file *dfile, unsigned int *handle)
-{
-   struct armada_framebuffer *dfb = drm_fb_to_armada_fb(fb);
-   return drm_gem_handle_create(dfile, >obj->obj, handle);
-}
-
 static const struct drm_framebuffer_funcs armada_fb_funcs = {
-   .destroy= armada_fb_destroy,
-   .create_handle  = armada_fb_create_handle,
+   .destroy= drm_gem_fb_destroy,
+   .create_handle  = drm_gem_fb_create_handle,
 };
 
 struct armada_framebuffer *armada_framebuffer_create(struct drm_device *dev,
@@ -78,7 +63,7 @@ struct armada_framebuffer *armada_framebuffer_create(struct 
drm_device *dev,
 
dfb->fmt = format;
dfb->mod = config;
-   dfb->obj = obj;
+   dfb->fb.obj[0] = >obj;
 
drm_helper_mode_fill_fb_struct(dev, >fb, mode);
 
diff --git a/drivers/gpu/drm/armada/armada_fb.h 
b/drivers/gpu/drm/armada/armada_fb.h
index 48073c4f54d8..5c130ff5da77 100644
--- a/drivers/gpu/drm/armada/armada_fb.h
+++ b/drivers/gpu/drm/armada/armada_fb.h
@@ -10,13 +10,12 @@
 
 struct armada_framebuffer {
struct drm_framebuffer  fb;
-   struct armada_gem_object *obj;
uint8_t fmt;
uint8_t mod;
 };
 #define drm_fb_to_armada_fb(dfb) \
container_of(dfb, struct armada_framebuffer, fb)
-#define drm_fb_obj(fb) drm_fb_to_armada_fb(fb)->obj
+#define drm_fb_obj(fb) drm_to_armada_gem((fb)->obj[0])
 
 struct armada_framebuffer *armada_framebuffer_create(struct drm_device *,
const struct drm_mode_fb_cmd2 *, struct armada_gem_object *);
-- 
2.16.2

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

[PATCH 10/24] drm/mtk: mtk_drm_fb -> drm_framebuffer

[Daniel Stone]

Now that mtk_drm_fb is an empty wrapper around drm_framebuffer, we can
just delete it.

Signed-off-by: Daniel Stone 
Cc: CK Hu 
Cc: Philipp Zabel 
---
 drivers/gpu/drm/mediatek/mtk_drm_fb.c | 40 ---
 1 file changed, 14 insertions(+), 26 deletions(-)

diff --git a/drivers/gpu/drm/mediatek/mtk_drm_fb.c 
b/drivers/gpu/drm/mediatek/mtk_drm_fb.c
index f130e37123b5..be5f6f1daf55 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_fb.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_fb.c
@@ -23,49 +23,37 @@
 #include "mtk_drm_fb.h"
 #include "mtk_drm_gem.h"
 
-/*
- * mtk specific framebuffer structure.
- *
- * @fb: drm framebuffer object.
- * @gem_obj: array of gem objects.
- */
-struct mtk_drm_fb {
-   struct drm_framebuffer  base;
-};
-
-#define to_mtk_fb(x) container_of(x, struct mtk_drm_fb, base)
-
 static const struct drm_framebuffer_funcs mtk_drm_fb_funcs = {
.create_handle = drm_gem_fb_create_handle,
.destroy = drm_gem_fb_destroy,
 };
 
-static struct mtk_drm_fb *mtk_drm_framebuffer_init(struct drm_device *dev,
+static struct drm_framebuffer *mtk_drm_framebuffer_init(struct drm_device *dev,
const struct drm_mode_fb_cmd2 *mode,
struct drm_gem_object *obj)
 {
-   struct mtk_drm_fb *mtk_fb;
+   struct drm_framebuffer *fb;
int ret;
 
if (drm_format_num_planes(mode->pixel_format) != 1)
return ERR_PTR(-EINVAL);
 
-   mtk_fb = kzalloc(sizeof(*mtk_fb), GFP_KERNEL);
-   if (!mtk_fb)
+   fb = kzalloc(sizeof(*fb), GFP_KERNEL);
+   if (!fb)
return ERR_PTR(-ENOMEM);
 
-   drm_helper_mode_fill_fb_struct(dev, _fb->base, mode);
+   drm_helper_mode_fill_fb_struct(dev, fb, mode);
 
-   mtk_fb->base.obj[0] = obj;
+   fb->obj[0] = obj;
 
-   ret = drm_framebuffer_init(dev, _fb->base, _drm_fb_funcs);
+   ret = drm_framebuffer_init(dev, fb, _drm_fb_funcs);
if (ret) {
DRM_ERROR("failed to initialize framebuffer\n");
-   kfree(mtk_fb);
+   kfree(fb);
return ERR_PTR(ret);
}
 
-   return mtk_fb;
+   return fb;
 }
 
 /*
@@ -100,7 +88,7 @@ struct drm_framebuffer *mtk_drm_mode_fb_create(struct 
drm_device *dev,
   struct drm_file *file,
   const struct drm_mode_fb_cmd2 
*cmd)
 {
-   struct mtk_drm_fb *mtk_fb;
+   struct drm_framebuffer *fb;
struct drm_gem_object *gem;
unsigned int width = cmd->width;
unsigned int height = cmd->height;
@@ -123,13 +111,13 @@ struct drm_framebuffer *mtk_drm_mode_fb_create(struct 
drm_device *dev,
goto unreference;
}
 
-   mtk_fb = mtk_drm_framebuffer_init(dev, cmd, gem);
-   if (IS_ERR(mtk_fb)) {
-   ret = PTR_ERR(mtk_fb);
+   fb = mtk_drm_framebuffer_init(dev, cmd, gem);
+   if (IS_ERR(fb)) {
+   ret = PTR_ERR(fb);
goto unreference;
}
 
-   return _fb->base;
+   return fb;
 
 unreference:
drm_gem_object_put_unlocked(gem);
-- 
2.16.2

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

[PATCH 13/24] drm/tegra: tegra_fb -> drm_framebuffer

[Daniel Stone]

Since tegra_fb is now the same as drm_framebuffer, we can just replace
the type completely.

Signed-off-by: Daniel Stone 
Cc: Thierry Reding 
Cc: linux-te...@vger.kernel.org
---
 drivers/gpu/drm/tegra/drm.h |  6 +-
 drivers/gpu/drm/tegra/fb.c  | 34 ++
 2 files changed, 15 insertions(+), 25 deletions(-)

diff --git a/drivers/gpu/drm/tegra/drm.h b/drivers/gpu/drm/tegra/drm.h
index 025e011d74af..f1fc2cfc8f02 100644
--- a/drivers/gpu/drm/tegra/drm.h
+++ b/drivers/gpu/drm/tegra/drm.h
@@ -29,14 +29,10 @@
 
 struct reset_control;
 
-struct tegra_fb {
-   struct drm_framebuffer base;
-};
-
 #ifdef CONFIG_DRM_FBDEV_EMULATION
 struct tegra_fbdev {
struct drm_fb_helper base;
-   struct tegra_fb *fb;
+   struct drm_framebuffer *fb;
 };
 #endif
 
diff --git a/drivers/gpu/drm/tegra/fb.c b/drivers/gpu/drm/tegra/fb.c
index 5bc8f968284c..57da9683a713 100644
--- a/drivers/gpu/drm/tegra/fb.c
+++ b/drivers/gpu/drm/tegra/fb.c
@@ -16,11 +16,6 @@
 #include "gem.h"
 #include 
 
-static inline struct tegra_fb *to_tegra_fb(struct drm_framebuffer *fb)
-{
-   return container_of(fb, struct tegra_fb, base);
-}
-
 #ifdef CONFIG_DRM_FBDEV_EMULATION
 static inline struct tegra_fbdev *to_tegra_fbdev(struct drm_fb_helper *helper)
 {
@@ -99,7 +94,6 @@ int tegra_fb_get_tiling(struct drm_framebuffer *framebuffer,
 
 static void tegra_fb_destroy(struct drm_framebuffer *framebuffer)
 {
-   struct tegra_fb *fb = to_tegra_fb(framebuffer);
unsigned int i;
 
for (i = 0; i < framebuffer->format->num_planes; i++) {
@@ -114,7 +108,7 @@ static void tegra_fb_destroy(struct drm_framebuffer 
*framebuffer)
}
 
drm_framebuffer_cleanup(framebuffer);
-   kfree(fb);
+   kfree(framebuffer);
 }
 
 static const struct drm_framebuffer_funcs tegra_fb_funcs = {
@@ -122,12 +116,12 @@ static const struct drm_framebuffer_funcs tegra_fb_funcs 
= {
.create_handle = drm_gem_fb_create_handle,
 };
 
-static struct tegra_fb *tegra_fb_alloc(struct drm_device *drm,
-  const struct drm_mode_fb_cmd2 *mode_cmd,
-  struct tegra_bo **planes,
-  unsigned int num_planes)
+static struct drm_framebuffer *tegra_fb_alloc(struct drm_device *drm,
+ const struct drm_mode_fb_cmd2 
*mode_cmd,
+ struct tegra_bo **planes,
+ unsigned int num_planes)
 {
-   struct tegra_fb *fb;
+   struct drm_framebuffer *fb;
unsigned int i;
int err;
 
@@ -135,12 +129,12 @@ static struct tegra_fb *tegra_fb_alloc(struct drm_device 
*drm,
if (!fb)
return ERR_PTR(-ENOMEM);
 
-   drm_helper_mode_fill_fb_struct(drm, >base, mode_cmd);
+   drm_helper_mode_fill_fb_struct(drm, fb, mode_cmd);
 
-   for (i = 0; i < fb->base.format->num_planes; i++)
-   fb->base.obj[i] = [i]->gem;
+   for (i = 0; i < fb->format->num_planes; i++)
+   fb->obj[i] = [i]->gem;
 
-   err = drm_framebuffer_init(drm, >base, _fb_funcs);
+   err = drm_framebuffer_init(drm, fb, _fb_funcs);
if (err < 0) {
dev_err(drm->dev, "failed to initialize framebuffer: %d\n",
err);
@@ -158,7 +152,7 @@ struct drm_framebuffer *tegra_fb_create(struct drm_device 
*drm,
unsigned int hsub, vsub, i;
struct tegra_bo *planes[4];
struct drm_gem_object *gem;
-   struct tegra_fb *fb;
+   struct drm_framebuffer *fb;
int err;
 
hsub = drm_format_horz_chroma_subsampling(cmd->pixel_format);
@@ -194,7 +188,7 @@ struct drm_framebuffer *tegra_fb_create(struct drm_device 
*drm,
goto unreference;
}
 
-   return >base;
+   return fb;
 
 unreference:
while (i--)
@@ -275,7 +269,7 @@ static int tegra_fbdev_probe(struct drm_fb_helper *helper,
return PTR_ERR(fbdev->fb);
}
 
-   fb = >fb->base;
+   fb = fbdev->fb;
helper->fb = fb;
helper->fbdev = info;
 
@@ -376,7 +370,7 @@ static void tegra_fbdev_exit(struct tegra_fbdev *fbdev)
drm_fb_helper_unregister_fbi(>base);
 
if (fbdev->fb)
-   drm_framebuffer_remove(>fb->base);
+   drm_framebuffer_remove(fbdev->fb);
 
drm_fb_helper_fini(>base);
tegra_fbdev_free(fbdev);
-- 
2.16.2

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

[PATCH 14/24] drm/tegra: Move fbdev unmap special case

[Daniel Stone]

User framebuffers are created with either bo->pages or bo->vaddr set,
depending on whether or not an IOMMU is present. On the other hand, the
framebuffer created for fbdev emulation has a vaddr mapping made if
bo->pages is set after creation. This is set up in fbdev probe.

Remove the special case unmapping from the general-purpose framebuffer
destroy, and move it to fbdev teardown.

Signed-off-by: Daniel Stone 
Cc: Thierry Reding 
Cc: linux-te...@vger.kernel.org
---
 drivers/gpu/drm/tegra/fb.c | 17 +++--
 1 file changed, 11 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/tegra/fb.c b/drivers/gpu/drm/tegra/fb.c
index 57da9683a713..709aa6ef171a 100644
--- a/drivers/gpu/drm/tegra/fb.c
+++ b/drivers/gpu/drm/tegra/fb.c
@@ -99,12 +99,8 @@ static void tegra_fb_destroy(struct drm_framebuffer 
*framebuffer)
for (i = 0; i < framebuffer->format->num_planes; i++) {
struct tegra_bo *bo = tegra_fb_get_plane(framebuffer, i);
 
-   if (bo) {
-   if (bo->pages)
-   vunmap(bo->vaddr);
-
+   if (bo)
drm_gem_object_put_unlocked(>gem);
-   }
}
 
drm_framebuffer_cleanup(framebuffer);
@@ -369,8 +365,17 @@ static void tegra_fbdev_exit(struct tegra_fbdev *fbdev)
 {
drm_fb_helper_unregister_fbi(>base);
 
-   if (fbdev->fb)
+   if (fbdev->fb) {
+   struct tegra_bo *bo = tegra_fb_get_plane(fbdev->fb, 0);
+
+   /* Undo the special mapping we made in fbdev probe. */
+   if (bo && bo->pages) {
+   vunmap(bo->vaddr);
+   bo->vaddr = 0;
+   }
+
drm_framebuffer_remove(fbdev->fb);
+   }
 
drm_fb_helper_fini(>base);
tegra_fbdev_free(fbdev);
-- 
2.16.2

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

[PATCH 08/24] drm/mtk: Promote impossible internal error to WARN_ON

[Daniel Stone]

A FB with no object is something we should be shouting very loudly
about, not quietly logging as debug.

Signed-off-by: Daniel Stone 
Cc: CK Hu 
Cc: Philipp Zabel 
---
 drivers/gpu/drm/mediatek/mtk_drm_plane.c | 5 +
 1 file changed, 1 insertion(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/mediatek/mtk_drm_plane.c 
b/drivers/gpu/drm/mediatek/mtk_drm_plane.c
index 2f4b0ffee598..ac010365d88b 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_plane.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_plane.c
@@ -95,10 +95,7 @@ static int mtk_plane_atomic_check(struct drm_plane *plane,
if (!fb)
return 0;
 
-   if (!mtk_fb_get_gem_obj(fb)) {
-   DRM_DEBUG_KMS("buffer is null\n");
-   return -EFAULT;
-   }
+   WARN_ON(!mtk_fb_get_gem_obj(fb));
 
if (!state->crtc)
return 0;
-- 
2.16.2

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

Re: [PATCH 2/8] PCI: Add pci_find_common_upstream_dev()

[Jerome Glisse]

On Thu, Mar 29, 2018 at 11:33:34PM -0700, Christoph Hellwig wrote:
> On Thu, Mar 29, 2018 at 09:58:54PM -0400, Jerome Glisse wrote:
> > dma_map_resource() is the right API (thought its current implementation
> > is fill with x86 assumptions). So i would argue that arch can decide to
> > implement it or simply return dma error address which trigger fallback
> > path into the caller (at least for GPU drivers). SG variant can be added
> > on top.
> 
> It isn't in general.  It doesn't integrate with scatterlists (see my
> comment to page one), and it doesn't integrate with all the subsystems
> that also need a kernel virtual address.

IIRC SG variant was proposed at the time dma_map_resource() was added,
dunno why they did not make it (again from memory i think it was because
it grows the scatterlist struct size). My point is more than people that
need SG variant should work on adding it. People who do not, should not
be stop by the lack of it. There is something there upstream, it does
not make sense to not use it. The dma-buf infrastructure is useful to
many drivers.

If you do not want to share the underlying logic of dma_map_resource()
fine (ie not sharing code inside drivers/iommu/*). I thought it would
be a good thing to share code ...

Cheers,
Jérôme
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Intel-gfx] [PATCH] drm/i915: Do NOT skip the first 4k of stolen memory for pre-allocated buffers

[Hans de Goede]

Hi,

On 30-03-18 14:30, Chris Wilson wrote:

Quoting Hans de Goede (2018-03-30 13:27:15)

Before this commit the WaSkipStolenMemoryFirstPage workaround code was
skipping the first 4k by passing 4096 as start of the address range passed
to drm_mm_init(). This means that calling drm_mm_reserve_node() to try and
reserve the firmware framebuffer so that we can inherit it would always
fail, as the firmware framebuffer starts at address 0.

Commit d43537610470 ("drm/i915: skip the first 4k of stolen memory on
everything >= gen8") says in its commit message: "This is confirmed to fix
Skylake screen flickering issues (probably caused by the fact that we
initialized a ring in the first page of stolen, but I didn't 100% confirm
this theory)."

Which suggests that it is safe to use the first page for a linear
framebuffer as the firmware is doing.

This commit always passes 0 as start to drm_mm_init() and works around
WaSkipStolenMemoryFirstPage in i915_gem_stolen_insert_node_in_range()
by insuring the start address passed by to drm_mm_insert_node_in_range()
is always 4k or more. All entry points to i915_gem_stolen.c go through
i915_gem_stolen_insert_node_in_range(), so that any newly allocated
objects such as ring-buffers will not be allocated in the first 4k.

The one exception is i915_gem_object_create_stolen_for_preallocated()
which directly calls drm_mm_reserve_node() which now will be able to
use the first 4k.

This fixes the i915 driver no longer being able to inherit the firmware
framebuffer on gen8+, which fixes the video output changing from the
vendor logo to a black screen as soon as the i915 driver is loaded
(on systems without fbcon).


We've been told by the HW guys not to use the first page. (That's my
understanding from every time this gets questioned.)


Yet the GOP is happily using the first page. I think we may need to make
a difference here between the GPU not using the first page and the
display engine/pipeline not using the first page. Note that my patch
only influences the inheriting of the initial framebuffer as allocated
by the GOP. It does not influence any other allocations from the
reserved range, those will still all avoid the first page.

Without this patch fastboot / flickerfree support is essentially broken
on any gen8+ hardware given that one of the goals of atomic is to be
able to do flickerfree transitions I think that this warrants a closer
look then just simply saying never use the first page.

Regards,

Hans




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

[Bug 199101] AMDGPU Fury X random screen flicker on Linux kernel 4.16rc5

[bugzilla-daemon]

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

--- Comment #10 from Thomas Crider (tcride...@gmail.com) ---
just fyi I do not get the flicker on 4.16 rc3, this may help to shorten the
time it takes to bisect

-- 
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 libdrm 1/2] headers: Sync with drm-next

[Alex Deucher]

On Fri, Mar 30, 2018 at 8:28 AM, Daniel Stone  wrote:
> Taken from the drm-next pull for 4.17-rc1 (694f54f680f7), and manually
> reconciled:
>
>   core:
> - Dropped DRM_MODE_TYPE_ALL and DRM_MODE_FLAG_ALL; these are purely
>   internal details of the bits accepted by the currently running
>   kernel, and can not be generally relied on by userspace
> - Add HDCP flags
> - Note CTM entry representation is sign-magnitude format, not
>   two's-complement
>   amdgpu:
> - Add QUERY_STATE2 context op
> - Add VCN firmware version query
>   etnaviv:
> - Add more GPU feature flags
>   i915:
> - Add caps, params and ioctls for PMU / perf-stream
> - Add support for explicit fencing
>   nouveau:
> - Add TILE_COMP layout
>   vc4:
> - Add perfmon ioctls
>   virtgpu:
> - Add capset-fix param
>   vmware:
> - Add handle-close ioctl and explicit-fencing support
>
> Signed-off-by: Daniel Stone 

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

[PATCH 02/24] drm/cirrus: cirrus_framebuffer -> drm_framebuffer

[Daniel Stone]

Now cirrus_framebuffer is just an empty wrapper around drm_framebuffer,
we can drop it.

Signed-off-by: Daniel Stone 
Cc: Dave Airlie 
Cc: Gerd Hoffmann 
Cc: virtualizat...@lists.linux-foundation.org
---
 drivers/gpu/drm/cirrus/cirrus_drv.h   |  9 ++---
 drivers/gpu/drm/cirrus/cirrus_fbdev.c | 20 ++--
 drivers/gpu/drm/cirrus/cirrus_main.c  | 20 ++--
 drivers/gpu/drm/cirrus/cirrus_mode.c  | 12 +++-
 4 files changed, 25 insertions(+), 36 deletions(-)

diff --git a/drivers/gpu/drm/cirrus/cirrus_drv.h 
b/drivers/gpu/drm/cirrus/cirrus_drv.h
index 70b23629be0a..ce9db7aab225 100644
--- a/drivers/gpu/drm/cirrus/cirrus_drv.h
+++ b/drivers/gpu/drm/cirrus/cirrus_drv.h
@@ -92,7 +92,6 @@
 
 #define to_cirrus_crtc(x) container_of(x, struct cirrus_crtc, base)
 #define to_cirrus_encoder(x) container_of(x, struct cirrus_encoder, base)
-#define to_cirrus_framebuffer(x) container_of(x, struct cirrus_framebuffer, 
base)
 
 struct cirrus_crtc {
struct drm_crtc base;
@@ -117,10 +116,6 @@ struct cirrus_connector {
struct drm_connectorbase;
 };
 
-struct cirrus_framebuffer {
-   struct drm_framebuffer  base;
-};
-
 struct cirrus_mc {
resource_size_t vram_size;
resource_size_t vram_base;
@@ -151,7 +146,7 @@ struct cirrus_device {
 
 struct cirrus_fbdev {
struct drm_fb_helper helper;
-   struct cirrus_framebuffer gfb;
+   struct drm_framebuffer gfb;
void *sysram;
int size;
int x1, y1, x2, y2; /* dirty rect */
@@ -197,7 +192,7 @@ int cirrus_dumb_create(struct drm_file *file,
   struct drm_mode_create_dumb *args);
 
 int cirrus_framebuffer_init(struct drm_device *dev,
-  struct cirrus_framebuffer *gfb,
+   struct drm_framebuffer *gfb,
const struct drm_mode_fb_cmd2 *mode_cmd,
struct drm_gem_object *obj);
 
diff --git a/drivers/gpu/drm/cirrus/cirrus_fbdev.c 
b/drivers/gpu/drm/cirrus/cirrus_fbdev.c
index a74d32846958..b643ac92801c 100644
--- a/drivers/gpu/drm/cirrus/cirrus_fbdev.c
+++ b/drivers/gpu/drm/cirrus/cirrus_fbdev.c
@@ -22,14 +22,14 @@ static void cirrus_dirty_update(struct cirrus_fbdev *afbdev,
struct drm_gem_object *obj;
struct cirrus_bo *bo;
int src_offset, dst_offset;
-   int bpp = afbdev->gfb.base.format->cpp[0];
+   int bpp = afbdev->gfb.format->cpp[0];
int ret = -EBUSY;
bool unmap = false;
bool store_for_later = false;
int x2, y2;
unsigned long flags;
 
-   obj = afbdev->gfb.base.obj[0];
+   obj = afbdev->gfb.obj[0];
bo = gem_to_cirrus_bo(obj);
 
/*
@@ -82,7 +82,7 @@ static void cirrus_dirty_update(struct cirrus_fbdev *afbdev,
}
for (i = y; i < y + height; i++) {
/* assume equal stride for now */
-   src_offset = dst_offset = i * afbdev->gfb.base.pitches[0] + (x 
* bpp);
+   src_offset = dst_offset = i * afbdev->gfb.pitches[0] + (x * 
bpp);
memcpy_toio(bo->kmap.virtual + src_offset, afbdev->sysram + 
src_offset, width * bpp);
 
}
@@ -204,7 +204,7 @@ static int cirrusfb_create(struct drm_fb_helper *helper,
gfbdev->sysram = sysram;
gfbdev->size = size;
 
-   fb = >gfb.base;
+   fb = >gfb;
if (!fb) {
DRM_INFO("fb is NULL\n");
return -EINVAL;
@@ -246,19 +246,19 @@ static int cirrusfb_create(struct drm_fb_helper *helper,
 static int cirrus_fbdev_destroy(struct drm_device *dev,
struct cirrus_fbdev *gfbdev)
 {
-   struct cirrus_framebuffer *gfb = >gfb;
+   struct drm_framebuffer *gfb = >gfb;
 
drm_fb_helper_unregister_fbi(>helper);
 
-   if (gfb->base.obj[0]) {
-   drm_gem_object_put_unlocked(gfb->base.obj[0]);
-   gfb->base.obj[0] = NULL;
+   if (gfb->obj[0]) {
+   drm_gem_object_put_unlocked(gfb->obj[0]);
+   gfb->obj[0] = NULL;
}
 
vfree(gfbdev->sysram);
drm_fb_helper_fini(>helper);
-   drm_framebuffer_unregister_private(>base);
-   drm_framebuffer_cleanup(>base);
+   drm_framebuffer_unregister_private(gfb);
+   drm_framebuffer_cleanup(gfb);
 
return 0;
 }
diff --git a/drivers/gpu/drm/cirrus/cirrus_main.c 
b/drivers/gpu/drm/cirrus/cirrus_main.c
index f1ee4139ff19..60d54e10a34d 100644
--- a/drivers/gpu/drm/cirrus/cirrus_main.c
+++ b/drivers/gpu/drm/cirrus/cirrus_main.c
@@ -20,15 +20,15 @@ static const struct drm_framebuffer_funcs cirrus_fb_funcs = 
{
 };
 
 int cirrus_framebuffer_init(struct drm_device *dev,
-   struct cirrus_framebuffer *gfb,
+   struct drm_framebuffer *gfb,
const struct 

[PATCH 20/24] drm/gma500: Move GEM BO to drm_framebuffer

[Daniel Stone]

Since drm_framebuffer can now store GEM objects directly, place them
there rather than in our own subclass. As this makes the framebuffer
create_handle and destroy functions the same as the GEM framebuffer
helper, we can reuse those.

Signed-off-by: Daniel Stone 
Cc: Patrik Jakobsson 
---
 drivers/gpu/drm/gma500/accel_2d.c  |  2 +-
 drivers/gpu/drm/gma500/framebuffer.c   | 62 ++
 drivers/gpu/drm/gma500/framebuffer.h   |  1 -
 drivers/gpu/drm/gma500/gma_display.c   | 10 +++---
 drivers/gpu/drm/gma500/gtt.h   |  2 ++
 drivers/gpu/drm/gma500/oaktrail_crtc.c |  3 +-
 6 files changed, 20 insertions(+), 60 deletions(-)

diff --git a/drivers/gpu/drm/gma500/accel_2d.c 
b/drivers/gpu/drm/gma500/accel_2d.c
index c51d9259c7a7..204c8e452eb7 100644
--- a/drivers/gpu/drm/gma500/accel_2d.c
+++ b/drivers/gpu/drm/gma500/accel_2d.c
@@ -251,7 +251,7 @@ static void psbfb_copyarea_accel(struct fb_info *info,
if (!fb)
return;
 
-   offset = psbfb->gtt->offset;
+   offset = to_gtt_range(fb->obj[0])->offset;
stride = fb->pitches[0];
 
switch (fb->format->depth) {
diff --git a/drivers/gpu/drm/gma500/framebuffer.c 
b/drivers/gpu/drm/gma500/framebuffer.c
index cb0a2ae916e0..8fa4ef192c1e 100644
--- a/drivers/gpu/drm/gma500/framebuffer.c
+++ b/drivers/gpu/drm/gma500/framebuffer.c
@@ -33,6 +33,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "psb_drv.h"
 #include "psb_intel_reg.h"
@@ -40,14 +41,9 @@
 #include "framebuffer.h"
 #include "gtt.h"
 
-static void psb_user_framebuffer_destroy(struct drm_framebuffer *fb);
-static int psb_user_framebuffer_create_handle(struct drm_framebuffer *fb,
- struct drm_file *file_priv,
- unsigned int *handle);
-
 static const struct drm_framebuffer_funcs psb_fb_funcs = {
-   .destroy = psb_user_framebuffer_destroy,
-   .create_handle = psb_user_framebuffer_create_handle,
+   .destroy = drm_gem_fb_destroy,
+   .create_handle = drm_gem_fb_create_handle,
 };
 
 #define CMAP_TOHW(_val, _width) _val) << (_width)) + 0x7FFF - (_val)) >> 
16)
@@ -96,17 +92,18 @@ static int psbfb_pan(struct fb_var_screeninfo *var, struct 
fb_info *info)
struct psb_fbdev *fbdev = info->par;
struct psb_framebuffer *psbfb = >pfb;
struct drm_device *dev = psbfb->base.dev;
+   struct gtt_range *gtt = to_gtt_range(psbfb->base.obj[0]);
 
/*
 *  We have to poke our nose in here. The core fb code assumes
 *  panning is part of the hardware that can be invoked before
 *  the actual fb is mapped. In our case that isn't quite true.
 */
-   if (psbfb->gtt->npage) {
+   if (gtt->npage) {
/* GTT roll shifts in 4K pages, we need to shift the right
   number of pages */
int pages = info->fix.line_length >> 12;
-   psb_gtt_roll(dev, psbfb->gtt, var->yoffset * pages);
+   psb_gtt_roll(dev, gtt, var->yoffset * pages);
}
 return 0;
 }
@@ -117,13 +114,14 @@ static int psbfb_vm_fault(struct vm_fault *vmf)
struct psb_framebuffer *psbfb = vma->vm_private_data;
struct drm_device *dev = psbfb->base.dev;
struct drm_psb_private *dev_priv = dev->dev_private;
+   struct gtt_range *gtt = to_gtt_range(psbfb->base.obj[0]);
int page_num;
int i;
unsigned long address;
int ret;
unsigned long pfn;
unsigned long phys_addr = (unsigned long)dev_priv->stolen_base +
- psbfb->gtt->offset;
+ gtt->offset;
 
page_num = vma_pages(vma);
address = vmf->address - (vmf->pgoff << PAGE_SHIFT);
@@ -246,7 +244,7 @@ static int psb_framebuffer_init(struct drm_device *dev,
return -EINVAL;
 
drm_helper_mode_fill_fb_struct(dev, >base, mode_cmd);
-   fb->gtt = gt;
+   fb->base.obj[0] = >gem;
ret = drm_framebuffer_init(dev, >base, _fb_funcs);
if (ret) {
dev_err(dev->dev, "framebuffer init failed: %d\n", ret);
@@ -518,8 +516,8 @@ static int psb_fbdev_destroy(struct drm_device *dev, struct 
psb_fbdev *fbdev)
drm_framebuffer_unregister_private(>base);
drm_framebuffer_cleanup(>base);
 
-   if (psbfb->gtt)
-   drm_gem_object_unreference_unlocked(>gtt->gem);
+   if (psbfb->base.obj[0])
+   drm_gem_object_unreference_unlocked(psbfb->base.obj[0]);
return 0;
 }
 
@@ -576,44 +574,6 @@ static void psb_fbdev_fini(struct drm_device *dev)
dev_priv->fbdev = NULL;
 }
 
-/**
- * psb_user_framebuffer_create_handle - add hamdle to a framebuffer
- * @fb: framebuffer
- * @file_priv: our DRM file
- * @handle: returned handle
- *
- * Our framebuffer object is a GTT range which also 

[PATCH 23/24] drm/radeon: radeon_framebuffer -> drm_framebuffer

[Daniel Stone]

Since drm_framebuffer can now store GEM objects directly, place them
there rather than in our own subclass. As this makes the framebuffer
create_handle and destroy functions the same as the GEM framebuffer
helper, we can reuse those.

Signed-off-by: Daniel Stone 
Cc: Alex Deucher 
Cc: Christian König 
Cc: David (ChunMing) Zhou 
Cc: amd-...@lists.freedesktop.org
---
 drivers/gpu/drm/radeon/atombios_crtc.c  | 32 -
 drivers/gpu/drm/radeon/radeon_device.c  |  6 +++---
 drivers/gpu/drm/radeon/radeon_display.c | 30 ---
 drivers/gpu/drm/radeon/radeon_fb.c  | 20 +-
 drivers/gpu/drm/radeon/radeon_legacy_crtc.c | 11 +++---
 drivers/gpu/drm/radeon/radeon_mode.h|  7 +--
 6 files changed, 39 insertions(+), 67 deletions(-)

diff --git a/drivers/gpu/drm/radeon/atombios_crtc.c 
b/drivers/gpu/drm/radeon/atombios_crtc.c
index 028a811c1462..efbd5816082d 100644
--- a/drivers/gpu/drm/radeon/atombios_crtc.c
+++ b/drivers/gpu/drm/radeon/atombios_crtc.c
@@ -1145,7 +1145,6 @@ static int dce4_crtc_do_set_base(struct drm_crtc *crtc,
struct radeon_crtc *radeon_crtc = to_radeon_crtc(crtc);
struct drm_device *dev = crtc->dev;
struct radeon_device *rdev = dev->dev_private;
-   struct radeon_framebuffer *radeon_fb;
struct drm_framebuffer *target_fb;
struct drm_gem_object *obj;
struct radeon_bo *rbo;
@@ -1164,19 +1163,15 @@ static int dce4_crtc_do_set_base(struct drm_crtc *crtc,
return 0;
}
 
-   if (atomic) {
-   radeon_fb = to_radeon_framebuffer(fb);
+   if (atomic)
target_fb = fb;
-   }
-   else {
-   radeon_fb = to_radeon_framebuffer(crtc->primary->fb);
+   else
target_fb = crtc->primary->fb;
-   }
 
/* If atomic, assume fb object is pinned & idle & fenced and
 * just update base pointers
 */
-   obj = radeon_fb->base.obj[0];
+   obj = target_fb->obj[0];
rbo = gem_to_radeon_bo(obj);
r = radeon_bo_reserve(rbo, false);
if (unlikely(r != 0))
@@ -1441,8 +1436,7 @@ static int dce4_crtc_do_set_base(struct drm_crtc *crtc,
WREG32(EVERGREEN_MASTER_UPDATE_MODE + radeon_crtc->crtc_offset, 0);
 
if (!atomic && fb && fb != crtc->primary->fb) {
-   radeon_fb = to_radeon_framebuffer(fb);
-   rbo = gem_to_radeon_bo(radeon_fb->base.obj[0]);
+   rbo = gem_to_radeon_bo(fb->obj[0]);
r = radeon_bo_reserve(rbo, false);
if (unlikely(r != 0))
return r;
@@ -1463,7 +1457,6 @@ static int avivo_crtc_do_set_base(struct drm_crtc *crtc,
struct radeon_crtc *radeon_crtc = to_radeon_crtc(crtc);
struct drm_device *dev = crtc->dev;
struct radeon_device *rdev = dev->dev_private;
-   struct radeon_framebuffer *radeon_fb;
struct drm_gem_object *obj;
struct radeon_bo *rbo;
struct drm_framebuffer *target_fb;
@@ -1481,16 +1474,12 @@ static int avivo_crtc_do_set_base(struct drm_crtc *crtc,
return 0;
}
 
-   if (atomic) {
-   radeon_fb = to_radeon_framebuffer(fb);
+   if (atomic)
target_fb = fb;
-   }
-   else {
-   radeon_fb = to_radeon_framebuffer(crtc->primary->fb);
+   else
target_fb = crtc->primary->fb;
-   }
 
-   obj = radeon_fb->base.obj[0];
+   obj = target_fb->obj[0];
rbo = gem_to_radeon_bo(obj);
r = radeon_bo_reserve(rbo, false);
if (unlikely(r != 0))
@@ -1641,8 +1630,7 @@ static int avivo_crtc_do_set_base(struct drm_crtc *crtc,
WREG32(AVIVO_D1MODE_MASTER_UPDATE_MODE + radeon_crtc->crtc_offset, 3);
 
if (!atomic && fb && fb != crtc->primary->fb) {
-   radeon_fb = to_radeon_framebuffer(fb);
-   rbo = gem_to_radeon_bo(radeon_fb->base.obj[0]);
+   rbo = gem_to_radeon_bo(fb->obj[0]);
r = radeon_bo_reserve(rbo, false);
if (unlikely(r != 0))
return r;
@@ -2149,11 +2137,9 @@ static void atombios_crtc_disable(struct drm_crtc *crtc)
atombios_crtc_dpms(crtc, DRM_MODE_DPMS_OFF);
if (crtc->primary->fb) {
int r;
-   struct radeon_framebuffer *radeon_fb;
struct radeon_bo *rbo;
 
-   radeon_fb = to_radeon_framebuffer(crtc->primary->fb);
-   rbo = gem_to_radeon_bo(radeon_fb->base.obj[0]);
+   rbo = gem_to_radeon_bo(crtc->primary->fb->obj[0]);
r = radeon_bo_reserve(rbo, false);
if (unlikely(r))
DRM_ERROR("failed to reserve rbo before unpin\n");
diff --git a/drivers/gpu/drm/radeon/radeon_device.c 

[PATCH 01/24] drm/cirrus: Place GEM BOs in drm_framebuffer

[Daniel Stone]

Since drm_framebuffer can now store GEM objects directly, place them
there rather than in our own subclass. As this makes the framebuffer
create_handle and destroy functions the same as the GEM framebuffer
helper, we can reuse those.

Signed-off-by: Daniel Stone 
Cc: Dave Airlie 
Cc: Gerd Hoffmann 
Cc: virtualizat...@lists.linux-foundation.org
---
 drivers/gpu/drm/cirrus/cirrus_drv.h   |  1 -
 drivers/gpu/drm/cirrus/cirrus_fbdev.c |  8 
 drivers/gpu/drm/cirrus/cirrus_main.c  | 25 -
 drivers/gpu/drm/cirrus/cirrus_mode.c  |  4 ++--
 4 files changed, 10 insertions(+), 28 deletions(-)

diff --git a/drivers/gpu/drm/cirrus/cirrus_drv.h 
b/drivers/gpu/drm/cirrus/cirrus_drv.h
index be2d7e488062..70b23629be0a 100644
--- a/drivers/gpu/drm/cirrus/cirrus_drv.h
+++ b/drivers/gpu/drm/cirrus/cirrus_drv.h
@@ -119,7 +119,6 @@ struct cirrus_connector {
 
 struct cirrus_framebuffer {
struct drm_framebuffer  base;
-   struct drm_gem_object *obj;
 };
 
 struct cirrus_mc {
diff --git a/drivers/gpu/drm/cirrus/cirrus_fbdev.c 
b/drivers/gpu/drm/cirrus/cirrus_fbdev.c
index 32fbfba2c623..a74d32846958 100644
--- a/drivers/gpu/drm/cirrus/cirrus_fbdev.c
+++ b/drivers/gpu/drm/cirrus/cirrus_fbdev.c
@@ -29,7 +29,7 @@ static void cirrus_dirty_update(struct cirrus_fbdev *afbdev,
int x2, y2;
unsigned long flags;
 
-   obj = afbdev->gfb.obj;
+   obj = afbdev->gfb.base.obj[0];
bo = gem_to_cirrus_bo(obj);
 
/*
@@ -250,9 +250,9 @@ static int cirrus_fbdev_destroy(struct drm_device *dev,
 
drm_fb_helper_unregister_fbi(>helper);
 
-   if (gfb->obj) {
-   drm_gem_object_put_unlocked(gfb->obj);
-   gfb->obj = NULL;
+   if (gfb->base.obj[0]) {
+   drm_gem_object_put_unlocked(gfb->base.obj[0]);
+   gfb->base.obj[0] = NULL;
}
 
vfree(gfbdev->sysram);
diff --git a/drivers/gpu/drm/cirrus/cirrus_main.c 
b/drivers/gpu/drm/cirrus/cirrus_main.c
index 26df1e8cd490..f1ee4139ff19 100644
--- a/drivers/gpu/drm/cirrus/cirrus_main.c
+++ b/drivers/gpu/drm/cirrus/cirrus_main.c
@@ -10,30 +10,13 @@
  */
 #include 
 #include 
+#include 
 
 #include "cirrus_drv.h"
 
-static int cirrus_create_handle(struct drm_framebuffer *fb,
-   struct drm_file* file_priv,
-   unsigned int* handle)
-{
-   struct cirrus_framebuffer *cirrus_fb = to_cirrus_framebuffer(fb);
-
-   return drm_gem_handle_create(file_priv, cirrus_fb->obj, handle);
-}
-
-static void cirrus_user_framebuffer_destroy(struct drm_framebuffer *fb)
-{
-   struct cirrus_framebuffer *cirrus_fb = to_cirrus_framebuffer(fb);
-
-   drm_gem_object_put_unlocked(cirrus_fb->obj);
-   drm_framebuffer_cleanup(fb);
-   kfree(fb);
-}
-
 static const struct drm_framebuffer_funcs cirrus_fb_funcs = {
-   .create_handle = cirrus_create_handle,
-   .destroy = cirrus_user_framebuffer_destroy,
+   .create_handle = drm_gem_fb_create_handle,
+   .destroy = drm_gem_fb_destroy,
 };
 
 int cirrus_framebuffer_init(struct drm_device *dev,
@@ -44,7 +27,7 @@ int cirrus_framebuffer_init(struct drm_device *dev,
int ret;
 
drm_helper_mode_fill_fb_struct(dev, >base, mode_cmd);
-   gfb->obj = obj;
+   gfb->base.obj[0] = obj;
ret = drm_framebuffer_init(dev, >base, _fb_funcs);
if (ret) {
DRM_ERROR("drm_framebuffer_init failed: %d\n", ret);
diff --git a/drivers/gpu/drm/cirrus/cirrus_mode.c 
b/drivers/gpu/drm/cirrus/cirrus_mode.c
index c91b9b054e3f..91b9c42013ff 100644
--- a/drivers/gpu/drm/cirrus/cirrus_mode.c
+++ b/drivers/gpu/drm/cirrus/cirrus_mode.c
@@ -110,7 +110,7 @@ static int cirrus_crtc_do_set_base(struct drm_crtc *crtc,
/* push the previous fb to system ram */
if (!atomic && fb) {
cirrus_fb = to_cirrus_framebuffer(fb);
-   obj = cirrus_fb->obj;
+   obj = cirrus_fb->base.obj[0];
bo = gem_to_cirrus_bo(obj);
ret = cirrus_bo_reserve(bo, false);
if (ret)
@@ -120,7 +120,7 @@ static int cirrus_crtc_do_set_base(struct drm_crtc *crtc,
}
 
cirrus_fb = to_cirrus_framebuffer(crtc->primary->fb);
-   obj = cirrus_fb->obj;
+   obj = cirrus_fb->base.obj[0];
bo = gem_to_cirrus_bo(obj);
 
ret = cirrus_bo_reserve(bo, false);
-- 
2.16.2

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

[PATCH 18/24] drm/exynos: exynos_drm_fb -> drm_framebuffer

[Daniel Stone]

Now exynos_drm_fb is just an empty wrapper around drm_framebuffer, we
can drop it.

Signed-off-by: Daniel Stone 
Cc: Inki Dae 
Cc: Joonyoung Shim 
Cc: Seung-Woo Kim 
Cc: Kyungmin Park 
---
 drivers/gpu/drm/exynos/exynos_drm_fb.c | 28 
 1 file changed, 8 insertions(+), 20 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_fb.c 
b/drivers/gpu/drm/exynos/exynos_drm_fb.c
index 8be6263929b7..7fcc1a7ab1a0 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fb.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fb.c
@@ -27,18 +27,6 @@
 #include "exynos_drm_iommu.h"
 #include "exynos_drm_crtc.h"
 
-#define to_exynos_fb(x)container_of(x, struct exynos_drm_fb, fb)
-
-/*
- * exynos specific framebuffer structure.
- *
- * @fb: drm framebuffer obejct.
- * @exynos_gem: array of exynos specific gem object containing a gem object.
- */
-struct exynos_drm_fb {
-   struct drm_framebuffer  fb;
-};
-
 static int check_fb_gem_memory_type(struct drm_device *drm_dev,
struct exynos_drm_gem *exynos_gem)
 {
@@ -76,12 +64,12 @@ exynos_drm_framebuffer_init(struct drm_device *dev,
struct exynos_drm_gem **exynos_gem,
int count)
 {
-   struct exynos_drm_fb *exynos_fb;
+   struct drm_framebuffer *fb;
int i;
int ret;
 
-   exynos_fb = kzalloc(sizeof(*exynos_fb), GFP_KERNEL);
-   if (!exynos_fb)
+   fb = kzalloc(sizeof(*fb), GFP_KERNEL);
+   if (!fb)
return ERR_PTR(-ENOMEM);
 
for (i = 0; i < count; i++) {
@@ -89,21 +77,21 @@ exynos_drm_framebuffer_init(struct drm_device *dev,
if (ret < 0)
goto err;
 
-   exynos_fb->fb.obj[i] = _gem[i]->base;
+   fb->obj[i] = _gem[i]->base;
}
 
-   drm_helper_mode_fill_fb_struct(dev, _fb->fb, mode_cmd);
+   drm_helper_mode_fill_fb_struct(dev, fb, mode_cmd);
 
-   ret = drm_framebuffer_init(dev, _fb->fb, _drm_fb_funcs);
+   ret = drm_framebuffer_init(dev, fb, _drm_fb_funcs);
if (ret < 0) {
DRM_ERROR("failed to initialize framebuffer\n");
goto err;
}
 
-   return _fb->fb;
+   return fb;
 
 err:
-   kfree(exynos_fb);
+   kfree(fb);
return ERR_PTR(ret);
 }
 
-- 
2.16.2

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

[PATCH 12/24] drm/tegra: Move GEM BOs to drm_framebuffer

[Daniel Stone]

Since drm_framebuffer can now store GEM objects directly, place them
there rather than in our own subclass. As this makes the framebuffer
create_handle function the same as the GEM framebuffer helper, we
can reuse that.

Signed-off-by: Daniel Stone 
Cc: Thierry Reding 
Cc: linux-te...@vger.kernel.org
---
 drivers/gpu/drm/tegra/drm.h |  1 -
 drivers/gpu/drm/tegra/fb.c  | 37 -
 2 files changed, 8 insertions(+), 30 deletions(-)

diff --git a/drivers/gpu/drm/tegra/drm.h b/drivers/gpu/drm/tegra/drm.h
index 79340fb1de43..025e011d74af 100644
--- a/drivers/gpu/drm/tegra/drm.h
+++ b/drivers/gpu/drm/tegra/drm.h
@@ -31,7 +31,6 @@ struct reset_control;
 
 struct tegra_fb {
struct drm_framebuffer base;
-   struct tegra_bo **planes;
 };
 
 #ifdef CONFIG_DRM_FBDEV_EMULATION
diff --git a/drivers/gpu/drm/tegra/fb.c b/drivers/gpu/drm/tegra/fb.c
index 75badf371721..5bc8f968284c 100644
--- a/drivers/gpu/drm/tegra/fb.c
+++ b/drivers/gpu/drm/tegra/fb.c
@@ -14,6 +14,7 @@
 
 #include "drm.h"
 #include "gem.h"
+#include 
 
 static inline struct tegra_fb *to_tegra_fb(struct drm_framebuffer *fb)
 {
@@ -30,19 +31,14 @@ static inline struct tegra_fbdev *to_tegra_fbdev(struct 
drm_fb_helper *helper)
 struct tegra_bo *tegra_fb_get_plane(struct drm_framebuffer *framebuffer,
unsigned int index)
 {
-   struct tegra_fb *fb = to_tegra_fb(framebuffer);
-
-   if (index >= framebuffer->format->num_planes)
-   return NULL;
-
-   return fb->planes[index];
+   return to_tegra_bo(drm_gem_fb_get_obj(framebuffer, index));
 }
 
 bool tegra_fb_is_bottom_up(struct drm_framebuffer *framebuffer)
 {
-   struct tegra_fb *fb = to_tegra_fb(framebuffer);
+   struct tegra_bo *bo = tegra_fb_get_plane(framebuffer, 0);
 
-   if (fb->planes[0]->flags & TEGRA_BO_BOTTOM_UP)
+   if (bo->flags & TEGRA_BO_BOTTOM_UP)
return true;
 
return false;
@@ -51,8 +47,7 @@ bool tegra_fb_is_bottom_up(struct drm_framebuffer 
*framebuffer)
 int tegra_fb_get_tiling(struct drm_framebuffer *framebuffer,
struct tegra_bo_tiling *tiling)
 {
-   struct tegra_fb *fb = to_tegra_fb(framebuffer);
-   uint64_t modifier = fb->base.modifier;
+   uint64_t modifier = framebuffer->modifier;
 
switch (modifier) {
case DRM_FORMAT_MOD_LINEAR:
@@ -108,7 +103,7 @@ static void tegra_fb_destroy(struct drm_framebuffer 
*framebuffer)
unsigned int i;
 
for (i = 0; i < framebuffer->format->num_planes; i++) {
-   struct tegra_bo *bo = fb->planes[i];
+   struct tegra_bo *bo = tegra_fb_get_plane(framebuffer, i);
 
if (bo) {
if (bo->pages)
@@ -119,21 +114,12 @@ static void tegra_fb_destroy(struct drm_framebuffer 
*framebuffer)
}
 
drm_framebuffer_cleanup(framebuffer);
-   kfree(fb->planes);
kfree(fb);
 }
 
-static int tegra_fb_create_handle(struct drm_framebuffer *framebuffer,
- struct drm_file *file, unsigned int *handle)
-{
-   struct tegra_fb *fb = to_tegra_fb(framebuffer);
-
-   return drm_gem_handle_create(file, >planes[0]->gem, handle);
-}
-
 static const struct drm_framebuffer_funcs tegra_fb_funcs = {
.destroy = tegra_fb_destroy,
-   .create_handle = tegra_fb_create_handle,
+   .create_handle = drm_gem_fb_create_handle,
 };
 
 static struct tegra_fb *tegra_fb_alloc(struct drm_device *drm,
@@ -149,22 +135,15 @@ static struct tegra_fb *tegra_fb_alloc(struct drm_device 
*drm,
if (!fb)
return ERR_PTR(-ENOMEM);
 
-   fb->planes = kzalloc(num_planes * sizeof(*planes), GFP_KERNEL);
-   if (!fb->planes) {
-   kfree(fb);
-   return ERR_PTR(-ENOMEM);
-   }
-
drm_helper_mode_fill_fb_struct(drm, >base, mode_cmd);
 
for (i = 0; i < fb->base.format->num_planes; i++)
-   fb->planes[i] = planes[i];
+   fb->base.obj[i] = [i]->gem;
 
err = drm_framebuffer_init(drm, >base, _fb_funcs);
if (err < 0) {
dev_err(drm->dev, "failed to initialize framebuffer: %d\n",
err);
-   kfree(fb->planes);
kfree(fb);
return ERR_PTR(err);
}
-- 
2.16.2

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

[PATCH -next] drm/amdkfd: Make function kfd_dev_is_large_bar() static

[Wei Yongjun]

Fixes the following sparse warning:

drivers/gpu/drm/amd/amdkfd/kfd_chardev.c:1150:6: warning:
 symbol 'kfd_dev_is_large_bar' was not declared. Should it be static?

Signed-off-by: Wei Yongjun 
---
 drivers/gpu/drm/amd/amdkfd/kfd_chardev.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_chardev.c 
b/drivers/gpu/drm/amd/amdkfd/kfd_chardev.c
index cd679cf..fb5d997 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_chardev.c
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_chardev.c
@@ -1147,7 +1147,7 @@ static int kfd_ioctl_acquire_vm(struct file *filep, 
struct kfd_process *p,
return ret;
 }
 
-bool kfd_dev_is_large_bar(struct kfd_dev *dev)
+static bool kfd_dev_is_large_bar(struct kfd_dev *dev)
 {
struct kfd_local_mem_info mem_info;

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

Re: [PATCH 2/8] PCI: Add pci_find_common_upstream_dev()

[Logan Gunthorpe]

On 28/03/18 01:44 PM, Christian König wrote:
> Well, isn't that exactly what dma_map_resource() is good for? As far as 
> I can see it makes sure IOMMU is aware of the access route and 
> translates a CPU address into a PCI Bus address.

> I'm using that with the AMD IOMMU driver and at least there it works 
> perfectly fine.

Yes, it would be nice, but no arch has implemented this yet. We are just
lucky in the x86 case because that arch is simple and doesn't need to do
anything for P2P (partially due to the Bus and CPU addresses being the
same). But in the general case, you can't rely on it.

>>> Yeah, but not for ours. See if you want to do real peer 2 peer you need
>>> to keep both the operation as well as the direction into account.
>> Not sure what you are saying here... I'm pretty sure we are doing "real"
>> peer 2 peer...
>>
>>> For example when you can do writes between A and B that doesn't mean
>>> that writes between B and A work. And reads are generally less likely to
>>> work than writes. etc...
>> If both devices are behind a switch then the PCI spec guarantees that A
>> can both read and write B and vice versa.
> 
> Sorry to say that, but I know a whole bunch of PCI devices which 
> horrible ignores that.

Can you elaborate? As far as the device is concerned it shouldn't know
whether a request comes from a peer or from the host. If it does do
crazy stuff like that it's well out of spec. It's up to the switch (or
root complex if good support exists) to route the request to the device
and it's the root complex that tends to be what drops the load requests
which causes the asymmetries.

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

[PATCH -next] drm/amdgpu: fix error return code in amdgpu_amdkfd_gpuvm_create_process_vm()

[Wei Yongjun]

Fix to return error code -ENOMEM from the eviction fence create fail
error handling case instead of 0, as done elsewhere in this function.

Fixes: a46a2cd103a8 ("drm/amdgpu: Add GPUVM memory management functions for 
KFD")
Signed-off-by: Wei Yongjun 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
index a12a165..c5c9c6f 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
@@ -846,6 +846,7 @@ int amdgpu_amdkfd_gpuvm_create_process_vm(struct kgd_dev 
*kgd, void **vm,
   current->mm);
if (!info->eviction_fence) {
pr_err("Failed to create eviction fence\n");
+   ret = -ENOMEM;
goto create_evict_fence_fail;
}

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

[PATCH -next] drm/amdkfd: Fix the error return code in kfd_ioctl_unmap_memory_from_gpu()

[Wei Yongjun]

Passing NULL pointer to PTR_ERR will result in return value of 0
indicating success which is clearly not what it is intended here.
This patch returns -EINVAL instead.

Fixes: 5ec7e02854b3 ("drm/amdkfd: Add ioctls for GPUVM memory management")
Signed-off-by: Wei Yongjun 
---
 drivers/gpu/drm/amd/amdkfd/kfd_chardev.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_chardev.c 
b/drivers/gpu/drm/amd/amdkfd/kfd_chardev.c
index cd679cf..c32a341 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_chardev.c
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_chardev.c
@@ -1421,7 +1421,7 @@ static int kfd_ioctl_unmap_memory_from_gpu(struct file 
*filep,
 
pdd = kfd_get_process_device_data(dev, p);
if (!pdd) {
-   err = PTR_ERR(pdd);
+   err = -EINVAL;
goto bind_process_to_device_failed;
}

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

[PATCH v2] drm/mxsfb: add output_poll_changed handler for initial configuration

[Michael Grzeschik]

The driver registers the poll helper but has no output plug handler
registered. Therefor kms_hotplug_event doesn't trigger any configuration
changes on the framebuffer. The initial configuration setup, after
drm_kms_helper_poll_init is started, will also be missed. This is
running the framebuffer unusable. We fix it by assigning
drm_fb_helper_output_poll_changed to output_pull_changed.

Signed-off-by: Michael Grzeschik 
---
v1 -> v2: - improved the commit message
  - deleted unnecessary move of drm_kms_helper_poll_init.
It was a leftover from using drm_fbdev_cma_hotplug_event
which is also calling drm_fb_helper_hotplug_event

 drivers/gpu/drm/mxsfb/mxsfb_drv.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/mxsfb/mxsfb_drv.c 
b/drivers/gpu/drm/mxsfb/mxsfb_drv.c
index 1207ffe362505..b8b93e8be1975 100644
--- a/drivers/gpu/drm/mxsfb/mxsfb_drv.c
+++ b/drivers/gpu/drm/mxsfb/mxsfb_drv.c
@@ -94,6 +94,7 @@ void mxsfb_disable_axi_clk(struct mxsfb_drm_private *mxsfb)
 
 static const struct drm_mode_config_funcs mxsfb_mode_config_funcs = {
.fb_create  = drm_gem_fb_create,
+   .output_poll_changed= drm_fb_helper_output_poll_changed,
.atomic_check   = drm_atomic_helper_check,
.atomic_commit  = drm_atomic_helper_commit,
 };
-- 
2.16.1

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

Re: [PATCH 2/8] PCI: Add pci_find_common_upstream_dev()

[Logan Gunthorpe]

On 29/03/18 10:10 AM, Christian König wrote:
> Why not? I mean the dma_map_resource() function is for P2P while other 
> dma_map_* functions are only for system memory.

Oh, hmm, I wasn't aware dma_map_resource was exclusively for mapping
P2P. Though it's a bit odd seeing we've been working under the
assumption that PCI P2P is different as it has to translate the PCI bus
address. Where as P2P for devices on other buses is a big unknown.

>> And this is necessary to
>> check if the DMA ops in use support it or not. We can't have the
>> dma_map_X() functions do the wrong thing because they don't support it yet.
> 
> Well that sounds like we should just return an error from 
> dma_map_resources() when an architecture doesn't support P2P yet as Alex 
> suggested.

Yes, well except in our patch-set we can't easily use
dma_map_resources() as we either have SGLs to deal with or we need to
create whole new interfaces to a number of subsystems.

> You don't seem to understand the implications: The devices do have a 
> common upstream bridge! In other words your code would currently claim 
> that P2P is supported, but in practice it doesn't work.

Do they? They don't on any of the Intel machines I'm looking at. The
previous version of the patchset not only required a common upstream
bridge but two layers of upstream bridges on both devices which would
effectively limit transfers to PCIe switches only. But Bjorn did not
like this.

> You need to include both drivers which participate in the P2P 
> transaction to make sure that both supports this and give them 
> opportunity to chicken out and in the case of AMD APUs even redirect the 
> request to another location (e.g. participate in the DMA translation).

I don't think it's the drivers responsibility to reject P2P . The
topology is what governs support or not. The discussions we had with
Bjorn settled on if the devices are all behind the same bridge they can
communicate with each other. This is essentially guaranteed by the PCI spec.

> DMA-buf fortunately seems to handle all this already, that's why we 
> choose it as base for our implementation.

Well, unfortunately DMA-buf doesn't help for the drivers we are working
with as neither the block layer nor the RDMA subsystem have any
interfaces for it.

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

[Bug 105170] Radeon R9 Nano failed testing IB on GFX ring (-110). [amd64, kernel 4.15.4]

[bugzilla-daemon]

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

--- Comment #7 from Alex Deucher  ---
Does anything change if you try the cards in different slots in the
motherboard?

-- 
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: [Intel-gfx] [PATCH] drm/i915: Do NOT skip the first 4k of stolen memory for pre-allocated buffers

[Hans de Goede]

Hi,

On 30-03-18 15:25, Hans de Goede wrote:

Hi,

On 30-03-18 14:44, Chris Wilson wrote:

Quoting Hans de Goede (2018-03-30 13:37:40)

Hi,

On 30-03-18 14:30, Chris Wilson wrote:

Quoting Hans de Goede (2018-03-30 13:27:15)

Before this commit the WaSkipStolenMemoryFirstPage workaround code was
skipping the first 4k by passing 4096 as start of the address range passed
to drm_mm_init(). This means that calling drm_mm_reserve_node() to try and
reserve the firmware framebuffer so that we can inherit it would always
fail, as the firmware framebuffer starts at address 0.

Commit d43537610470 ("drm/i915: skip the first 4k of stolen memory on
everything >= gen8") says in its commit message: "This is confirmed to fix
Skylake screen flickering issues (probably caused by the fact that we
initialized a ring in the first page of stolen, but I didn't 100% confirm
this theory)."

Which suggests that it is safe to use the first page for a linear
framebuffer as the firmware is doing.

This commit always passes 0 as start to drm_mm_init() and works around
WaSkipStolenMemoryFirstPage in i915_gem_stolen_insert_node_in_range()
by insuring the start address passed by to drm_mm_insert_node_in_range()
is always 4k or more. All entry points to i915_gem_stolen.c go through
i915_gem_stolen_insert_node_in_range(), so that any newly allocated
objects such as ring-buffers will not be allocated in the first 4k.

The one exception is i915_gem_object_create_stolen_for_preallocated()
which directly calls drm_mm_reserve_node() which now will be able to
use the first 4k.

This fixes the i915 driver no longer being able to inherit the firmware
framebuffer on gen8+, which fixes the video output changing from the
vendor logo to a black screen as soon as the i915 driver is loaded
(on systems without fbcon).


We've been told by the HW guys not to use the first page. (That's my
understanding from every time this gets questioned.)


Yet the GOP is happily using the first page. I think we may need to make
a difference here between the GPU not using the first page and the
display engine/pipeline not using the first page. Note that my patch
only influences the inheriting of the initial framebuffer as allocated
by the GOP. It does not influence any other allocations from the
reserved range, those will still all avoid the first page.

Without this patch fastboot / flickerfree support is essentially broken
on any gen8+ hardware given that one of the goals of atomic is to be
able to do flickerfree transitions I think that this warrants a closer
look then just simply saying never use the first page.


The concern is what else (i.e. nothing that we allocated ourselves) that
may be in the first page...


Given that the GOP has put its framebuffer there at least at boot there
is nothing there, otherwise it would show up on the display.

We have a whole bunch of code to inherit the BIOS fb in intel_display.c
and AFAIK that code is there because this inheriting the BIOS fb is
deemed an important feature. So I'm not happy at all with the handwavy
best to not touch it answer I'm getting to this patch.

Unless there are some clear answer from the hardware folks which specifically
say we cannot put a framebuffer there (and then why is the GOP doing it?)
then I believe that the best way forward here is to get various people to
test with this patch and the best way to do that is probably to put it
in next. Note I deliberately did not add a Cc stable.


To elaborate on this, the excluding of the first 4k of the stolen memory
region causes intel_alloc_initial_plane_obj() from intel_display.c to fail,
which in turn causes intel_find_initial_plane_obj() to call
intel_plane_disable_noatomic(intel_crtc, intel_plane); which temporarily
completely turns off the display which leads to a very ugly flickering
of the display at boot (as well as replacing the vendor logo with a
black screen).

I think we can all agree that this behavior is undesirable and even a
regression in behavior caused by the fix to exclude the first 4k.

Chris, if my patch is not an acceptable way to fix this, then how do you
suggest that we fix this?

Digging a bit deeper I found this:

https://01.org/sites/default/files/documentation/intel-gfx-prm-osrc-kbl-vol16-workarounds.pdf

Which says:

"WaSkipStolenMemoryFirstPage:

WA to skip the first page of stolen
memory due to sporadic HW write on *CS Idle"

And also about FBC:

"First line of FBC getting corrupted when FBC
compressed frame buffer offset is programmed to
zero. Command streamers are doing flush writes to
base of stolen.
WA: New restriction to program FBC compressed
frame buffer offset to at least 4KB."

So using the first 4kB for the *framebuffer* as done by the GOP will
not cause any major problems (freezes, hangs, etc.), and commit
d43537610470 ("drm/i915: skip the first 4k of stolen memory on
everything >= gen8") was correct in deducing that the problem was
likely that some *vital* information was being stored i the first 4k
and that go 

Re: [PATCH 00/24] drm_framebuffer boilerplate removal

[Alex Deucher]

On Fri, Mar 30, 2018 at 10:11 AM, Daniel Stone  wrote:
> Hi,
> I've been working on a getfb2[0] ioctl, which amongst other things
> supports multi-planar framebuffers as well as modifiers. getfb
> currently calls the framebuffer's handle_create hook, which doesn't
> support multiple planes.
>
> Thanks to Noralf's recent work, drivers can just store GEM objects
> directly in drm_framebuffer. I use this directly in getfb2: we need
> direct access to the GEM objects and not a vfunc in order to not hand
> out duplicate GEM names for the same object.
>
> This series converts all drivers except for nouveau, which was a
> little too non-trivial for my comfort, to storing GEM objects directly
> in drm_framebuffer. For those drivers whose driver_framebuffer struct
> was nothing but drm_framebuffer + BO, it deletes the driver-specific
> struct. It also makes use of Noralf's generic framebuffer helpers for
> create_handle and destroy where possible.
>
> I don't have the hardware for most of these drivers, so have had to
> settle for just staring really hard at the diff.
>
> I intend to remove create_handle when all drivers are converted over
> to placing BOs directly inside drm_framebuffer. For most drivers
> there's a relatively easy conversion to using the helpers for
> basically all framebuffer handling and fbdev emulation as well, though
> that's a bit further than I was willing to go without hardware to test
> on ...

Series is:
Acked-by: Alex Deucher 

>
> Cheers,
> Daniel
>
> [0]: https://lists.freedesktop.org/archives/dri-devel/2018-March/170512.html
> ___
> amd-gfx mailing list
> amd-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/amd-gfx
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[RFC 0/2] drm/vc4: Async page flip cleanup

[Boris Brezillon]

Hello,

This is an attempt at simplifying the async page flip handling in VC4
in order to get rid of vc4_queue_seqno_cb() and its dependencies and
rely on fences instead.

The reason I'm sending this as an RFC is because I'm pretty sure we can
put some of the code added in patch 1 in drm_atomic_helper.c. Also, I'd
like to have feedback from Padovan, Daniel and maybe others who have
already thought about handling async page flips generically.
And the last reason is that it's not been extensively tested, so it may
not work correctly :-).

Regards,

Boris

Boris Brezillon (2):
  drm/vc4: Handle async page flips in the atomic_commit() path
  drm/vc4: Get rid of vc4_queue_seqno_cb() and its dependencies

 drivers/gpu/drm/vc4/vc4_crtc.c | 103 +
 drivers/gpu/drm/vc4/vc4_drv.h  |  14 --
 drivers/gpu/drm/vc4/vc4_gem.c  |  39 
 drivers/gpu/drm/vc4/vc4_kms.c  | 101 +---
 4 files changed, 86 insertions(+), 171 deletions(-)

-- 
2.14.1

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

[RFC 2/2] drm/vc4: Get rid of vc4_queue_seqno_cb() and its dependencies

[Boris Brezillon]

The last user of vc4_queue_seqno_cb() (async page flip handling code)
is gone. Get rid of this function and all the related structs and
fields.

Signed-off-by: Boris Brezillon 
---
 drivers/gpu/drm/vc4/vc4_drv.h | 14 --
 drivers/gpu/drm/vc4/vc4_gem.c | 39 ---
 2 files changed, 53 deletions(-)

diff --git a/drivers/gpu/drm/vc4/vc4_drv.h b/drivers/gpu/drm/vc4/vc4_drv.h
index 1b4cd1fabf56..80ed7d02fcee 100644
--- a/drivers/gpu/drm/vc4/vc4_drv.h
+++ b/drivers/gpu/drm/vc4/vc4_drv.h
@@ -158,11 +158,6 @@ struct vc4_dev {
 */
struct vc4_perfmon *active_perfmon;
 
-   /* List of struct vc4_seqno_cb for callbacks to be made from a
-* workqueue when the given seqno is passed.
-*/
-   struct list_head seqno_cb_list;
-
/* The memory used for storing binner tile alloc, tile state,
 * and overflow memory allocations.  This is freed when V3D
 * powers down.
@@ -271,12 +266,6 @@ to_vc4_fence(struct dma_fence *fence)
return (struct vc4_fence *)fence;
 }
 
-struct vc4_seqno_cb {
-   struct work_struct work;
-   uint64_t seqno;
-   void (*func)(struct vc4_seqno_cb *cb);
-};
-
 struct vc4_v3d {
struct vc4_dev *vc4;
struct platform_device *pdev;
@@ -692,9 +681,6 @@ void vc4_move_job_to_render(struct drm_device *dev, struct 
vc4_exec_info *exec);
 int vc4_wait_for_seqno(struct drm_device *dev, uint64_t seqno,
   uint64_t timeout_ns, bool interruptible);
 void vc4_job_handle_completed(struct vc4_dev *vc4);
-int vc4_queue_seqno_cb(struct drm_device *dev,
-  struct vc4_seqno_cb *cb, uint64_t seqno,
-  void (*func)(struct vc4_seqno_cb *cb));
 int vc4_gem_madvise_ioctl(struct drm_device *dev, void *data,
  struct drm_file *file_priv);
 
diff --git a/drivers/gpu/drm/vc4/vc4_gem.c b/drivers/gpu/drm/vc4/vc4_gem.c
index 2107b0daf8ef..93d52be1cd37 100644
--- a/drivers/gpu/drm/vc4/vc4_gem.c
+++ b/drivers/gpu/drm/vc4/vc4_gem.c
@@ -973,7 +973,6 @@ void
 vc4_job_handle_completed(struct vc4_dev *vc4)
 {
unsigned long irqflags;
-   struct vc4_seqno_cb *cb, *cb_temp;
 
spin_lock_irqsave(>job_lock, irqflags);
while (!list_empty(>job_done_list)) {
@@ -987,46 +986,9 @@ vc4_job_handle_completed(struct vc4_dev *vc4)
spin_lock_irqsave(>job_lock, irqflags);
}
 
-   list_for_each_entry_safe(cb, cb_temp, >seqno_cb_list, work.entry) {
-   if (cb->seqno <= vc4->finished_seqno) {
-   list_del_init(>work.entry);
-   schedule_work(>work);
-   }
-   }
-
spin_unlock_irqrestore(>job_lock, irqflags);
 }
 
-static void vc4_seqno_cb_work(struct work_struct *work)
-{
-   struct vc4_seqno_cb *cb = container_of(work, struct vc4_seqno_cb, work);
-
-   cb->func(cb);
-}
-
-int vc4_queue_seqno_cb(struct drm_device *dev,
-  struct vc4_seqno_cb *cb, uint64_t seqno,
-  void (*func)(struct vc4_seqno_cb *cb))
-{
-   struct vc4_dev *vc4 = to_vc4_dev(dev);
-   int ret = 0;
-   unsigned long irqflags;
-
-   cb->func = func;
-   INIT_WORK(>work, vc4_seqno_cb_work);
-
-   spin_lock_irqsave(>job_lock, irqflags);
-   if (seqno > vc4->finished_seqno) {
-   cb->seqno = seqno;
-   list_add_tail(>work.entry, >seqno_cb_list);
-   } else {
-   schedule_work(>work);
-   }
-   spin_unlock_irqrestore(>job_lock, irqflags);
-
-   return ret;
-}
-
 /* Scheduled when any job has been completed, this walks the list of
  * jobs that had completed and unrefs their BOs and frees their exec
  * structs.
@@ -1211,7 +1173,6 @@ vc4_gem_init(struct drm_device *dev)
INIT_LIST_HEAD(>bin_job_list);
INIT_LIST_HEAD(>render_job_list);
INIT_LIST_HEAD(>job_done_list);
-   INIT_LIST_HEAD(>seqno_cb_list);
spin_lock_init(>job_lock);
 
INIT_WORK(>hangcheck.reset_work, vc4_reset_work);
-- 
2.14.1

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

[RFC 1/2] drm/vc4: Handle async page flips in the atomic_commit() path

[Boris Brezillon]

Rework the atomic commit logic to handle async page flip requests in
the atomic update path.

Async page flips are a bit more complicated than async cursor updates
(already handled in the vc4_atomic_commit() function) in that you need
to wait for fences on the new framebuffers to be signaled before doing
the flip. In order to ensure that, we schedule a commit_work work to do
the async update (note that the existing implementation already uses a
work to wait for fences to be signaled, so, the latency shouldn't
change that much).

Of course, we have to modify a bit the atomic_complete_commit()
implementation to avoid waiting for things we don't care about when
doing an async page flip:

* drm_atomic_helper_wait_for_dependencies() waits for flip_done which
  we don't care about when doing async page flips. Instead we replace
  that call by a loop that waits for hw_done only
* drm_atomic_helper_commit_modeset_disables() and
  drm_atomic_helper_commit_modeset_enables() are not needed because
  nothing except the planes' FBs are updated in async page flips
* drm_atomic_helper_commit_planes() is replaced by
  vc4_plane_async_set_fb() which is doing only the FB update and is
  thus much simpler
* drm_atomic_helper_wait_for_vblanks() is not needed because we don't
  wait for the next VBLANK period to apply the new state, and flip
  events are signaled manually just after the HW has been updated

Thanks to this rework, we can get rid of the custom vc4_page_flip()
implementation and its dependencies and use
drm_atomic_helper_page_flip() instead.

Signed-off-by: Boris Brezillon 
---
 drivers/gpu/drm/vc4/vc4_crtc.c | 103 +
 drivers/gpu/drm/vc4/vc4_kms.c  | 101 +---
 2 files changed, 86 insertions(+), 118 deletions(-)

diff --git a/drivers/gpu/drm/vc4/vc4_crtc.c b/drivers/gpu/drm/vc4/vc4_crtc.c
index bf4667481935..3843c39dce61 100644
--- a/drivers/gpu/drm/vc4/vc4_crtc.c
+++ b/drivers/gpu/drm/vc4/vc4_crtc.c
@@ -757,107 +757,6 @@ static irqreturn_t vc4_crtc_irq_handler(int irq, void 
*data)
return ret;
 }
 
-struct vc4_async_flip_state {
-   struct drm_crtc *crtc;
-   struct drm_framebuffer *fb;
-   struct drm_pending_vblank_event *event;
-
-   struct vc4_seqno_cb cb;
-};
-
-/* Called when the V3D execution for the BO being flipped to is done, so that
- * we can actually update the plane's address to point to it.
- */
-static void
-vc4_async_page_flip_complete(struct vc4_seqno_cb *cb)
-{
-   struct vc4_async_flip_state *flip_state =
-   container_of(cb, struct vc4_async_flip_state, cb);
-   struct drm_crtc *crtc = flip_state->crtc;
-   struct drm_device *dev = crtc->dev;
-   struct vc4_dev *vc4 = to_vc4_dev(dev);
-   struct drm_plane *plane = crtc->primary;
-
-   vc4_plane_async_set_fb(plane, flip_state->fb);
-   if (flip_state->event) {
-   unsigned long flags;
-
-   spin_lock_irqsave(>event_lock, flags);
-   drm_crtc_send_vblank_event(crtc, flip_state->event);
-   spin_unlock_irqrestore(>event_lock, flags);
-   }
-
-   drm_crtc_vblank_put(crtc);
-   drm_framebuffer_put(flip_state->fb);
-   kfree(flip_state);
-
-   up(>async_modeset);
-}
-
-/* Implements async (non-vblank-synced) page flips.
- *
- * The page flip ioctl needs to return immediately, so we grab the
- * modeset semaphore on the pipe, and queue the address update for
- * when V3D is done with the BO being flipped to.
- */
-static int vc4_async_page_flip(struct drm_crtc *crtc,
-  struct drm_framebuffer *fb,
-  struct drm_pending_vblank_event *event,
-  uint32_t flags)
-{
-   struct drm_device *dev = crtc->dev;
-   struct vc4_dev *vc4 = to_vc4_dev(dev);
-   struct drm_plane *plane = crtc->primary;
-   int ret = 0;
-   struct vc4_async_flip_state *flip_state;
-   struct drm_gem_cma_object *cma_bo = drm_fb_cma_get_gem_obj(fb, 0);
-   struct vc4_bo *bo = to_vc4_bo(_bo->base);
-
-   flip_state = kzalloc(sizeof(*flip_state), GFP_KERNEL);
-   if (!flip_state)
-   return -ENOMEM;
-
-   drm_framebuffer_get(fb);
-   flip_state->fb = fb;
-   flip_state->crtc = crtc;
-   flip_state->event = event;
-
-   /* Make sure all other async modesetes have landed. */
-   ret = down_interruptible(>async_modeset);
-   if (ret) {
-   drm_framebuffer_put(fb);
-   kfree(flip_state);
-   return ret;
-   }
-
-   WARN_ON(drm_crtc_vblank_get(crtc) != 0);
-
-   /* Immediately update the plane's legacy fb pointer, so that later
-* modeset prep sees the state that will be present when the semaphore
-* is released.
-*/
-   drm_atomic_set_fb_for_plane(plane->state, fb);
-   plane->fb = fb;
-
-   vc4_queue_seqno_cb(dev, 

Re: [Intel-gfx] [PATCH] drm/i915: Do NOT skip the first 4k of stolen memory for pre-allocated buffers

[Chris Wilson]

Quoting Hans de Goede (2018-03-30 13:27:15)
> Before this commit the WaSkipStolenMemoryFirstPage workaround code was
> skipping the first 4k by passing 4096 as start of the address range passed
> to drm_mm_init(). This means that calling drm_mm_reserve_node() to try and
> reserve the firmware framebuffer so that we can inherit it would always
> fail, as the firmware framebuffer starts at address 0.
> 
> Commit d43537610470 ("drm/i915: skip the first 4k of stolen memory on
> everything >= gen8") says in its commit message: "This is confirmed to fix
> Skylake screen flickering issues (probably caused by the fact that we
> initialized a ring in the first page of stolen, but I didn't 100% confirm
> this theory)."
> 
> Which suggests that it is safe to use the first page for a linear
> framebuffer as the firmware is doing.
> 
> This commit always passes 0 as start to drm_mm_init() and works around
> WaSkipStolenMemoryFirstPage in i915_gem_stolen_insert_node_in_range()
> by insuring the start address passed by to drm_mm_insert_node_in_range()
> is always 4k or more. All entry points to i915_gem_stolen.c go through
> i915_gem_stolen_insert_node_in_range(), so that any newly allocated
> objects such as ring-buffers will not be allocated in the first 4k.
> 
> The one exception is i915_gem_object_create_stolen_for_preallocated()
> which directly calls drm_mm_reserve_node() which now will be able to
> use the first 4k.
> 
> This fixes the i915 driver no longer being able to inherit the firmware
> framebuffer on gen8+, which fixes the video output changing from the
> vendor logo to a black screen as soon as the i915 driver is loaded
> (on systems without fbcon).

We've been told by the HW guys not to use the first page. (That's my
understanding from every time this gets questioned.)
-Chris
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 00/24] drm_framebuffer boilerplate removal

[Daniel Stone]

Hi,
I've been working on a getfb2[0] ioctl, which amongst other things
supports multi-planar framebuffers as well as modifiers. getfb
currently calls the framebuffer's handle_create hook, which doesn't
support multiple planes.

Thanks to Noralf's recent work, drivers can just store GEM objects
directly in drm_framebuffer. I use this directly in getfb2: we need
direct access to the GEM objects and not a vfunc in order to not hand
out duplicate GEM names for the same object.

This series converts all drivers except for nouveau, which was a
little too non-trivial for my comfort, to storing GEM objects directly
in drm_framebuffer. For those drivers whose driver_framebuffer struct
was nothing but drm_framebuffer + BO, it deletes the driver-specific
struct. It also makes use of Noralf's generic framebuffer helpers for
create_handle and destroy where possible.

I don't have the hardware for most of these drivers, so have had to
settle for just staring really hard at the diff.

I intend to remove create_handle when all drivers are converted over
to placing BOs directly inside drm_framebuffer. For most drivers
there's a relatively easy conversion to using the helpers for
basically all framebuffer handling and fbdev emulation as well, though
that's a bit further than I was willing to go without hardware to test
on ...

Cheers,
Daniel

[0]: https://lists.freedesktop.org/archives/dri-devel/2018-March/170512.html
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 105760] [4.17-drm-wip] RIP: smu7_populate_single_firmware_entry.isra.6+0x57/0xc0 [amdgpu] RSP: ffffa17901efb930

[bugzilla-daemon]

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

--- Comment #1 from taij...@posteo.de ---
OK, I think I've managed to narrow this one down a bit.

If I build the kernel from commit 09695ad78f1f5f315c7e9c5090f0c7b846a43690,
which is also tagged as 'drm-next-4.17', then everything is shiny. However, if
I go one step beyond that, which is commit
33d009cd889490838c5db9b9339856c9e3d3facc - being the rebasing of
drm-next-4.17-wip onto David Airlie's drm-next branch after he merged AMD's
drm-next-4.17 into his branch, then things to belly up and the kernel does not
boot anymore.

Now, what I do not get is how the rebase to a tree that includes stuff that is
not amdgpu would bork up the ability of amdgpu to load it's firmware?

-- 
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 105760] [4.17-drm-wip] RIP: smu7_populate_single_firmware_entry.isra.6+0x57/0xc0 [amdgpu] RSP: ffffa17901efb930

[bugzilla-daemon]

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

taij...@posteo.de changed:

   What|Removed |Added

   See Also||https://bugs.freedesktop.or
   ||g/show_bug.cgi?id=104854

-- 
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 104854] smu7_populate_single_firmware_entry fails to load powerplay firmware.

[bugzilla-daemon]

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

taij...@posteo.de changed:

   What|Removed |Added

   See Also||https://bugs.freedesktop.or
   ||g/show_bug.cgi?id=105760

-- 
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 102553] Venus PRO R9 M265X amdgpu: Kernel OOPS si_dpm_set_power_state unable to handle kernel NULL pointer dereference

[bugzilla-daemon]

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

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

Thanks for looking into this.  Good start!  The attached patch should fix it.

-- 
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 104063] (DC 4.15-rc2) [drm:dm_logger_write [amdgpu]] *ERROR* hwss_edp_wait_for_hpd_ready: wait timed out!

[bugzilla-daemon]

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

taij...@posteo.de changed:

   What|Removed |Added

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

--- Comment #2 from taij...@posteo.de ---
OK, this one has been fixed in the mean time, closing.

-- 
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 105218] Regresion in 847d0a393d7f0f967f39302900d5330f32b804c8

[bugzilla-daemon]

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

--- Comment #3 from Matias N. Goldberg  ---
Hi!

Thanks for starting to look into this!

First:
 glxinfo | grep OpenGL
OpenGL vendor string: X.Org
OpenGL renderer string: Radeon RX 560 Series (POLARIS11 / DRM 3.19.0 / 4.14.11,
LLVM 6.0.0)
OpenGL core profile version string: 4.5 (Core Profile) Mesa 18.1.0-devel
(git-b3a1d9588e)
OpenGL core profile shading language version string: 4.50
OpenGL core profile context flags: (none)
OpenGL core profile profile mask: core profile
OpenGL core profile extensions:
OpenGL version string: 3.0 Mesa 18.1.0-devel (git-b3a1d9588e)
OpenGL shading language version string: 1.30
OpenGL context flags: (none)
OpenGL extensions:
OpenGL ES profile version string: OpenGL ES 3.1 Mesa 18.1.0-devel
(git-b3a1d9588e)
OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.10
OpenGL ES profile extensions:

To be more specific, my LLVM is from SVN revision 321389

As for the Terra crash: It seems the build didn't pick rapidjson, so there's no
JSON material support.
Place rapidjson into /Dependencies/include/rapidjson folder (create
it if it doesn't exist) so that the header lies at
/Dependencies/include/rapidjson/rapidjson.h

To avoid any potential problem just grab rapidjson files from here:
https://bitbucket.org/cabalistic/ogredeps/src/d0f0609a769a5a4a5824256280e07b3a72637a63/src/rapidjson/include/?at=default

Then run CMake again on Ogre so that it picks up rapidjson and build again.

-- 
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: [Intel-gfx] [PATCH v3 05/10] drm/i915/psr/cnl: Enable Y-coordinate support in source

[Pandiyan, Dhinakaran]

On Wed, 2018-03-28 at 15:30 -0700, José Roberto de Souza wrote:
> For Geminilake and Cannonlake+ the Y-coordinate support must be
> enabled in PSR2_CTL too.
> 
> Spec: 7713 and 7720
> 
> Cc: Dhinakaran Pandiyan 
> Reviewed-by: Rodrigo Vivi 
> Signed-off-by: José Roberto de Souza 
> ---
> 
> v3: rebased
> 
>  drivers/gpu/drm/i915/i915_reg.h  |  3 +++
>  drivers/gpu/drm/i915/intel_psr.c | 16 
>  2 files changed, 15 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 33e52cc98d99..9d61ab1288d3 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -4058,6 +4058,8 @@ enum {
>  #define EDP_PSR2_CTL _MMIO(0x6f900)
>  #define   EDP_PSR2_ENABLE(1<<31)
>  #define   EDP_SU_TRACK_ENABLE(1<<30)
> +#define   EDP_Y_COORDINATE_VALID (1<<26) /* GLK and CNL+ */
> +#define   EDP_Y_COORDINATE_ENABLE(1<<25) /* GLK and CNL+ */
>  #define   EDP_MAX_SU_DISABLE_TIME(t) ((t)<<20)
>  #define   EDP_MAX_SU_DISABLE_TIME_MASK   (0x1f<<20)
>  #define   EDP_PSR2_TP2_TIME_500  (0<<8)
> @@ -7064,6 +7066,7 @@ enum {
>  #define CHICKEN_TRANS_A 0x420c0
>  #define CHICKEN_TRANS_B 0x420c4
>  #define CHICKEN_TRANS(trans) _MMIO_TRANS(trans, CHICKEN_TRANS_A, 
> CHICKEN_TRANS_B)
> +#define  VSC_DATA_SEL_SOFTWARE_CONTROL   (1<<25) /* GLK and CNL+ */
>  #define  DDI_TRAINING_OVERRIDE_ENABLE(1<<19)
>  #define  DDI_TRAINING_OVERRIDE_VALUE (1<<18)
>  #define  DDIE_TRAINING_OVERRIDE_ENABLE   (1<<17) /* CHICKEN_TRANS_A only 
> */
> diff --git a/drivers/gpu/drm/i915/intel_psr.c 
> b/drivers/gpu/drm/i915/intel_psr.c
> index fb2d0fe7106b..84e1f8be5c48 100644
> --- a/drivers/gpu/drm/i915/intel_psr.c
> +++ b/drivers/gpu/drm/i915/intel_psr.c
> @@ -386,8 +386,10 @@ static void hsw_activate_psr2(struct intel_dp *intel_dp)
>   /* FIXME: selective update is probably totally broken because it doesn't
>* mesh at all with our frontbuffer tracking. And the hw alone isn't
>* good enough. */
> - val |= EDP_PSR2_ENABLE |
> - EDP_SU_TRACK_ENABLE;
> + val |= EDP_PSR2_ENABLE | EDP_SU_TRACK_ENABLE;
> + if (INTEL_GEN(dev_priv) >= 10 || IS_GEMINILAKE(dev_priv)) {
> + val |= EDP_Y_COORDINATE_VALID | EDP_Y_COORDINATE_ENABLE;

Bspecs says Bit 26 : Y-coordinate valid
1b stands for "Do not include Y-coordinate valid eDP 1.4".

Was "val |= EDP_Y_COORDINATE_VALID" intended?


> + }
>  
>   if (drm_dp_dpcd_readb(_dp->aux,
>   DP_SYNCHRONIZATION_LATENCY_IN_SINK,
> @@ -569,8 +571,14 @@ static void hsw_psr_enable_source(struct intel_dp 
> *intel_dp,
>   hsw_psr_setup_aux(intel_dp);
>  
>   if (dev_priv->psr.psr2_support) {
> - u32 chicken = PSR2_VSC_ENABLE_PROG_HEADER
> -   | PSR2_ADD_VERTICAL_LINE_COUNT;
> + u32 chicken = I915_READ(CHICKEN_TRANS(cpu_transcoder));
> +
> + if (INTEL_GEN(dev_priv) == 9 && !IS_GEMINILAKE(dev_priv))
> + chicken |= (PSR2_VSC_ENABLE_PROG_HEADER
> +| PSR2_ADD_VERTICAL_LINE_COUNT);
> +
> + else
> + chicken &= ~VSC_DATA_SEL_SOFTWARE_CONTROL;
>   I915_WRITE(CHICKEN_TRANS(cpu_transcoder), chicken);
>  
>   I915_WRITE(EDP_PSR_DEBUG,
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 105819] Window system hang due to GPU Fault

[bugzilla-daemon]

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

Bug ID: 105819
   Summary: Window system hang due to GPU Fault
   Product: DRI
   Version: unspecified
  Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
  Severity: normal
  Priority: medium
 Component: DRM/AMDgpu
  Assignee: dri-devel@lists.freedesktop.org
  Reporter: hjpries...@gmail.com

Created attachment 138449
  --> https://bugs.freedesktop.org/attachment.cgi?id=138449=edit
dmesg output with the GPU fault.

When displaying a "png" with Image magick display the system quite often hangs.
Screen is not updated, X can not be terminated.

In dmesg I got this error:

[ 1338.134608] amdgpu :20:00.0: GPU fault detected: 147 0x03684402
[ 1338.134611] amdgpu :20:00.0:   VM_CONTEXT1_PROTECTION_FAULT_ADDR  
0x0050
306D
[ 1338.134614] amdgpu :20:00.0:   VM_CONTEXT1_PROTECTION_FAULT_STATUS
0x0C04
4002
[ 1338.134618] amdgpu :20:00.0: VM fault (0x02, vmid 6, pasid 32773) at
page
 5255277, read from 'TC1' (0x54433100) (68)
[ 1348.576412] [drm:amdgpu_job_timedout [amdgpu]] *ERROR* ring gfx timeout,
last
 signaled seq=20984, last emitted seq=20986
[ 1348.576423] [drm] IP block:gfx_v8_0 is hung!
[ 1348.576472] [drm] GPU recovery disabled.

I could login using ssh but could not kill X. 

I was using the "drm-next-4.17wip" from 29/03/2018 but the problem also happens
with 4.15.X
Full dmesg is attached.

-- 
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] drm/i915: Promote .format_mod_supported() to the lead role

[Eric Anholt]

Ville Syrjala  writes:

> From: Ville Syrjälä 
>
> Up to now we've used the plane's modifier list as the primary
> source of information for which modifiers are supported by a
> given plane. In order to allow auxiliary metadata to be embedded
> within the bits of the modifier we need to stop doing that.
>
> Thus we have to make .format_mod_supported() aware of the plane's
> capabilities and gracefully deal with any modifier being passed
> in directly from userspace.

I took a look, and I think you have the chance to delete a whole ton of
code if you keep the assumption that the core will check that the format
is one of plane->format_types.

>
> Cc: Eric Anholt 
> References: 
> https://lists.freedesktop.org/archives/dri-devel/2018-March/169782.html
> Signed-off-by: Ville Syrjälä 
> ---
>  drivers/gpu/drm/i915/intel_display.c | 147 +++---
>  drivers/gpu/drm/i915/intel_drv.h |   1 +
>  drivers/gpu/drm/i915/intel_sprite.c  | 194 
> ++-
>  3 files changed, 210 insertions(+), 132 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_display.c 
> b/drivers/gpu/drm/i915/intel_display.c
> index 3e7ab75e1b41..d717004be0b8 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -88,15 +88,7 @@ static const uint32_t skl_primary_formats[] = {
>   DRM_FORMAT_VYUY,
>  };
>  
> -static const uint64_t skl_format_modifiers_noccs[] = {
> - I915_FORMAT_MOD_Yf_TILED,
> - I915_FORMAT_MOD_Y_TILED,
> - I915_FORMAT_MOD_X_TILED,
> - DRM_FORMAT_MOD_LINEAR,
> - DRM_FORMAT_MOD_INVALID
> -};
> -
> -static const uint64_t skl_format_modifiers_ccs[] = {
> +static const uint64_t skl_format_modifiers[] = {
>   I915_FORMAT_MOD_Yf_TILED_CCS,
>   I915_FORMAT_MOD_Y_TILED_CCS,
>   I915_FORMAT_MOD_Yf_TILED,
> @@ -12997,8 +12989,17 @@ void intel_plane_destroy(struct drm_plane *plane)
>   kfree(to_intel_plane(plane));
>  }
>  
> -static bool i8xx_mod_supported(uint32_t format, uint64_t modifier)
> +static bool i8xx_plane_format_mod_supported(struct drm_plane *_plane,
> + u32 format, u64 modifier)
>  {
> + switch (modifier) {
> + case DRM_FORMAT_MOD_LINEAR:
> + case I915_FORMAT_MOD_X_TILED:
> + break;
> + default:
> + return false;
> + }
> +

I think you could just remove the format-dependent switch below in favor
of s/break/return true/.  It's just a list of all the formats in
i8xx_primary_formats[].

>   switch (format) {
>   case DRM_FORMAT_C8:
>   case DRM_FORMAT_RGB565:
> @@ -13011,8 +13012,17 @@ static bool i8xx_mod_supported(uint32_t format, 
> uint64_t modifier)
>   }
>  }
>  
> -static bool i965_mod_supported(uint32_t format, uint64_t modifier)
> +static bool i965_plane_format_mod_supported(struct drm_plane *_plane,
> + u32 format, u64 modifier)
>  {
> + switch (modifier) {
> + case DRM_FORMAT_MOD_LINEAR:
> + case I915_FORMAT_MOD_X_TILED:
> + break;
> + default:
> + return false;
> + }

Again, there's no format dependence, so drop the switch statement, and
probably just reuse the mod_supported func from 8xx.

> +
>   switch (format) {
>   case DRM_FORMAT_C8:
>   case DRM_FORMAT_RGB565:
> @@ -13027,17 +13037,37 @@ static bool i965_mod_supported(uint32_t format, 
> uint64_t modifier)
>   }
>  }
>  
> -static bool skl_mod_supported(uint32_t format, uint64_t modifier)
> +static bool skl_plane_format_mod_supported(struct drm_plane *_plane,
> +u32 format, u64 modifier)
>  {
> + struct intel_plane *plane = to_intel_plane(_plane);
> +
> + switch (modifier) {
> + case DRM_FORMAT_MOD_LINEAR:
> + case I915_FORMAT_MOD_X_TILED:
> + case I915_FORMAT_MOD_Y_TILED:
> + case I915_FORMAT_MOD_Yf_TILED:
> + break;
> + case I915_FORMAT_MOD_Y_TILED_CCS:
> + case I915_FORMAT_MOD_Yf_TILED_CCS:
> + if (!plane->has_ccs)
> + return false;
> + break;
> + default:
> + return false;
> + }
> +
>   switch (format) {
>   case DRM_FORMAT_XRGB:
>   case DRM_FORMAT_XBGR:
>   case DRM_FORMAT_ARGB:
>   case DRM_FORMAT_ABGR:
> - if (modifier == I915_FORMAT_MOD_Yf_TILED_CCS ||
> - modifier == I915_FORMAT_MOD_Y_TILED_CCS)
> - return true;
> - /* fall through */

I think these SKL changes could have just been done with a "&&
plane->has_ccs" in this '-' area.  I do think the new version is more
readable, though.

> + return modifier == DRM_FORMAT_MOD_LINEAR ||
> + modifier == I915_FORMAT_MOD_X_TILED ||
> + modifier == I915_FORMAT_MOD_Y_TILED ||

[Bug 105725] WARNING: CPU: 0 PID: 487 at drivers/gpu/drm/amd/amdgpu/../display /dc/gpio/gpio_base.c:64 dal_gpio_open_ex+0xc/0x30 [amdgpu]

[bugzilla-daemon]

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

--- Comment #5 from hjpries...@gmail.com ---
Created attachment 138448
  --> https://bugs.freedesktop.org/attachment.cgi?id=138448=edit
dmesg of  drm-next-4.17-wip (date of clone 2018-03-29)

-- 
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] drm/amd/display: fix spelling mistake: "Usupported" -> "Unsupported"

[Colin King]

From: Colin Ian King 

Trivial fix to spelling mistake in DRM_ERROR error message text

Signed-off-by: Colin Ian King 
---
 drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c 
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index e42a28e3adc5..1df1c91b6ae5 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -1521,7 +1521,7 @@ static int amdgpu_dm_initialize_drm_device(struct 
amdgpu_device *adev)
break;
 #endif
default:
-   DRM_ERROR("Usupported ASIC type: 0x%X\n", adev->asic_type);
+   DRM_ERROR("Unsupported ASIC type: 0x%X\n", adev->asic_type);
goto fail;
}
 
@@ -1715,7 +1715,7 @@ static int dm_early_init(void *handle)
break;
 #endif
default:
-   DRM_ERROR("Usupported ASIC type: 0x%X\n", adev->asic_type);
+   DRM_ERROR("Unsupported ASIC type: 0x%X\n", adev->asic_type);
return -EINVAL;
}
 
-- 
2.15.1

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

Re: [PATCH v2 3/4] drm/vc4: Add color transformation matrix (CTM) support

[Eric Anholt]

Stefan Schake  writes:

> The hardware supports a CTM with S0.9 values. We therefore only allow
> a value of 1.0 or fractional only and reject all others with integer
> parts. This restriction is mostly inconsequential in practice since
> commonly used transformation matrices have all scalars <= 1.0.
>
> Signed-off-by: Stefan Schake 

My primary concern with this patch is whether the OLEDCOEFFs apply
before or after gamma, since atomic is specific about what order they
happen in.  I didn't find anything in the docs, so I'd have to pull up
RTL to confirm.

> ---
> v2: Simplify CTM atomic check (Ville)
>
>  drivers/gpu/drm/vc4/vc4_crtc.c | 97 
> --
>  1 file changed, 94 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/vc4/vc4_crtc.c b/drivers/gpu/drm/vc4/vc4_crtc.c
> index 8d71098d00c4..bafb0102fe1d 100644
> --- a/drivers/gpu/drm/vc4/vc4_crtc.c
> +++ b/drivers/gpu/drm/vc4/vc4_crtc.c
> @@ -315,6 +315,79 @@ vc4_crtc_update_gamma_lut(struct drm_crtc *crtc)
>   vc4_crtc_lut_load(crtc);
>  }
>  
> +/* Converts a DRM S31.32 value to the HW S0.9 format. */
> +static u16 vc4_crtc_s31_32_to_s0_9(u64 in)
> +{
> + u16 r;
> +
> + /* Sign bit. */
> + r = in & BIT_ULL(63) ? BIT(9) : 0;
> + /* We have zero integer bits so we can only saturate here. */
> + if ((in & GENMASK_ULL(62, 32)) > 0)
> + r |= GENMASK(8, 0);
> + /* Otherwise take the 9 most important fractional bits. */
> + else
> + r |= (in >> 22) & GENMASK(8, 0);
> + return r;
> +}
> +
> +static void
> +vc4_crtc_update_ctm(struct drm_crtc *crtc)
> +{
> + struct drm_device *dev = crtc->dev;
> + struct vc4_dev *vc4 = to_vc4_dev(dev);
> + struct vc4_crtc *vc4_crtc = to_vc4_crtc(crtc);
> + struct drm_color_ctm *ctm = crtc->state->ctm->data;
> +
> + HVS_WRITE(SCALER_OLEDCOEF2,
> +   VC4_SET_FIELD(vc4_crtc_s31_32_to_s0_9(ctm->matrix[0]),
> + SCALER_OLEDCOEF2_R_TO_R) |
> +   VC4_SET_FIELD(vc4_crtc_s31_32_to_s0_9(ctm->matrix[3]),
> + SCALER_OLEDCOEF2_R_TO_G) |
> +   VC4_SET_FIELD(vc4_crtc_s31_32_to_s0_9(ctm->matrix[6]),
> + SCALER_OLEDCOEF2_R_TO_B));
> + HVS_WRITE(SCALER_OLEDCOEF1,
> +   VC4_SET_FIELD(vc4_crtc_s31_32_to_s0_9(ctm->matrix[1]),
> + SCALER_OLEDCOEF1_G_TO_R) |
> +   VC4_SET_FIELD(vc4_crtc_s31_32_to_s0_9(ctm->matrix[4]),
> + SCALER_OLEDCOEF1_G_TO_G) |
> +   VC4_SET_FIELD(vc4_crtc_s31_32_to_s0_9(ctm->matrix[7]),
> + SCALER_OLEDCOEF1_G_TO_B));
> + HVS_WRITE(SCALER_OLEDCOEF0,
> +   VC4_SET_FIELD(vc4_crtc_s31_32_to_s0_9(ctm->matrix[2]),
> + SCALER_OLEDCOEF0_B_TO_R) |
> +   VC4_SET_FIELD(vc4_crtc_s31_32_to_s0_9(ctm->matrix[5]),
> + SCALER_OLEDCOEF0_B_TO_G) |
> +   VC4_SET_FIELD(vc4_crtc_s31_32_to_s0_9(ctm->matrix[8]),
> + SCALER_OLEDCOEF0_B_TO_B));
> +
> + /* Channel is 0-based but for DISPFIFO, 0 means disabled. */
> + HVS_WRITE(SCALER_OLEDOFFS, VC4_SET_FIELD(vc4_crtc->channel + 1,
> +  SCALER_OLEDOFFS_DISPFIFO));
> +}
> +
> +/* Check if the CTM contains valid input.
> + *
> + * DRM exposes CTM with S31.32 scalars, but the HW only supports S0.9.
> + * We don't allow integer values >1, and 1 only without fractional part
> + * to handle the common 1.0 value.
> + */
> +static int vc4_crtc_atomic_check_ctm(struct drm_crtc_state *state)
> +{
> + struct drm_color_ctm *ctm = state->ctm->data;
> + u32 i;
> +
> + for (i = 0; i < ARRAY_SIZE(ctm->matrix); i++) {
> + u64 val = ctm->matrix[i];
> +
> + val &= ~BIT_ULL(63);
> + if (val > BIT_ULL(32))
> + return -EINVAL;
> + }
> +
> + return 0;
> +}
> +
>  static u32 vc4_get_fifo_full_level(u32 format)
>  {
>   static const u32 fifo_len_bytes = 64;
> @@ -621,6 +694,15 @@ static int vc4_crtc_atomic_check(struct drm_crtc *crtc,
>   if (hweight32(state->connector_mask) > 1)
>   return -EINVAL;
>  
> + if (state->ctm) {
> + /* The CTM hardware has no integer bits, so we check
> +  * and reject scalars >1.0 that we have no chance of
> +  * approximating.
> +  */
> + if (vc4_crtc_atomic_check_ctm(state))
> + return -EINVAL;
> + }
> +
>   drm_atomic_crtc_state_for_each_plane_state(plane, plane_state, state)
>   dlist_count += vc4_plane_dlist_size(plane_state);
>  
> @@ -697,8 +779,17 @@ static void vc4_crtc_atomic_flush(struct drm_crtc *crtc,
>   if (crtc->state->active && old_state->active)
>   vc4_crtc_update_dlist(crtc);
>  
> - if 

[Bug 105218] Regresion in 847d0a393d7f0f967f39302900d5330f32b804c8

[bugzilla-daemon]

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

--- Comment #4 from Matias N. Goldberg  ---
This is an example of how JSON settings look in my CMake setup:

https://i.imgur.com/mj77iEz.png

-- 
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] MAINTAINERS: drm: fsl-dcu: Update to NXP email address

[Fabio Estevam]

From: Fabio Estevam 

The freescale.com domain will stop working soon, so use
the nxp.com domain instead.

Signed-off-by: Fabio Estevam 
---
 MAINTAINERS | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index 4923621..794c130 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -4661,7 +4661,7 @@ F:
Documentation/devicetree/bindings/display/exynos/
 
 DRM DRIVERS FOR FREESCALE DCU
 M: Stefan Agner 
-M: Alison Wang 
+M: Alison Wang 
 L: dri-devel@lists.freedesktop.org
 S: Supported
 F: drivers/gpu/drm/fsl-dcu/
-- 
2.7.4

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

[Bug 199101] AMDGPU Fury X random screen flicker on Linux kernel 4.16rc5

[bugzilla-daemon]

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

Samuel Grahn (samuel.gr...@outlook.com) changed:

   What|Removed |Added

 CC||samuel.gr...@outlook.com

--- Comment #11 from Samuel Grahn (samuel.gr...@outlook.com) ---
I get the same issue on arch kernels: linux (4.15), linux-mainline, and from
linux-git(4.16rc6) on my Vega 64 when using both latest mesa-git (18) and
stable mesa (17) from arch repos.

It seemed not to appear when using fullscreen Vulkan rendering, pointing at GL
issues (right?), can examine further later.

Crosshair VI x370 mobo
Ryzen 1800X
16GB DDR4
STRIX Vega 64

-- 
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

[Bug 105725] WARNING: CPU: 0 PID: 487 at drivers/gpu/drm/amd/amdgpu/../display /dc/gpio/gpio_base.c:64 dal_gpio_open_ex+0xc/0x30 [amdgpu]

[bugzilla-daemon]

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

--- Comment #4 from hjpries...@gmail.com ---
Harry,

I have build a kernel using the:

git clone -b drm-next-4.17-wip git://people.freedesktop.org/~agd5f/linux

I did the clone about 2018-29-03 20:00 UTC  

The warnings are still there.
root@hjp2:~# dmesg | grep -i Warning
[0.00] ACPI BIOS Warning (bug): Optional FADT field Pm2ControlBlock has
valid Length but zero Address: 0x/0x1 (20180105/tbfadt-658)
[5.351226] WARNING: CPU: 1 PID: 491 at
drivers/gpu/drm/amd/amdgpu/../display/dc/gpio/gpio_base.c:64
dal_gpio_open_ex+0xc/0x30 [amdgpu]
[5.353376] WARNING: CPU: 1 PID: 491 at
drivers/gpu/drm/amd/amdgpu/../display/dc/gpio/gpio_service.c:487
dal_ddc_open+0x2c/0xd0 [amdgpu]

I never get the hang during a boot. I will report that as a separate bug.

The display I am using is a IIYama Prolite XUB2792QSU using Displayport.
It it a 27" 2560x1440 monitor.
The distrubution is Slackware-current. ("pre 15.0")

-- 
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: [Intel-gfx] [PATCH v3 09/10] drm/i915/psr: Set DPCD PSR2 enable bit when needed

[Rodrigo Vivi]

On Wed, Mar 28, 2018 at 03:30:45PM -0700, José Roberto de Souza wrote:
> In the 2 eDP1.4a pannels tested set or not set bit have no effect
> but is better set it and comply with specification.
> 
> Signed-off-by: José Roberto de Souza 
> Cc: Dhinakaran Pandiyan 
> Reviewed-by: Rodrigo Vivi 

patches 1-9 pushed to dinq. Thanks for patches and reviews.

> ---
> 
> v3: rebased
> 
>  drivers/gpu/drm/i915/intel_psr.c | 11 ++-
>  1 file changed, 6 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_psr.c 
> b/drivers/gpu/drm/i915/intel_psr.c
> index d079cf0b034c..2d53f7398a6d 100644
> --- a/drivers/gpu/drm/i915/intel_psr.c
> +++ b/drivers/gpu/drm/i915/intel_psr.c
> @@ -278,18 +278,19 @@ static void hsw_psr_enable_sink(struct intel_dp 
> *intel_dp)
>   struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp);
>   struct drm_device *dev = dig_port->base.base.dev;
>   struct drm_i915_private *dev_priv = to_i915(dev);
> + u8 dpcd_val = DP_PSR_ENABLE;
>  
>   /* Enable ALPM at sink for psr2 */
>   if (dev_priv->psr.psr2_enabled && dev_priv->psr.alpm)
>   drm_dp_dpcd_writeb(_dp->aux,
>   DP_RECEIVER_ALPM_CONFIG,
>   DP_ALPM_ENABLE);
> +
> + if (dev_priv->psr.psr2_enabled)
> + dpcd_val |= DP_PSR_ENABLE_PSR2;
>   if (dev_priv->psr.link_standby)
> - drm_dp_dpcd_writeb(_dp->aux, DP_PSR_EN_CFG,
> -DP_PSR_ENABLE | DP_PSR_MAIN_LINK_ACTIVE);
> - else
> - drm_dp_dpcd_writeb(_dp->aux, DP_PSR_EN_CFG,
> -DP_PSR_ENABLE);
> + dpcd_val |= DP_PSR_MAIN_LINK_ACTIVE;
> + drm_dp_dpcd_writeb(_dp->aux, DP_PSR_EN_CFG, dpcd_val);
>  
>   drm_dp_dpcd_writeb(_dp->aux, DP_SET_POWER, DP_SET_POWER_D0);
>  }
> -- 
> 2.16.3
> 
> ___
> Intel-gfx mailing list
> intel-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Intel-gfx] [PATCH v3 05/10] drm/i915/psr/cnl: Enable Y-coordinate support in source

[Souza, Jose]

On Fri, 2018-03-30 at 10:36 -0700, Pandiyan, Dhinakaran wrote:
> 
> 
> On Wed, 2018-03-28 at 15:30 -0700, José Roberto de Souza wrote:
> > For Geminilake and Cannonlake+ the Y-coordinate support must be
> > enabled in PSR2_CTL too.
> > 
> > Spec: 7713 and 7720
> > 
> > Cc: Dhinakaran Pandiyan 
> > Reviewed-by: Rodrigo Vivi 
> > Signed-off-by: José Roberto de Souza 
> > ---
> > 
> > v3: rebased
> > 
> >  drivers/gpu/drm/i915/i915_reg.h  |  3 +++
> >  drivers/gpu/drm/i915/intel_psr.c | 16 
> >  2 files changed, 15 insertions(+), 4 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/i915_reg.h
> > b/drivers/gpu/drm/i915/i915_reg.h
> > index 33e52cc98d99..9d61ab1288d3 100644
> > --- a/drivers/gpu/drm/i915/i915_reg.h
> > +++ b/drivers/gpu/drm/i915/i915_reg.h
> > @@ -4058,6 +4058,8 @@ enum {
> >  #define EDP_PSR2_CTL   _MMIO(0x6f900)
> >  #define   EDP_PSR2_ENABLE  (1<<31)
> >  #define   EDP_SU_TRACK_ENABLE  (1<<30)
> > +#define   EDP_Y_COORDINATE_VALID   (1<<26) /* GLK and CNL+ */
> > +#define   EDP_Y_COORDINATE_ENABLE  (1<<25) /* GLK and CNL+
> > */
> >  #define   EDP_MAX_SU_DISABLE_TIME(t)   ((t)<<20)
> >  #define   EDP_MAX_SU_DISABLE_TIME_MASK (0x1f<<20)
> >  #define   EDP_PSR2_TP2_TIME_500(0<<8)
> > @@ -7064,6 +7066,7 @@ enum {
> >  #define CHICKEN_TRANS_A 0x420c0
> >  #define CHICKEN_TRANS_B 0x420c4
> >  #define CHICKEN_TRANS(trans) _MMIO_TRANS(trans, CHICKEN_TRANS_A,
> > CHICKEN_TRANS_B)
> > +#define  VSC_DATA_SEL_SOFTWARE_CONTROL (1<<25) /* GLK and
> > CNL+ */
> >  #define  DDI_TRAINING_OVERRIDE_ENABLE  (1<<19)
> >  #define  DDI_TRAINING_OVERRIDE_VALUE   (1<<18)
> >  #define  DDIE_TRAINING_OVERRIDE_ENABLE (1<<17) /*
> > CHICKEN_TRANS_A only */
> > diff --git a/drivers/gpu/drm/i915/intel_psr.c
> > b/drivers/gpu/drm/i915/intel_psr.c
> > index fb2d0fe7106b..84e1f8be5c48 100644
> > --- a/drivers/gpu/drm/i915/intel_psr.c
> > +++ b/drivers/gpu/drm/i915/intel_psr.c
> > @@ -386,8 +386,10 @@ static void hsw_activate_psr2(struct intel_dp
> > *intel_dp)
> > /* FIXME: selective update is probably totally broken
> > because it doesn't
> >  * mesh at all with our frontbuffer tracking. And the hw
> > alone isn't
> >  * good enough. */
> > -   val |= EDP_PSR2_ENABLE |
> > -   EDP_SU_TRACK_ENABLE;
> > +   val |= EDP_PSR2_ENABLE | EDP_SU_TRACK_ENABLE;
> > +   if (INTEL_GEN(dev_priv) >= 10 || IS_GEMINILAKE(dev_priv))
> > {
> > +   val |= EDP_Y_COORDINATE_VALID |
> > EDP_Y_COORDINATE_ENABLE;
> 
> Bspecs says Bit 26 : Y-coordinate valid
> 1b stands for "Do not include Y-coordinate valid eDP 1.4".
> 
> Was "val |= EDP_Y_COORDINATE_VALID" intended?

Hum not intended, I will send a patch fixing it.
Thanks

> 
> 
> > +   }
> >  
> > if (drm_dp_dpcd_readb(_dp->aux,
> > DP_SYNCHRONIZATION_LATENCY_IN_SINK
> > ,
> > @@ -569,8 +571,14 @@ static void hsw_psr_enable_source(struct
> > intel_dp *intel_dp,
> > hsw_psr_setup_aux(intel_dp);
> >  
> > if (dev_priv->psr.psr2_support) {
> > -   u32 chicken = PSR2_VSC_ENABLE_PROG_HEADER
> > - | PSR2_ADD_VERTICAL_LINE_COUNT;
> > +   u32 chicken =
> > I915_READ(CHICKEN_TRANS(cpu_transcoder));
> > +
> > +   if (INTEL_GEN(dev_priv) == 9 &&
> > !IS_GEMINILAKE(dev_priv))
> > +   chicken |= (PSR2_VSC_ENABLE_PROG_HEADER
> > +  |
> > PSR2_ADD_VERTICAL_LINE_COUNT);
> > +
> > +   else
> > +   chicken &= ~VSC_DATA_SEL_SOFTWARE_CONTROL;
> > I915_WRITE(CHICKEN_TRANS(cpu_transcoder),
> > chicken);
> >  
> > I915_WRITE(EDP_PSR_DEBUG,
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

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

[Eric Anholt]

Boris Brezillon  writes:

> From: Gustavo Padovan 
>
> Add support for 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.

My r-b still applies with your fixes here.  Go ahead and push when
you're ready.


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

Re: [PATCH] drm/atomic: Add sanity checks to drm_atomic_helper_async_commit()

[Eric Anholt]

Boris Brezillon  writes:

> ->atomic_async_update() requires that drivers update the plane->state
> object before returning. Make sure at least common properties have been
> updated.
>
> Cc: Gustavo Padovan 
> Signed-off-by: Boris Brezillon 
> ---
> Hello,
>
> This is a problem I had when debugging the VC4 ->atomic_async_update()
> implementation. The function was not updating plane->fb as it's
> supposed thus leaving plane->state->fb in an inconsistent state after
> each async update.
>
> Not sure if such WARN_ON_ONCE() are accepted in the core though, so
> I'll maintainers decide whether this is relevant or not and whether
> they prefer to have WARN_ON() or DRM_ERROR() messages.

I'm a huge fan of this kind of safety check.  FWIW,

Acked-by: Eric Anholt 


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

[Bug 105218] Regresion in 847d0a393d7f0f967f39302900d5330f32b804c8

[bugzilla-daemon]

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

--- Comment #6 from Timothy Arceri  ---
(In reply to Timothy Arceri from comment #5)
> Ok built it correctly this time.
> 
> No crash with Mesa git and LLVM 7 the sample runs fine on my RX580. Possible
> there is a bug in LLVM 6.

Ok I tested the LLVM 6.0.0 release with git master and that worked fine for me
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: [Intel-gfx] [PATCH v3 10/10] drm/i915/debugfs: Print sink PSR status

[Souza, Jose]

On Fri, 2018-03-30 at 11:28 -0700, Pandiyan, Dhinakaran wrote:
> On Wed, 2018-03-28 at 15:30 -0700, José Roberto de Souza wrote:
> > IGT tests could be improved with sink status, knowing for sure that
> > hardware have activate or exit PSR.
> > 
> > Cc: Dhinakaran Pandiyan 
> > Cc: Rodrigo Vivi 
> > Signed-off-by: José Roberto de Souza 
> > ---
> > 
> > v3: rebased
> > 
> >  drivers/gpu/drm/i915/i915_debugfs.c | 29
> > +
> >  1 file changed, 29 insertions(+)
> > 
> > diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
> > b/drivers/gpu/drm/i915/i915_debugfs.c
> > index 1dba2c451255..89dc5b05ec24 100644
> > --- a/drivers/gpu/drm/i915/i915_debugfs.c
> > +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> > @@ -2603,6 +2603,26 @@ static const char *psr2_live_status(u32 val)
> > return "unknown";
> >  }
> >  
> > +static const char *psr_sink_self_refresh_status(u8 val)
> 
> nit:   psr_sink_status() is concise,
> "psr_self_refresh" sounds
> redundant.
> 
> > +{
> > +   static const char * const sink_status[] = {
> > +   "inactive",
> > +   "transitioning to active",
> 
> We muddle the meaning of these statuses by paraphrasing, it is better
> write these strings exactly as the states are defined in the spec.
> 
> > +   "active",
> > +   "active receiving selective update",
> 
> For example, this state corresponds to the capture of full static
> frame
> too.


It is fine this way?

static const char * const sink_status[] = {
"inactive",
"transition to active, capture and display",
"active, display from RFB",
"active, capture and display on sink device timings",
"transition to inactive, capture and display, timing
re-sync",
"reserved",
"reserved",
"sink internal error"
};


> 
> 
> Reviewed-by: Dhinakaran Pandiyan  with
> the nits addressed, thanks for the patch.
> 
> > +   "transitioning to inactive",
> > +   "reserved",
> > +   "reserved",
> > +   "sink internal error"
> > +   };
> > +
> > +   val &= DP_PSR_SINK_STATE_MASK;
> > +   if (val < ARRAY_SIZE(sink_status))
> > +   return sink_status[val];
> > +
> > +   return "unknown";
> > +}
> > +
> >  static int i915_edp_psr_status(struct seq_file *m, void *data)
> >  {
> > struct drm_i915_private *dev_priv = node_to_i915(m-
> > >private);
> > @@ -2684,6 +2704,15 @@ static int i915_edp_psr_status(struct
> > seq_file *m, void *data)
> > seq_printf(m, "EDP_PSR2_STATUS: %x [%s]\n",
> >psr2, psr2_live_status(psr2));
> > }
> > +
> > +   if (dev_priv->psr.enabled) {
> > +   struct drm_dp_aux *aux = _priv->psr.enabled-
> > >aux;
> > +   u8 val;
> > +
> > +   if (drm_dp_dpcd_readb(aux, DP_PSR_STATUS, ) ==
> > 1)
> > +   seq_printf(m, "Sink self refresh status:
> > 0x%x [%s]\n",
> > +  val,
> > psr_sink_self_refresh_status(val));
> > +   }
> > mutex_unlock(_priv->psr.lock);
> >  
> > intel_runtime_pm_put(dev_priv);
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel